- 10 Oct, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 Oct, 2016 4 commits
-
-
Chris Wilson authored
We reserve space in the GuC workqueue for submitting the request in the future. However, if we fail to construct the request, we need to give that reserved space back to the system. Fixes: dadd481b ("drm/i915/guc: Prepare for nonblocking execbuf submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Along with the interrupt, we want to restore the fake-irq and wait-timeout detection. If we use the breadcrumbs interface to setup the interrupt as it wants, the auxiliary timers will also be restored. v2: Cancel both timers as well, sanitize the IMR. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we run out of enough aperture space to fit the entire object, we fallback to trying to insert a single page. However, if that also fails, we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means to userspace that their batch could not be fitted within the GTT.) Prior to commit e8cb909a ("drm/i915: Fallback to single page GTT mmappings for relocations") the approach is to fallback to using the slow CPU relocation path in case of iomapping failure, and that is the behaviour we need to restore. Fixes: e8cb909a ("drm/i915: Fallback to single page GTT mmappings...") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order not to trigger hangcheck on a idle-but-waiting engine, we need to distinguish between the pending request queue and the actual execution queue. This is done later in "drm/i915: Enable multiple timelines" but for now we need a temporary fix to prevent blaming the wrong engine for a GPU hang. (Note that this causes a temporary subtle change in how we decide when to allow a waitboost to be re-awarded back to the waiter, the temporary effect is that if the wait is upon the most current execution the wait is given for free, instead of checking to see if the client stalled itself. This will be repaired in "drm/i915: Enable multiple timelines".) Fixes: 0a046a0e ("drm/i915: Nonblocking request submission") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104Signed-off-by:
-
- 06 Oct, 2016 3 commits
-
-
Ville Syrjälä authored
Intel DZ77BH-55K board doest't have a physical VGA connector, and yet it always detects that something is connected there. Add it to the DMI blacklist to ignore the spurious detection results. Allows me to drop 'video=VGA-1:d' from my kernel cmdline. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474881646-1326-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Having a shadow VGA connector is useful for testing purposes. We currently skip registering the connector on machines where the CRT detect falsely reports it as connected. Let's instead move the the blacklist check to the detect callback (and hpd setup) and if we get a match we always report the connector as disconnected. This way we get a shadow VGA connector to help with testing, while we still avoid the user facing problems from the incorrect detection results. commit 8ca4013d ("CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB") doesn't provide much in the way of details as to why 'ACER ZGB' was added to the blacklist. Trying to trace it further leads me to a chromeos bugreport I can't access. So based on the fact that the commit added the "/* Skip machines without VGA that falsely report hotplug events */" comment, I'm going to assume that it was just spurious CRT detection. So it should be safe to move the blacklist to just block the detection and hpd without causing a regression on said machine. In fact Stéphane confirmed on irc that the problem was indeed just crappy hotplug detect: "22:29 < marcheu> vsyrjala: the port isn't there, but the load detect is improperly stubbed in hw 22:29 < marcheu> vsyrjala: so it floats" so this change should be perfectly fine. v2: Add irc quote from Stéphane Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
This reverts commit 10b6ee4a. According to [1] Dell XPS8700 VBT says 'int_crt_support 0', so thanks to commit e4abb733 ("drm/i915: Check VBT for CRT port presence on HSW/BDW") we no longer need to blacklist it based on DMI. Looking through the bug report, SFUSE_STRAP based detection was apparently also tried and failed, but the VBT based one should still work just fine. The commit says that the symptom was a frozen machine, but based on the bug report it doesn't look like the CRT detection was at least directly responsible for such a drastic outcome. Cc: Giacomo Comes <comes@naic.edu> References: https://bugs.freedesktop.org/show_bug.cgi?id=73559 References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038178.html [1] Signed-off-by:
-
- 05 Oct, 2016 12 commits
-
-
Joonas Lahtinen authored
Sort DEV_INFO_FOR_EACH_FLAG to alphabetical order (except is_*). v2: - Add comments in the hope of maintaining order (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Joonas Lahtinen authored
Get rid of SEP_SEMICOLON and SEP_BLANK in DEV_INFO_FOR_EACH_FLAG. Consolidate the debug output so that instead of one huge line with "cap1,cap2,capN" each capability is split to own line and displayed as "capN: [yes|no]" to make the dumps more historically informative. v2: - Do not break auto-indent by keeping semicolon after macro (Jani) - Consolidate and use yesno() in all locations (Chris) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Ville Syrjälä authored
Allow returning "connected" or "unknown" connector status for DP branch devices that don't have an EDID. Currently we'd claim the thing as "disconnected" if there is no EDID. This stuff used to broken already, I think, but it got more broken by commit f21a2198 ("drm/i915: Splitting intel_dp_detect") Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by:
Arno <blouin.arno@gmail.com> Fixes: f21a2198 ("drm/i915: Splitting intel_dp_detect") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
Ville Syrjälä authored
We can't rely on connector->status in the detect() hook if the long hpd was already handled by the dig_port_work as that won't update connector->status. Thus we have to defer the long hpd handling entirely until the hotplug work runs to avoid the double long hpd handling the "detect_done" flag is trying to prevent. We'll start to depend on connector->status being up to date in a following patch. Cc: Damien Cassou <damien@cassou.me> Cc: freedesktop.org@gp.mailgun.org Cc: Arno <blouin.arno@gmail.com> Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: stable@vger.kernel.org Tested-by:
-
Chris Wilson authored
It is convenient to know what processes are waiting when looking at hangcheck status in debugfs. Signed-off-by:
-
Chris Wilson authored
Knowing where the RINGs are pointing is extremely useful in diagnosing if the engines are executing the ringbuffers you expect - and igt may be suppressing the usual method of looking in the GPU error state. Signed-off-by:
-
Chris Wilson authored
Include the position of the active request in the ring, and display that alongside the current RING registers (on a GPU hang). Signed-off-by:
-
Chris Wilson authored
Check that there was not a late recovery between us declaring the GPU hung and processing the reset. If the GPU did recover by itself, let the request remain on the active list and see if it hangs again! Signed-off-by:
-
Chris Wilson authored
Whilst we reset the GPU, we want to prevent execlists from submitting new work (which it does via an interrupt handler). To achieve this we disable the irq (and drain the irq tasklet) around the reset. When we enable it again afters, the interrupt queue should be empty and we can reinitialise from a known state without fear of the tasklet running concurrently. Signed-off-by:
-
Chris Wilson authored
After a GPU reset, we want to replay our queue of requests. However, the GPU reset clobbered the state and we only fixup the state for the guilty request - and engines deemed innocent we try to leave untouched so that we recover as completely as possible. However, we need to clear the sw tracking of the ELSP ports even for innocent requests, so move the clear to the common path of init_hw (from reset_hw). Reported-by:
-
Chris Wilson authored
On Braswell, at least, we observe that the context image is written in multiple phases. The first phase is to clear the register state, and subsequently rewrite it. A GPU reset at the right moment can interrupt the context update leaving it corrupt, and our update of the RING_HEAD is not sufficient to restart the engine afterwards. To recover, we need to reset the registers back to their original values. The context state is lost. What we need is a better mechanism to serialise the reset with pending flushes from the GPU. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
-
Chris Wilson authored
Since both legacy and execlists want to populate the RING_CTL register, share the computation of the right bits for the ring->size. We can then stop masking errors and explicitly forbid them during creation! Signed-off-by:
-
- 04 Oct, 2016 18 commits
-
-
Jani Nikula authored
drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52: expected void [noderef] <asn:2>*vaddr drivers/gpu/drm/i915/i915_gem_execbuffer.c:432:52: got void * drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15: expected void *vaddr drivers/gpu/drm/i915/i915_gem_execbuffer.c:477:15: got void [noderef] <asn:2>* Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475574853-4178-2-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
Fix sparse warning: drivers/gpu/drm/i915/intel_pm.c:3970:1: warning: symbol 'skl_ddb_add_affected_planes' was not declared. Should it be static? Fixes: 7f60e200 ("drm/i915/gen9: only add the planes actually affected by ddb changes") Cc: Lyude <cpaul@redhat.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Instead of using bsearch library function make a local generator macro out of it so the comparison callback can be inlined. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
-
Tvrtko Ursulin authored
Simply replace the linear search with the kernel's binary search implementation. There is only six registers currently in that table so this may not be that interesting. It adds a function call so hopefully remains performance neutral for now. v2: No need for manual conversion to bool for return. (Joonas Lahtinen) Signed-off-by: -
Tvrtko Ursulin authored
Also verify the order at runtime. This was we can start using binary search on it in a following patch. v2: Add comment on the sorted array and only check it when debug option is enabled. v3: Use IS_ENABLED. (Chris Wilson) Signed-off-by: -
Tvrtko Ursulin authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
They are completely identical to gen6_write* ones. Signed-off-by:
-
Jani Nikula authored
Fix sparse warning: drivers/gpu/drm/i915/intel_device_info.c:195:31: warning: Variable length array is used. In truth the array does have constant length, but sparse is too dumb to realize. This is a bit ugly, but silence the warning no matter what. Fixes: 91bedd34 ("drm/i915/bdw: Check for slice, subslice and EU count for BDW") Reviewed-by:
-
Jani Nikula authored
Move the outcast intel_fbdev_output_poll_changed() stub for CONFIG_DRM_FBDEV_EMULATION=n next to its friends. Reviewed-by:
-
- 03 Oct, 2016 2 commits
-
-
Chris Wilson authored
When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add36 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by:
-
Chris Wilson authored
We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by:
-
