- 27 Dec, 2018 1 commit
-
-
Brajeswar Ghosh authored
Remove i915_scheduler.h which is included more than once Signed-off-by:
Brajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181225132340.GA2584@hp-pavilion-15-notebook-pc-brajeswar
-
- 25 Dec, 2018 3 commits
-
-
Hans de Goede authored
Call intel_psr_enable() and intel_edp_drrs_enable() on pipe updates to make sure that we enable PSR / DRRS (when applicable) on fastsets. Note calling these functions when PSR / DRRS has already been enabled is a no-op, so it is safe to do this on every encoder->update_pipe callback. Changes in v2: -Merge the patches adding the intel_psr_enable() and intel_edp_drrs_enable() calls into a single patch Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-3-hdegoede@redhat.com
-
Hans de Goede authored
Do not make it an error to call intel_edp_drrs_enable while drrs has already been enabled, instead exit silently in this case. This is a preparation patch for ensuring that DRRS is enabled on fastsets. Note that the removed WARN_ON could also be triggered from userspace through the i915_drrs_ctl debugfs entry which was added by commit 35954e88 ("drm/i915: Runtime disable for eDP DRRS") Reviewed-by:
-
Hans de Goede authored
When we are doing a fastset (needs_modeset=false, update_pipe=true) we may need to update some encoder-level things such as checking that PSR is enabled. This commit adds an update_pipe callback to intel_encoder and a new intel_encoders_update_pipe helper which calls this for all encoders connected to a crtc. The new intel_encoders_update_pipe helper is called from intel_update_crtc when doing a fastset. Changes in v2: -Name the new encoder callback update_pipe instead of just update Reviewed-by:
-
- 22 Dec, 2018 1 commit
-
-
Chris Wilson authored
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need to unwind the locals before reporting the error. Or else on subsequent attempts to bind the page tables into the ggtt, we will already believe that the vma has been pinned and continue on blithely. If something else should happen to be at that location, choas ensues. Fixes: a2bbf714 ("drm/i915/gtt: Only keep gen6 page directories pinned while active") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk
-
- 21 Dec, 2018 4 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by: -
Paulo Zanoni authored
BSpec does not show these WAs as applicable to GLK, and for CNL it only shows them applicable for a super early pre-production stepping we shouldn't be caring about anymore. Remove these so we can avoid them on ICL too. v2: Change how we check for gen9 display platforms (Ville). Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Without this, we will get a dmesg-warn when enable_fbc is cleared on a fastset: WARN_ON(!crtc_state->enable_fbc) WARNING: CPU: 0 PID: 1090 at drivers/gpu/drm/i915/intel_fbc.c:1091 intel_fbc_enable+0x2ce/0x580 [i915] RIP: 0010:intel_fbc_enable+0x2ce/0x580 [i915] Call Trace: ? __mutex_unlock_slowpath+0x46/0x2b0 intel_update_crtc+0x6f/0x2b0 [i915] skl_update_crtcs+0x1d1/0x2b0 [i915] intel_atomic_commit_tail+0x1ea/0xdb0 [i915] intel_atomic_commit+0x244/0x330 [i915] drm_mode_atomic_ioctl+0x85d/0x950 ? drm_atomic_set_property+0x970/0x970 drm_ioctl_kernel+0x81/0xf0 drm_ioctl+0x2de/0x390 ? drm_atomic_set_property+0x970/0x970 ? __handle_mm_fault+0x81b/0xfc0 do_vfs_ioctl+0xa0/0x6e0 ? __do_page_fault+0x2a5/0x550 ksys_ioctl+0x35/0x60 __x64_sys_ioctl+0x11/0x20 do_syscall_64+0x55/0x190 entry_SYSCALL_64_after_hwframe+0x49/0xbe Changes since v1: - Move intel_fbc_disable to intel_update_crtc() (Hans) Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 20 Dec, 2018 1 commit
-
-
Manasi Navare authored
The DSC debugfs node causes a possible deadlock situation. This patch resets the try_again at the beginning of loop to fix this. Fixes: e845f099 ('drm/i915/dsc: Add Per connector debugfs node for DSC support/enable') Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109097 Cc: Lyude Paul <lyude@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- 18 Dec, 2018 7 commits
-
-
Imre Deak authored
Add a fallback detection method for TypeC legacy ports in case the VBT port information used to detect normally such ports is incorrect. For the fallback method we use the TypeC legacy mode specific HPD interrupt flag which should only be raised for a legacy port. WARN if the VBT port info is incorrect. In a case where we'd detect the port in a contradicting way both as a legacy and also as a USB DP and/or TBT alternate port treat the port as legacy (by also emitting a WARN from icl_update_tc_port_type). v2: - Repurpose the detection as a fallback method instead of using it only for the DP legacy case. By now we should normally use VBT to detect DP legacy ports as well. Suggested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-5-imre.deak@intel.com
-
Imre Deak authored
Atm HPD disconnect events on TypeC ports will break things, since we'll switch the TypeC mode (between legacy and disconnected modes as well as among USB DP alternate, Thunderbolt alternate and disconnected modes) on the fly from the HPD disconnect interrupt work while the port may be still active. Even if the port happens to be not active during the disconnect we'd still have a problem during a subsequent modeset or AUX transfer that could happen regardless of the port's connected state. For instance the system resume display mode restore code and userspace could perform a modeset on the port or userspace could start an AUX transfer even if the port is in disconnected state. To fix this keep TypeC legacy ports in legacy mode whenever we're not suspended. This mode is a static configuration as opposed to the Thunderbolt and USB DP alternate modes between which we can switch dynamically. We determine if a TypeC port is legacy (wired to a legacy HDMI or a legacy DP connector) via the VBT DDI port specific USB-TypeC and Thunderbolt flags. If both these flags are cleared then the port is configured for legacy mode. On such legacy ports we'll run the TypeC PHY connect sequence explicitly during driver loading and system resume (vs. running the sequence during HPD processing). The connect will succeed even if the display is not connected to begin with (or disappears during the suspended state) since for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB DP alternate mode where it gets set only when a display is connected). Correspondingly run the TypeC PHY disconnect sequence during system suspend and driver unloading. For the unloading case I had to split up intel_dp_encoder_destroy() to be able to have the 1. flush any pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and kfree on the encoder object. For now run the PHY disconnect during suspend only for TypeC legacy ports. We will need to disconnect even in USB DP alternate mode in the future, but atm we don't have a way to reconnect the port in this mode during resume if the display disappears while being suspended. So for now punt on this case. Note that we do not disconnect the port during runtime suspend; in legacy mode there are no shared HW resources (PHY lanes) with other HW blocks (USB), so no need to release / reacquire these resources as with USB DP alternate mode. The only reason to disconnect legacy ports during system suspend is that the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be connected again during system resume. We'll also have to turn the check for this flag into a poll, after figuring out what's the proper timeout value for it. v2: - Remove the redundant special casing of legacy mode when doing a disconnect in icl_tc_port_connected(). It's guaranteed already that we won't disconnect legacy ports in that function. - Add a note about the new intel_ddi_encoder_destroy() hook. - Reword the commit message after switching to the VBT based detection. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
This is needed by the next patch to determine if a DDI TypeC port is physically wired to a legacy DP or legacy HDMI connector or if the port is wired to a USB-C/Thunderbolt connector. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
It's useful to see at which point a TypeC port gets disconnected, so add a debug print for it. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Chris Wilson authored
Having completed a test run of gem_eio across all machines in CI we also observe the phenomenon (of lost interrupts after resetting the GPU) on gen3 machines as well as the previously sighted gen6/gen7. Let's apply the same HWSTAM workaround that was effective for gen6+ for all, as although we haven't seen the same failure on gen4/5 it seems prudent to keep the code the same. As a consequence we can remove the extra setting of HWSTAM and apply the register from a single site. v2: Delazy and move the HWSTAM into its own function v3: Mask off all HWSP writes on driver unload and engine cleanup. v4: And what about the physical hwsp? v5: No, engine->init_hw() is not called from driver_init_hw(), don't be daft. Really scrub HWSTAM as early as we can in driver_init_mmio() v6: Rename set_hwsp as it was setting the mask not the hwsp register. v7: Ville pointed out that although vcs(bsd) was introduced for g4x/ilk, per-engine HWSTAM was not introduced until gen6! References: https://bugs.freedesktop.org/show_bug.cgi?id=108735Signed-off-by:
-
Clint Taylor authored
In August 2018 the BSPEC changed the ICL port programming sequence to closely resemble earlier gen programming sequence. Restrict combo phy to HBR max rate unless eDP panel is connected to port. v2: remove debug code that Imre found v3: simplify translation table if-else v4: edp translation table now based on link rate and low_swing v5: Misc review comments + r-b BSpec: 21257 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Hans de Goede authored
When the pipe_config's update_pipe flag is set we may need to update the panel fitting settings. On GEN9+ this means we need to update the crtc's scaler settings. This fixes the following WARN_ON, during i915 loading on an Asrock B150M Pro4S/D3 board with an i5-6500 CPU / graphics: [drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled (expected no, found yes) pipe state doesn't match! WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084 With line 12084 being the I915_STATE_WARN call inside the "if (!intel_pipe_config_compare())" block in verify_crtc_state(). On this board with 2 1920x1080 monitors connected over HDMI the GOP initializes both monitors at 1920x1080 and despite no scaling being necessary configures a scaler for one of them. When booting with fastboot=1 on the initial modeset needs_modeset will be false while update_pipe is true. Since we were not calling skl_update_scaler_crtc() in this case we would leave the scaler enabled causing this error. Signed-off-by:
-
- 17 Dec, 2018 2 commits
-
-
Anusha Srivatsa authored
We have an update for HuC for BXT. Load the latest version. v2: Change the subject. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Manasi Navare authored
DSC can be supported per DP connector. This patch adds a per connector debugfs node to expose DSC support capability by the kernel. The same node can be used from userspace to force DSC enable. force_dsc_en written through this debugfs node is used to force DSC even for lower resolutions. Credits to Ville Syrjala for suggesting the proper locks to be used and to Lyude Paul for explaining how to use them in this context v8: * Add else if (ret) for drm_modeset_lock (Lyude) v7: * Get crtc, crtc_state from connector atomic state and add proper locks and backoff (Ville, Chris Wilson, Lyude) (Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>) * Use %zu for printing size_t variable (Lyude) v6: * Read fec_capable only for non edp (Manasi) v5: * Name it dsc sink support and also add fec support in the same node (Ville) v4: * Add missed connector_status check (Manasi) * Create i915_dsc_support node only for Gen >=10 (manasi) * Access intel_dp->dsc_dpcd only if its not NULL (Manasi) v3: * Combine Force_dsc_en with this patch (Ville) v2: * Use kstrtobool_from_user to avoid explicit error checking (Lyude) * Rebase on drm-tip (Manasi) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- 13 Dec, 2018 8 commits
-
-
Chris Wilson authored
Do not dereference the LUT blob before checking whether that blob exists. Or else, <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 <6>[ 13.978718] PGD 0 P4D 0 <4>[ 13.978733] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1 <4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 <4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915] <4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75 <4>[ 13.979001] RSP: 0018:ffffc9000026f840 EFLAGS: 00010246 <4>[ 13.979018] RAX: 0000000000000000 RBX: ffff888165500000 RCX: 7885fe6200000000 <4>[ 13.979039] RDX: 0000000000000020 RSI: ffff88816553a008 RDI: ffff888165464a88 <4>[ 13.979060] RBP: ffff888165464a88 R08: 000000000ed0e429 R09: 0000000000000001 <4>[ 13.979080] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004000 <4>[ 13.979101] R13: 0000000000004000 R14: ffff888165500000 R15: ffff888165464a88 <4>[ 13.979122] FS: 00007fb69c4f3540(0000) GS:ffff88817ba00000(0000) knlGS:0000000000000000 <4>[ 13.979146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 13.979163] CR2: 0000000000000048 CR3: 000000016d7fa000 CR4: 00000000001006f0 <4>[ 13.979184] Call Trace: <4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915] <4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915] <4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915] <4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915] <4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] <4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915] <4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915] <4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915] <4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915] <4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80 <4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0 <4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915] <4>[ 13.980421] pci_device_probe+0xa1/0x130 <4>[ 13.980440] really_probe+0xf3/0x3e0 <4>[ 13.980456] driver_probe_device+0x10a/0x120 <4>[ 13.980474] __driver_attach+0xdb/0x100 <4>[ 13.980489] ? driver_probe_device+0x120/0x120 <4>[ 13.980505] ? driver_probe_device+0x120/0x120 <4>[ 13.980522] bus_for_each_dev+0x74/0xc0 <4>[ 13.980539] bus_add_driver+0x15f/0x250 <4>[ 13.980554] ? 0xffffffffa0348000 <4>[ 13.980568] driver_register+0x56/0xe0 <4>[ 13.980583] ? 0xffffffffa0348000 <4>[ 13.980597] do_one_initcall+0x58/0x2e0 <4>[ 13.980615] ? do_init_module+0x1d/0x1ea <4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80 <4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290 <4>[ 13.980668] do_init_module+0x56/0x1ea <4>[ 13.980685] load_module+0x227a/0x29c0 <4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980756] do_syscall_64+0x55/0x190 <4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 13.980789] RIP: 0033:0x7fb69c019839 <4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 <4>[ 13.980851] RSP: 002b:00007ffdc112e3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 <4>[ 13.980875] RAX: ffffffffffffffda RBX: 000055c689fe0b30 RCX: 00007fb69c019839 <4>[ 13.980895] RDX: 0000000000000000 RSI: 000055c689a05d2e RDI: 0000000000000000 <4>[ 13.980916] RBP: 000055c689a05d2e R08: 0000000000000000 R09: 0000000000000000 <4>[ 13.980936] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 <4>[ 13.980957] R13: 000055c689fe0c60 R14: 0000000000040000 R15: 000055c689fe0b30 <4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers <4>[ 13.981027] CR2: 0000000000000048 Fixes: 302da0cd ("drm/i915: Use intel_ types more consistently for color management code (v2)") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Oscar Mateo authored
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes. They also happen to have separate reset bits. So, whenever we want to reset one or more of the media engines, we have to make sure the SFCs do not change owner in the process and, if this owner happens to be one of the engines being reset, we need to reset the SFC as well. This happens in 4 steps: 1) Tell the engine that a software reset is going to happen. The engine will then try to force lock the SFC (if currently locked, it will remain so; if currently unlocked, it will ignore this and all new lock requests). 2) Poll the ack bit to make sure the hardware has received the forced lock from the driver. Once this bit is set, it indicates SFC status (lock or unlock) will not change anymore (until we tell the engine it is safe to unlock again). 3) Check the usage bit to see if the SFC has ended up being locked to the engine we want to reset. If this is the case, we have to reset the SFC as well. 4) Unlock all the SFCs once the reset sequence is completed. Obviously, if we are resetting the whole GPU, we don't have to worry about all of this. BSpec: 10989 BSpec: 10990 BSpec: 10954 BSpec: 10955 BSpec: 10956 BSpec: 19212 Signed-off-by:
Tomasz Lis <tomasz.lis@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
-
Oscar Mateo authored
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC (Scaler & Format Converter) unit. We will use this information to decide when the SFC units need to be reset. BSpec: 20189 Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
We currently require that our per-engine reset can be called from any context, even hardirq, and in the future wish to perform the device reset without holding struct_mutex (which requires some lockless shenanigans that demand the lowlevel intel_reset_gpu() be able to be used in atomic context). Test that we meet the current requirements by calling i915_reset_engine() from under various atomic contexts. Signed-off-by:
-
Chris Wilson authored
After declaring a terminally wedged device, we allow ourselves to recover on the next GPU reset (manually triggered), or resume. Check that resetting a wedged device does work. v2: Add rpm (taken explicitly in the subtest in case we remove the outer wakeref) and early warning to i915_reset() for missed wakerefs Signed-off-by:
-
Lucas De Marchi authored
Instead of using IS_GEN() for consecutive gen checks, let's pass the range to IS_GEN_RANGE(). By code inspection these were the ranges deemed necessary for spatch: @@ expression e; @@ ( - IS_GEN(e, 3) || IS_GEN(e, 2) + IS_GEN_RANGE(e, 2, 3) | - IS_GEN(e, 3) || IS_GEN(e, 4) + IS_GEN_RANGE(e, 3, 4) | - IS_GEN(e, 5) || IS_GEN(e, 6) + IS_GEN_RANGE(e, 5, 6) | - IS_GEN(e, 6) || IS_GEN(e, 7) + IS_GEN_RANGE(e, 6, 7) | - IS_GEN(e, 7) || IS_GEN(e, 8) + IS_GEN_RANGE(e, 7, 8) | - IS_GEN(e, 8) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 8, 9) | - IS_GEN(e, 10) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 9, 10) | - IS_GEN(e, 9) || IS_GEN(e, 10) + IS_GEN_RANGE(e, 9, 10) ) After conversion, checking we don't have any missing IS_GEN_RANGE() || IS_GEN() was also done. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: -
Lucas De Marchi authored
RANGE makes it longer, but clearer. We are also going to add a macro to check an individual gen, so add the _RANGE prefix here. Diff generated with: sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i v2: use IS_GEN rather than GT_GEN Signed-off-by:
-
- 12 Dec, 2018 2 commits
-
-
Matt Roper authored
During DDB allocation, we try to distribute enough blocks for each plane to hit the highest watermark level; if that fails, we retry each lower level (which should require fewer blocks) until we find one that's possible (or until the whole commit is rejected as impossible). We need to reset our running block count when trying each lower level, otherwise all lower levels will fail as well. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d8e87498 ("drm/i915: Switch to level-based DDB allocation algorithm (v5)") Signed-off-by:
-
Bob Paauwe authored
It's not just GEN9 platforms that allow for pipes to be disabled via the DFSM register, but all later platforms as well. v2: drop pointless parentheses (Ville) Signed-off-by:
Bob Paauwe <bob.j.paauwe@intel.com> Acked-by:
-
- 11 Dec, 2018 3 commits
-
-
Matt Roper authored
The DDB allocation algorithm currently used by the driver grants each plane a very small minimum allocation of DDB blocks and then divies up all of the remaining blocks based on the percentage of the total data rate that the plane makes up. It turns out that this proportional allocation approach is overly-generous with the larger planes and can leave very small planes wthout a big enough allocation to even hit their level 0 watermark requirements (especially on APL, which has a smaller DDB in general than other gen9 platforms). Or there can be situations where the smallest planes hit a lower watermark level than they should have been able to hit with a more equitable division of DDB blocks, thus limiting the overall system sleep state that can be achieved. The bspec now describes an alternate algorithm that can be used to overcome these types of issues. With the new algorithm, we calculate all plane watermark values for all wm levels first, then go back and partition a pipe's DDB space second. The DDB allocation will calculate what the highest watermark level that can be achieved on *all* active planes, and then grant the blocks necessary to hit that level to each plane. Any remaining blocks are then divided up proportionally according to data rate, similar to the old algorithm. There was a previous attempt to implement this algorithm a couple years ago in bb9d85f6 ("drm/i915/skl: New ddb allocation algorithm"), but some regressions were reported, the patch was reverted, and nobody ever got around to figuring out exactly where the bug was in that version. Our watermark code has evolved significantly in the meantime, but we're still getting bug reports caused by the unfair proportional algorithm, so let's give this another shot. v2: - Make sure cursor allocation stays constant and fixed at the end of the pipe allocation. - Fix some watermark level iterators that weren't handling the max level. v3: - Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min to calculate the extra blocks for each plane. (Ville) - Replace a while() loop with a for() loop to be more consistent with surrounding code. (Ville) - Clean unattainable watermark levels with memset rather than directly clearing the member fields. Also do the same for the transition watermark values if they can't be achieved. (Ville) - Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since the results are no longer needed or used. (Ville) - Drop skl_latency[0] != 0 sanity check; both watermark methods already account for an invalid 0 latency by returning FP_16_16_MAX. (Ville) v4: - Break DDB allocation loop when total_data_rate=0 rather than alloc_size=0. If total_data_rate has dropped to 0, all remaining planes are disabled, which isn't true for alloc_size (we might just have not had any remaining blocks to hand out). Plus total_data_rate=0 is the case we need to avoid to a prevent a div-by-0. (Ville) - s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville) v5: - Don't forget to move 'start' pointer forward for UV surface when setting plane DDB boundaries. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458Signed-off-by:
-
Matt Roper authored
The bspec gives an if/else chain for choosing whether to use "method 1" or "method 2" for calculating the watermark "Selected Result Blocks" value for a plane. One of the branches of the if chain is: "Else If ('plane buffer allocation' is known and (plane buffer allocation / plane blocks per line) >=1)" Since our driver currently calculates DDB allocations first and the actual watermark values second, the plane buffer allocation is known at this point in our code and we include this test in our driver's logic. However we plan to soon move to a "watermarks first, ddb allocation second" sequence where we won't know the DDB allocation at this point. Let's drop this arm of the if/else statement (effectively considering the DDB allocation unknown) as an independent patch so that any regressions can be more accurately bisected to either the different watermark value (in this patch) or the new DDB allocation (in the next patch). Signed-off-by: -
Clint Taylor authored
Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests HF1-12 and HF1-13 to fail. V2: Removed "Source Shall" entries to a new patch V3: Rebase to drm-tip Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107896Signed-off-by:
-
- 10 Dec, 2018 2 commits
-
-
Matt Roper authored
Try to be more consistent about intel_* types rather than drm_* types for lower-level driver functions. While we're at it, let's also be more consistent with state variable naming (half of the platforms use the name 'state' whereas the other half used 'crtc_state'). While we're touching these variables, let's also be more consistent about always naming the intel_crtc_state's "crtc_state" rather than "state" so that different platform types aren't using different naming conventions. v2: - s/state/crtc_state/ for consistency between platform types (Ville) - Drop the crtc parameter to intel_color_check(); we can just pull that out of the state object. Signed-off-by:
-
Matt Roper authored
Try to be more consistent about intel_* types rather than drm_* types for lower-level driver functions. v2: - Also drop the intel_crtc parameter from compute_intermediate_wm() since we can just extract it from the crtc_state parameter. (Ville) Signed-off-by:
-
- 07 Dec, 2018 6 commits
-
-
Ville Syrjälä authored
SKL+ do not use crtc_state->update_wm_pre, so there is absolutely no point it setting it. crtc_state->update_wm_pre only exists as a temporary hack for pre-g4x platforms until we redo their watermarks to be be atomic. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We do return an error when the watermark calculation fails, so the FIXME claiming otherwise is outdated. Remove it. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
skl_compute_wm() wants to compare the old and new watermarks. Currently it gets at the old watermarks via crtc->state, which is confusing since it can point at either the old or the new state depending on where in the sequence we are. In this case it is correct since we have not yet swapped the states, but let's make it super clear what this is doing by using the explicit old state. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Chris Wilson authored
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3 was good, but still not good enough. To survive 24+ hours under test we needed to perform not one, not two but three extra store-dw. Doing so for each GPU relocation was a little unsightly and since we need to worry about userspace hitting the same issues, we should apply the dummy store-dw into the EMIT_FLUSH. Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing") References: 7fa28e14 ("drm/i915: Write GPU relocs harder with gen3") Testcase: igt/gem_tiled_fence_blits # blb/pnv Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207134037.11848-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Although commit fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") applied cleanly after a 24 month hiatus, the code had moved on with new methods for peeking and fetching the captured gpu info. Make sure we catch all uses of the stashed error state and avoid dereferencing the error pointer. v2: Move error pointer determination into i915_gpu_capture_state v3: Restore early check to avoid capturing and then throwing away subsequent GPU error states. Fixes: fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by:
-
Chris Wilson authored
Currently we face a severe problem on Braswell that manifests as invalid ppGTT accesses. The code tries to maintain the PDP (page directory pointers) inside the context in two ways, direct write into the context and a pipelined LRI update. The direct write into the context is fundamentally racy as it is unserialised with any access (read or write) the GPU is doing. By asserting that Braswell is not used with vGPU (currently an unsupported platform) we can eliminate the dangerous direct write into the context image and solely use the pipelined update. However, the LRI of the PDP fouls up the GPU, causing it to freeze and take out the machine with "forcewake ack timeouts". This seems possible to workaround by preventing the GPU from sleeping (via means of disabling the power-state management interface, i.e. forcing each ring to remain awake) around the update. Equally, it seems an EMIT_INVALIDATE before the LRI is sufficient to prevent the forcewake errors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656 References: https://bugs.freedesktop.org/show_bug.cgi?id=108714Signed-off-by:
-
