- 14 Jan, 2019 7 commits
-
-
Roman Li authored
[Why] Hotplug on raven results in REG_WAIT_TIMEOUT warning due to failing attempt to lock disabled otg for the hubp interdependent pipes programming. [How] Don't setup pipe interdependencies for disabled otg. Also removed the unnecessary duplicate logic checks. Signed-off-by:
Roman Li <Roman.Li@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>
-
Charlene Liu authored
[Why] PPLIB not receive the PME when unplug. Signed-off-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] This fixes a stuttering issue that occurs when moving a hardware cursor when VRR is enabled. Previously when VRR is enabled atomic check will grab the connector state for every atomic update. This has to lock the connector in order to do so. The locking is bad enough by itself for performance, but it gets worse with what we do just below that - add all the planes for the CRTC to the commit. This prevents the cursor fast path from working - there's more than one plane now. With state->allow_modeset = true on top of this, it also adds and removes all the planes from the DC context triggering a full (very slow) update in DC. [How] We need the connector state to get the VRR min/max capbilities, but we only need them when there's a CRTC mode change or when VRR is toggled. The condition has been updated accordingly. Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR properties") Signed-off-by:Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
-
Josip Pavic authored
[Why] When the DMCU's iRAM definition was moved to the newly created power_helpers, a #pragma pack was lost, causing the iRAM to be misaligned [How] Restore the #pragma pack Signed-off-by:
Josip Pavic <Josip.Pavic@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Kenneth Feng authored
acg btc was added to Vega12 Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Felix Kuehling authored
dGPUs need their own topology devices. Don't assign them to APU topology devices with CPU cores. Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Tested-by:
Elias Konstantinidis <ekondis@gmail.com> Acked-by:
-
Felix Kuehling authored
ifdef x86_64 specific code. Allow enabling CONFIG_HSA_AMD on ARM64. v2: Fixed a compiler warning due to an unused variable CC: Mark Nutter <Mark.Nutter@arm.com> Signed-off-by:
Mark Nutter <Mark.Nutter@arm.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 11 Jan, 2019 6 commits
-
-
Daniel Vetter authored
Merge tag 'drm-intel-fixes-2019-01-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes i915 fixes for v5.0-rc2: - Disable PSR for Apple panels - Broxton ERR_PTR error state fix - Kabylake VECS workaround fix - Unwind failure on pinning the gen7 ppgtt - GVT workload request allocation fix Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87pnt35z8h.fsf@intel.com
-
Daniel Vetter authored
Merge tag 'drm-misc-fixes-2019-01-10-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Second pull request, drm-misc-fixes for v5.0-rc2: - Fix fb-helper to work correctly with SDL 1.2 bugs. - Fix lockdep warning in the atomic ioctl and setproperty. Signed-off-by:
-
git://github.com/skeggsb/linuxDave Airlie authored
3 nouveau fixes: one backlight, falcon register access, and a fan fix. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv4MHr=Rq3FkZFTYWPc7o5-dTWFysXB=wN2L91SYeFbzkQ@mail.gmail.com
-
Ilia Mirkin authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Takashi Iwai authored
When a fan is controlled via linear fallback without cstate, we shouldn't stop polling. Otherwise it won't be adjusted again and keeps running at an initial crazy pace. Fixes: 800efb4c ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447Reported-by:
Thomas Blume <thomas.blume@suse.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
- 10 Jan, 2019 11 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- Powerplay fixes - Virtual display pinning fixes - Golden register updates for vega - Pitch and gem size validation fixes - Fix for error case in sr-iov init - Disable page tables in system memory on RV due to issues with IOMMU reported on some platforms Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
Pull request for drm-misc-fixes for v5.0-rc2: - Fixes for the tc358767 bridge to work correctly with tc358867 using a DP connector. - Make resume work on amdgpu when a DP-MST display is unplugged. Signed-off-by:
-
José Roberto de Souza authored
The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this warning when generating kernel documentation. ./include/drm/drm_dp_helper.h:1374: warning: Incorrect use of kernel-doc format: * @DP_DPCD_QUIRK_NO_PSR Fixes: 1035f4a6 ("drm/i915: Disable PSR in Apple panels") Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181205184850.13218-1-jose.souza@intel.com (cherry picked from commit ed17b555) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Daniele Ceraolo Spurio authored
commit 4a15c75c ("drm/i915: Introduce per-engine workarounds") refactored the workaround code to have functions per-engine, but didn't call any of them from logical_xcs_ring_init. Since we do have a non-RCS workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call intel_engine_init_workarounds for non-RCS engines. Note that whitelist is still RCS-only. v2: move the call to logical_ring_init (Chris) Fixes: 4a15c75c ("drm/i915: Introduce per-engine workarounds") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110013232.8972-2-daniele.ceraolospurio@intel.com (cherry picked from commit a60acb22) Signed-off-by:
-
Chris Wilson authored
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need to unwind the locals before reporting the error. Or else on subsequent attempts to bind the page tables into the ggtt, we will already believe that the vma has been pinned and continue on blithely. If something else should happen to be at that location, choas ensues. Fixes: a2bbf714 ("drm/i915/gtt: Only keep gen6 page directories pinned while active") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk (cherry picked from commit d4de7535) Signed-off-by:
-
Chris Wilson authored
Although commit fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") applied cleanly after a 24 month hiatus, the code had moved on with new methods for peeking and fetching the captured gpu info. Make sure we catch all uses of the stashed error state and avoid dereferencing the error pointer. v2: Move error pointer determination into i915_gpu_capture_state v3: Restore early check to avoid capturing and then throwing away subsequent GPU error states. Fixes: fb6f0b64 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by:
-
José Roberto de Souza authored
i915 yet don't support PSR in Apple panels, so lets keep it disabled while we work on that. v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to DP_DPCD_QUIRK_NO_PSR (Ville) v3: Adding documentation to DP_DPCD_QUIRK_NO_PSR(Dhinakaran and Jani) Fixed typo in comment of the new quirk entry(Jani) Fixes: 598c6cfe (drm/i915/psr: Enable PSR1 on gen-9+ HW) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
https://github.com/intel/gvt-linuxJani Nikula authored
gvt-fixes-2019-01-09 - Fix one race issue between pre-scan of guest workload with submission Signed-off-by:
-
Tetsuo Handa authored
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc() failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc() succeeded. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
syzbot <syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com> Signed-off-by:
-
Ivan Mironov authored
Strict requirement of pixclock to be zero breaks support of SDL 1.2 which contains hardcoded table of supported video modes with non-zero pixclock values[1]. To better understand which pixclock values are considered valid and how driver should handle these values, I briefly examined few existing fbdev drivers and documentation in Documentation/fb/. And it looks like there are no strict rules on that and actual behaviour varies: * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c); * some treat (pixclock == 0) as invalid value which leads to -EINVAL (clps711x-fb.c); * some pass converted pixclock value to hardware (uvesafb.c); * some are trying to find nearest value from predefined table (vga16fb.c, video_gx.c). Given this, I believe that it should be safe to just ignore this value if changing is not supported. It seems that any portable fbdev application which was not written only for one specific device working under one specific kernel version should not rely on any particular behaviour of pixclock anyway. However, while enabling SDL1 applications to work out of the box when there is no /etc/fb.modes with valid settings, this change affects the video mode choosing logic in SDL. Depending on current screen resolution, contents of /etc/fb.modes and resolution requested by application, this may lead to user-visible difference (not always): image will be displayed in a right way, but it will be aligned to the left instead of center. There is no "right behaviour" here as well, as emulated fbdev, opposing to old fbdev drivers, simply ignores any requsts of video mode changes with resolutions smaller than current. The easiest way to reproduce this problem is to install sdl-sopwith[2], remove /etc/fb.modes file if it exists, and then try to run sopwith from console without X. At least in Fedora 29, sopwith may be simply installed from standard repositories. [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings [2] http://sdl-sopwith.sourceforge.net/Signed-off-by:Ivan Mironov <mironov.ivan@gmail.com> Cc: stable@vger.kernel.org Fixes: 79e53945 ("DRM: i915: add mode setting support") Fixes: 771fe6b9 ("drm/radeon: introduce kernel modesetting for radeon hardware") Fixes: 785b93ef ("drm/kms: move driver specific fb common code to helper functions (v2)") Signed-off-by:
-
Ivan Mironov authored
SDL 1.2 sets all fields related to the pixel format to zero in some cases[1]. Prior to commit db05c481 ("drm: fb-helper: Reject all pixel format changing requests"), there was an unintentional workaround for this that existed for more than a decade. First in device-specific DRM drivers, then here in drm_fb_helper.c. Previous code containing this workaround just ignores pixel format fields from userspace code. Not a good thing either, as this way, driver may silently use pixel format different from what client actually requested, and this in turn will lead to displaying garbage on the screen. I think that returning EINVAL to userspace in this particular case is the right option, so I decided to left code from problematic commit untouched instead of just reverting it entirely. Here is the steps required to reproduce this problem exactly: 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL support. SDL should be compiled with fbdev support (which is on by default). 2) Create /etc/fb.modes with following contents (values seems not used, and just required to trigger problematic code in SDL): mode "test" geometry 1 1 1 1 1 timings 1 1 1 1 1 1 1 endmode 3) Create ~/.fceux/fceux.cfg with following contents: SDL.Hotkeys.Quit = 27 SDL.DoubleBuffering = 1 4) Ensure that screen resolution is at least 1280x960 (e.g. append "video=Virtual-1:1280x960-32" to the kernel cmdline for qemu/QXL). 5) Try to run fceux on VT with some ROM file[3]: # ./fceux color_test.nes [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, FB_SetVideoMode() [2] http://www.fceux.com [3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nesReported-by:
saahriktu <mail@saahriktu.org> Suggested-by:
-
- 09 Jan, 2019 11 commits
-
-
Christian König authored
We hit a problem with IOMMU with that. Disable until we have time to debug further. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Jim Qu authored
effect asics: VEGA10 and VEGA12 Signed-off-by:
Jim Qu <Jim.Qu@amd.com> Acked-by:
-
Tao Zhou authored
Fix CPDMA hang in PRT mode for both VEGA10 and VEGA20 Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Tested-by:
Yukun.Li <yukun1.li@amd.com> Acked-by:
-
Tomi Valkeinen authored
tc358767 driver sets the connector type always to eDP. This patch sets the type to DP if there is no panel defined, which implies that there's a DP connector on the board. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Tomi Valkeinen authored
The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by:
-
Tomi Valkeinen authored
The current driver accepts any videomode with pclk < 154MHz. This is not correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be supported. Add code to reject modes that require more bandwidth that is available. Signed-off-by:
-
Tomi Valkeinen authored
Initially DP0_SRCCTRL is set to a static value which includes DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of 1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number. This patch changes the configuration as follows: Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct value. DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL: SSCG and BW27. All other bits can be zero. Signed-off-by:
-
Tomi Valkeinen authored
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use. Set PHY_2LANE only when 2 lanes are used. Signed-off-by:
-
Tomi Valkeinen authored
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines. Add these. Signed-off-by:
-
Tomi Valkeinen authored
tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by:
-
Zhenyu Wang authored
In commit 6bb2a2af ("drm/i915/gvt: Fix crash after request->hw_context change"), forgot to handle workload scan path in ELSP handler case which was to optimize scanning earlier instead of in gvt submission thread, so request alloc and add was splitting then which is against right process. This trys to do a partial revert of that commit which still has workload request alloc helper and make sure shadow state population is handled after request alloc for target state buffer. v3: Fix missed workload status setting in request alloc error path v2: Fix dispatch workload err path that should add request after alloc anyway. Fixes: 6bb2a2af ("drm/i915/gvt: Fix crash after request->hw_context change") Cc: Bin Yang <bin.yang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
Bin Yang <bin.yang@intel.com> Reviewed-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 08 Jan, 2019 5 commits
-
-
Lyude Paul authored
Since I've had to fix two cases of drivers not checking the return code from this function, let's make the compiler complain so this doesn't come up again in the future. Changes since v1: * Remove unneeded __must_check in function declaration - danvet Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-4-lyude@redhat.com
-
Lyude Paul authored
This is an ugly one unfortunately. Currently, all DRM drivers supporting atomic modesetting will save the state that userspace had set before suspending, then attempt to restore that state on resume. This probably worked very well at one point, like many other things, until DP MST came into the picture. While it's easy to restore state on normal display connectors that were disconnected during suspend regardless of their state post-resume, this can't really be done with MST because of the fact that setting up a downstream sink requires performing sideband transactions between the source and the MST hub, sending out the ACT packets, etc. Because of this, there isn't really a guarantee that we can restore the atomic state we had before suspend once we've resumed. This sucks pretty bad, but so far I haven't run into any compositors that this actually causes serious issues with. Most compositors will notice the hotplug we send afterwards, and then reprobe state. Since nouveau and i915 also don't fail the suspend/resume process due to failing to restore the atomic state, let's make amdgpu match this behavior. Better to resume the GPU properly, then to stop the process half way because of a potentially unavoidable atomic commit failure. Eventually, we'll have a real fix for this problem on the DRM level. But we've got some more important low-hanging fruit to deal with first. Signed-off-by:
-
Lyude Paul authored
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to find the topology in question after a suspend resume cycle, and the driver is supposed to check this value and disable MST accordingly if it's gone-in addition to sending a hotplug in order to notify userspace that something changed during suspend. Currently, amdgpu just makes the mistake of ignoring the return code from drm_dp_mst_topology_mgr_resume() which means that if a topology was removed in suspend, amdgpu never notices and assumes it's still connected which leads to all sorts of problems. So, fix this by actually checking the rc from drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the function while we're at it to fix the over-indenting. Signed-off-by:
-
Yu Zhao authored
When creating frame buffer, userspace may request to attach to a previously allocated GEM object that is smaller than what GPU requires. Validation must be done to prevent out-of-bound DMA, otherwise it could be exploited to reveal sensitive data. This fix is not done in a common code path because individual driver might have different requirement. Cc: stable@vger.kernel.org # v4.2+ Reviewed-by:
Yu Zhao <yuzhao@google.com> Signed-off-by:
-
Yu Zhao authored
Userspace may request pitch alignment that is not supported by GPU. Some requests 32, but GPU ignores it and uses default 64 when cpp is 4. If GEM object is allocated based on the smaller alignment, GPU DMA will go out of bound. Cc: stable@vger.kernel.org # v4.2+ Reviewed-by:
-
