aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_uncore.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-10-04drm/i915: Remove identical write mmmio functionsTvrtko Ursulin1-75/+19
We notice two identical copies of the shadow register table and following from that removal can also unify CHV and Gen9 write mmio functions and macros into a single implementation. v2: Name fwtable consistently and use HAS_FWTABLE. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Remove identical mmio read functionsTvrtko Ursulin1-44/+10
It is now obvious VLV, CHV and Gen9 mmio read fcuntions are completely identical so we can remove the three copies and just keep the newly named generic implementation. v2: Use fwtable naming consistently. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Remove identical macrosTvrtko Ursulin1-50/+20
Remove some macros which are now obviously identical. v2: Added HAS_FWTABLE macro and simplified intel_uncore_forcewake_for_read. (Joonas Lahtinen) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Store the active forcewake range table pointerTvrtko Ursulin1-34/+34
If we store this in the uncore structure we are on a good way to show more commonality between the per-platform implementations. v2: Constify table pointer and correct coding style. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Eliminate Gen9 special caseTvrtko Ursulin1-21/+21
If we insert blitter forcewake domain entries in the range table we can eliminate that special case and simplify the code in a few macros. This will enable more unification later. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Use binary search when looking up forcewake domainsTvrtko Ursulin1-8/+19
Instead of the existing linear seach, now that we have sorted range tables, we can do a binary search on them for some potential miniscule performance gain, but more importantly for elegance and code size. Hopefully the perfomance gain is sufficient to offset the function calls which were not there before. v2: Removed const cast away. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Sort forcewake mapping tablesTvrtko Ursulin1-13/+43
Sorting the tables (verified at runtime to help during development) is another prerequisite for interesting work which will follow. v2: * Remove const away cast and improve comments. (Chris Wilson) * Check tables only when debug option is enabled. v3: Use IS_ENABLED. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Data driven register to forcewake domains lookupTvrtko Ursulin1-109/+103
Move finding the correct forcewake domains to take for register access from code to a mapping table. This will allow more interesting work in the following patches and is easier to review if singled out early. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Do not inline forcewake taking in mmio accessorsTvrtko Ursulin1-10/+14
Once we know we need to take new forcewakes, that being a slow operation, it does not make sense to inline that code into every mmio accessor. Move it to a separate function and save some code. v2: Be explicit with noinline and remove stale comment. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Keep track of active forcewake domains in a bitmaskTvrtko Ursulin1-31/+23
There are current places in the code, and there will be more in the future, which iterate the forcewake domains to find out which ones are currently active. To save them from doing this iteration, we can cheaply keep a mask of active domains in dev_priv->uncore.fw_domains_active. This has no cost in terms of object size, even manages to shrink it overall by 368 bytes on my config. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-04drm/i915: Remove redundant hsw_write* mmio functionsTvrtko Ursulin1-24/+1
They are completely identical to gen6_write* ones. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-03drm/i915: Just clear the mmiodebug before a register accessChris Wilson1-4/+3
When we enable the per-register access mmiodebug, it is to detect which access is illegal. Reporting on earlier untraced access outside of the mmiodebug does not help debugging (as the suspicion is immediately put upon the current register which is not at fault)! References: https://bugs.freedesktop.org/show_bug.cgi?id=97985 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-1-chris@chris-wilson.co.uk
2016-09-06drm/i915: Remove 64b mmio write vfuncsChris Wilson1-9/+0
We don't have safe 64-bit mmio writes as they are really split into 2x32-bit writes. This tearing is dangerous as the hardware *will* operate on the intermediate value, requiring great care when assigning. (See, for example, i965_write_fence_reg.) As such we don't currently use them and strongly advise not to us them. Go one step further and remove the 64-bit write vfuncs. v2: Add some more details to the comment about why WRITE64 is absent, and why you need to think twice before using READ64. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160906144538.4204-1-chris@chris-wilson.co.uk
2016-08-27drm/i915: Make for_each_engine_masked() more compact and quickerChris Wilson1-3/+6
Rather than walk the full array of engines checking whether each is in the mask in turn, we can use the mask to jump to the right engines. This should quicker for a sparse array of engines or mask, whilst generating smaller code: text data bss dec hex filename 1251010 4579 800 1256389 132bc5 drivers/gpu/drm/i915/i915.ko 1250530 4579 800 1255909 1329e5 drivers/gpu/drm/i915/i915.ko The downside is that we have to pass in a temporary, alas no C99 iterators yet. [P.S. Joonas doesn't like having to pass extra temporaries into the macro, and even less that I called them tmp. As yet, we haven't found a macro that avoids passing in a temporary that is smaller. We probably will get C99 iterators first!] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160827075401.16470-2-chris@chris-wilson.co.uk
2016-07-21Revert "drm/i915: Enable RC6 immediately"Chris Wilson1-1/+1
This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1469132179-4052-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-07-21drm/i915: Enable RC6 immediatelyChris Wilson1-1/+1
Now that PCU communication is reasonably fast, we do not need to defer RC6 initialisation to a workqueue. References: https://bugs.freedesktop.org/show_bug.cgi?id=97017 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-07-19drm/i915: Fixup kerneldoc code snippets in intel_uncore.cDaniel Vetter1-4/+8
We need :: before, blank lines around and indentation with 4 _additional_ spaces to make it work. Also, don't use @param in code snippets, it results in confusion. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468612088-9721-8-git-send-email-daniel.vetter@ffwll.ch
2016-07-14drm/i915: Defer enabling rc6 til after we submit the first batch/contextChris Wilson1-1/+1
Some hardware requires a valid render context before it can initiate rc6 power gating of the GPU; the default state of the GPU is not sufficient and may lead to undefined behaviour. The first execution of any batch will load the "golden render state", at which point it is safe to enable rc6. As we do not forcibly load the kernel context at resume, we have to hook into the batch submission to be sure that the render state is setup before enabling rc6. However, since we don't enable powersaving until that first batch, we queued a delayed task in order to guarantee that the batch is indeed submitted. v2: Rearrange intel_disable_gt_powersave() to match. v3: Apply user specified cur_freq (or idle_freq if not set). v4: Give in, and supply a delayed work to autoenable rc6 v5: Mika suggested a couple of better names for delayed_resume_work v6: Rebalance rpm_put around the autoenable task Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-7-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2016-07-05drm/i915: Convert dev_priv->dev backpointers to dev_priv->drmChris Wilson1-3/+3
Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 1068757 4565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko 1066949 4565 416 1071930 105b3a drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ struct drm_i915_private *d; identifier i; @@ ( - d->dev->i + d->drm.i | - d->dev + &d->drm ) and for good measure the dev_priv->dev backpointer was removed entirely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467711623-2905-4-git-send-email-chris@chris-wilson.co.uk
2016-07-04drm/i915: Mass convert dev->dev_private to to_i915(dev)Chris Wilson1-1/+1
Since we now subclass struct drm_device, we can save pointer dances by noting the equivalence of struct drm_device and struct drm_i915_private, i.e. by using to_i915(). text data bss dec hex filename 1073824 4562 416 1078802 107612 drivers/gpu/drm/i915/i915.ko 1068976 4562 416 1073954 106322 drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ expression E; identifier p; @@ - struct drm_i915_private *p = E->dev_private; + struct drm_i915_private *p = to_i915(E); Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467628477-25379-1-git-send-email-chris@chris-wilson.co.uk
2016-07-04drm/i915: Hold irq uncore.lock when initialising fw_domainsChris Wilson1-0/+2
Acquiring the forcewake domain asserts that it is in an atomic section (as we always expect to be under the uncore.lock). This is true except for initialising the domains on Ivybridge, and so we generate a warning. Wrap the manual usage of fw_domains inside the spin_lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467566973-13596-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-06-30drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()Chris Wilson1-7/+3
By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-61-git-send-email-chris@chris-wilson.co.uk
2016-06-30drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()Chris Wilson1-4/+6
By using the out-of-line intel_wait_for_register() not only do we can efficiency from using the hybrid wait_for() contained within, but we avoid code bloat from the numerous inlined loops, in total (all patches): text data bss dec hex filename 1078551 4557 416 1083524 108884 drivers/gpu/drm/i915/i915.ko 1070775 4557 416 1075748 106a24 drivers/gpu/drm/i915/i915.ko Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-60-git-send-email-chris@chris-wilson.co.uk
2016-06-30drm/i915: Use a hybrid scheme for fast register waitsChris Wilson1-11/+72
Ville Syrjälä reported that in the majority of wait_for(I915_READ()) he inspect, most completed within the first couple of reads and that the delay between those wait_for() reads was the ratelimiting step for many code paths. For example, __gen6_update_ring_freq() was blamed for slowing down boot by many milliseconds, but under Ville's scrutiny the issue was just excessive delay waiting for sandybridge_pcode_write(). We can eliminate the wait by initially using a busyspin upon the register read and only fallback to the sleeping loop in cases where the hardware is indeed too slow. A threshold of 2 microseconds is used as the initial ballpark. To avoid excessive code bloating from converting every wait_for() into a hybrid busy/sleep loop, we extend wait_for_register_fw() and export it for use by other callers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-1-git-send-email-chris@chris-wilson.co.uk
2016-05-23drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHEDDave Gordon1-1/+1
For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro rather than HAS_GUC_UCODE() or testing enable_guc_submission. v4: Added a couple more uses of the new macro. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-13drm/i915: Move get-reset-stats ioctl from intel_uncore.c to i915_gem_context.cChris Wilson1-39/+0
The get-reset-stats ioctl reports upon the statistics (number of hangs, be it as a victim or the guilty party) of a particular context. It is semantically better as being part of i915_gem_context.c user interface, as opposed to the hardware level access of intel_uncore.c Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463137042-9669-1-git-send-email-chris@chris-wilson.co.uk
2016-05-11drm/i915: Make IS_GENx macros work on a maskTvrtko Ursulin1-2/+2
If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. v2: Make bit zero of gen mask mean gen 1. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-05-10drm/i915: Use drm_i915_private as the native pointer for intel_uncore.cChris Wilson1-83/+79
Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462885804-26750-1-git-send-email-chris@chris-wilson.co.uk
2016-05-09drm/i915: Store a i915 backpointer from engine, and use itChris Wilson1-7/+7
text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
2016-04-14drm/i915: Use fw_domains_put_with_fifo() on HSWVille Syrjälä1-1/+5
HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2016-04-14drm/i915: Calculate edram sizeMika Kuoppala1-4/+17
With gen9+ the edram capabilities are defined so that we can calculate the edram (ellc) size accordingly. Note that there are undefined combinations for some subset of edram capability bits. Return the closest size for undefined indexes. Even if we get it wrong with beginning of future gen enabling, the size information is currently only used for boot message and in debugfs entry. v2: Use function instead of hard to read macro (Daniel) v3: s/INTEL_INFO/INTEL_GEN (Matthew) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460557604-7126-2-git-send-email-mika.kuoppala@intel.com
2016-04-14drm/i915: Store and use edram capabilitiesMika Kuoppala1-12/+27
Store the edram capabilities instead of only the size of edram. This is preparatory patch to allow edram size calculation based on edram capability bits for gen9+. With gen9 the edram is behind llc and is a separate entity. With hsw/bdw it was more of a victim cache for LLC so the name 'eLLC' might be warranted. Regardless, rename all mentions of eLLC to EDRAM to clear the confusion. v2: return bytes for edram size (Chris) s/eLLC/eDRAM in output if we are gen > 8 v3: rebase, INTEL_GEN (Chris) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"Ville Syrjälä1-9/+0
Enable the unclaimd register detection stuff on vlv/chv since we've now fixed the known problems during suspend. This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-04-12drm/i915: Only grab correct forcewake for the engine with execlistsTvrtko Ursulin1-0/+108
Rather than blindly waking up all forcewake domains on command submission, we can teach each engine what is (or are) the correct one to take. On platforms with multiple forcewake domains like VLV, CHV, SKL and BXT, this has the potential of lowering the GPU and CPU power use and submission latency. To implement it we add a function named intel_uncore_forcewake_for_reg whose purpose is to query which forcewake domains need to be taken to read or write a specific register with raw mmio accessors. These enables the execlists engine setup to query which forcewake domains are relevant per engine on the currently running platform. v2: * Kerneldoc. * Split from intel_uncore.c macro extraction, WARN_ON, no warns on old platforms. (Chris Wilson) v3: * Single domain per engine, mention all registers, bi-directional function and a new name, fix handling of gen6 and gen7 writes. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460468251-14069-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Remove forcewake request registers from the shadowed tableTvrtko Ursulin1-4/+0
Chris Wilson points out that we can remove them from the array since they are always written to with raw accessors. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Extract knowledge of register forcewake domainsTvrtko Ursulin1-100/+155
Knowledge of which register per platform belonds in which forcewake domain was embedded in the MMIO accessors themselves. Extract it into standalone macros so they can be used from new code in the following patches. This causes GCC to compile some of the MMIO accessors slightly differently and grows the code a tiny amount. But none of the growth is on the fast-path so it does not matter hugely. Affected sizes before: 00000000000026f0 00000000000001a5 t gen6_read16 0000000000002390 00000000000001a5 t gen6_read32 00000000000028a0 00000000000001a5 t gen6_read64 00000000000061d0 000000000000019e t gen8_write16 0000000000006510 000000000000019d t gen8_write32 0000000000006370 000000000000019d t gen8_write64 00000000000021f0 000000000000019d t gen8_write8 Affected sizes after: 0000000000002840 00000000000001aa t gen6_read16 00000000000024e0 00000000000001a9 t gen6_read32 00000000000029f0 00000000000001a9 t gen6_read64 0000000000004f20 00000000000001b5 t gen8_write16 0000000000004ba0 00000000000001b4 t gen8_write32 00000000000050e0 00000000000001b4 t gen8_write64 0000000000004d60 00000000000001b4 t gen8_write8 Other MMIO accessors are not affected in size. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-12drm/i915: Do not serialize forcewake acquire across domainsTvrtko Ursulin1-1/+3
On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460045074-1006-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-12drm/i915: Simplify for_each_fw_domain iteratorsTvrtko Ursulin1-24/+21
As the vast majority of users do not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain mask, store it in the domain array (which already has the domain id), then both can be retrieved thence. Result is clearer code and smaller generated binary, especially in the tight fw get/put loops. Also, relationship between domain id and mask is no longer assumed in the macro. v2: Improve grammar in the commit message and rename the iterator to for_each_fw_domain_masked for consistency. (Dave Gordon) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
2016-04-12drm/i915: Use consistent forcewake auto-release timeout across kernel configsTvrtko Ursulin1-9/+16
Because it is based on jiffies, current implementation releases the forcewake at any time between straight away and between 1ms and 10ms, depending on the kernel configuration (CONFIG_HZ). This is probably not what has been desired, since the dynamics of keeping parts of the GPU awake should not be correlated with this kernel configuration parameter. Change the auto-release mechanism to use hrtimers and set the timeout to 1ms with a 1ms of slack. This should make the GPU power consistent across kernel configs, and timer slack should enable some timer coalescing where multiple force-wake domains exist, or with unrelated timers. For GlBench/T-Rex this decreases the number of forcewake releases from ~480 to ~300 per second, and for a heavy combined OGL/OCL test from ~670 to ~360 (HZ=1000 kernel). Even though this reduction can be attributed to the average release period extending from 0-1ms to 1-2ms, as discussed above, it will make the forcewake timeout consistent for different CONFIG_HZ values. Real life measurements with the above workload has shown that, with this patch, both manage to auto-release the forcewake between 2-4 times per 10ms, even though the number of forcewake gets is dramatically different. T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each 10ms period, while the OGL/OCL test requests 250 and 380 times in the same period. The two data points together suggest that the nature of the forwake accesses is bursty and that further changes and potential timeout extensions, or moving the start of timeout from the first to the last automatic forcewake grab, should be carefully measured for power and performance effects. v2: * Commit spelling. (Dave Gordon) * More discussion on numbers in the commit. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-07drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev)Joonas Lahtinen1-2/+2
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
2016-04-05drm/i915/guc: reset GuC and retry on firmware load failureArun Siluvery1-0/+19
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: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-03-30drm/i915: Rename __force_wake_get to __force_wake_autoChris Wilson1-9/+9
__force_wake_get() only acquires a temporary wakeref on forcewake that is automatically released when a timer expires. When reading the code again, I confused __intel_uncore_forcewake_get() for __force_wake_get() and to my shame thought I found a bug in unbalanced wake_count handling. I claim that if the function had been called __force_wake_auto() instead I would not have embarrassed myself. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458829907-26596-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-03-17drm/i915: Modify reset func to handle per engine resetsMika Kuoppala1-23/+64
In full gpu reset we prime all engines and reset domains corresponding to each engine. Per engine reset is just a special case of this process wherein only a single engine is reset. This change is aimed to modify relevant functions to achieve this. There are some other steps we carry out in case of engine reset which are addressed in later patches. Reset func now accepts a mask of all engines that need to be reset. Where per engine resets are supported, error handler populates the mask accordingly otherwise all engines are specified. v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris) v3: Whitespace fixes (Chris) v4: Rebase due to s/ring/engine Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458143640-20563-1-git-send-email-mika.kuoppala@intel.com
2016-03-16drm/i915: More intel_engine_cs renamingTvrtko Ursulin1-2/+2
Some trivial ones, first pass done with Coccinelle: @@ @@ ( - I915_NUM_RINGS + I915_NUM_ENGINES | - intel_ring_flag + intel_engine_flag | - for_each_ring + for_each_engine | - i915_gem_request_get_ring + i915_gem_request_get_engine | - intel_ring_idle + intel_engine_idle | - i915_gem_reset_ring_status + i915_gem_reset_engine_status | - i915_gem_reset_ring_cleanup + i915_gem_reset_engine_cleanup | - init_ring_lists + init_engine_lists ) But that didn't fully work so I cleaned it up with: for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-03-04drm/i915: Generalise common GPU engine reset request/unrequest codeTomas Elf1-20/+36
GPU engine reset handshaking is something that is applicable to both full GPU reset and engine reset, which is something that is part of the upcoming TDR per-engine hang recovery patches. Break out the common engine reset request/unrequest code (originally written by Mika Kuoppala) for reuse later in the TDR enablement patch series. v2: correct indentation and drop unused returned value (Mika) v3: We have forcewake during reset so use *_FW reg access (Mika) Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Tomas Elf <tomas.elf@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> [Mika: Fixed format warning] Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456929984-16323-1-git-send-email-mika.kuoppala@intel.com
2016-02-05drm/i915/bxt: Check BIOS RC6 setup before enabling RC6Sagar Arun Kamble1-0/+2
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using BIOS settings alone. RC6 related instability can be avoided by disabling via BIOS settings till driver fixes it. v2: Had placed logic in gen8 function by mistake. Fixed it. Ensuring RPM is not enabled in case BIOS disabled RC6. v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel) Runtime PM enabling happens before gen9_enable_rc6. Moved the updation of enable_rc6 parameter in intel_uncore_sanitize. v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt. (Imre) v5: Caching reserved stolen base and size in the driver private data. Reorganized RC6 setup check. Moved from gen9_enable_rc6 to intel_uncore_sanitize. (Imre) v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen earlier in the load. v7: Removed PWRCTX_MAXCNT_VCSUNIT1 check as it applies to SKL. (Imre) v8: Fixed formatting and checkpatch issues. Fixed functional issue where RC6 ctx size check was missing. (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454697809-22113-1-git-send-email-sagar.a.kamble@intel.com
2016-01-21drm/i915: Limit the auto arming of mmio debugs on vlv/chvMika Kuoppala1-0/+9
The capability to detect unclaimed register access was recently introduced for vlv/chv platforms. Apparently there are plenty of unclaimed access on these platforms, resulting in new dmesg warns. But as we are trying to form a beachhead for CI/Bat, all new warns are adding to the noise and thus not desirable at this point in time. Make it so that if in these platforms the automatic arming was responsible for mmio_debug enabling, ignore the warns. If user/dev wants to fix these, he can still do so by i915.mmio_debug=1234. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453285943-24614-1-git-send-email-mika.kuoppala@intel.com
2016-01-11drm/i915: Arm the unclaimed mmio debugs on suspend pathMika Kuoppala1-2/+5
If we go into suspend with unclaimed access detected, it would be nice to catch that access on a next suspend path. So instead of just notifying about it, arm the unclaimed mmio checks on suspend side. We want to keep the asymmetry on resume, as if it was on resume path, it was not driver that is responsible so no point in arming mmio debugs. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-2-git-send-email-mika.kuoppala@intel.com
2016-01-11drm/i915: Enable mmio_debug for vlv/chvMika Kuoppala1-19/+22
With commit 8ac3e1bb76cc ("drm/i915: Add non claimed mmio checking for vlv/chv") we now have chv/vlv support in place for detecting unclaimed access. Also the perf hit of extra mmio read is now only suffered if mmio_debug is set. This allows us to stuff the macro for unclaimed reg detection inside a generic gen6 register access, as now all gens using these macros uses also unclaimed debugs, the one exception being snb. We gain more clean and generic macros and only downside is that snb will suffer one branch perf hit without upside. Note that the hsw write path debug register check now happens before fifo check, but this should not make any real difference. As vlv/chv use the generic gen6 access macros, the consequence is that they gain the mmio_debug feature. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452261080-6979-1-git-send-email-mika.kuoppala@intel.com
2016-01-08drm/i915: Add non claimed mmio checking for vlv/chvMika Kuoppala1-4/+27
Imre mentioned that chv might also have capability to track unclaimed mmio accesses. Ville added that both chv and vlv has this capability and he had already made this way back [1]. Mimic what Ville's patch does but adapt on top of less frequent mmio accesses by omitting checking always on reg writes. This patch is untested as of now. v2: overflow handling and posting omitted (Ville) References: [1] http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450201542-22918-1-git-send-email-mika.kuoppala@intel.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.