- 17 Aug, 2018 1 commit
-
-
Dave Airlie authored
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
-
- 16 Aug, 2018 3 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Fixes for 4.19: - Add VCN PSP FW loading for RV (this is required on upcoming parts) - Fix scheduler setup ordering for VCE and UVD - Few misc display fixes Signed-off-by:
-
git://people.freedesktop.org/~robclark/linuxDave Airlie authored
Some small msm fixes. Signed-off-by:
-
Michel Dänzer authored
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/107432Reviewed-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>
-
- 15 Aug, 2018 5 commits
-
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
Merge tag 'gvt-next-fixes-2018-08-14' of https://github.com/intel/gvt-linux into drm-intel-next-fixes gvt-next-fixes-2018-08-14 - 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:
Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180814073140.GJ22630@zhen-hp.sh.intel.com
-
Jani Nikula authored
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 dae84799 ("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 55bc60db ("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:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com (cherry picked from commit dc5977da) Signed-off-by:
-
Chris Wilson authored
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: 932cac10 ("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 7b5ee80a) Signed-off-by:
-
Chris Wilson authored
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: b8473050 ("drm/i915: Fix forcewake active domain tracking") Signed-off-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 d60996ab) Signed-off-by:
-
Chris Wilson authored
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: c5498089 ("drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode") References: d420a50c ("drm/i915: Clean up the HWSTAM mess") Testcase: igt/gem_eio/reset-stress Signed-off-by:
-
- 14 Aug, 2018 6 commits
-
-
Yi Wang authored
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>
-
Dan Carpenter authored
The > should be >= here so that we don't read one element beyond the end of the array. Fixes: 28a60dee ("drm/i915/gvt: vGPU HW resource management") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Gustavo A. R. Silva authored
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:
-
Zhao Yan authored
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:
-
Hang Yuan authored
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: e546e281("drm/i915/gvt: Dmabuf support for GVT-g") Signed-off-by:
Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by:
-
Hang Yuan authored
Create one vGPU and then unbind IGD device from i915 driver. The following oops will happen. This patch will free vgpu resource first and then gvt resource to remove these oops. BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 PGD 80000003c9d2c067 P4D 80000003c9d2c067 PUD 3c817c067 P MD 0 Oops: 0002 [#1] SMP PTI RIP: 0010:down_write+0x1b/0x40 Call Trace: debugfs_remove_recursive+0x46/0x1a0 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [i915] intel_gvt_destroy_vgpu+0x2d/0xf0 [i915] intel_vgpu_remove+0x2c/0x30 [kvmgt] mdev_device_remove_ops+0x23/0x50 [mdev] mdev_device_remove+0xdb/0x190 [mdev] mdev_device_remove+0x190/0x190 [mdev] device_for_each_child+0x47/0x90 mdev_unregister_device+0xd5/0x120 [mdev] intel_gvt_clean_device+0x91/0x120 [i915] i915_driver_unload+0x9d/0x120 [i915] i915_pci_remove+0x15/0x20 [i915] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x157/0x230 unbind_store+0xfc/0x150 kernfs_fop_write+0x10f/0x180 __vfs_write+0x36/0x180 ? common_file_perm+0x41/0x130 ? _cond_resched+0x16/0x40 vfs_write+0xb3/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x55/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: unable to handle kernel NULL pointer dereference at 0 000000000000038 PGD 8000000405bce067 P4D 8000000405bce067 PUD 405bcd067 PM D 0 Oops: 0000 [#1] SMP PTI RIP: 0010:hrtimer_active+0x5/0x40 Call Trace: hrtimer_try_to_cancel+0x25/0x120 ? tbs_sched_clean_vgpu+0x1f/0x50 [i915] hrtimer_cancel+0x15/0x20 intel_gvt_destroy_vgpu+0x4c/0xf0 [i915] intel_vgpu_remove+0x2c/0x30 [kvmgt] mdev_device_remove_ops+0x23/0x50 [mdev] mdev_device_remove+0xdb/0x190 [mdev] ? mdev_device_remove+0x190/0x190 [mdev] device_for_each_child+0x47/0x90 mdev_unregister_device+0xd5/0x120 [mdev] intel_gvt_clean_device+0x89/0x120 [i915] i915_driver_unload+0x9d/0x120 [i915] i915_pci_remove+0x15/0x20 [i915] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x157/0x230 unbind_store+0xfc/0x150 kernfs_fop_write+0x10f/0x180 __vfs_write+0x36/0x180 ? common_file_perm+0x41/0x130 ? _cond_resched+0x16/0x40 vfs_write+0xb3/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x55/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: bc7b0be3("drm/i915/gvt: Add basic debugfs infrastructure") Fixes: afe04fbe("drm/i915/gvt: create an idle vGPU") Signed-off-by:
-
- 13 Aug, 2018 14 commits
-
-
Nicholas Kazlauskas authored
[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:
-
Mikita Lipski authored
[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:
-
Mikita Lipski authored
[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:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
Mikita Lipski authored
[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:
Tony Cheng <Tony.Cheng@amd.com> Reviewed-by:
-
Jerry (Fangzhi) Zuo authored
[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:
-
Charlene Liu authored
Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Emily Deng authored
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:
-
Emily Deng authored
Entity init should after ring init, as the entity's sched_rq's initialization is in ring init. SWDEV-161495 Signed-off-by:
-
Likun Gao authored
Setup psp firmware loading for VCN, and make VCN block booting from tmr mac address. Signed-off-by:
James Zhu <James.Zhu@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Likun Gao <Likun.Gao@amd.com> Signed-off-by:
-
Likun Gao authored
Add VCN support in PSP driver Signed-off-by:
-
Likun Gao authored
Add the new firmware id for VCN into the enum Signed-off-by:
-
James Zhu authored
Update tmr mc address with firmware loading address which is returned from PSP firmware Signed-off-by:
-
James Zhu authored
amdgpu IP blocks booting need Trust Memory Region(tmr) mc address of its firmware which is loaded by PSP Signed-off-by:
-
Hang Yuan authored
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:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
-
- 10 Aug, 2018 4 commits
-
-
Jeykumar Sankaran authored
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>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
More fixes for 4.19: - Fixes for scheduler - Fix for SR-IOV - Fixes for display Signed-off-by:
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
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:
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
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:
-
- 09 Aug, 2018 2 commits
-
-
Emily Deng authored
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:
-
Nayan Deshmukh authored
We no longer have sched parameter so remove its description as well Signed-off-by:
Nayan Deshmukh <nayan26deshmukh@gmail.com> Signed-off-by:
-
- 07 Aug, 2018 5 commits
-
-
Dave Airlie authored
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 authored
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:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
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:
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
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:
-
git://git.armlinux.org.uk/~rmk/linux-armDave Airlie authored
From: Russell King <rmk@armlinux.org.uk> As per the patches posted, discussed and tested by Peter Rosin, this converts TDA998x to a bridge driver, while still allowing Armada and TI LCDC to continue using it as they always have done. It also gets rid of the private .fill_modes function, and tweaks the TMDS divider calculation to be more correct to the available information. [airlied: fixed two conflicts] Signed-off-by:
-
