We do not explicitly mark the PTE for the user's GTT mmap as being
wrprotect, so we don't get a refault when we would need to change a
read-only mmapping into read-write. As such, we must presume that if the
vma has PROT_WRITE it may be written to, although this is supposed to be
indicated by set-domain there are cases (e.g. after swap) where
userspace may not be aware of the implicit domain change.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-2-chris@chris-wilson.co.uk
This trys to give new born vGPU with higher scheduling chance
not only with adding to sched list head and also have higher
priority for workload sched for 2 seconds after starting to
schedule it. In order for fast GPU execution during VM boot,
and ensure guest driver setup with required state given in time.
This fixes recent failure seen on one VM with multiple linux VMs
running on kernel with commit 2621cefaa42b3("drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup"),
which had shorter setup timeout that caused context state init failed.
v2: change to 2s for higher scheduling period
Cc: Yuan Hang <hang.yuan@intel.com>
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Vega20 does not appear to be affected by the same issue
as vega10. Enable the full stolen memory handling on
vega20. Reserve the appropriate size at init time to avoid
display artifacts and then free it at the end of init once
the new FB is up and running.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
vega12 does not appear to be affected by the same issue
as vega10. Enable the full stolen memory handling on
vega12. Reserve the appropriate size at init time to avoid
display artifacts and then free it at the end of init once
the new FB is up and running.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No functional change, just rework it in order to adjust the
behavior on a per asic level. The problem is that on vega10,
something corrupts the lower 8 MB of vram on the second
resume from S3. This does not seem to affect Raven, other
gmc9 based asics need testing.
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Staring at the function for six hours, just to essentially move one line
of code. The problem was that the first list_cut_position call could result
in list2 pointing to la-la-land.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This at least allows to fail any subsequent IOCTLs with -ENODEV
after the device is gone.
Still this operation is not supported yet in graphic mode
and will lead at least to page faults and other issues.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
So far we have been relying on vm->file pointer being NULL to declare
something GGTT.
This has the unfortunate consequence that the default kernel context is
also declared GGTT and interferes with the following patch which wants to
instantiate VMA's and execute requests against the kernel context.
Change the is_ggtt test to use an explicit flag in struct address_space to
solve this issue.
Note that the bit used is free since there is an alignment hole in the
struct.
v2:
* Mark mock ggtt.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180831143643.12366-1-tvrtko.ursulin@linux.intel.com
This patch resolves the DMC FW loading issue.
Earlier DMC FW package have only one DMC FW for one stepping. But as such
there is no such restriction from Package side.
For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings.
So while reading the dmc_offset from package header, for 1st stepping
offset used to come 0x0 and was working fine till now.
But for second stepping and other steppings, offset is non zero number
and is in dwords. So we need to convert into bytes to fetch correct DMC
FW from correct place.
v2 : Added check for DMC FW max size for various gen. (Imre Deak)
v3 : Corrected naming convention for various gen. (Imre Deak)
v4 : Initialized max_fw_size to 0
v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak)
v6 : Fixed the typo issues.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jyoti Yadav <jyoti.r.yadav@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1535695223-4648-1-git-send-email-jyoti.r.yadav@intel.com
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in those drivers before
every drm_dp_cec call, but it makes sense to check it in the
drm_dp_cec functions to prevent a kernel oops.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827075820.41109-2-hverkuil@xs4all.nl
The optimisation inherent in commit 6a2c4232ec ("drm/i915: Make the
physical object coherent with GTT") relies on that once we allocated a
cursor we would have coherent, zero overhead access to the scanout plane
holding the cursor. That is we could then do the very frequent cursor
updates X enjoys with no indirection or kernel involvement. However,
that all hinges on the GGTT mmap of the cursor being pinned and not
require refaulting on each access -- handling such a page fault likely
requires the busy GGTT to be rearranged causing a stall. A very simple
fix is then to handle the physical cursor exactly like other cursors and
keep its vma pinned while active.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107600
References: 6a2c4232ec ("drm/i915: Make the physical object coherent with GTT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20180817082405.755-1-chris@chris-wilson.co.uk
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20180731062127.10131-3-tzimmermann@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20180731063559.11629-1-tzimmermann@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20180731063128.11041-1-tzimmermann@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20180731062851.10812-1-tzimmermann@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Physical plane's tiling mode value is given directly as
drm_format_mod for plane query, which is not correct fourcc
code. Fix it by using correct intel tiling fourcc mod definition.
Current qemu seems also doesn't correctly utilize drm_format_mod
for plane object setting. Anyway this is required to fix the usage.
v3: use DRM_FORMAT_MOD_LINEAR, fix comment
v2: Fix missed old 'tiled' use for stride calculation
Fixes: e546e281d3 ("drm/i915/gvt: Dmabuf support for GVT-g")
Cc: Tina Zhang <tina.zhang@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Colin Xu <Colin.Xu@intel.com>
Reviewed-by: Colin Xu <Colin.Xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915
device is not active. When stop vgpu schedule, the device may be
inactive. So need to move runtime_pm_get out of spin_lock/unlock.
Fixes: b24881e0b0b6("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
Cc: <stable@vger.kernel.org>
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Recent patch introduce strict check on scanning cmd:
Commit 8d458ea0ec ("drm/i915/gvt: return error on cmd access")
Before 8d458ea0ec, if cmd_reg_handler() checks that a cmd access a mmio
that not marked as F_CMD_ACCESS, it simply returns 0 and log an error.
Now it will return -EBADRQC which will cause the workload fail to submit.
On BXT, i915 applies WaClearHIZ_WM_CHICKEN3 which will program
GEN9_WM_CHICKEN3 by LRI when init wa ctx. If it has no F_CMD_ACCESS flag,
vgpu will fail to start. Also add F_MODE_MASK since it's mode mask reg.
v2: Refresh commit message to elaborate issue symptom in detail.
v3: Make SKL_PLUS share same handling since GEN9_WM_CHICKEN3 should be
F_CMD_ACCESS from HW aspect. (yan, zhenyu)
Signed-off-by: Colin Xu <colin.xu@intel.com>
Acked-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Guest kernel will write to BXT_PHY_CTL_FAMILY to reset DDI PHY
and pull BXT_PHY_CTL to check PHY status. Previous handling will
set/reset BXT_PHY_CTL of all PHYs at same time on receiving vreg
write to some BXT_PHY_CTL_FAMILY. If some BXT_PHY_CTL is already
enabled, following reset to another BXT_PHY_CTL_FAMILY will clear
the enabled BXT_PHY_CTL, which result in guest kernel print:
-----------------------------------
[drm:intel_ddi_get_hw_state [i915]]
*ERROR* Port B enabled but PHY powered down? (PHY_CTL 00000000)
-----------------------------------
The correct handling should operate BXT_PHY_CTL_FAMILY and
BXT_PHY_CTL on the same DDI.
v2: Use correct reg define. The naming looks confusing, however
current i915_reg.h bind DPIO_PHY0 to _PHY_CTL_FAMILY_DDI and
bind DPIO_PHY1 to _PHY_CTL_FAMILY_EDP, pairing to
_BXT_PHY_CTL_DDI_A and _BXT_PHY_CTL_DDI_B respectively.
v3: v2 incorrectly map _PHY_CTL_FAMILY_EDP to _BXT_PHY_CTL_DDI_A.
BXT_PHY_CTL() looks up DDI using PORTx but not PHYx. Based on
DPIO_PHY to DDI mapping, make correct vreg handle to BXT_PHY_CTL
on receiving vreg write to BXT_PHY_CTL_FAMILY. (He, Min)
Current mapping according to bxt_power_wells:
dpio-common-a:
>>> DPIO_PHY1
>>> BXT_DPIO_CMN_A_POWER_DOMAINS
>>> POWER_DOMAIN_PORT_DDI_A_LANES
>>> PORT_A
dpio-common-bc:
>>> DPIO_PHY0
>>> BXT_DPIO_CMN_BC_POWER_DOMAINS
>>> POWER_DOMAIN_PORT_DDI_B_LANES | POWER_DOMAIN_PORT_DDI_C_LANES
>>> PORT_B or PORT_C
Signed-off-by: Colin Xu <colin.xu@intel.com>
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Move some KFD-related (but used in amdgpu_drv.c) definitions from
kfd_priv.h to kgd_kfd_interface.h so we don't need to include kfd_priv.h
in amdgpu_drv.c. This fixes a build failure when AMDGPU is enabled but
MMU_NOTIFIER is not.
This patch also disables KFD-related module options when HSA_AMD is not
enabled.
v2: rebase (Alex)
Signed-off-by: Amber Lin <Amber.Lin@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
kvmalloc_array uses __GFP_ZERO flag ensures that the returned address
is zeroed already, memset it to zero again afterwards is unnecessary,
and in this case buggy because we only clear the first entry.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>