summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Move vma lookup to its own lockChris Wilson2019-01-286-58/+98
| | | | | | | | | | | | Remove the struct_mutex requirement for looking up the vma for an object. v2: Highlight how the race for duplicate vma creation is resolved on reacquiring the lock with a short comment. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128102356.15037-3-chris@chris-wilson.co.uk
* drm/i915: Pull VM lists under the VM mutex.Chris Wilson2019-01-288-8/+46
| | | | | | | | | | | | | A starting point to counter the pervasive struct_mutex. For the goal of avoiding (or at least blocking under them!) global locks during user request submission, a simple but important step is being able to manage each clients GTT separately. For which, we want to replace using the struct_mutex as the guard for all things GTT/VM and switch instead to a specific mutex inside i915_address_space. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128102356.15037-2-chris@chris-wilson.co.uk
* drm/i915: Stop tracking MRU activity on VMAChris Wilson2019-01-2810-111/+95Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracking is less agreeable. One solution is not to do any MRU tracking and do a simple coarse evaluation during eviction of active/inactive, with a loose temporal ordering of last insertion/evaluation. That keeps all the locking constrained to when we are manipulating the VM itself, neatly avoiding the tricky handling of possible recursive locking during execbuf and elsewhere. Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search) is unlikely to impact upon our efficiency to reclaim VM space (where we think a LRU model is best) as our current strategy is to use random idle replacement first before doing a search, and over time the use of softpinned 48b per-ppGTT is growing (thereby eliminating any need to perform any eviction searches, in theory at least) with the remaining users being found on much older devices (gen2-gen6). v2: Changelog and commentary rewritten to elaborate on the duality of a single list being both an inactive and active list. v3: Consolidate bool parameters into a single set of flags; don't comment on the duality of a single variable being a multiplicity of bits. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128102356.15037-1-chris@chris-wilson.co.uk
* drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSenVille Syrjälä2019-01-281-6/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
* drm/i915/tv: Use the scanline counter for timestamps on i965gm TV outputVille Syrjälä2019-01-283-3/+18
| | | | | | | | | | | | | | Just like the frame counter, the pixel counter also reads zero all the time when the TV encoder is used. Fortunately the scanline counter still works sufficiently well so let's use that to correct the vblank timestamps. Otherwise the timestamps may en up out of whack, and since we use them to guesstimate the vblank counter value that may end up incorrect as well. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125181931.19482-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Fix return value for intel_tv_compute_config()Ville Syrjälä2019-01-281-1/+1
| | | | | | | | | | | | | | Ever since commit 204474a6b859 ("drm/i915: Pass down rc in intel_encoder->compute_config()") we're supposed to return an errno from .compute_config(). I failed to notice that when pushing the TV encoder fixes which were written before said commmit. Fix up the return value for the error case. Cc: Imre Deak <imre.deak@intel.com> Fixes: 690157f0a9e7 ("drm/i915/tv: Fix >1024 modes on gen3") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125181931.19482-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Wait for a moment before forcibly resetting the deviceChris Wilson2019-01-281-1/+2
| | | | | | | | | | | | | | | | | | During igt, we ask to reset the device if any requests are still outstanding at the end of a test, as this quickly kills off any erroneous hanging request streams that may escape a test. However, since it may take the device a few milliseconds to flush itself after the end of a normal test, *cough* guc *cough*, we may accidentally tell the device to reset itself after it idles. If we wait a moment, our usual I915_IDLE_ENGINES_TIMEOUT of 200ms (seems a bit high, but still better than umpteen hangchecks!), we can differentiate better between a stuck engine and a healthy one, and so avoid prematurely forcing the reset and any extra complications that may entail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128010245.20148-1-chris@chris-wilson.co.uk
* drm/i915: Disable -WuninitializedNathan Chancellor2019-01-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This warning is disabled by default in scripts/Makefile.extrawarn when W= is not provided but this Makefile adds -Wall after this warning is disabled so it shows up in the build when it shouldn't: In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895: drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error: variable 'wq' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq); ^~ ./include/linux/wait.h:74:63: note: expanded from macro 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK' struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) ~~~~ ^~~~ ./include/linux/wait.h:72:33: note: expanded from macro '__WAIT_QUEUE_HEAD_INIT_ONSTACK' ({ init_waitqueue_head(&name); name; }) ^~~~ 1 error generated. Explicitly disable the warning like commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings"). Link: https://github.com/ClangBuiltLinux/linux/issues/220 Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <nick.desaulniers@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190126071122.24557-1-natechancellor@gmail.com
* drm/i915: correct the pitch check for NV12 framebufferP Raviraj Sitaram2019-01-251-8/+0Star
| | | | | | | | | | | | | | | | | | | | | framebuffer for NV12 requires the pitch to the multiplier of 4, instead of the width. This patch corrects it. For instance, a 480p video, whose width and pitch are 854 and 896 respectively, is excluded for NV12 plane so far. Changes since v1: - Removed check for NV12 buffer dimensions since additional checks are done for viewport size in intel_sprite.c Signed-off-by: Dongseong Hwang <dongseong.hwang@intel.com> Signed-off-by: P Raviraj Sitaram <raviraj.p.sitaram@intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1545208152-22658-1-git-send-email-raviraj.p.sitaram@intel.com
* drm/i915: Clean up intel_plane_atomic_check_with_state()Ville Syrjälä2019-01-251-19/+17Star
| | | | | | | | | | Rename some of the state variables in intel_plane_atomic_check_with_state() to make it less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111170823.4441-2-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com>
* drm/i915/tv: Filter out >1024 wide modes that would need vertical scaling on ↵Ville Syrjälä2019-01-251-0/+6
| | | | | | | | | | | | | | gen3 Since gen3 can't handle >1024 wide sources with vertical scaling let's not advertize such modes in the mode list. Less tempetation to the user to try out things that won't work. v2: s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-17-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Fix >1024 modes on gen3Ville Syrjälä2019-01-251-8/+83
| | | | | | | | | | | | | | | | | | | | | | | | On gen3 we must disable the TV encoder vertical filter for >1024 pixel wide sources. Once that's done all we can is try to center the image on the screen. Naturally the TV mode vertical resolution must be equal or larger than the user mode vertical resolution or else we'd have to cut off part of the user mode. And while we may not be able to respect the user's choice of top and bottom borders exactly (or we'd have to reject he mode most likely), we can try to maintain the relative sizes of the top and bottom border with respect to each orher. Additionally we must configure the pipe as interlaced if the TV mode is interlaced. v2: Make +intel_tv_connector_duplicate_state() static and drop the badly copy pasted kerneldoc s/IS_GEN3(dev_priv/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-16-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Generate better pipe timings for TV encoderVille Syrjälä2019-01-252-45/+278
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To make vblank timestamps work better with the TV encoder let's scale the pipe timings such that the relationship between the TV active and TV blanking periods is mirrored in the corresponding pipe timings. Note that in reality the pipe runs at a faster speed during the TV vblank, and correspondigly there are periods when the pipe is enitrely stopped. We pretend that this isn't the case and as such we incur some error in the vblank timestamps during the TV vblank. Further explanation of the issues in a big comment in the code. This makes the vblank timestamps good enough to make i965gm (which doesn't have a working frame counter with the TV encoder) report correct frame numbers. Previously you could get all kinds of nonsense which resulted in eg. glxgears reporting that it's running at twice the actual framerate in most cases. v2: s/IS_GEN4(dev_priv)/IS_GEN(dev_priv, 4)/ in the comment for consistency Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-15-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Add 1080p30/50/60 TV modesVille Syrjälä2019-01-251-4/+86
| | | | | | | | | | | Add the missing 1080p TV modes. On gen4 all of them work just fine, whereas on gen3 only the 30Hz mode actually works correctly. v2: s/IS_GEN3(dev_priv)/IS_GEN(dev_priv, 3)/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-14-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Nuke reported_modes[]Ville Syrjälä2019-01-251-21/+1Star
| | | | | | | | | | | | Remove the silly reported_modes[] array. I suppse once upon a time this actually had something to do with modes we reported to userspace. Now it is just the placeholder for the mode we use for load detection. We don't need it even for that, and instead we can just rely on the fallback mode in intel_get_load_detect_pipe(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-13-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Make TV mode autoselection actually useableVille Syrjälä2019-01-251-5/+7
| | | | | | | | | | | The current code insists on picking a new TV mode when switching between component and non-component cables. That's super annoying. Let's just keep the current TV mode unless the new cable type actually disagrees with it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-12-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Use drm_mode_set_name() to name TV modesVille Syrjälä2019-01-251-10/+11
| | | | | | | | | | No point in storing the mode names in the array. drm_mode_set_name() will give us the same names without wasting space for these string constants. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-11-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Deobfuscate preferred mode selectionVille Syrjälä2019-01-251-20/+30
| | | | | | | | | | | Rewrite the preferred mode selection to just check whether the TV modes is HD or SD. For SD TV modes we favor 480 line modes, for 720p we prefer 720 line modes, and for 1080i/p we prefer 1080 line modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-10-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Nuke silly 0 initialzation of xpos/yposVille Syrjälä2019-01-251-3/+3
| | | | | | | | | Just assign the margin values directly to xpos/ypos instead of first initializing to zero and then adding the values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-8-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Use bools where appropriateVille Syrjälä2019-01-251-12/+12
| | | | | | | | 'component_only' is a bool. Initialize it like a bool. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Store the TV oversampling factor in the TV modeVille Syrjälä2019-01-251-14/+28
| | | | | | | | | | Store the oversampling factor as a number in the TV modes. We shall want to arithmetic with this which is easier if it's a number we can use directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Fix tv mode clocksVille Syrjälä2019-01-251-7/+7
| | | | | | | | | The oversample clock is always supposed to be either 108 MHz or 148.5 MHz. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/tv: Fix interlaced ysize calculationVille Syrjälä2019-01-251-1/+1
| | | | | | | | | Fix the calculation of the vertical active period for interlaced TV modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112170000.27531-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Don't try to use the hardware frame counter with i965gm TV outputVille Syrjälä2019-01-252-17/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by the TV encoder are also rather peculiar. Apparently the pipe wants to run at a much higher speed (related to the oversample clock somehow it seems) but during the vertical active period the TV encoder stalls the pipe every few lines to keep its speed in check. But once the vertical blanking period is reached the pipe gets to run at full speed. This means our vblank timestamp estimates are suspect. Fixing all that would require quite a bit more work. This simple fix at least avoids the nasty vblank timeouts that are happening currently. Curiously the frame counter works just fine on i945gm and gm45. I don't really understand what kind of mishap occurred with the hardware design on i965gm. Sadly I wasn't able to find any chicken bits etc. that would fix the frame counter :( v2: Move the zero vs. non-zero hw counter value handling into i915_get_vblank_counter() (Daniel) Use the per-crtc maximum exclusively, leaving the per-device maximum at zero v3: max_vblank_count not populated yet in intel_enable_pipe() use intel_crtc_max_vblank_count() instead Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190122125149.GE5527@ideak-desk.fi.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Issue engine resets onto idle enginesChris Wilson2019-01-252-20/+6Star
| | | | | | | | | | | Always perform the requested reset, even if we believe the engine is idle. Presumably there was a reason the caller wanted the reset, and in the near future we lose the easy tracking for whether the engine is idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-5-chris@chris-wilson.co.uk
* drm/i915/selftests: Trim struct_mutex duration for set-wedged selftestChris Wilson2019-01-251-3/+4
| | | | | | | | | | | Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-4-chris@chris-wilson.co.uk
* drm/i915: Remove GPU reset dependence on struct_mutexChris Wilson2019-01-2520-537/+404Star
| | | | | | | | | | | | | | | | | Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend independently. The major change is around the backoff/handoff strategy for performing the reset. With no mutex deadlock, we no longer have to coordinate with any waiter, and just perform the reset immediately. Testcase: igt/gem_mmap_gtt/hang # regresses Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-3-chris@chris-wilson.co.uk
* drm/i915/guc: Disable global resetChris Wilson2019-01-251-0/+3
| | | | | | | | | | | | | | | | | | | | | The guc (and huc) currently inexcruitably depend on struct_mutex for device reinitialisation from inside the reset, and indeed taking any mutex here is verboten (as we must be able to reset from underneath any of our mutexes). That makes recovering the guc unviable without, for example, reserving contiguous vma space and pages for it to use. The plan to re-enable global reset for the GuC centres around reusing the WOPM reserved space at the top of the aperture (that we know we can populate a contiguous range large enough to dma xfer the fw image). In the meantime, hopefully no one even notices as the device-reset is only used as a backup to the per-engine resets for handling GPU hangs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-2-chris@chris-wilson.co.uk
* drm/i915: Make all GPU resets atomicChris Wilson2019-01-251-51/+39Star
| | | | | | | | | | | In preparation for the next few commits, make resetting the GPU atomic. Currently, we have prepared gen6+ for atomic resetting of individual engines, but now there is a requirement to perform the whole device level reset (just the register poking) from inside an atomic context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125132230.22221-1-chris@chris-wilson.co.uk
* drm/i915: Compute the HWS offsets explicitlyChris Wilson2019-01-253-8/+7Star
| | | | | | | | | | | | | | | Simplify by using sizeof(u32) to convert from the index inside the HWSP to the byte offset. This has the advantage of not only being shorter (and so not upsetting checkpatch!) but that it matches use where we are writing to byte addresses using other commands than MI_STORE_DWORD_IMM. v2: Drop the now superfluous MI_STORE_DWORD_INDEX_SHIFT, it appears to be a local invention so keeping it after the final use does not help to clarify the GPU instruction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125120005.25191-2-chris@chris-wilson.co.uk
* drm/i915: Remove manual breadcumb countingChris Wilson2019-01-255-34/+11Star
| | | | | | | | | Now that we know we measure the size of the engine->emit_breadcrumb() correctly, we can remove the previous manual counting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125120005.25191-1-chris@chris-wilson.co.uk
* drm/i915: Measure the required reserved size for request emissionChris Wilson2019-01-255-14/+77
| | | | | | | | | | | | | | Instead of tediously and fragilely counting up the number of dwords required to emit the breadcrumb to seal a request, fake a request and measure it automatically once during engine setup. The downside is that this requires a fair amount of mocking to create a proper breadcrumb. Still, should be less error prone in future as the breadcrumb size fluctuates! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125100520.20163-1-chris@chris-wilson.co.uk
* drm/i915/execlists: Move RPCS setup to context pinTvrtko Ursulin2019-01-251-17/+28
| | | | | | | | | | | | | | | | | | | | | | Configuring RPCS in context image just before pin is sufficient and will come extra handy in one of the following patches. v2: * Split image setup a bit differently. (Chris Wilson) v3: * Update context image after reset as well - otherwise the application of pinned default state clears the RPCS. v4: * Use local variable throughout the function. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-chris@chris-wilson.co.uk
* drm/i915/icl: Define MOCS table for IcelakeTomasz Lis2019-01-251-9/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The table has been unified across OSes to minimize virtualization overhead. The MOCS table is now published as part of bspec, and versioned. Entries are supposed to never be modified, but new ones can be added. Adding entries increases table version. The patch includes version 1 entries. Meaning of each entry is now explained in bspec, and user mode clients are expected to know what each entry means. The 3 entries used for previous platforms are still compatible with their legacy definitions, but that is not guaranteed to be true for future platforms. v2: Fixed SCC values, improved commit comment (Daniele) v3: Improved MOCS table comment (Daniele) v4: Moved new entries below gen9 ones. Put common entries into definition to be used in multiple arrays. (Lucas) v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas) v6: Removed definitions of reserved entries. (Michal) Increased limit of entries sent to the hardware on gen11+. v7: Simplify table as done for previou gens (Lucas) v8: Rebase on cached number of entries per-platform and use new MOCS_ENTRY() macro (Lucas) v9: Update comment (from Tomasz) BSpec: 34007 BSpec: 560 Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-8-lucas.demarchi@intel.com
* drm/i915: cache number of MOCS entriesLucas De Marchi2019-01-251-13/+14
| | | | | | | | | | | | | | | | | Instead of checking the gen number every time we need to know the max number of entries, just save it into the table struct so we don't need extra branches throughout the code. This will be useful for Ice Lake that has 64 rather than 62 defined entries. Ice Lake changes will be added in a follow up. v2: make size and n_entries `unsigned int` and introduce changes as a pre-work for the Ice Lake changes (Tvrtko) Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-7-lucas.demarchi@intel.com
* drm/i915: keep track of used entries in MOCS tableLucas De Marchi2019-01-251-33/+78
| | | | | | | | | | | | | | | | | Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in which we have holes of undefined entries. Repeated comments about the meaning of undefined entries were removed since they are overly verbose and copy-pasted in several functions: now the definition is in the top only. v2: add helper function to get the index (from Chris) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-6-lucas.demarchi@intel.com
* drm/i915: use a macro to define MOCS entriesLucas De Marchi2019-01-251-25/+18Star
| | | | | | | | | | | | | Let's use a macro to make tables smaller and at the same time allow us to add fields that apply to all entries in future. v2: rewrap lines to respect 80 chars limit and make it more readable (from Chris) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-5-lucas.demarchi@intel.com
* drm/i915/skl: Rework MOCS tables to keep common part in a defineTomasz Lis2019-01-251-32/+25Star
| | | | | | | | | | | | | | | | | | | | | | | The MOCS tables are going to be very similar across platforms. To reduce the amount of copied code, this patch rips the common part and puts it into a definition valid for all gen9 platforms. v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. (Joonas) v3 (Lucas): - Fix indentation - Rebase on rework done by additional patch - Remove define for or-ing flags as it made the table more complex by requiring zeroed values to be passed - Do not embed comma in the macro, so to treat that just as another item and please source code formatting tools Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-4-lucas.demarchi@intel.com
* drm/i915: Simplify MOCS table definitionLucas De Marchi2019-01-251-51/+29Star
| | | | | | | | | | | | | | | | | | | | | | Make the defines for LE and L3 caching options to contain the shifts and remove the zeros from the tables as shifting zeros always result in zero. Starting from Ice Lake the MOCS table is defined in the spec and contains all entries. So to simplify checking the table with the values set in code, the value is now part of the macro name. This allows to still give the most used option and sensible name, but also to easily cross check the table from the spec for gen >= 11. By removing the zeros we avoid maintaining a huge table since the one from spec contains many more entries. The new table for Ice Lake will be added by other patches, this only reformats the table. While at it also fix the indentation. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-3-lucas.demarchi@intel.com
* drm/i915: initialize unused MOCS entries to PTELucas De Marchi2019-01-251-33/+23Star
| | | | | | | | | | | | | | | | | Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. From Chris: "What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always undefined. So we should at least be able to guarantee that the data written by userspace from the CPU is visible. After that, your caches are on your own". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-2-lucas.demarchi@intel.com
* drm/i915: Update DRIVER_DATE to 20190124Rodrigo Vivi2019-01-251-2/+2
| | | | Signed-off-by: Rodrigo Vivi <vivijim@rdvivi-cozumel.jf.intel.com>
* Merge tag 'gvt-next-2019-01-24' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi2019-01-2422-213/+204Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | drm-intel-next-queued gvt-next-2019-01-24 - split kvmgt as seperate module (Zhenyu) - Coffeelake GVT support (Fred) - const treatment and change for kernel type (Jani) Signed-off-by: Rodrigo Vivi <vivijim@rdvivi-cozumel.jf.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124054048.GO7203@zhen-hp.sh.intel.com
| * drm/i915/gvt: switch to kernel typesJani Nikula2019-01-236-27/+27
| | | | | | | | | | | | | | | | | | | | Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915: Enable gfx virtualization for Coffeelake platformfred gao2019-01-101-0/+3
| | | | | | | | | | | | | | | | Enable gfx virtualization for CFL. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: Refine port select logic for CFL platformfred gao2019-01-101-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Refine the code since the port select definition for CFL is different than SKL/BXT. v2: - replace PCH_CNP with IS_COFFEELAKE. (zhenyu) Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: Reuse the gmbus pin macrofred gao2019-01-101-7/+7
| | | | | | | | | | | | | | | | Reuse the gmbus pin macro from i915_reg.h file to improve readablity. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: Enable gfx virtualiztion for CFLfred gao2019-01-108-53/+36Star
| | | | | | | | | | | | | | | | | | | | | | | | | | Use INTEL_GEN to simplify the code for SKL+ platforms. v2: - split the enabling code into final one to identify any regression. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Fei Jiang <fei.jiang@intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: Add mmio handler for CFLfred gao2019-01-101-2/+2
| | | | | | | | | | | | | | | | | | Add registers of 0x4ab8 and 0x2248 into MMIO handler. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Fei Jiang <fei.jiang@intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: Add coffeelake platform definitionfred gao2019-01-102-5/+8
| | | | | | | | | | | | | | | | | | Add D_CFL for CFL platform. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Fei Jiang <fei.jiang@intel.com> Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
| * drm/i915/gvt: give the cmd parser cmd_info a const treatmentJani Nikula2019-01-102-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | It doesn't need to be changed, make it const. The string literals should anyway be referred to as const data. The following gets moved to rodata section: 0000000000000080 l O .rodata 0000000000001c00 cmd_info Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-12 07:24:28 +0200