| Age | Commit message (Collapse) | Author | Files | Lines |
|
Scan enc/jpeg fences to init dpg pause new state in begin use.
It will help set dpg mode to desire state actively.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Always check all vcn ring status during dpg mode stop, it will help
identify which vcn ring may cause the issue.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
It is a bug fix.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Under Dynamic Power Gate mode, UVD_STATUS needn't be checked.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend,
to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
|
|
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: Ville Syrjälä <ville.syrjala@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 <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
|
|
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 <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-4-imre.deak@intel.com
|
|
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 <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-3-imre.deak@intel.com
|
|
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: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-2-imre.deak@intel.com
|
|
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=108735
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181218102712.11058-1-chris@chris-wilson.co.uk
|
|
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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1545084827-5776-1-git-send-email-clinton.a.taylor@intel.com
|
|
Lucas writes:
"nothing major this time, mostly some cleanups that were found on the
way of reworking the code in preparation for new feature additions."
Small conflict in drivers/gpu/drm/etnaviv/etnaviv_drv.c because
drm-misc-next also has a patch to switch over to _put() functions.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1545130845.5874.23.camel@pengutronix.de
|
|
It only written and we don't infer any useful information from
it anymore. Remove it.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
The etnaviv_gpu header only needs to know about the pointer types, so
replace by a forward declaration and only include the headers where needed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
The only event function that is called from IRQ context is event_free,
which is already using atomic bitmap operations, so we can avoid taking
the event spinlock in this function completely. As other the other
functions still using the event spinlock are all called from normal
process context, we can avoid disabling IRQs while holding the spinlock.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181217141903.4182-1-hdegoede@redhat.com
|
|
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207182840.9292-2-anusha.srivatsa@intel.com
|
|
Otherwise DRM_CAP_DUMB_PREFERRED_DEPTH is zero.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/o2SmEP0M6h287Fs5OeL3HtQzTr8uV0PyOhFict_qdxeS7vFvV1Zr8qzRUJh-YnCoJHo13nJgAqqQByzEzTZTqk9R2ExsOszYLj68hQLqBIc=@emersion.fr
|
|
The drm_ati_pcigart_init() function was originally suppose to return one
on success and zero on failure, but these days it returns a mix of
zero, one and -ENOMEM on failure.
This patch cleans it up and modifies the caller so now the function
returns zero on success and negative error codes on failure.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181217070344.GC12159@kadam
|
|
The drm_mode_create_tile_group() is only called from
drm_parse_tiled_block() and the caller expects it to return a NULL on
error. In other words, this function should match
drm_mode_get_tile_group().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181217065733.GA12159@kadam
|
|
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: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206005407.4698-1-manasi.d.navare@intel.com
|
|
It indicates a pin/unpin imbalance bug somewhere. While the bug isn't
necessarily in the call chain hitting this, it's at least one part
involved.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Page queue is supported on Vega20 with SDMA firmware
123 onwards.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Vega20 uses ring id 1 for page queues EOP irq while previous
ASICs take ring id 3.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We need new invalidation engine layout due to new SDMA page
queues added.
V2: fix coding style and add correct return value
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
As two more SDMA page queue rings are added on Vega20.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When the fence is already signaled it is perfectly normal to get a NULL
fence here. But since we can't export that we need to use a stub fence.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This:
- Adds local variables in the first loop, instead of using array indices
everywhere
- Adds an early continue to reduce the indent level in the second loop
There should be no functional changes here
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Juston Li <juston.li@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214012604.13746-3-lyude@redhat.com
|
|
There's no reason we need this, it's just confusing looking.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Juston Li <juston.li@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181214012604.13746-2-lyude@redhat.com
|
|
Currently driver only psp v11 support vmr.
v2: squash in unused variable removal (Alex)
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If PSP FW is running already, driver will not load PSP FW again and skip
it. So psp fw version is not correct if reading it from FW binary file,
need to get right version from register.
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There is no need to access register such as mmSMC_IND_INDEX_11
and mmSMC_IND_DATA_11, PCIE_INDEX, PCIE_DATA through KIQ because
they are VF-copy.
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
XGMI hive put kfd_pre_reset into amdgpu_device_lock_adev,
but outside req_full_gpu of sriov.
It would make sriov hang during reset.
Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181213134915.24722-1-kraxel@redhat.com
|
|
The fimd hardware supports different blend modes. Add pixel blend mode
property and make it configurable, by modifying the blend equation.
Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.
Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The fimd hardware supports variable plane alpha. Currently planes
are opaque, make this configurable.
Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.
Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
We need to call drm_dp_mst_topology_mgr_set_mst(mgr, false) when
destroying the topology manager in order to ensure that the root mstb
and all of it's descendents are actually destroyed, and additionally to
try to make sure that we leave the hub in a clean state.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181211235026.21758-1-lyude@redhat.com
|
|
This patch solves this TODO task:
drm_mode_config.crtc_idr is misnamed, since it contains all KMS object.
Should be renamed to drm_mode_config.object_idr.
Signed-off-by: Shayenne da Luz Moura <shayenneluzmoura@gmail.com>
[danvet: resolve conflict with addition of privobj_list.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213212957.vkitkyl5cj2qh7qr@smtp.gmail.com
|
|
Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
Tested-by: Tony Luck <tony.luck@intel.com>
|
|
One regression fix for avoiding kernel OOM, one cleanup return fix.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213122815.10581-1-thellstrom@vmware.com
|
|
Pull request of 2018-12-13
Two minor fixes for next pull.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213130848.3080-1-thellstrom@vmware.com
|
|
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: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color management code (v2)")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
|
|
With the new validation code, a malicious user-space app could
potentially submit command streams with enough buffer-object and resource
references in them to have the resulting allocated validion nodes and
relocations make the kernel run out of GFP_KERNEL memory.
Protect from this by having the validation code reserve TTM graphics
memory when allocating.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
---
v2: Removed leftover debug printouts
|
|
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: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
|
|
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: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
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 <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-3-chris@chris-wilson.co.uk
|
|
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 <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-2-chris@chris-wilson.co.uk
|
|
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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
|
|
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
|
|
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 <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
|