- 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 1 commit
-
-
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 3 commits
-
-
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:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180809200052.2777-1-alexander.deucher@amd.com
-
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:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@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 14 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:
-
git://linux-arm.org/linux-ldDave Airlie authored
From: Liviu Dudau <Liviu.Dudau@arm.com> "I managed to loose track of a few patches for HDLCD while focusing on Mali DP and found them again when investigating an issue with the way HDLCD behaves on teardown. They can go into drm-next for one of the v4.19-rcX if you're not going to do another pull request before the merge window." Signed-off-by:
-
Russell King authored
The serializer PLL divider is a power-of-two divider, so our calculation which assumes that it's a numerical divider is incorrect. Replace it with one that results in a power-of-two divider value instead. Tested with all supported modes with a Samsung S24C750. Tested-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk>
-
Russell King authored
We can achieve the same effect via the get_modes() method, rather than wrapping the fill_modes helper. Tested-by:
-
Russell King authored
Move the mode_valid() implementation to the bridge instead of the connector, as we're checking the bridge's capabilities. Tested-by:
-
Russell King authored
Register the bridge outside of the component helper as we have drivers that wish to use the tda998x without its encoder. Tested-by:
-
Russell King authored
Cleanup the code a little from the effects of the previous changes: - Move tda998x_destroy() to be above tda998x_create() - Use 'dev' directly in tda998x_create() where appropriate. Tested-by:
-
Russell King authored
Move the tda998x_priv allocation inside tda998x_create() and simplify the tda998x_create()'s arguments. Pass the same to tda998x_destroy(). Tested-by:
-
Russell King authored
Convert tda998x to a bridge driver with built-in encoder support for compatibility with existing component drivers. Tested-by:
-
Dan Carpenter authored
The dma_mapping_error() returns true on error but we want to return -ENOMEM here. Fixes: 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages") Signed-off-by:
-
- 06 Aug, 2018 9 commits
-
-
Lucas Stach authored
drm_sched_job_finish() is a work item scheduled for each finished job on a unbound system workqueue. This means the workers can execute out of order with regard to the real hardware job completions. If this happens queueing a timeout worker for the first job on the ring mirror list is wrong, as this may be a job which has already finished executing. Fix this by reorganizing the code to always queue the worker for the next job on the list, if this job hasn't finished yet. This is robust against a potential reordering of the finish workers. Also move out the timeout worker cancelling, so that we don't need to take the job list lock twice. As a small optimization list_del is used to remove the job from the ring mirror list, as there is no need to reinit the list head in the job we are about to free. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Hersen Wu authored
[why] for vega, dp set_panel_mode is handled by psp firmware. dal should not program the register again. [how] dal does not program panel mode. Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Mikita Lipski authored
[why] When programming tonga's connector's backend we didn't take in account that HDMI's colour depth might be more than 8bpc therefore we need to add a switch statement that would adjust the pixel clock accordingly. [how] Add a switch statement updating clock by its appropriate coefficient. Signed-off-by:
Mikita Lipski <mikita.lipski@amd.com> Reviewed-by:
-
Dmytro Laktyushkin authored
[Why] We seem to have an issue where high enough display clock will not get set properly during S3 resume if we only call vbios once [How] Expand condition of display clock programming to happen even when cached display clock matches requested display clock Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] The pointer for integrated_info can be NULL which causes the system to do a null pointer deference and hang on boot. [How] Add a check to ensure that integrated_info is not null before enabling DP ss. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
-
Dmytro Laktyushkin authored
Signed-off-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
-
Mikita Lipski authored
[why] Prevent clock source sharing between HDMI and DP connectors. DP shouldn't be sharing its ref clock with phy clock, which caused an issue of older ASICS booting up with multiple diplays plugged in. [how] Add an extra check that would prevent HDMI and DP sharing clk. Signed-off-by:
-
Hersen Wu authored
[why] dp hbr2 eye diagram pattern for raven asic is not stabled. workaround is to use tp4 pattern. But this should not be applied to asic before raven. [how] add new bool varilable in asic caps. for raven asic, use the workaround. for carrizo, vega, do not use workaround. Signed-off-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] The calculated values for actual disp_clk_khz were ignored when notifying pplib of the new display requirements. In order to honor DFS bypass clocks from the hardware, the calculated value should be used. [How] The return value for set_dispclk is now assigned back into new_clocks and correctly carried through into dccg->clks.phyclk_khz. When notifying pplib of new display requirements dccg->clks.phyclk_khz is used instead of dce.dispclk_khz. The value of dce.dispclk_khz was never explicitly set to anything before. A 15% higher display clock value than calculated is no longer requested for dce110 since it now makes use of the calculated value. Since dce112 makes use of dce110's set_bandwidth but not its update_clocks it needs to have the value correctly carried through. Signed-off-by:
-
