- 09 Feb, 2017 2 commits
-
-
Ander Conselvan de Oliveira authored
This shaves a few lines from intel_dp_init_connector() and will serve as a good place to add other port specific information in a follow up patch. While at it, convert BUG() to MISSING_CASE() in the default case. v2: s/BUG/MISSING_CASE. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170203140316.20792-2-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Remove workaround for swapped HPD pins in broxton A stepping, which is pre-production hardware. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 08 Feb, 2017 22 commits
-
-
Chris Wilson authored
When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may race with the engine to restart, and so may corrupt the current state. Disabling the engine->irq_tasklet prevents the two paths from writing into ELSP simultaneously (and modifyin the execlists_port[] at the same time). Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Testcase: igt/gem_exec_fence/await-hang Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170208143033.11651-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently we do a reset prepare/finish around the call to reset the GPU, but it looks like we need a later stage after the hw has been reinitialised to allow GEM to restart itself. Start by splitting the 2 GEM phases into 3: prepare - before the reset, check if GEM recovered, then stop GEM reset - after the reset, update GEM bookkeeping finish - after the re-initialisation following the reset, restart GEM Signed-off-by:
-
Chris Wilson authored
Just a simple refactor to move a loop and some support code out of i915_gem_init_hw(). This is in preparation for avoiding a race between the tasklet writing to ELSP whilst simultaneously being written by engine->init_hw() following a GPU reset. Signed-off-by:
-
Chris Wilson authored
Since to unbind an object, we may need a powered up device to access the GTT entries, we only shrink bound objects if awake. Callers to i915_gem_shrink_all() had to take this into account and take the rpm wakeref, but we can move this wakeref into the shrink_all itself for convenience and making the function live up to its name. Signed-off-by:
-
Ville Syrjälä authored
Move ilk_pipe_pixel_rate() next to its only caller (intel_crtc_compute_pixel_rate()). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-15-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
With the cdclk state, all the .modeset_commit_cdclk() hooks are now pointless wrappers. Let's replace them with just a .set_cdclk() function pointer. However let's wrap that in a small helper that does the state comparison and prints a unified debug message across all platforms. We didn't even have the debug print on all platforms previously. This reduces the clutter in intel_atomic_commit_tail() a little bit. v2: Wrap .set_cdclk() in intel_set_cdclk() v3: Add kernel-docs v4: Deal with IS_GEN9_BC() Signed-off-by:
-
Ville Syrjälä authored
The hack to grab the pipe A power domain around VLV/CHV cdclk programming has surely outlived its usefulness. We should be holding sufficient power domains during any modeset, so let's just nuke this hack. v2: Fix typo in commit message (Ander) Signed-off-by:
-
Ville Syrjälä authored
Move the vlv_program_pfi_credits() into vlv_set_cdclk() and chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk(). v2: Do the PFI programming after cdclk readout since it currently depends on the readout to fill dev_priv->cdclk.hw Signed-off-by: -
Ville Syrjälä authored
Rather than passing all the different parameters (cdclk,vco so far) sparately to the set_cdclk() functions, just pass the entire cdclk state. v2: Deal with churn v3: Drop the usless .ref assignment (Ander) Signed-off-by:
-
Ville Syrjälä authored
Clean up the dev vs. dev_priv straggles that are making things look inconsistentt. v2: Deal with churn Signed-off-by:
-
Ville Syrjälä authored
The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess. So here I'm introducing the "actual" and "logical" naming for our cdclk state. "actual" is what we'll bash into the hardware and "logical" is what everyone should use for state computaion/checking and whatnot. We'll track both using the intel_cdclk_state as both will need other differing parameters than just the actual cdclk frequency. While doing that we can at the same time unify the appearance of the .modeset_calc_cdclk() implementations a little bit. v2: Commit dev_priv->cdclk.actual since that already has the new state by the time .modeset_commit_cdclk() is called. v3: s/locical/logical/ and improve the docs a bit Signed-off-by: -
Ville Syrjälä authored
Introduce intel_cdclk state which for now will track the cdclk frequency, the vco frequency and the reference frequency (not sure we want the last one, but I put it there anyway). We'll also make the .get_cdclk() function fill out this state structure rather than just returning the current cdclk frequency. One immediate benefit is that calling .get_cdclk() will no longer clobber state stored under dev_priv unless ex[plicitly told to do so. Previously it clobbered the vco and reference clocks stored there on some platforms. We'll expand the use of this structure to actually precomputing the state and whatnot later. v2: Constify intel_cdclk_state_compare() v3: Document intel_cdclk_state_compare() v4: Deal with i945gm_get_cdclk() Signed-off-by:
-
Ville Syrjälä authored
Rather than compute the vco inside bxt_set_cdclk() let's precompute it outside and pass it in. A small step towards a fully precomputed cdclk state. Signed-off-by:
-
Ville Syrjälä authored
Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk stuff to a new file. It's all reasonably self contained so we don't even have to add that many non-static symbols. We'll also take the opportunity to shuffle around the functions a bit to get things in a more consistent order based on the platform. v2: Add kernel-docs (Ander) v3: Deal with IS_GEN9_BC() v4: Deal with i945gm_get_cdclk() Signed-off-by:
-
Ville Syrjälä authored
Let's clean up the mess we have in the if ladder that assigns the .get_cdclk() hooks. The grouping of the platforms by the function results in a thing that's not really legible, so let's do it the other way around and order the if ladder by platform and duplicate whatever assignments we need. To further avoid confusion with the function names let's rename them to just fixed_<freq>_get_cdclk(). The other option would be to duplicate the functions entirely but it seems quite pointless to do that since each one just returns a fixed value. v2: Deal with i945gm_get_cdclk() Signed-off-by:
-
Ville Syrjälä authored
Rename the .get_display_clock_speed() hook to .get_cdclk(). .get_cdclk() is more specific (which clock) and it's much shorter. v2: Deal with IS_GEN9_BC() v3: Deal with i945gm_get_display_clock_speed() Signed-off-by:
-
Ville Syrjälä authored
ilk_max_pixel_rate() will now give the "correct" pixel rate for all platforms, so let's rename it to intel_max_pixel_rate() and kill off intel_mode_max_pixclk(). v2: Fix typo in commit message (Ander) Signed-off-by:
-
Ville Syrjälä authored
Rather than recomputing the pipe pixel rate on demand everywhere, let's just stick the precomputed value into the crtc state. v2: Rebase due to min_pixclk[] code movement Document the new pixel_rate struct member (Ander) Combine vlv/chv with bdw+ in intel_modeset_readout_hw_state() v3: Fix typos in commit message (David) Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com> Signed-off-by: -
Tvrtko Ursulin authored
Currently to establish whether GuC firmware has been loaded or submission enabled (default DRM log level), one has to detect the absence of the message saying that the load has been skipped and infer the opposite. It is better to log the fact GuC firmware has been loaded and/or submission enabled explicitly to avoid any guesswork when looking at the logs. v2: * Log message polish. (Chris) * Future proof by reporting found firmware version. (Michal) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Joonas Lahtinen authored
Macro seems to do exactly the same thing. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Joonas Lahtinen authored
"BIT(max) - 1" will overflow when max = 32, and GCC will complain. We already have GENMASK for generating the mask, use it! v2: Majestic off by one spotted (Chris) Signed-off-by:
-
Michał Winiarski authored
We're using non-canonical addresses in drm_mm, and we're making sure that userspace is using canonical addressing - both in case of softpin (verifying incoming offset) and when relocating (converting to canonical when updating offset returned to userspace). Unfortunately when considering the need for relocations, we're comparing offset from userspace (in canonical form) with drm_mm node (in non-canonical form), and as a result, we end up always relocating if our offsets are in the "problematic" range. Let's always convert the offsets to avoid the performance impact of relocations. Fixes: a5f0edf6 ("drm/i915: Avoid writing relocs with addresses in non-canonical form") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Reported-by:
Michał Pyrzowski <michal.pyrzowski@intel.com> Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207195559.18798-1-michal.winiarski@intel.comReviewed-by:
-
- 07 Feb, 2017 3 commits
-
-
Chris Wilson authored
Following a reset, the context and page directory registers are lost. However, the queue of requests that we resubmit after the reset may depend upon them - the registers are restored from a context image, but that restore may be inhibited and may simply be absent from the request if it was in the middle of a sequence using the same context. If we prime the CCID/PD registers with the first request in the queue (even for the hung request), we prevent invalid memory access for the following requests (and continually hung engines). v2: Magic BIT(8), reserved for future use but still appears unused. v3: Some commentary on handling innocent vs guilty requests v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my Ivybridge, but this bit probably exists for a reason. Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
-
Arthur Heymans authored
This is according to Mobile Intel
® 945 Express Chipset Family datasheet. Signed-off-by:Arthur Heymans <arthur@aheymans.xyz> Link: http://patchwork.freedesktop.org/patch/msgid/20170131235026.26003-1-arthur@aheymans.xyzReviewed-by:
-
Chris Wilson authored
The goal of the WARN was to catch when we are still actively using the fence as we go into the runtime suspend. However, the reg->pin_count is too coarse as it does not distinguish between exclusive ownership of the fence register from activity. I've not improved on the WARN, nor have we captured this WARN in an exact igt, but it is showing up regularly in the wild: [ 1915.935332] WARNING: CPU: 1 PID: 10861 at drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 [i915] [ 1915.935383] WARN_ON(reg->pin_count)[ 1915.935399] Modules linked in: snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper] [ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G U W 4.9.0-rc5+ #170 [ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015 [ 1915.935822] Workqueue: pm pm_runtime_work [ 1915.935845] ffffc900044fbbf0 ffffffffac3220bc ffffc900044fbc40 0000000000000000 [ 1915.935890] ffffc900044fbc30 ffffffffac059bcb 000007e6044fbc60 ffff8801626e3198 [ 1915.935937] ffff8801626e0000 0000000000000002 ffffffffc05e5d4e 0000000000000000 [ 1915.935985] Call Trace: [ 1915.936013] [<ffffffffac3220bc>] dump_stack+0x4f/0x73 [ 1915.936038] [<ffffffffac059bcb>] __warn+0xcb/0xf0 [ 1915.936060] [<ffffffffac059c4f>] warn_slowpath_fmt+0x5f/0x80 [ 1915.936158] [<ffffffffc052d916>] i915_gem_runtime_suspend+0x116/0x130 [i915] [ 1915.936251] [<ffffffffc04f1c74>] intel_runtime_suspend+0x64/0x280 [i915] [ 1915.936277] [<ffffffffac0926f1>] ? dequeue_entity+0x241/0xbc0 [ 1915.936298] [<ffffffffac36bb85>] pci_pm_runtime_suspend+0x55/0x180 [ 1915.936317] [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1915.936339] [<ffffffffac4514e2>] __rpm_callback+0x32/0x70 [ 1915.936356] [<ffffffffac451544>] rpm_callback+0x24/0x80 [ 1915.936375] [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1915.936392] [<ffffffffac45222d>] rpm_suspend+0x12d/0x680 [ 1915.936415] [<ffffffffac69f6d7>] ? _raw_spin_unlock_irq+0x17/0x30 [ 1915.936435] [<ffffffffac0810b8>] ? finish_task_switch+0x88/0x220 [ 1915.936455] [<ffffffffac4534bf>] pm_runtime_work+0x6f/0xb0 [ 1915.936477] [<ffffffffac074353>] process_one_work+0x1f3/0x4d0 [ 1915.936501] [<ffffffffac074678>] worker_thread+0x48/0x4e0 [ 1915.936523] [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0 [ 1915.936542] [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0 [ 1915.936559] [<ffffffffac07a2c9>] kthread+0xd9/0xf0 [ 1915.936580] [<ffffffffac07a1f0>] ? kthread_park+0x60/0x60 [ 1915.936600] [<ffffffffac69fe62>] ret_from_fork+0x22/0x30 In the case the register is pinned, it should be present and we will need to invalidate them to be restored upon resume as we cannot expect the owner of the pin to call get_fence prior to use after resume. Fixes: 7c108fd8 ("drm/i915: Move fence cancellation to runtime suspend") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98804Reported-by:
Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com> Signed-off-by:
-
- 06 Feb, 2017 13 commits
-
-
Chris Wilson authored
Alongside the hw capabilities, it is useful to know which of those have been overridden by the user setting module parameters. v2: Use __always_inline and BUILD_BUG magic Signed-off-by:
-
Chris Wilson authored
They include useful material such as what mode the VM address space is running in, what submission mode, extra quirks, etc. v2: Undef the right macro, use type specific pretty printers v3: Use strcmp(TYPENAME) rather than creating per-type pretty printers v4: Use __always_inline to force GCC to eliminate the calls to strcmp and generate the right call to seq_printf for each parameter. v5: With the strcmp elimination, we can now use BUILD_BUG to ensure there are no unhandled types, also use __builtin_strcmp to make it look even more magic. Signed-off-by:
-
Chris Wilson authored
The alpha_support module option can only take one of two values, so assign it to a boolean type. The only advantage is in pretty printing via /sys/module/i915/parameters/alpha_support and elsewhere. Signed-off-by:
-
Chris Wilson authored
I want to print the struct from the error state and so would like to use the existing struct definition as the template ala DEV_INFO* v2: Use MEMBER() rather than p(). Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170206213608.31328-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
In commit 86aa7e76 ("drm/i915: Assert that the context-switch completion matches our context") I added a read to the irq tasklet handler that compared the on-chip status with that of our sw tracking, using an unguarded read of the request pointer to get the context and beyond. Whilst we hold a reference to the request, we do not hold anything on the context and if we are unlucky it may be reaped from a second thread retiring the request (since it may retire the request as soon as the breadcrumb is complete, even before we finish processing the context switch) as we try to read from the context pointer. Avoid the racy read from underneath the request by storing the expected result in the execlist_port[]. v2: Include commentary about port[].request being unprotected. Fixes: 86aa7e76 ("drm/i915: Assert that the context-switch completion matches our context") Reported-by:
-
Chris Wilson authored
It is required that the caller declare the exact number of dwords they wish to write into the ring. This is required for two reasons, we need to allocate sufficient space for the entire command packet and we need to be sure that the contents are completely written to avoid executing stale data. The current interface requires for any bug to be caught in review, the reader has to carefully count the number of intel_ring_emit() between intel_ring_begin() and intel_ring_advance(). If we record the end of the packet of each intel_ring_begin() we can also have CI check for us. Signed-off-by:
-
Zhi Wang authored
execlist_update_context() will try to update PDPs in a context before a ELSP submission only for full PPGTT mode, while PDPs was populated during context initialization. Now the latter code path is removed. Let execlist_update_context() also cover !FULL_PPGTT mode. Fixes: 34869776 ("drm/i915: check ppgtt validity when init reg state") Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1486377436-15380-1-git-send-email-zhi.a.wang@intel.comReviewed-by:
-
Imre Deak authored
To be consistent with the recent change to enable hotplug detection early on GEN9 platforms do the same on all non-GMCH platforms starting from GEN5. On GMCH platforms enabling detection without interrupts isn't trivial, since AUX and HPD have a shared interrupt line. It could be done there too by using a SW interrupt mask, but I punt on that for now. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-5-git-send-email-imre.deak@intel.com
-
Imre Deak authored
This effectively reverts commit 489375c8 Author: Imre Deak <imre.deak@intel.com> Date: Mon Oct 24 19:33:31 2016 +0300 drm/i915/lspcon: Add workaround for resuming in PCON mode The workaround was added without considering that HPD is low during the failed AUX transfers the WA fixed. Since the previous patch we wait for HPD to get asserted. My tests also show that this happens _after_ the DPCD reads start to return correct values. This suggests that we don't need this WA any more, let's try to remove it to reduce the clutter. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Imre Deak authored
During system resume time initialization the HPD level on LSPCON ports can stay low for an extended amount of time, leading to failed AUX transfers and LSPCON initialization. Fix this by waiting for HPD to get asserted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99178 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by:
-
Imre Deak authored
For LSPCON resume time initialization we need to sample the corresponding pin's HPD level, but this is only available when HPD detection is enabled. Currently we enable detection only when enabling HPD interrupts which is too late, so bring the enabling of detection earlier. This is needed by the next patch. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by:
-
Chris Wilson authored
As we now mark the reserved hole (drm_mm.head_node) with the special UNEVICTABLE color, we can use the page coloring to avoid prefetching of the CS beyond the end of the GTT. Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
The drm_mm range manager (within i915_address_space) uses a special drm_mm_node that excludes the unavailable range (beyond the end of the drm_mm). However, we play games with the global GTT to use the head_node to exclude the tail page but tell ourselves that the whole range is available. This causes an issue when we try to evict using the full range of the global GTT which is wider than the drm_mm, resulting in complete confusion and catastrophe. One way to resolve this would be to use a reserved node to exclude the guard page, or we can treat the drm_mm's head_node as our guard page and assign it the appropriate colour. Signed-off-by:
-
