- 27 Feb, 2017 6 commits
-
-
Ander Conselvan de Oliveira authored
According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. v2: Rebase. - Take power domain references before sanitizing encoders. (Imre) - Add comment to get_encoder_power_domains() defition. (Ander) v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI) v4: Put IO power domain before unmapping DPLL. (Imre) - Change return type of intel_ddi_get_power_domains() to u64. (Imre) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> # v1 Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170224141959.5955-1-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
In Geminilake, the DDI IO power domains can't be enabled before a DPLL is running and mapped to the appropriate DDI. At least on Geminilake, attempting to enable those during init will lead to a timeout. The failure to enable the power domain also causes issues with the state verifier during resume from suspend. After all the init power domains are enabled, the call to intel_power_domains_sync_hw() from the resume path will cause the hw_enabled field on the respective power wells to be false while the usage count remains above zero. Further attempts to enable the power domain caused by a modeset will simply update the usage count without doing anything else. When the state verifier attempts to read the state of a DDI encoder, intel_display_power_get_if_enabled() returns false, leading to the following WARN: WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 verify_connector_state.isra.80+0x26c/0x2b0 [i915] attached crtc is active, but connector isn't Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915] CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: G W E 4.10.0-rc3ander+ #300 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0023.B40.1611302145 11/30/2016 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 verify_connector_state.isra.80+0x26c/0x2b0 [i915] intel_atomic_commit_tail+0x520/0x1000 [i915] ? remove_wait_queue+0x70/0x70 intel_atomic_commit+0x3f8/0x520 [i915] ? intel_runtime_pm_put+0x6e/0xa0 [i915] drm_atomic_commit+0x4b/0x50 [drm] __intel_display_resume+0x72/0xc0 [i915] intel_display_resume+0x107/0x150 [i915] i915_drm_resume+0xe0/0x180 [i915] i915_pm_restore+0x1e/0x30 [i915] i915_pm_resume+0xe/0x10 [i915] pci_pm_resume+0x64/0xa0 dpm_run_callback+0xa1/0x2a0 ? pci_pm_thaw+0x90/0x90 device_resume+0xe3/0x200 async_resume+0x1d/0x50 async_run_entry_fn+0x39/0x170 process_one_work+0x212/0x670 ? process_one_work+0x197/0x670 worker_thread+0x4e/0x490 kthread+0x101/0x140 ? process_one_work+0x670/0x670 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x2a/0x40 Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-6-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO power domains. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Don't allow conversion from arbitraty encoder types to a digital port. Calling enc_to_dig_port() with the wrong encoder may seem far fetched, but certain paths of the ddi code may be called with hasell's analog encoder and the conversion is wrong for DP mst encoders too, so safe guard against it. v2: Warn if encoder type is unknown and device is not DDI. (Imre) v3: Remove stray hunk from rebase error. (Ander) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The encoder power domain is obviously tied to the encoder, so store it in struct intel_encoder. This avoids some indirection. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
The aux power domain only makes sense in the DP code. Storing it in struct intel_dp avoids some indirection. v2: Rebase Signed-off-by:
-
- 25 Feb, 2017 4 commits
-
-
Chris Wilson authored
When advancing onto the next 4th level page table entry, we need to reset our indices to 0. Currently we restart from the original address which means we start with an offset into the next PML table. Fixes: 894ccebe ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()") Reported-by:
Matthew Auld <matthew.william.auld@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948 Testcase: igt/drv_selftest/live_gtt Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Tested-by:
-
Chris Wilson authored
We rely on the VMA being allocated inside the drm_mm and for its allotted node being large enough to accommodate all the vma->pages. Signed-off-by:
-
Chris Wilson authored
Before looking up the page directory entry, check we are still within bounds. Signed-off-by:
-
Chris Wilson authored
Double check that we allocated the right amount of scatterlist elements for our obj->size. Signed-off-by:
-
- 24 Feb, 2017 8 commits
-
-
Chris Wilson authored
Check for a timeout in the lowlevel_hole GTT before we allocate state for that pass, as our cleanup phase stops on the iteration before the timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=99947Signed-off-by:
-
Kenneth Graunke authored
This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional feature: I checked the git history of Mesa, xf86-video-intel, libva, and Beignet, and there were zero commits showing a use of these flags. Kernel commit 72bfa19c apparently introduced the feature prematurely. According to Chris, the intention was to use this in cairo-drm, but "the use was broken for gen6", so I don't think it ever happened. 'relative_constants_mode' has always been tracked per-device, but this has actually been wrong ever since hardware contexts were introduced, as the INSTPM register is saved (and automatically restored) as part of the render ring context. The software per-device value could therefore get out of sync with the hardware per-context value. This meant that using them is actually unsafe: a client which tried to use them could damage the state of other clients, causing the GPU to interpret their BO offsets as absolute pointers, leading to bogus memory reads. These flags were also never ported to execlist mode, making them no-ops on Gen9+ (which requires execlists), and Gen8 in the default mode. On Gen8+, userspace can write these registers directly, achieving the same effect. On Gen6-7.5, it likely makes sense to extend the command parser to support them. I don't think anyone wants this on Gen4-5. Based on a patch by Dave Gordon. v3: Return -ENODEV for the getparam, as this is what we do for other obsolete features. Suggested by Chris Wilson. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Imre Deak authored
At least a ParadTech PS175 LSPCON chip/firmware uses long instead of short pulses to signal output unplug/plug events. This is contrary to how branch devices normally work which use short HPD signaling. This chip will also switch to LS mode after an unplug event, which could be the consequence of the long HPD signaling semantics and an effort to save power automatically. Because of this we'll fail to do AUX and detect the output after a replug event. To fix this make sure we are in PCON mode during connector detection. v2: - Switch the mode in the proper spot. Cc: raptorteak@gmail.com Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912 Reported-and-tested-by: raptorteak@gmail.com Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487776252-6288-1-git-send-email-imre.deak@intel.com
-
Chris Wilson authored
We require that the request is completed before the context is switched away. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Ville Syrjälä authored
Rather than sprinkling ideas of how big the DDI buf translation tables are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c where the actual tables are defined. To that end we introduce intel_ddi_dp_voltage_max() which will actually look at the proper translation table to determine what is the maximum voltage swing level supported. v2: Mask out the preemphasis bits from the return value of intel_ddi_dp_voltage_max() Signed-off-by: -
Ville Syrjälä authored
Convert the big switch statement in translate_signal_level() into a neat table. The table also serves as documentation for the translation tables. We'll also have other uses for this table later on. v2: Remove superfluous space (David) Signed-off-by:
-
Ville Syrjälä authored
Split the code to select the correct translation table into DP, eDP and FDI specific helpers. This reduces the clutter in intel_prepare_dp_ddi_buffers(), and we'll have other uses for some of these new helper functions later on. v2: Fix typo in commit message (David) Signed-off-by:
-
Chris Wilson authored
If we cease making progress in finding matching outputs for a tiled configuration, stop looping over the remaining unconfigured outputs. v2: Use conn_seq (instead of pass) to only apply tile configuration on first pass. Fixes: b0ee9e7f ("drm/fb: add support for tiled monitor configurations. (v2)") Signed-off-by:
Tomasz Lis <tomasz.lis@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170224114306.4400-1-chris@chris-wilson.co.uk
-
- 23 Feb, 2017 22 commits
-
-
Chris Wilson authored
If the reserved region of memory has not been setup (most probably because it has been limited by hardware or virtualisation), don't tell the user to try and increase the amount of memory reserved for graphics. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Now that the code is getting simpler, we can reduce the indentation when waiting for the global_seqno. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-17-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we handoff the GPU reset to the waiter, we need to check we don't miss a wakeup if it has already been sent prior to us starting the wait. v2: Tweak checking for reset to be clear to the need before sleeping after changing the task state. Signed-off-by:
-
Chris Wilson authored
Combine the common code for the pair of waiters into a single function. v2: Rename reset_request to wait_request_check_and_reset Signed-off-by:
-
Chris Wilson authored
If we change the wait_queue_t from using the autoremove_wake_function to the default_wake_function, we no longer have to restore the wait_queue_t entry on the wait_queue_head_t list after being woken up by it, as we are unusual in sleeping multiple times on the same wait_queue_t. Signed-off-by:
-
Chris Wilson authored
Add a mock selftest to preempt a request and check that we cancel it, requeue the request and then complete its execution. v2: Error leaks no more. Signed-off-by:
-
Chris Wilson authored
After the request is cancelled, we then need to remove it from the global execution timeline and return it to the context timeline, the inverse of submit_request(). v2: Move manipulation of struct intel_wait to helpers Signed-off-by:
-
Chris Wilson authored
If we preempt a request and remove it from the execution queue, we need to undo its global seqno and restart any waiters. Signed-off-by:
-
Chris Wilson authored
The plan in the near-future is to allow requests to be removed from the signaler. We can no longer then rely on holding a reference to the request for the duration it is in the signaling tree, and instead must obtain a reference to the request for the current operation using RCU. Signed-off-by:
-
Chris Wilson authored
A request is assigned a global seqno only when it is on the hardware execution queue. The global seqno can be used to maintain a list of requests on the same engine in retirement order, for example for constructing a priority queue for waiting. Prior to its execution, or if it is subsequently removed in the event of preemption, its global seqno is zero. As both insertion and removal from the execution queue may operate in IRQ context, it is not guarded by the usual struct_mutex BKL. Instead those relying on the global seqno must be prepared for its value to change between reads. Only when the request is complete can the global seqno be stable (due to the memory barriers on submitting the commands to the hardware to write the breadcrumb, if the HWS shows that it has passed the global seqno and the global seqno is unchanged after the read, it is indeed complete). Signed-off-by:
-
Chris Wilson authored
On reflection, we are only using the execute fence as a waitqueue on the global_seqno and not using it for dependency tracking between fences (unlike the submit and dma fences). By only treating it as a waitqueue, we can then treat it similar to the other waitqueues during submit, making the code simpler. Signed-off-by:
-
Chris Wilson authored
It had only one callsite and existed to keep the code clearer. Now having shared the wait-on-error between phases and with plans to change the wait-for-execute in the next few patches, remove the out of line wait loop and move it into the main body of i915_wait_request. Signed-off-by:
-
Chris Wilson authored
Add ourselves to the gpu error waitqueue earlier on, even before we determine we have to wait on the seqno. This is so that we can then share the waitqueue between stages in subsequent patches. Signed-off-by:
-
Chris Wilson authored
Use a local variable to avoid having to type out the full name of the gpu_error wait_queue. Signed-off-by:
-
Chris Wilson authored
Move the companion functions next to each other. Signed-off-by:
-
Chris Wilson authored
Replace the global device seqno with one for each engine, and account for in-flight seqno on each separately. This is consistent with dma-fence as each timeline has separate fence-contexts for each engine and a seqno is only ordered within a fence-context (i.e. seqno do not need to be ordered wrt to other engines, just ordered within a single engine). This is required to enable request rewinding for preemption on individual engines (we have to rewind the global seqno to avoid overflow, and we do not have to rewind all engines just to preempt one.) v2: Rename active_seqno to inflight_seqnos to more clearly indicate that it is a counter and not equivalent to the existing seqno. Update functions that operated on active_seqno similarly. Signed-off-by:
-
Chris Wilson authored
When dma_fence_signal() is called, it sets a flag to indicate the fence is complete. Before the dma_fence is signaled, the seqno check will first be passed. During an unlocked check (such as inside a waiter), it is possible for the fence to be signaled even though the seqno has been reset (by engine wraparound). In this case the waiter will be kicked, but for an extra layer of protection we can check the persistent signaled bit from the fence. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
This reverts commit 7ee68603 "drm/i915/dp: Ratelimit DP aux timeout messages" as although it successfully squelches the debug messages, when it does so it generates a warning instead. CI lights up orange with all the warnings! In its current incarnation DRM_DEBUG_RATELIMITED is not usable for us, and we need to first teach lib/ratelimit.c not to warn when used for debug messages. Fixes: 7ee68603 ("drm/i915/dp: Ratelimit DP aux timeout messages") Signed-off-by:
-
Ander Conselvan de Oliveira authored
Geminilake scalers can do 7x7 filtering for all supported input sizes, so it doesn't need the "high quality" mode programming, which was actually removed from that platform. v2: Split dev_priv parameter change out. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>, Signed-off-by:
-
Ander Conselvan de Oliveira authored
Pass dev_priv to intel_atomic_setup_scalers(). The next patch will need a dev_priv pointer. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
Geminilake can output two pixels per clock, and that affects the maximum scaling factor for its scalers. Take that into account and avoid the following warning: WARNING: CPU: 1 PID: 593 at drivers/gpu/drm/i915/intel_display.c:13223 skl_max_scale.part.129+0x78/0x80 [i915] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Modules linked in: x86_pkg_temp_thermal i915 coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul prime_numbers crc32_pclmul drm ghash_clmulni_intel shpchp tpm_tis tpm_tis_core tpm nfsd authw CPU: 1 PID: 593 Comm: kworker/u8:3 Tainted: G W 4.10.0-rc8ander+ #330 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0035.B33.1702150552 02/15/2017 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 skl_max_scale.part.129+0x78/0x80 [i915] intel_check_primary_plane+0xa6/0xc0 [i915] intel_plane_atomic_check_with_state+0xd1/0x1a0 [i915] ? drm_printk+0xb5/0xc0 [drm] intel_plane_atomic_check+0x3d/0x80 [i915] drm_atomic_helper_check_planes+0x7c/0x200 [drm_kms_helper] intel_atomic_check+0xa5b/0x11a0 [i915] drm_atomic_check_only+0x353/0x600 [drm] ? drm_atomic_add_affected_connectors+0x10c/0x120 [drm] drm_atomic_commit+0x18/0x50 [drm] restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] intel_fbdev_set_par+0x1a/0x70 [i915] fbcon_init+0x582/0x610 visual_init+0xd6/0x130 do_bind_con_driver+0x1da/0x3c0 do_take_over_console+0x116/0x180 do_fbcon_takeover+0x5c/0xb0 fbcon_event_notify+0x772/0x8a0 ? __blocking_notifier_call_chain+0x35/0x70 notifier_call_chain+0x4a/0x70 __blocking_notifier_call_chain+0x4d/0x70 blocking_notifier_call_chain+0x16/0x20 fb_notifier_call_chain+0x1b/0x20 register_framebuffer+0x278/0x360 drm_fb_helper_initial_config+0x253/0x440 [drm_kms_helper] intel_fbdev_initial_config+0x18/0x30 [i915] async_run_entry_fn+0x39/0x170 process_one_work+0x212/0x670 ? process_one_work+0x197/0x670 worker_thread+0x4e/0x490 kthread+0x101/0x140 ? process_one_work+0x670/0x670 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x31/0x40 v2: s/max_pixclk/max_dotclk/ (Ville) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
Geminilake has a third sprite plane (or fourth universal plane) that is independent from the cursor. Make sure that for_each_plane_id_on_crtc() is aware of that extra plane so that the watermark code takes it into account. Fixes: e9c98825 ("drm/i915/glk: Configure number of sprite planes properly") Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <drm-intel-fixes@lists.freedesktop.org> Signed-off-by:
-
