- 30 4月, 2018 5 次提交
-
-
由 Chris Wilson 提交于
We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings. v2: s/live/active/ for consistency with gt.active_requests Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-4-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the position of ring->head. As an added bonus, retiring along the ring reduces the penalty of having one execlists client do cleanup for another (old legacy submission shares a ring between all clients). The downside is that slow and irregular (off the critical path) process of cleaning up stale requests after userspace becomes a modicum less efficient. In the long run, it will become apparent that the ordered ring->request_list matches the ring->timeline, a fun challenge for the future will be unifying the two lists to avoid duplication! v2: We need both engine-order and ring-order processing to maintain our knowledge of where individual rings have completed upto as well as knowing what was last executing on any engine. And finally by decoupling retiring the contexts on the engine and the timelines along the rings, we do have to keep a reference to the context on each request (previously it was guaranteed by the context being pinned). v3: Not just a reference to the context, but we need to keep it pinned as we manipulate the rings; i.e. we need a pin for both the manipulation of the engine state during its retirements, and a separate pin for the manipulation of the ring state. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-3-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. v2: Fixup mock_engine to mark the context as pinned on use. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
In commit 9b6586ae ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to preserve the semantics that no engine wraps in the middle of a submit. (Although this semantic is now only required for gen7 semaphore support, which only supports greater-then comparisons!) v2: Keep a global counter of all requests ever submitted and force the reset when it wraps. References: 9b6586ae ("drm/i915: Keep a global seqno per-engine") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an inconsistent state by the reset. The presumption was that at worst it would just cause another reset and skip again until it recovered, however it seems just as likely to cause an unrecoverable hang. Instead of risking loading an incomplete context image, restore it back to the default state. v2: Fix up off-by-one from including the ppHSWP in with the register state. v3: Use a ring local to compact a few lines. v4: Beware setting the ring local before checking for a NULL request. References: https://bugs.freedesktop.org/show_bug.cgi?id=105304Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20180428111532.15819-1-chris@chris-wilson.co.uk
-
- 28 4月, 2018 5 次提交
-
-
由 Paulo Zanoni 提交于
There's a lot of code for the PLL enabling, so let's first only introduce the register definitions in order to make patch reviewing a little easier. v2: Coding style (Jani). v3: Preparation for upstreaming. v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James). Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-3-paulo.r.zanoni@intel.com
-
由 Mahesh Kumar 提交于
Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to 11 bits. This patch make changes to use proper mask for ICL+ during hardware ddb value readout. Changes since V1: - Use _MASK & _SHIFT macro (James) Changes since V2: - use kernel type u8 instead of uint8_t Changes since V3: - Rebase Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-4-mahesh1.kumar@intel.com
-
由 Mahesh Kumar 提交于
ICL has two slices of DBuf, each slice of size 1024 blocks. We should not always enable slice-2. It should be enabled only if display total required BW is > 12GBps OR more than 1 pipes are enabled. Changes since V1: - typecast total_data_rate to u64 before multiplication to solve any possible overflow (Rodrigo) - fix where skl_wm_get_hw_state was memsetting ddb, resulting enabled_slices to become zero - Fix the logic of calculating ddb_size Changes since V2: - If no-crtc is part of commit required_slices will have value "0", don't try to disable DBuf slice. Changes since V3: - Create a generic helper to enable/disable slice - don't return early if total_data_rate is 0, it may be cursor only commit, or atomic modeset without any plane. Changes since V4: - Solve checkpatch warnings - use kernel types u8/u64 instead of uint8_t/uint64_t Changes since V5: - Rebase Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-3-mahesh1.kumar@intel.com
-
由 Mahesh Kumar 提交于
This patch adds support to start tracking status of DBUF slices. This is foundation to introduce support for enabling/disabling second DBUF slice dynamically for ICL. Changes Since V1: - use kernel type u8 over uint8_t Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-2-mahesh1.kumar@intel.com
-
由 James Ausmus 提交于
These fields have been deprecated and moved in ICL+. Stop setting the bits. They have moved to GAMMA_MODE and CSC_MODE, respectively. This patch is just to stop incorrectly setting bits in PLANE_COLOR_CTL while we're waiting for the new replacement functionality to be done. v2: Drop useless comment, and change !(GEN >= 11) to (GEN < 11). (Ville) v3: No changes v4 (from Paulo): Rebase. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NJames Ausmus <james.ausmus@intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-2-paulo.r.zanoni@intel.com
-
- 27 4月, 2018 6 次提交
-
-
由 Ian W MORRISON 提交于
As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 0000:00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2 i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://01.org/linuxgraphics/downloads/firmware and now shows that the firmware has correctly loaded: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) Signed-off-by: NIan W MORRISON <ianwmorrison@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
-
由 José Roberto de Souza 提交于
This was my bad, spec says that the name of this bit is 'Y-coordinate valid' but the values for it is: 0: Include Y-coordinate valid eDP1.4a 1: Do not include Y-coordinate valid eDP 1.4 So not setting it. BSpec: 7713 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-4-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. v3: Reading i915_edp_psr_status was causing PSR to exit but now with 'drm/i915/psr: Prevent PSR exit when a non-pipe related register is written' it is fixed. Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-3-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
This will be helpful to debug what hardware is actually tracking and causing PSR to exit. BSpec: 7721 v4: - Using _MMIO_TRANS2() in PSR_EVENT - Cleaning events before printing Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-2-jose.souza@intel.com
-
由 osé Roberto de Souza 提交于
Any write in any display register was causing HW to exit PSR, masking it to allow more power savings. Writes to pipe related registers will still cause HW to exit PSR. This is already masked for PSR2. It also do not break the Display WA #0884, writes to CURSURFLIVE are still causing hardware to exit PSR. This was tested in CNL machine by triggering a write to CURSURFLIVE when a debugfs was read by user. Bspec: 7721 and 8042 v4: Checked that it do not breaks WA #0884 and added this information to the commit message. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-1-jose.souza@intel.com
-
由 Chris Wilson 提交于
Even though we weren't injecting guilty requests to be reset, we could still fall over the issue of resetting the same request too fast -- where the GPU refuses to start again. (Although it is interesting to note that reloading the driver is sufficient, suggesting that we could recover if we delayed the setup after reset?) Continue to paper over the problem by adding a small delay by waiting for the engine to idle between tests, and ensure that the engines are idle before starting the idle tests. v2: Replace single instance of 50 with a magic macro. References: 02866679 ("drm/i915/selftests: Avoid repeatedly harming the same innocent context") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
-
- 26 4月, 2018 10 次提交
-
-
由 Jani Nikula 提交于
Abstract compliance test adjustments to a single function. Also make the bpc adjustments affect the limits, actually forcing the bpc. Seems like directly changing the pipe_bpp in the past could not have been effective. Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ef61e76003ab7719c82810b742f3fb5765c0e14c.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
For now, there's just the one link config selection, optimizing for slow and wide link. No functional changes. Keep the debug logging in the caller, to avoid duplication later on if alternative link confing selection gets added. v2: Improved commit message Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/64848b76bf90d6ceecd7ec6b5add28531e0b1a41.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Also use same min/max model for bpp, and adjust debug logging while at it. Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/72f78c7ae0cd1810798bd94cbf5e574c78da83f8.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Keep related things together. No functional changes. v2: Fix a typo in patch subject, fix a checkpatch alignment warning. Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f24d44547a586a0e342f24e69ab4d576a2474891.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Abstract a new intel_dp_compute_link_config() from intel_dp_compute_config(), with the parts related to link configuration, i.e. bpp, link rate, and lane count selection. No functional changes. v2: Fix a checkpatch warn about spacing. Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/80f99a625633f87f44d38d487ba3b32ff9a26b07.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be able to debug log the link_bw and rate_select parameters; we don't use the parameters here for anything else. We call intel_dp_compute_rate() again during link training where we actually need and use the parameters. Move the debug logging of link_bw and rate_select to intel_dp_link_training_clock_recovery(), and clean up the extra intel_dp_compute_rate() call and extra clutter from the already overcrowded intel_dp_compute_config(). v2: Rewrote commit message (Rodrigo, Manasi) Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c5cf6a179e2d244eceb6bb80a792765d9efbee4f.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
We haven't used the DP bw constants here for a while. No functional changes. Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1dc7763cdc70c7f64c0a01f76f218d9ac0717227.1524730974.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special circumstances. v2: don't change device info dump (Chris) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426113521.28417-1-jani.nikula@intel.com
-
由 Chris Wilson 提交于
The majority of the engine state dumping is too voluminous to be useful outside of a controlled setup, though a few do accompany severe errors. Keep the debug dumps next to the errors, but hide the others behind a CI compile flag. This becomes more useful when adding more dumps to latency sensitive paths. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426103219.22181-1-chris@chris-wilson.co.uk
-
由 Tvrtko Ursulin 提交于
We can convert engine stats from a spinlock to seqlock to ensure interrupt processing is never even a tiny bit delayed by parallel readers. There is a smidgen bit more cost on the write lock side, and an extremely unlikely chance that readers will have to retry a few times in face of heavy interrupt load. But it should be extremely unlikely given how lightweight read side section is compared to the interrupt processing side, and also compared to the rest of the code paths which can lead into it. Furthermore, writer is the ones doing the real, latency sensitive work, while readers are only informative. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180426074716.7352-1-tvrtko.ursulin@linux.intel.com
-
- 25 4月, 2018 5 次提交
-
-
由 Oscar Mateo 提交于
Interrupt handling in Gen11 is quite different from previous platforms. v2: Rebased (Michel) v3: Rebased with wiggle v4: Rebased, remove TODO warning correctly (Daniele) v5: Rebased, made gen11_gtiir const while at it (Michel) v6: Rebased v7: Adapt to the style currently in upstream Suggested-by: NMichel Thierry <michel.thierry@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Signed-off-by: NOscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMichel Thierry <michel.thierry@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1524605995-22324-1-git-send-email-oscar.mateo@intel.com
-
由 Chris Wilson 提交于
A more complete, and more importantly stable, interface for controlling the RPS frequency range is available in sysfs, obsoleting the unstable debugfs. It's presence seems to trick people into using it, forgetting it is not ABI. References: https://bugs.freedesktop.org/show_bug.cgi?id=106237Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425142334.27113-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
When filling the ring to align the emit pointer to the next cacheline, use memset64() rather than open-coding it. As we know that we always have an even number of dwords, we can replace the dword loop with the qword equivalent. v2: s/0/MI_NOOP<<32 | MI_NOOP/ Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425123718.16366-1-chris@chris-wilson.co.uk
-
由 Lyude Paul 提交于
Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NLyude Paul <lyude@redhat.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411234302.2896-2-lyude@redhat.com
-
由 Chris Wilson 提交于
Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting an engine. It also allows us to react better to the user poking around debugfs for testing missed irqs. v2: Tighten the order of del_timer_sync as the fake_irq timer may trigger the hangcheck timer, and so we should cancel it first and then cancel the hangcheck (Mika) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424142945.6787-1-chris@chris-wilson.co.uk
-
- 24 4月, 2018 8 次提交
-
-
由 Gustavo A. R. Silva 提交于
There is a potential execution path in which variable err is returned without being properly initialized previously. Fix this by initializing variable err to 0. Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable") Fixes: f4ecfbfc ("drm/i915: Check whitelist registers across resets") Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180424131545.GA4053@embeddedor.com
-
由 José Roberto de Souza 提交于
If the initial fbdev configuration (intel_fbdev_initial_config()) runs and there still no sink connected it will cause drm_fb_helper_initial_config() to return 0 as no error happened (but internally the return is -EAGAIN). Because no framebuffer was allocated, when a sink is connected intel_fbdev_output_poll_changed() will not execute drm_fb_helper_hotplug_event() that would trigger another try to do the initial fbdev configuration. So here allowing drm_fb_helper_hotplug_event() to be executed when there is no framebuffer allocated and fbdev was not set up yet. This issue also happens when a MST DP sink is connected since boot, as the MST topology is discovered in parallel if intel_fbdev_initial_config() is executed before the first sink MST is discovered it will cause this same issue. This is a follow-up patch of https://patchwork.freedesktop.org/patch/196089/ Changes from v1: - not creating a dump framebuffer anymore, instead just allowing drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de> Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17 Tested-by: NIan Pilcher <arequipeno@gmail.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
-
由 Chris Wilson 提交于
Knowing the offset of the per-engine scratch/HWS page during boot is not very informative, so remove the DRM_DEBUG. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424115236.2022-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
If we have more than a few, possibly several thousand request in the queue, don't show the central portion, just the first few and the last being executed and/or queued. The first few should be enough to help identify a problem in execution, and most often comparing the first/last in the queue is enough to identify problems in the scheduling. We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common debug scenarios, but for the moment if we can avoiding spending more than a few seconds dumping the GPU state that will avoid a nasty livelock (where hangcheck spends so long dumping the state, it fires again and starts to dump the state again in parallel, ad infinitum). v2: Remember to print last not the stale rq iter after the loop. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424081600.27544-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
printk unhelpfully inserts a '\n' between consecutive calls, and since our drm_printf wrapper may be emitting info a seq_file instead, KERN_CONT is not an option. To work with any drm_printf destination, we need to build up the output into a temporary buf on the stack and then feed the complete line in a single call to printk. Fixes: b7268c5e ("drm/i915: Pack params to engine->schedule() into a struct") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424010839.22860-1-chris@chris-wilson.co.uk
-
由 Mika Kuoppala 提交于
We need to be careful to not let compiler evaluate the expiration and the operation on it's terms. Document and enforce that COND will be evaluated before checking timeout expiration. Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-2-mika.kuoppala@linux.intel.com
-
由 Mika Kuoppala 提交于
We use jiffies to determine when wait expires. However Imre did find out that jiffies can and will do a >1 increments on certain situations [1]. When this happens in a wait_for loop, we return timeout errorneously much earlier than what the real wallclock would say. We can't afford our waits to timeout prematurely. Discard jiffies and change to ktime to detect timeouts. v2: added bugzilla entry (Imre), added stable (Chris) Reported-by: NImre Deak <imre.deak@intel.com> References: https://lkml.org/lkml/2018/4/18/798 [1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771 Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
-
由 Matt Atwood 提交于
Adding a missing GT2 sku discovered off hardware. Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com> Reviewed-by: NClint Taylor <clinton.a.taylor@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1524522483-19987-1-git-send-email-matthew.s.atwood@intel.com
-
- 23 4月, 2018 1 次提交
-
-
https://github.com/intel/gvt-linux由 Jani Nikula 提交于
- Minor condition check improvment (Gustavo A. R. Silva) - Non-priviliged batch buffer scan (Yan Zhao) - Scheduling optimizations (Zhipeng Gong) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5dafba29-b2bd-6b94-630e-db5c009da7e3@intel.com
-