summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2019-01-12Merge tag 'remove-dma_zalloc_coherent-5.0' of ↵Linus Torvalds
git://git.infradead.org/users/hch/dma-mapping Pull dma_zalloc_coherent() removal from Christoph Hellwig: "We've always had a weird situation around dma_zalloc_coherent. To safely support mapping the allocations to userspace major architectures like x86 and arm have always zeroed allocations from dma_alloc_coherent, but a couple other architectures were missing that zeroing either always or in corner cases. Then later we grew anothe dma_zalloc_coherent interface to explicitly request zeroing, but that just added __GFP_ZERO to the allocation flags, which for some allocators that didn't end up using the page allocator ended up being a no-op and still not zeroing the allocations. So for this merge window I fixed up all remaining architectures to zero the memory in dma_alloc_coherent, and made dma_zalloc_coherent a no-op wrapper around dma_alloc_coherent, which fixes all of the above issues. dma_zalloc_coherent is now pointless and can go away, and Luis helped me writing a cocchinelle script and patch series to kill it, which I think we should apply now just after -rc1 to finally settle these issue" * tag 'remove-dma_zalloc_coherent-5.0' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: remove dma_zalloc_coherent() cross-tree: phase out dma_zalloc_coherent() on headers cross-tree: phase out dma_zalloc_coherent()
2019-01-11Merge tag 'drm-intel-fixes-2019-01-11' of ↵Daniel Vetter
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
2019-01-11Merge tag 'drm-misc-fixes-2019-01-10-1' of ↵Daniel Vetter
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: Daniel Vetter <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2cf24f5c-2b1f-befa-8d08-058661146b61@linux.intel.com
2019-01-11Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
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
2019-01-11drm/nouveau/falcon: avoid touching registers if engine is offIlia Mirkin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-01-11drm/nouveau: Don't disable polling in fallback modeTakashi Iwai
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: 800efb4c2857 ("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=107447 Reported-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 <bskeggs@redhat.com>
2019-01-11drm/nouveau: register backlight on pascal and newerBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-01-11Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes - 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: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190109204336.3315-1-alexander.deucher@amd.com
2019-01-10drm/i915: init per-engine WAs for all enginesDaniele Ceraolo Spurio
commit 4a15c75c4246 ("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: 4a15c75c4246 ("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 a60acb223fecc77531540196008ac2de89e2a162) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-01-10drm/i915: Unwind failure on pinning the gen7 ppgttChris Wilson
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: a2bbf7148342 ("drm/i915/gtt: Only keep gen6 page directories pinned while active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-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 d4de753526f4d99f541f1b6ed1d963005c09700c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-01-10drm/i915: Skip the ERR_PTR error stateChris Wilson
Although commit fb6f0b64e455 ("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: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207110554.19897-1-chris@chris-wilson.co.uk (cherry picked from commit e6154e4cb8b0d3692f84ca0d66b4e1ba0389b134) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-01-10drm/i915: Disable PSR in Apple panelsJosé Roberto de Souza
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: 598c6cfe0690 (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: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-1-jose.souza@intel.com (cherry picked from commit 7c5c641a930ed06ca317ee39faee7d5824266348) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-01-10gpu/drm: Fix lock held when returning to user space.Tetsuo Handa
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1547115571-21219-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
2019-01-10drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclockIvan Mironov
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: 79e539453b34e ("DRM: i915: add mode setting support") Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware") Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
2019-01-10drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2Ivan Mironov
SDL 1.2 sets all fields related to the pixel format to zero in some cases[1]. Prior to commit db05c48197759 ("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.nes Reported-by: saahriktu <mail@saahriktu.org> Suggested-by: saahriktu <mail@saahriktu.org> Cc: stable@vger.kernel.org Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests") Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com> [danvet: Delete misleading comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
2019-01-09drm/amdgpu: disable system memory page tables for nowChristian König
We hit a problem with IOMMU with that. Disable until we have time to debug further. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-09drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hangJim Qu
effect asics: VEGA10 and VEGA12 Signed-off-by: Jim Qu <Jim.Qu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-09drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20Tao Zhou
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: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-09drm/bridge: tc358767: use DP connector if no panel setTomi Valkeinen
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: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-8-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: fix output H/V syncsTomi Valkeinen
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 <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: reject modes which require too much BWTomi Valkeinen
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 <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: fix initial DP0/1_SRCCTRL valueTomi Valkeinen
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 <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: fix single lane configurationTomi Valkeinen
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 <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANETomi Valkeinen
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines. Add these. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkeinen@ti.com
2019-01-09drm/bridge: tc358767: add bus flagsTomi Valkeinen
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: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-2-tomi.valkeinen@ti.com
2019-01-09drm/i915/gvt: Fix workload request allocation before request addZhenyu Wang
In commit 6bb2a2af8b1b ("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: 6bb2a2af8b1b ("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>
2019-01-08drm/amdgpu: Don't fail resume process if resuming atomic state failsLyude Paul
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 <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com
2019-01-08drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()Lyude Paul
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: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com
2019-01-08drm/amdgpu: validate user GEM object sizeYu Zhao
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: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Yu Zhao <yuzhao@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08drm/amdgpu: validate user pitch alignmentYu Zhao
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: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Yu Zhao <yuzhao@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08drm/amd/powerplay: drop the unnecessary uclk hard min settingEvan Quan
Since soft min setting is enough. Hard min setting is redundant. Reported-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08drm/amd/powerplay: avoid possible buffer overflowEvan Quan
Make sure the clock level enforced is within the allowed ranges. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08drm/amd/powerplay: create pp_od_clk_voltage device file under OD supportEvan Quan
Since pp_od_clk_voltage device file is for OD related sysfs operations. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08drm/amd/powerplay: update OD support flag for SKU with no OD capabilitiesEvan Quan
For those ASICs with no overdrive capabilities, the OD support flag will be reset. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-08cross-tree: phase out dma_zalloc_coherent()Luis Chamberlain
We already need to zero out memory for dma_alloc_coherent(), as such using dma_zalloc_coherent() is superflous. Phase it out. This change was generated with the following Coccinelle SmPL patch: @ replace_dma_zalloc_coherent @ expression dev, size, data, handle, flags; @@ -dma_zalloc_coherent(dev, size, handle, flags) +dma_alloc_coherent(dev, size, handle, flags) Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> [hch: re-ran the script on the latest tree] Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-01-05Merge tag 'drm-next-2019-01-05' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Happy New Year, just decloaking from leave to get some stuff from the last week in before rc1: core: - two regression fixes for damage blob and atomic i915 gvt: - Some missed GVT fixes from the original pull amdgpu: - new PCI IDs - SR-IOV fixes - DC fixes - Vega20 fixes" * tag 'drm-next-2019-01-05' of git://anongit.freedesktop.org/drm/drm: (53 commits) drm: Put damage blob when destroy plane state drm: fix null pointer dereference on null state pointer drm/amdgpu: Add new VegaM pci id drm/ttm: Use drm_debug_printer for all ttm_bo_mem_space_debug output drm/amdgpu: add Vega20 PSP ASD firmware loading drm/amd/display: Fix MST dp_blank REG_WAIT timeout drm/amd/display: validate extended dongle caps drm/amd/display: Use div_u64 for flip timestamp ns to ms drm/amdgpu/uvd:Change uvd ring name convention drm/amd/powerplay: add Vega20 LCLK DPM level setting support drm/amdgpu: print process info when job timeout drm/amdgpu/nbio7.4: add hw bug workaround for vega20 drm/amdgpu/nbio6.1: add hw bug workaround for vega10/12 drm/amd/display: Optimize passive update planes. drm/amd/display: verify lane status before exiting verify link cap drm/amd/display: Fix bug with not updating VSP infoframe drm/amd/display: Add retry to read ddc_clock pin drm/amd/display: Don't skip link training for empty dongle drm/amd/display: Wait edp HPD to high in detect_sink drm/amd/display: fix surface update sequence ...
2019-01-05Merge tag 'fbdev-v4.21' of git://github.com/bzolnier/linuxLinus Torvalds
Pull fbdev updates from Bartlomiej Zolnierkiewicz: "This time the pull request is really small. The most notable changes are fixing fbcon to not cause crash on unregister_framebuffer() operation when there is more than one framebuffer, adding config option to center the bootup logo and making FB_BACKLIGHT config option tristate (which in turn uncovered incorrect FB_BACKLIGHT usage by DRM's nouveau driver). Summary: - fix fbcon to not cause crash on unregister_framebuffer() when there is more than one framebuffer (Noralf Trønnes) - improve support for small rotated displays (Peter Rosin) - fix probe failure handling in udlfb driver (Dan Carpenter) - add config option to center the bootup logo (Peter Rosin) - make FB_BACKLIGHT config option tristate (Rob Clark) - remove superfluous HAS_DMA dependency for goldfishfb driver (Geert Uytterhoeven) - misc fixes (Alexey Khoroshilov, YueHaibing, Colin Ian King, Lubomir Rintel) - misc cleanups (Yangtao Li, Wen Yang) also there is DRM's nouveau driver fix for wrong FB_BACKLIGHT config option usage (FB_BACKLIGHT is for internal fbdev subsystem use only)" * tag 'fbdev-v4.21' of git://github.com/bzolnier/linux: drm/nouveau: fix incorrect FB_BACKLIGHT usage in Kconfig fbdev: fbcon: Fix unregister crash when more than one framebuffer fbdev: Remove depends on HAS_DMA in case of platform dependency pxa168fb: trivial typo fix fbdev: fsl-diu: remove redundant null check on cmap fbdev: omap2: omapfb: convert to DEFINE_SHOW_ATTRIBUTE fbdev: uvesafb: fix spelling mistake "memoery" -> "memory" fbdev: fbmem: add config option to center the bootup logo fbdev: fbmem: make fb_show_logo_line return the end instead of the height video: fbdev: pxafb: Fix "WARNING: invalid free of devm_ allocated data" fbdev: fbmem: behave better with small rotated displays and many CPUs video: clps711x-fb: release disp device node in probe() fbdev: make FB_BACKLIGHT a tristate udlfb: fix some inconsistent NULL checking
2019-01-04make 'user_access_begin()' do 'access_ok()'Linus Torvalds
Originally, the rule used to be that you'd have to do access_ok() separately, and then user_access_begin() before actually doing the direct (optimized) user access. But experience has shown that people then decide not to do access_ok() at all, and instead rely on it being implied by other operations or similar. Which makes it very hard to verify that the access has actually been range-checked. If you use the unsafe direct user accesses, hardware features (either SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged Access Never - on ARM) do force you to use user_access_begin(). But nothing really forces the range check. By putting the range check into user_access_begin(), we actually force people to do the right thing (tm), and the range check vill be visible near the actual accesses. We have way too long a history of people trying to avoid them. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-04i915: fix missing user_access_end() in page fault exception caseLinus Torvalds
When commit fddcd00a49e9 ("drm/i915: Force the slow path after a user-write error") unified the error handling for various user access problems, it didn't do the user_access_end() that is needed for the unsafe_put_user() case. It's not a huge deal: a missed user_access_end() will only mean that SMAP protection isn't active afterwards, and for the error case we'll be returning to user mode soon enough anyway. But it's wrong, and adding the proper user_access_end() is trivial enough (and doing it for the other error cases where it isn't needed doesn't hurt). I noticed it while doing the same prep-work for changing user_access_begin() that precipitated the access_ok() changes in commit 96d4f267e40f ("Remove 'type' argument from access_ok() function"). Fixes: fddcd00a49e9 ("drm/i915: Force the slow path after a user-write error") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@kernel.org # v4.20 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-04Merge tag 'drm-misc-next-fixes-2019-01-02' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next Fixes for v4.21: - Fix null pointer dereference on null state pointer. - Fix leaking damage clip when destroying plane state. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/46c4dbcd-dc23-7b46-fda9-16fe33e6ceef@linux.intel.com
2019-01-03Remove 'type' argument from access_ok() functionLinus Torvalds
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument of the user address range verification function since we got rid of the old racy i386-only code to walk page tables by hand. It existed because the original 80386 would not honor the write protect bit when in kernel mode, so you had to do COW by hand before doing any user access. But we haven't supported that in a long time, and these days the 'type' argument is a purely historical artifact. A discussion about extending 'user_access_begin()' to do the range checking resulted this patch, because there is no way we're going to move the old VERIFY_xyz interface to that model. And it's best done at the end of the merge window when I've done most of my merges, so let's just get this done once and for all. This patch was mostly done with a sed-script, with manual fix-ups for the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form. There were a couple of notable cases: - csky still had the old "verify_area()" name as an alias. - the iter_iov code had magical hardcoded knowledge of the actual values of VERIFY_{READ,WRITE} (not that they mattered, since nothing really used it) - microblaze used the type argument for a debug printout but other than those oddities this should be a total no-op patch. I tried to fix up all architectures, did fairly extensive grepping for access_ok() uses, and the changes are trivial, but I may have missed something. Any missed conversion should be trivially fixable, though. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-03drm/amdgpu: make gfx9 enter into rlc safe mode when set MGCGLikun Gao
MGCG should RLC enter into safe mode first. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-03drm/amdgpu: Cleanup 2 compiler warningsKent Russell
These 2 variables are unused now, so remove their references. Fixes: e4ae0fc drm/amdgpu: implement gfx8 post_soft_reset Fixes: 5e01c09 drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings test sequence Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings test sequenceTiecheng Zhou
The kiq ring and the very first compute ring may fail occasionally if they are tested directly following kiq_kcq_enable. Insert the gfx ring test before kiq ring test to delay the kiq and kcq ring tests will fix the issue. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tiecheng Zhou <Tiecheng.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/amdgpu/sriov:Correct pfvf exchange logicEmily Deng
The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu reset. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-By: Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/amd/powerplay: support BOOTUP_DEFAULT power profile modeEvan Quan
This can avoid unexpected profile mode change after running compute workload. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/amdgpu/virtual_dce: No need to pin the cursor boEmily Deng
For virtual display feature, no need to pin cursor bo. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/amdgpu/virtual_dce: No need to pin the fb's boEmily Deng
For virtual display, no need to pin the fb's bo. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-01-02drm/nouveau: fix incorrect FB_BACKLIGHT usage in KconfigBartlomiej Zolnierkiewicz
Making FB_BACKLIGHT tristate by commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") caused unmet dependencies in some configurations: WARNING: unmet direct dependencies detected for FB_BACKLIGHT Depends on [m]: HAS_IOMEM [=y] && FB [=m] Selected by [y]: - DRM_NOUVEAU [=y] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] && DRM_NOUVEAU_BACKLIGHT [=y] Selected by [m]: - FB_NVIDIA [=m] && HAS_IOMEM [=y] && FB [=m] && PCI [=y] && FB_NVIDIA_BACKLIGHT [=y] Fix it by making DRM_NOUVEAU select BACKLIGHT_CLASS_DEVICE and BACKLIGHT_LCD_SUPPORT instead of FB_BACKLIGHT. Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Rob Clark <robdclark@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2019-01-01Merge tag 'iommu-updates-v4.21' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull IOMMU updates from Joerg Roedel: - Page table code for AMD IOMMU now supports large pages where smaller page-sizes were mapped before. VFIO had to work around that in the past and I included a patch to remove it (acked by Alex Williamson) - Patches to unmodularize a couple of IOMMU drivers that would never work as modules anyway. - Work to unify the the iommu-related pointers in 'struct device' into one pointer. This work is not finished yet, but will probably be in the next cycle. - NUMA aware allocation in iommu-dma code - Support for r8a774a1 and r8a774c0 in the Renesas IOMMU driver - Scalable mode support for the Intel VT-d driver - PM runtime improvements for the ARM-SMMU driver - Support for the QCOM-SMMUv2 IOMMU hardware from Qualcom - Various smaller fixes and improvements * tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (78 commits) iommu: Check for iommu_ops == NULL in iommu_probe_device() ACPI/IORT: Don't call iommu_ops->add_device directly iommu/of: Don't call iommu_ops->add_device directly iommu: Consolitate ->add/remove_device() calls iommu/sysfs: Rename iommu_release_device() dmaengine: sh: rcar-dmac: Use device_iommu_mapped() xhci: Use device_iommu_mapped() powerpc/iommu: Use device_iommu_mapped() ACPI/IORT: Use device_iommu_mapped() iommu/of: Use device_iommu_mapped() driver core: Introduce device_iommu_mapped() function iommu/tegra: Use helper functions to access dev->iommu_fwspec iommu/qcom: Use helper functions to access dev->iommu_fwspec iommu/of: Use helper functions to access dev->iommu_fwspec iommu/mediatek: Use helper functions to access dev->iommu_fwspec iommu/ipmmu-vmsa: Use helper functions to access dev->iommu_fwspec iommu/dma: Use helper functions to access dev->iommu_fwspec iommu/arm-smmu: Use helper functions to access dev->iommu_fwspec ACPI/IORT: Use helper functions to access dev->iommu_fwspec iommu: Introduce wrappers around dev->iommu_fwspec ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 03:32:18 +0000