- 11 Oct, 2016 10 commits
-
-
Jani Nikula authored
Have generic macros in line with the rest of the register bit definition macros instead of a dedicated function in intel_audio.c, and use them. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/c8709b065ba5cb91b85c54f4e099219e4e68b192.1476111629.git.jani.nikula@intel.com
-
Libin Yang authored
HDMI audio should use crtc_clock to get the TMDS clock. This patch renames mode to adjusted_mode to unify the name. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
-
Libin Yang authored
This patch applies setting proper N/M, N/CTS on more platforms. Reviewed-by:
-
Jani Nikula authored
The code for dp and hdmi are already different, and they're about to diverge even more. Split them for clarity in future work. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
It gets fragile to duplicate the code for updating HSW_AUD_CFG. The only change should be that the hdmi pixel clock is also updated in i915_audio_component_sync_audio_rate(), but it should not be any different. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
If it was wrong, we'd be screwed already. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Prepare for using the same code for updating HSW_AUD_CFG register. No functional changes. Cc: Libin Yang <libin.yang@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
If we want to know how many pages a VMA spans, we can use vma_pages() to find out. We have one such invocation inside our faulthandler, so convert it. (We have two other that want the size in bytes rather than pages, food for future thought.) Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161011090656.29554-1-chris@chris-wilson.co.ukReviewed-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
commit 1625e7e5 ("drm/i915: make compact dma scatter lists creation work with SWIOTLB backend") took a heavy handed approach to undo the scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug whereby we tried to pass a segment larger than SWIOTLB could handle.) We can be a little more intelligent and try compacting the scatterlist up to the maximum SWIOTLB segment size (when using SWIOTLB). v2: Tidy sg_mark_end() and cpp Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161011082021.14606-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
When we notice the system under memory pressure, we try to evict some driver pages before asking the VM to shrink all caches. As a final step in that process, we tried to evict everything, including active buffers. This is harming ourselves, and we can mix shrinking all caches as well as our residual buffers (after the first pass of trying to shrink just our own buffers). Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161011082021.14606-1-chris@chris-wilson.co.uk
-
- 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 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ä 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 10 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 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:
-
