- 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:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475664617-24541-1-git-send-email-joonas.lahtinen@linux.intel.com
-
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:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161004201132.21801-8-chris@chris-wilson.co.uk
-
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 3 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:
-
Chris Wilson authored
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=97985Signed-off-by:
-
- 30 Sep, 2016 1 commit
-
-
Paulo Zanoni authored
We were previously adding all the planes owned by the CRTC even when the ddb partitioning didn't change for them. As a consequence, a lot of functions were being called when we were just moving the cursor around the screen, such as skylake_update_primary_plane(). This was causing flickering on the primary plane when moving the cursor. I'm not 100% sure which operation caused the flickering, but we were writing to a lot of registers, so it could be any of these writes. With this patch, just moving the mouse won't add the primary plane to the commit since it won't trigger a change in DDB partitioning. v2: Use skl_ddb_entry_equal() (Lyude). v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch Fixes: 05a76d3d ("drm/i915/skl: Ensure pipes with changed wms get added to the state") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888 Cc: Mike Lothian <mike@fireburn.co.uk> Cc: stable@vger.kernel.org Reported-by:
Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475177808-29955-1-git-send-email-paulo.r.zanoni@intel.com
-
- 29 Sep, 2016 1 commit
-
-
Dhinakaran Pandiyan authored
This reverts 'commit 3708d5e0 ("drm/i915: start adding dp mst audio")' because it breaks MST multi-monitor setups on some platforms. Fixes: 3708d5e0 ("drm/i915: start adding dp mst audio") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reported-by:
Kim Lidström <kim@dxtr.im> Cc: Libin Yang <libin.yang@linux.intel.com> Cc: Lyude <cpaul@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 28 Sep, 2016 2 commits
-
-
Ville Syrjälä authored
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it forbidden to set it for LVDS/CRT as well. So let's also set it on CRT to make it possible to share the DPLL between HDMI and CRT. What that bit apparently does is enable the x5 clock to the port, which then pumps out the bits on both edges of the clock. The DAC doesn't need that clock since it's not pumping out bits, but I don't think it hurts to have the DPLL output that clock anyway. This is fairly important on IVB since it has only two DPLLs with three pipes. So trying to drive three or more PCH ports with three pipes is only possible when at least one of the DPLLs gets shared between two of the pipes. SNB doesn't really need to do this since it has only two pipes. It could be done to avoid enabling the second DPLL at all in certain cases, but I'm not sure that's such a huge win. So let's not do it for SNB, at least for now. On ILK it never makes sense as the DPLLs can't be shared. v2: Just always enable the high speed clock to keep things simple (Daniel) Beef up the commit message a bit (Daniel) Cc: Nick Yamane <nick.diego@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Tested-by:Nick Yamane <nick.diego@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204Signed-off-by:
-
Navare, Manasi D authored
Replace dev with dev_priv and INTEL_INFO with INTEL_GEN v1: * Rebased on drm-nightly (Jani Nikula) * Separated from the link training patch series Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
