- 22 May, 2018 3 commits
-
-
Jani Nikula authored
This reverts commit dc911f5b. Per the report, no matter what display mode you select with xrandr, the i915 driver will always select the alternate fixed mode. For the reporter this means that the display will always run at 40Hz which is quite annoying. This may be due to the mode comparison. But there are some other potential issues. The choice of alt_fixed_mode seems dubious. It's the first non-preferred mode, but there are no guarantees that the only difference would be refresh rate. Similarly, there may be more than one preferred mode in the probed modes list, and the commit changes the preferred mode selection to choose the last one on the list instead of the first. (Note that the probed modes list is the raw, unfiltered, unsorted list of modes from drm_add_edid_modes(), not the pretty result after a drm_helper_probe_single_connector_modes() call.) Finally, we already have eerily similar code in place to find the downclock mode for DRRS that seems like could be reused here. Back to the drawing board. Note: This is a hand-crafted revert due to conflicts. If it fails to backport, please just try reverting the original commit directly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469Reported-by:
Rune Petersen <rune@megahurts.dk> Reported-by:
Mark Spencer <n7u4722r35@ynzlx.anonbox.net> Fixes: dc911f5b ("drm/i915/edp: Allow alternate fixed mode for eDP if available.") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.14+ Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nikula@intel.com
-
Daniel Stone authored
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. v2: Only hold a single reference per framebuffer, not per plane. (Ville) v3: Drop NULL check in intel_fb_obj. (Ville) Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-2-daniels@collabora.com
-
Daniel Stone authored
We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by:
-
- 21 May, 2018 1 commit
-
-
Zhenyu Wang authored
When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context. v2: Move request alloc earlier as already try to track shadow status depending on request state, which also facilitate to use request->hw_context for target engine context reference. Fixes: 1fc44d9b ("drm/i915: Store a pointer to intel_context in i915_request") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Weinan Li <weinan.z.li@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 19 May, 2018 6 commits
-
-
Chris Wilson authored
When testing reset, we wait for 1s on the main thread for the hang to start. Meanwhile, we continue submitting requests on all the background threads, and we may have more threads than cores and so potentially starve the waiter from being woken within the timeout. As the hang timeout and the active timeouts are the same, it is hard to distinguish which caused the timeout. Bump the active thread timeouts to 5s, compared to the 1s timeout for the hang, so that we preferentially report the hang timing out, while hopefully ensuring that we do at least wake up the hang thread first before declaring the background active timeout. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
In order to support engine reset from irq (timer) context, we need to be able to re-initialise the breadcrumbs. So we need to promote the plain spin_lock_irq to a safe spin_lock_irqsave. Signed-off-by:
-
Chris Wilson authored
We want to be able to reset the GPU from inside a timer callback (hardirq context). One step requires us to copy the default context state over to the guilty context, which means we need to plan in advance to have that object accessible from within an atomic context. The atomic context prevents us from pinning the object or from peeking into the shmemfs backing store (all may sleep), so we choose to pin the default_state into memory when the engine becomes active. This compromise allows us to swap out the default state when idle, when required. References: 5692251c ("drm/i915/lrc: Scrub the GPU state of the guilty hanging request") Signed-off-by:
-
Chris Wilson authored
To be useful later, enable intel_engine_dump() to be called from irq context (i.e. using saving and restoring irq start rather than assuming we enter with irqs enabled). Signed-off-by:
-
Chris Wilson authored
We rely on ksoftirqd to run in a timely fashion in order to drain the execlists queue. Quite frequently, it does not. In some cases we may see latencies of over 200ms triggering our idle timeouts and forcing us to declare the driver wedged! Thus we can speed up idle detection by bypassing ksoftirqd in these cases and flush our tasklet to confirm if we are indeed still waiting for the ELSP to drain. v2: Put the execlists.first check back; it is required for handling reset! References: https://bugs.freedesktop.org/show_bug.cgi?id=106373Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180506171328.30034-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Delay registering ourselves with the acpi lid notification mechanism until we are registering the connectors after initialisation is complete. This prevents a possibility of trying to handle the lid notification before we are ready with the danger of chasing uninitialised function pointers. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: (null) PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP PTI Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod ehci_pci ehci_hcd usbcore usb_common i8042 serio CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1 Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012 RIP: 0010: (null) RSP: 0018:ffffaf4580c33a18 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffff947533558000 RCX: 000000000000003e RDX: ffffffffc0aa80c0 RSI: ffffaf4580c33a3c RDI: ffff947534e4c000 RBP: ffff947533558338 R08: ffff947534598930 R09: ffffffffc0a928b1 R10: ffffd8f181d5fd40 R11: 0000000000000000 R12: ffffffffc0a928b1 R13: ffff947533558368 R14: ffffffffc0a928a9 R15: ffff947534e4c000 FS: 00007f3dc4ddb940(0000) GS:ffff947539280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000006e214000 CR4: 00000000000406e0 Call Trace: ? intel_modeset_setup_hw_state+0x385/0xf60 [i915] ? __intel_display_resume+0x1e/0xc0 [i915] ? intel_display_resume+0xcc/0x120 [i915] ? intel_lid_notify+0xbc/0xc0 [i915] ? notifier_call_chain+0x47/0x70 ? blocking_notifier_call_chain+0x3e/0x60 ? acpi_lid_notify_state+0x8f/0x1d0 ? acpi_lid_update_state+0x49/0x70 ? acpi_lid_input_open+0x60/0x90 ? input_open_device+0x5d/0xa0 ? evdev_open+0x1ba/0x1e0 [evdev] ? chrdev_open+0xa3/0x1b0 ? cdev_put.part.0+0x20/0x20 ? do_dentry_open+0x14c/0x300 ? path_openat+0x30c/0x1240 ? current_time+0x16/0x60 ? do_filp_open+0x93/0x100 ? __check_object_size+0xfb/0x180 ? do_sys_open+0x186/0x210 ? do_syscall_64+0x74/0x190 ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Code: Bad RIP value. RIP: (null) RSP: ffffaf4580c33a18 CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559 Fixes: c1c7af60 ("drm/i915: force mode set at lid open time") Signed-off-by:
-
- 18 May, 2018 10 commits
-
-
Ville Syrjälä authored
i965 does not have native DP. Let's rename the remaining gen4 references in the DP code to g4x. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-5-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
To make the intent more clear, let's rename the signal level funcs for the SNB/IVB CPU eDP. Signed-off-by:
-
Ville Syrjälä authored
Almost all of the GEN7 checks in the DP code are actually looking for IVB. HSW doesn't even take these codepaths, and VLV is excluded on account of not having port A. So let's change the checks to IS_IVB to make the code less confusing. Reviewed-by:
-
Ville Syrjälä authored
All DDI platforms support the full set of preemph settings for each supported vswing, so let's use the same code for them. We'll also move the code into intel_ddi.c so that it sits closer to the actual buf trans tables. Signed-off-by:
-
Ville Syrjälä authored
Use intel_ddi_dp_voltage_max() for HSW/BDW too instead of letting these fall through the if ladder in a weird way. This function will look at the actual buf trans tables we have for HSW/BDW to determine the max vswing level. It looks to me like the current code leads HSW port A down the IVB port A path, HSW port B+ and BDW fall through to the very end. Both cases do result in the correct max vswing level 2, but it's very hard to see that from the code. Signed-off-by:
-
Ondrej Zary authored
Radiant P845 does not have LVDS, only VGA. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Chris Wilson authored
As all backends implement the same pin_count mechanism and do a dec-and-test as their first step, pull that into the common intel_context_unpin(). This also pulls into the caller, eliminating the indirect call in the usual steady state case. The intel_context_pin() side is a little more complicated as it combines the lookup/alloc as well as pinning the state, and so is left for a later date. Signed-off-by:
-
Chris Wilson authored
To ease the frequent and ugly pointer dance of &request->gem_context->engine[request->engine->id] during request submission, store that pointer as request->hw_context. One major advantage that we will exploit later is that this decouples the logical context state from the engine itself. v2: Set mock_context->ops so we don't crash and burn in selftests. Cleanups from Tvrtko. Signed-off-by: -
Chris Wilson authored
Move the knowledge about resetting the current context tracking on the engine from inside i915_gem_context.c into intel_engine_cs.c Signed-off-by:
-
Chris Wilson authored
In the next patch, we want to store the intel_context pointer inside i915_request, as it is frequently access via a convoluted dance when submitting the request to hw. Having two context pointers inside i915_request leads to confusion so first rename the existing i915_gem_context pointer to i915_request.gem_context. Signed-off-by:
-
- 17 May, 2018 10 commits
-
-
Paulo Zanoni authored
For all platforms that run haswell_crtc_enable, our spec tells us to configure the transcoder clocks and do link training before it tells us to set pipeconf and the other pipe/transcoder/plane registers. Starting from Icelake, we get machine hangs if we try to touch the pipe/transcoder registers without having the clocks configured and not having some chicken bits set. So this patch changes haswell_crtc_enable() to issue the calls at the appropriate order mandated by the spec. While setting the appropriate chicken bits would also work here, it's better if we actually program the hardware the way it is intended to be programmed. And the chicken bit also has some theoretical downsides that may or may not affect us. Also, correctly programming the hardware does not prevent us from setting the chicken bits in a later patch in case we decide to. v2: Don't forget link training (Ville). Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502215851.30736-1-paulo.r.zanoni@intel.com
-
Oscar Mateo authored
Stop reading some now deprecated interrupt registers in both debugfs and error state. Instead, read the new equivalents in the Gen11 interrupt repartitioning scheme. Note that the equivalent to the PM ISR & IIR cannot be read without affecting the current state of the system, so I've opted for leaving them out. See gen11_reset_one_iir() for more info. v2: else if !!! (Paulo) v3: another else if (Vinay) v4: - Rebased - Renamed patch - Improved the ordering of GENs - Improved the printing of per-GEN info v5: Avoid maybe-unitialized & add comment explaining the lack of PM ISR & IIR Suggested-by:Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> [Paulo: fix commit message and coding style.] Signed-off-by:
-
Chris Wilson authored
The command parser is feature complete, stable and required by userspace. In commit 41736a8e ("drm/i915: Use the precomputed value for whether to enable command parsing") I accidentally removed control from the modparam, and as no one has complained, remove the left over modparam completely! References: 41736a8e ("drm/i915: Use the precomputed value for whether to enable command parsing") Signed-off-by:
-
Chris Wilson authored
Make sure that when we don't have any scheduler attributes for the request, the string is terminated. Fixes: 247870ac ("drm/i915: Build request info on stack before printk") Signed-off-by:
-
Chris Wilson authored
The HWACK bit more generically solves the problem of resubmitting ESLP while the hardware is still processing the current ELSP write. We no longer need to check port[0].count itself. References: ba74cb10 ("drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write") Signed-off-by:
-
Ville Syrjälä authored
Parametrize the DVO pipe select bits. For consistency with the new way of doing things, let's read out the pipe select bits even when the port is disable, even though we don't need that behaviour for asserts in this case. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
Ville Syrjälä authored
Parametrize the TV pipe select bits. For consistency with the new way of doing things, let's read out the pipe select bits even when the port is disable, even though we don't need that behaviour for asserts in this case. v2: Order the defines shift,mask,value (Jani) Clear the stale pipe select bit in load detection (Jani) Reviewed-by: -
Ville Syrjälä authored
Clean up the SDVO pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
Ville Syrjälä authored
Clean up the LVDS pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Drop ruperfluous braces and whitesapce changes (Jani) Combine masks in compute_is_dual_link_lvds() (Jani) v3: Fix LVDS_PIPE_SEL_MASK_CPT Reviewed-by: -
Ville Syrjälä authored
Clean up the ADPA pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state() and the port state asserts. v2: Order the defines shift,mask,value (Jani) Reviewed-by:
-
- 16 May, 2018 10 commits
-
-
Chris Wilson authored
We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so that the GPU doesn't emit the breadcrumb for our chosen "guilty" request. v2: Refactor setting STOP_RING so that we don't have the same code thrice Signed-off-by:
-
Chris Wilson authored
Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. Signed-off-by:
-
Chris Wilson authored
Pull the CSB event processing into its own routine so that we can reuse it during reset to flush any missed interrupts/events. Signed-off-by:
-
Chris Wilson authored
In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by:
Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by:
-
Chris Wilson authored
As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. v2: And do the same for the guc. Signed-off-by:
-
Chris Wilson authored
When setting up reset, we may need to recursively prepare an engine. In which case we should only synchronously flush the tasklets on the outer most call, the inner calls will then be inside an atomic section where the tasklet will never be run (and so the sync will never complete). Signed-off-by:
-
Chris Wilson authored
The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution after reset (after spinning a bit during reset), but before we allow it to resume we will have cleared all the pending state. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistakes in WARN warning message text and in comments: "seqeuncer", "seqeuencer" -> "sequencer" Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Chris Wilson authored
When switching to the kernel context, we force the switch to occur after all currently active requests (so that we know the GPU won't switch immediately away and the kernel context remains current as we work). To do so we have to inspect all the timelines and add a fence from the active work to queue our switch afterwards. We can use the tracked set of active rings to shrink our search for active timelines. v2: Use a local to shrink the list_for_each_entry() Signed-off-by:
-
