Set correct address base for vega20.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dentist did ranges were incomplete as max setting has an unusual
divider step up of 66.
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
dp_ss_off flag doesn't need to be set, so we create a link_init
function if it is needed by an asic
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
dp_ss_control = 0 means ss is off, we had a typo where
we would double not dp_ss_control while setting dp_ss_off
flag
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Do not retrain link settings if lane count and link rate are both
unknown. Causes driver to be stuck reading VBIOS register after
removing emulated connection.
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
An optional follow-on PR for 4.19, on top of previous -fixes PR, which
brings in a6xx support.
These patches have been on list since earlier in the year (mostly
waiting for userspace). They have been in linux-next since earlier in
the week, now that we have freedreno userspace working on a6xx[1][2].
So far glmark2, Chromium/ChromiumOS, gnome-shell, glamor, xonotic,
etc, are working. And a healthy chuck of deqp works, and I've been
busy fixing things. The needed libdrm changes (no new uapi changes
needed) are already on master, and the 2nd branch is rebased on that.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGuCKekZ2Dho80qxODT1BEUGg4hbq33ACUy5VXs3dHbDLA@mail.gmail.com
- DP full color range.
- selftest for gem_object
- forcewake on suspend
- GPU reset
This also include accumulated fixes from GVT:
- Fix an error code in gvt_dma_map_page() (Dan)
- Fix off by one error in intel_vgpu_write_fence() (Dan)
- Fix potential Spectre v1 (Gustavo)
- Fix workload free in vgpu release (Henry)
- Fix cleanup sequence in intel_gvt_clean_device (Henry)
- dmabuf mutex init place fix (Henry)
- possible memory leak in intel_vgpu_ioctl() err path (Yi)
- return error on cmd access check failure (Yan)
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbdcppAAoJEPpiX2QO6xPKZ+IH/jzYLJDShTvJ01gyXMmNUn2/
JLKOVnKuBzDZj3duQHZTXZBBwC+Gr66uC0iX9hA0Zl/La/jmZdHfxY4PBDzlIuxq
AZpK9kX7yKAP9TfbF35H6qUb3n09rlWO6L4pMtdO8nS1oMHEZ1UXTz9okjQQ/GFd
hl4btwNo75xDB4aBFFNKT/bhpjSl0Yuox60Ff5q4kJ4XiZ88NKx+H9fppJWk/j3P
YK972jnR1NugYmVuhL8ENFt1b1IuQ7Rn64O7SqYNou2Xcr1yM7lCFGyWDf2Tang/
MSisLRmJSnHYSZ0d1qjJS3tRuTnQg0s3xi7KheMFYFnjYv8sR5hzvrDbFHYHzc8=
=Esml
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-fixes-2018-08-16-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
Fixes for:
- DP full color range.
- selftest for gem_object
- forcewake on suspend
- GPU reset
This also include accumulated fixes from GVT:
- Fix an error code in gvt_dma_map_page() (Dan)
- Fix off by one error in intel_vgpu_write_fence() (Dan)
- Fix potential Spectre v1 (Gustavo)
- Fix workload free in vgpu release (Henry)
- Fix cleanup sequence in intel_gvt_clean_device (Henry)
- dmabuf mutex init place fix (Henry)
- possible memory leak in intel_vgpu_ioctl() err path (Yi)
- return error on cmd access check failure (Yan)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816190335.GA7765@intel.com
The allocated size can be (at least?) as large as megabytes, and
there's no need for it to be physically contiguous.
May avoid spurious failures to initialize / suspend the corresponding
block while there's memory pressure.
Bugzilla: https://bugs.freedesktop.org/107432
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.
Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae847991a ("drm/i915: add
intel_ddi_set_pipe_settings").
Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.
Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db59 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.
After all these years, the fix boils down to flipping one bit.
[Per testing reports, this fixes DP sinks, but not the LSPCON. My
educated guess is that the LSPCON fails to turn the CEA range MSA into
AVI infoframes for HDMI.]
Reported-by: Michał Kopeć <mkopec12@gmail.com>
Reported-by: N. W. <nw9165-3201@yahoo.com>
Reported-by: Nicholas Stommel <nicholas.stommel@gmail.com>
Reported-by: Tom Yan <tom.ty89@gmail.com>
Tested-by: Nicholas Stommel <nicholas.stommel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.9+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
(cherry picked from commit dc5977da99)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The call to i915_gem_unpark() checks that we hold a rpm wakeref before
taking a long term wakeref for i915->gt.awake. We should therefore make
sure we do hold the wakeref when directly calling unpark to disable
the retire worker.
Fixes: 932cac10c8 ("drm/i915/selftests: Prevent background reaping of active objects")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809063449.4474-1-chris@chris-wilson.co.uk
(cherry picked from commit 7b5ee80a5d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon resume or else our accounting will be
off and we may not acquire the forcewake before we use it. So record
which domains we cleared on suspend and reacquire them early on resume.
v2: Hold the spinlock to appease our sanitychecks
v3: s/fw_domains_user/fw_domains_saved/ to convey intent more clearly
Reported-by: Imre Deak <imre.deak@linux.intel.com>
Fixes: b847305080 ("drm/i915: Fix forcewake active domain tracking")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808210842.3555-1-chris@chris-wilson.co.uk
(cherry picked from commit d60996ab43)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
An oddity occurs on Sandybridge, Ivybridge and Haswell (and presumably
Valleyview) in that for the period following the GPU restart after a
reset, there are no GT interrupts received. From Ville's notes, bit 0 in
the HWSTAM corresponds to the render interrupt, and if we unmask it we
do see immediate resumption of GT interrupt delivery (via the master irq
handler) after the reset.
v2: Limit the w/a to the render interrupt from rcs
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107500
Fixes: c549808946 ("drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode")
References: d420a50c21 ("drm/i915: Clean up the HWSTAM mess")
Testcase: igt/gem_eio/reset-stress
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808105101.913-2-chris@chris-wilson.co.uk
(cherry picked from commit a4a717010f)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The 'sparse' variable may leak when return in function
intel_vgpu_ioctl(), and this patch fix this.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The > should be >= here so that we don't read one element beyond the
end of the array.
Fixes: 28a60dee2c ("drm/i915/gvt: vGPU HW resource management")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]
Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
If a register is not cmd accessible, should not just print error
message. Return error here so as not to deliver this cmd.
v2: return -EBADRQC to align with return value elsewhere. (kevin tian)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Currently, the mutex used in GVT dmabuf support is not initialized until
vgpu device is opened. If one vgpu device is opened and then removed, the
mutex will be used in vgpu remove operation without initialization. This
patch initializes the mutex in vgpu create operation to avoid the problem.
Fixes: e546e281d33d("drm/i915/gvt: Dmabuf support for GVT-g")
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[Why]
A null pointer deference can occur if crtc is null in
amdgpu_dm_crtc_handle_crc_irq. This can happen if get_crtc_by_otg_inst
returns NULL during dm_crtc_high_irq, leading to a hang in some IGT
test cases.
[How]
Check that CRTC is non-null before accessing its fields.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Older ASICs require both phys_id and connector_id
to execute bios command table. If we are not passing the
right connector_id - it can lead to a black screen.
[how]
Set connector_obj_id when executing vbios command table
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
[why]
We are disabling clock source while other pipes are still using
it, because we don't verify the number of pipes that share it.
[how]
- Adding a function in resources to return the number of pipes
sharing the clock source.
- Checking that no one is sharing the clock source before disabling
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
[why]
HDMI and DVI share the same PHY clock and single link
DVI and HDMI both use 4 lanes, so they should be allowed
to be sharing the same clock source if all other parameters
are satisfied.
[how]
Change a check for general DVI to Dual DVI.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DOUBLE_BUFFER_EN bit is getting cleared before enable blanking.
That leads to CRTC_BLANK_DATA_EN is getting updated immediately.
[How]
Get DOUBLE_BUFFER_EN bit set, the same as DCE110.
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Entity init should after ring init, as the entity's sched_rq's initialization
is in ring init.
SWDEV-161495
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Entity init should after ring init, as the entity's sched_rq's initialization
is in ring init.
SWDEV-161495
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add the new firmware id for VCN into the enum
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Update tmr mc address with firmware loading address
which is returned from PSP firmware
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
amdgpu IP blocks booting need Trust Memory Region(tmr) mc address
of its firmware which is loaded by PSP
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Likun Gao <likun.gao@amd.com>
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Some workloads may be prepared in vgpu's queue but not be scheduled
to run yet. If vgpu is released at this time, they will not be freed
in workload complete callback and so need to be freed in vgpu release
operation.
Add new vgpu_release operation in gvt_ops to stop vgpu and release
runtime resources. gvt_ops vgpu_deactivate operation will only stop
vgpu.
v2: add new gvt ops to clean vgpu running status (Xiong Zhang)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Trivial fix to spelling mistake in dev_err message and comment
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change validates the physical encoder before it
is dereferenced.
Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Failure to load firmware is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
of missing firmware.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
- Fix U/V plane offsets for odd vertical offsets. Due to wrong operator
order, the y offset was not rounded down properly for vertically
chroma subsampled planar formats.
- Fix IPU id number for boards that don't have an OF alias for their
single IPU in the device tree. This is necessary to support imx-media
on i.MX51 and i.MX53 SoCs.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCW2RimhcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwM9hAP928KiDOQQNq4pYDTaq5pL3Tqnq
Co2evjrCqq8DJpbmPwD/cilKVCZ7rY24U2kV+X/nkNvemHg0uYwnmnfLeolKMAQ=
=uoGQ
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2018-08-03' of git://git.pengutronix.de/git/pza/linux into drm-next
drm/imx: ipu-v3 plane offset and IPU id fixes
- Fix U/V plane offsets for odd vertical offsets. Due to wrong operator
order, the y offset was not rounded down properly for vertically
chroma subsampled planar formats.
- Fix IPU id number for boards that don't have an OF alias for their
single IPU in the device tree. This is necessary to support imx-media
on i.MX51 and i.MX53 SoCs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1533552680.4204.14.camel@pengutronix.de
- Convert imx_drm_suspend/resume to use the
drm_mode_config_helper_suspend/ resume functions.
- Add support for V4L2_PIX_FMT_XRGB32/XBGR32, corresponding to
DRM_FORMAT_XRGB8888/BGRX8888, respectively.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCW2RkHxcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwLx+AQD9lfaYMq06ETXudTE3or832+eL
tyLrRLdZ/2I2B1weCQD/ez8+0nYzCwNi85dFDAvu0XieaC0E7my+QmfvsOQBKQA=
=U3BN
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-next-2018-08-03' of git://git.pengutronix.de/git/pza/linux into drm-next
drm/imx: use suspend/resume helpers, add ipu-v3 V4L2 XRGB32/XBGR32 support
- Convert imx_drm_suspend/resume to use the
drm_mode_config_helper_suspend/ resume functions.
- Add support for V4L2_PIX_FMT_XRGB32/XBGR32, corresponding to
DRM_FORMAT_XRGB8888/BGRX8888, respectively.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1533552701.4204.15.camel@pengutronix.de
Extend the timeout for recovering vram bos from shadows on sr-iov
to cover the worst case scenario for timeslices and VFs
Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode. For example, for 4 VF, every
VF's exclusive timeout time is set to 3s, then the worst case is
9s. If the VF number is more than 4,then the worst case time will
be longer.
The 8s is the test data, with setting to 8s, it will pass the TDR
test for 1000 times.
SWDEV-161490
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We no longer have sched parameter so remove its description
as well
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Fix runtime PM for LPE audio
- Revert on ICL workaround
- Interactive RPS mode
- Fix for PSR sink status report
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbaNnHAAoJEPpiX2QO6xPK8roIAKxWQcaVPjkfSKXYF+NiiJVE
Ge2zjPvAumHbFoJ68lP4uzCraaTt4+b3YrOxncbYyeT/6JBoRDT1vO6MjYkERXhO
mOmtR/Duum1Kg26Gs+GfDmX9ExFk7q/Xd/4WJ+rBBWYnpcqbg4e6kdqlp7lsUda6
To6k/lqrMfNF8XpJowDvrAqvqC/NBk45ofda53FE+krkJTGTrRuLrpvBXc57RbpD
1PGDOtJJBAogaIJUE7LFRnQAB+OzaDWStsSqyvfo9RJF4Z/IYzVcNwePo5Lw7Gq1
5itpRYCgNN+KblD3RFIxFc7GxvKrbvPbg02T8vR+Qep94Jv/mWmheHFU+2jeQ+A=
=qrZD
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-fixes-2018-08-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Fix gvt compilation broken on a silent conflict on fixes vs next merge
- Fix runtime PM for LPE audio
- Revert on ICL workaround
- Interactive RPS mode
- Fix for PSR sink status report
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806233034.GA20655@intel.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbYufqAAoJEEN0HIUfOBk0TP0P/3v4TXAGLBzeNjWcCgH5Av2C
W9mNpnaqncbKbqWqwXVol0xtO0c8YY7FbZj4Pf2zvJr9Ysg/7fkrOEgL2S7la2QW
C5mPFfpgW1ZBICihoDapnme573Cl0QkmetkY2E9OuDNb0RonywFPPHic8QwygDtx
pHMSyNsfFC3+ki10TW6NnNU5NHJY9GS4UmNb63bpCNzoWvbxKHx2r5A9bueqwIMR
tRSwVR7hfq0WO9x/WgNcNfNaIPwgQn+urloLC60fa3V0G2CL1AtB/FDloVk60aq0
o5D7JH2Q7LJ4mKAv2hkvihdfENkW+vui1b4zEyzOYvJ2z70pvmyG4cU7+8o6kadq
IKBVS/2jzYW2OiRxez15oIUxqhV+AqY7m4/BxPVmT7UxFNXKLyYk8aKvARaRylBp
UC2TDw8T1Nl0L689i00ZQemWzDGCkfv4w+Va8m1yntfYmFehYnb9nyKh0NTX3cp0
EdVM6f5JpLXBV+iaHL1IG/MUMnBTsOhX13sB8NdH+e+kmw0wRseYhyajcYwCLSdO
CprEcJSDdvh18T+3iRv8N9t4S6lokYEOdWdr2Nq5iHfc0iYCVVrzoFLE2Gz/Ojbi
B/yPcQhF2GYr7RR9h4ubqf0dxV5xrxwdmrSYo0cwo183dLIqw+CaSb2E4EOCvngf
O2nU9Z7fC6mvJ8TeS4yB
=ULzJ
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-fixes-2018-08-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Fixes an oops on the DP CEC code and a memory leak on the vkms driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Gustavo Padovan <gustavo@padovan.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802111728.GA27945@juma
Fixes for 4.19:
- Fix UVD 7.2 instance handling
- Fix UVD 7.2 harvesting
- GPU scheduler fix for when a process is killed
- TTM cleanups
- amdgpu CS bo_list fixes
- Powerplay fixes for polaris12 and CZ/ST
- DC fixes for link training certain HMDs
- DC fix for vega10 blank screen in certain cases
From: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801222906.1016-1-alexander.deucher@amd.com
From: Lucas Stach <l.stach@pengutronix.de>
"not much to de-stage this time. Changes from Philipp and Souptick to
use memset32 more and switch the fault handler to the new vm_fault_t
and two small fixes for issues that can be hit in rare corner cases
from me."
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1533563808.2809.7.camel@pengutronix.de
Evan Quan