summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2017-07-21Merge tag 'drm-misc-fixes-2017-07-20' of ↵Dave Airlie
git://anongit.freedesktop.org/git/drm-misc into drm-fixes Core Changes: - fence: Introduce new fence flag to signify timestamp is populated (Chris) - mst: Avoid processing incomplete data + fix NULL dereference (Imre) Driver Changes: - vc4: Avoid WARN from grabbing a ref from vblank that's not on (Boris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Imre Deak <imre.deak@intel.com> * tag 'drm-misc-fixes-2017-07-20' of git://anongit.freedesktop.org/git/drm-misc: drm/mst: Avoid processing partially received up/down message transactions drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req() drm/mst: Fix error handling during MST sideband message reception drm/vc4: Fix VBLANK handling in crtc->enable() path dma-buf/fence: Avoid use of uninitialised timestamp
2017-07-20drm/i915: Drop unpin stall in atomic_prepare_commitDaniel Vetter
The core already does this in setup_commit(). With this we can also remove the unpin_work_count since it's the last user, and also remove the loop since that was only used for stalling against legacy flips. v2: Amend commit message a bit (Chris). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-8-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Remove intel_flip_work infrastructureDaniel Vetter
This gets rid of all the interactions between the legacy flip code and the modeset code. Yay! This highlights an ommission in the atomic paths, where we fail to apply a boost to the pending rendering when we miss the target vblank. But the existing code is still dead and can be removed. v2: Note that the boosting doesn't work in atomic (Chris). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-7-daniel.vetter@ffwll.ch
2017-07-20drm/i915: adjust has_pending_fb_unpin to atomicDaniel Vetter
A bit an oversight - the current code did nothing, since only legacy flips used the unpin_work_count and assorted logic. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-6-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Rip out legacy page_flip completion/irq handlingDaniel Vetter
All these races and things are now solved through the vblank evasion trick, plus event handling is done using normal vblank even processing and drm_crtc_arm_vblank_event. We can get rid of all this complexity. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-5-daniel.vetter@ffwll.ch
2017-07-20drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'Christophe JAILLET
Goto the right label in case of error, otherwise there is a leak. This has been introduced by c5cf9a9147ff. In this patch a goto has not been updated. Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20170719223503.30580-1-christophe.jaillet@wanadoo.fr Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-07-20drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irqPandiyan, Dhinakaran
INTEL_GEN() appears to be the new way of doing these platform checks, so convert this i915_irq.c too. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@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/1500402480-30741-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-07-20drm/i915: Unbreak gpu reset vs. modeset lockingDaniel Vetter
Taking the modeset locks unconditionally isn't the greatest idea, because atm that part is still broken and times out (and then atomic keels over). And there's really no reason to do so, the old code didn't do that either. To make the patch a bit simpler let's also nuke 2 cases that are only around for the old mmioflip paths. Atomic nonblocking workers will not die (minus bugs) when a gpu reset happens. And of course this doesn't fix any of the gpu reset vs. modeset deadlock fun, but it at least stop modern CI machines from keeling over all over the place for no reason at all. And we still have the explicit testcases to run the fake gpu reset, so coverage isn't that much worse. v2: Split out additional changes on top, restrict this to purely reducing the critical section of modeset locks. v2: Review from Maarten - update comments - don't oops when state is NULL in intel_finish_reset, but try to at least still drop locks properly. The hw is going to be toast anyway. Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-3-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Nuke legacy flip queueing codeDaniel Vetter
Just a very minimal patch to nuke that code. Lots of the flip interrupt handling stuff is still around. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719125502.25696-2-daniel.vetter@ffwll.ch
2017-07-20drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()Matthias Kaehlcke
Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") misses some pieces, due to a problem with the patch format, this patch adds the remaining bits. Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH transcoders") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719173928.186638-1-mka@chromium.org
2017-07-20drm/mst: Avoid processing partially received up/down message transactionsImre Deak
Currently we may process up/down message transactions containing uninitialized data. This can happen if there was an error during the reception of any message in the transaction, but we happened to receive the last message correctly with the end-of-message flag set. To avoid this abort the reception of the transaction when the first error is detected, rejecting any messages until a message with the start-of-message flag is received (which will start a new transaction). This is also what the DP 1.4 spec 2.11.8.2 calls for in this case. In addtion this also prevents receiving bogus transactions without the first message with the the start-of-message flag set. v2: - unchanged v3: - git add the part that actually skips messages after an error in drm_dp_sideband_msg_build() Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719134632.13366-1-imre.deak@intel.com
2017-07-20drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()Imre Deak
In case of an unknown broadcast message is sent mstb will remain unset, so check for this. Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-3-imre.deak@intel.com
2017-07-20drm/mst: Fix error handling during MST sideband message receptionImre Deak
Handle any error due to partial reads, timeouts etc. to avoid parsing uninitialized data subsequently. Also bail out if the parsing itself fails. Cc: Dave Airlie <airlied@redhat.com> Cc: Lyude <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-2-imre.deak@intel.com
2017-07-20Merge tag 'drm-intel-next-2017-07-17' of ↵Dave Airlie
git://anongit.freedesktop.org/git/drm-intel into drm-next 2nd round of 4.14 features: - prep for deferred fbdev setup - refactor fixed 16.16 computations and skl+ wm code (Mahesh Kumar) - more cnl paches (Rodrigo, Imre et al) - tighten context cleanup and handling (Chris Wilson) - fix interlaced handling on skl+ (Mahesh Kumar) - small bits as usual * tag 'drm-intel-next-2017-07-17' of git://anongit.freedesktop.org/git/drm-intel: (84 commits) drm/i915: Update DRIVER_DATE to 20170717 drm/i915: Protect against deferred fbdev setup drm/i915/fbdev: Always forward hotplug events drm/i915/skl+: unify cpp value in WM calculation drm/i915/skl+: WM calculation don't require height drm/i915: Addition wrapper for fixed16.16 operation drm/i915: cleanup fixed-point wrappers naming drm/i915: Always perform internal fixed16 division in 64 bits drm/i915: take-out common clamping code of fixed16 wrappers drm/i915/cnl: Add missing type case. drm/i915/cnl: Add max allowed Cannonlake DC. drm/i915: Make DP-MST connector info work drm/i915/cnl: Get DDI clock based on PLLs. drm/i915/cnl: Inherit RPS stuff from previous platforms. drm/i915/cnl: Gen10 render context size. drm/i915/cnl: Don't trust VBT's alternate pin for port D for now. drm/i915: Fix the kernel panic when using aliasing ppgtt drm/i915/cnl: Cannonlake color init. drm/i915/cnl: Add force wake for gen10+. x86/gpu: CNL uses the same GMS values as SKL ...
2017-07-19drm/i915/selftests: Mark contexts as lost during freeing of mock deviceChris Wilson
We need to unpin the last retired context early in the shutdown sequence so that its RCU free is done before we try to free the context ida. I included this in a later patch ("drm/i915: Keep a recent cache of freed contexts objects for reuse") and so missed that the selftests were broken in the meantime. Reported-by: Matthew Auld <matthew.auld@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101627 Fixes: 5f09a9c8ab6b ("drm/i915: Allow contexts to be unreferenced locklessly") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719135957.14603-1-chris@chris-wilson.co.uk Tested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-07-19drm/i915: unregister interfaces first in unloadDaniel Vetter
We first need to make sure no one else can get at us anymore, before we can proceed to tear down all the datastructures. Just a small step towards eventually the perfect unload code ... Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-3-daniel.vetter@ffwll.ch
2017-07-19drm/i915: Fix fbdev unload sequenceDaniel Vetter
First thing we need to do is unregister the fbdev instance, but we can't just go ahead and kfree it. That must wait until the hotplug and polling work are stopped, since they can race with the with the teardown. That means we need to split up the fbdev teardown into the unregister part and the cleanup part. I originally suspected that this was broken in one of the unload shuffles, but on closer inspection the oldest sequence I've dug out also gets this wrong. Just not quite so badly. I've run drv_module_reload a few hundred times and it's rock solid compared to insta-death beforehand. This bug seems to have been uncovered by commit 88be58be886f1215cc73dc8c273c985eecd7385c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 6 15:00:19 2017 +0200 drm/i915/fbdev: Always forward hotplug events But the effect of that seems to only be to increase the race window enough to make it blow up easier. I'm not exactly clear on what's going on there ... v2: Fix whitespace and use fetch_and_zero (Chris). Testcase: igt/drv_module_reload Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791 Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170714224656.6431-2-daniel.vetter@ffwll.ch
2017-07-19drm/atomic-helper: Fix leak in disable_allDaniel Vetter
The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup first, and that usually cleans up the fb through drm_remove_framebuffer, which does this correctly. - Without fbdev the only framebuffers are from userspace, and those get cleaned up (again using drm_remove_framebuffer) befor the driver can even be unloaded. But in i915 I've switched the cleanup sequence around so that the _shutdown() calls happens after the drm_remove_framebuffer(), which is how I discovered this issue. v2: My analysis why the current code was ok for gpu reset and suspend/resume was correct, but then I totally failed to realize that we better keep this symmetric. Thanksfully CI noticed that for balance, a refcounting bug must exist at 2 places if previously there was no issue ... v3: Don't be lazy and compute the plane_mask in commit_duplicated_state properly too, instead of just using ~0U. Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Acked-by: Dave Airlie <airlied@gmail.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715093106.19873-1-daniel.vetter@ffwll.ch
2017-07-19drm/i915/selftests: Attach a stub pm_domainChris Wilson
Supply a pm_domain and its ops for our mock GEM device so that device runtime pm doesn't complain even though we only want to mark it permanently active! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170718173028.31207-1-chris@chris-wilson.co.uk Tested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-07-19drm/i915: Drain the device workqueue on unloadChris Wilson
Workers on the i915->wq may rearm themselves so for completeness we need to replace our flush_workqueue() with a call to drain_workqueue() before unloading the device. v2: Reinforce the drain_workqueue with an preceding rcu_barrier() as a few of the tasks that need to be drained may first be armed by RCU. References: https://bugs.freedesktop.org/show_bug.cgi?id=101627 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170718134124.14832-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2017-07-19drm/i915: More stolen quirkingDaniel Vetter
I've found a bios with an off-by-one at the other end. There's a pnp reservation for 0xc5400000-0xc7fffffe and we want stolen in 0xc6000000 through 0xc8000000. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99872 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98683 Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719100043.30851-1-daniel.vetter@ffwll.ch
2017-07-19drm/i915: Fix bad comparison in skl_compute_plane_wm, v2.Maarten Lankhorst
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler warning: drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than 0 or 1. Changes since v1: - Rebase, was missing the changes to the macro names. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d555cb5827d6 ("drm/i915/skl+: use linetime latency if ddb size is not available") Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com> Reported-by: David Binderman <dcb314@hotmail.com> Cc: David Binderman <dcb314@hotmail.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170717120230.2023-1-maarten.lankhorst@linux.intel.com Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
2017-07-19drm/i915: Explicit the connector name for DP link training resultPaul Kocialkowski
This adds the connector name when printing a debug message about the DP link training result. It is useful to figure out what connector is failing when multiple DP connectors are used. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170718142536.2306-1-paul.kocialkowski@linux.intel.com
2017-07-18sun4i_hdmi: add CEC supportHans Verkuil
Add HDMI CEC support to the Allwinner A10 SoC. This SoC uses a poor-man's CEC implementation by polling the CEC pin. It is using the CEC_PIN core implementation for such devices to do the heavy lifting. It just provides the callbacks to read/drive the CEC pin. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-18drm/sun4i: tcon: remove unused functionMaxime Ripard
Even though that function is defined in the TCON header, it's not defined nor used anywhere. Remove the prototype. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-18drm/sun4i: Remove useless atomic_checkMaxime Ripard
The atomic_check callback is optional, and we don't implement anything in some parts of our drivers. Let's remove it. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-18drm/sun4i: Add if statement instead of depends onMaxime Ripard
The depends on relationship is obvious, and using an if statement will propagate it to every option without the need for each and every one of them to define it. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-07-18drm/i915: Fix cursor updates on some platformsVille Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor on some platforms. My 830 works just fine, but eg. 945 and PNV don't. On those platforms we need to arm even the CURPOS update with a CURBASE write. Even worse, a write to any of the cursor register apart from CURBASE will cancel an already pending cursor update. So if we have armed a CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank would cancel that armed update. Thus we're left with a cursor that doesn't appear to move, or even change shape. Fix the problem by always performing the CURBASE write after a CURPOS write. Bspec is somewhat unclear which platforms actually require this CURBASE write and which don't. So to keep it simple and to make sure we really fix the problem across all supported devices, let's just perform the CURBASE write unconditionally. Cc: Paul Menzel <pmenzel@molgen.mpg.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790 Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
2017-07-18x86, drm, fbdev: Do not specify encrypted memory for video mappingsTom Lendacky
Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/a19436f30424402e01f63a09b32ab103272acced.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-18drm: Don't complain too much about struct_mutex.Daniel Vetter
For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in totally different places in the locking hierarchy. This results in a lot of bogus lockdep splats when running stuff on systems with multiple gpus. Partially remedy the situation by only doing might_lock checks on drivers that do use struct_mutex still for gem locking. A more complete solution would be to do the mutex_init in the drm core only for legacy drivers, plus add it to each modern driver that still needs it, which would also give each its own lockdep key. Trying to do that dynamically doesn't work, because lockdep requires it's keys to be statically allocated. v2: {} everywhere (Chris) Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715095328.25671-1-daniel.vetter@ffwll.ch
2017-07-17drm/vmwgfx: constify pci_device_id.Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 13765 800 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o File size After adding 'const': text data bss dec hex filename 13829 736 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2017-07-17drm/vmwgfx: Fix gcc-7.1.1 warningSinclair Yeh
The current code does not look correct, and the reason for it is probably lost. Since this now generates a compiler warning, fix it to what makes sense. Cc: <stable@vger.kernel.org> Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2017-07-17drm/vmwgfx: Fix cursor hotspot issue with Wayland on FedoraSinclair Yeh
Parts of commit <8fbf9d92a7bc> (“drm/vmwgfx: Implement the cursor_set2 callback v2”) were not moved over when we started atomic mode set development because at that time the DRM did not support cursor hotspots in the fb struct. This patch fixes what was not moved over. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Tested-by: Brian Paul <brianp@vmware.com>
2017-07-17drm/vmwgfx: Limit max desktop dimensions to 8Kx8KSinclair Yeh
This was originally chosen to be an arbitrarily large number. However, some user mode may actually try to set a 16Kx16K mode and run into other issues. Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will just use this limit for now. Cc: <stable@vger.kernel.org> # 4.12.x Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2017-07-17drm/vmwgfx: dma-buf: Constify ttm_place structures.Arvind Yadav
ttm_place are not supposed to change at runtime. All functions working with ttm_place provided by <drm/ttm/ttm_placement.h> work with const ttm_place. So mark the non-const structs as const. File size before: text data bss dec hex filename 3172 796 16 3984 f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o File size After adding 'const': text data bss dec hex filename 3456 512 16 3984 f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2017-07-17drm/vmwgfx: fix comment mistake for vmw_cmd_dx_set_index_buffer()Brian Paul
Comment fix. Signed-off-by: Brian Paul <brianp@vmware.com> Reviewed-by: Neha Bhende <bhenden@vmware.com>
2017-07-17drm/vmwgfx: Use dma_pool_zallocSouptick Joarder
We should use dma_pool_zalloc instead of dma_pool_alloc/memset Signed-off-by: Souptick joarder <jrdr.linux@gmail.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Sinclair Yeh <syeh@vmware.com>
2017-07-17drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'Christophe JAILLET
'vmw_cotable_alloc()' returns an error pointer on error, not NULL. Propagate the error code, instead of returning -ENOMEM unconditionally Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Sinclair Yeh <syeh@vmware.com>
2017-07-18drm/zte: Use gem_free_object_unlockedDaniel Vetter
CMA helpers are struct_mutex free, and so is the zte itself. And that's the only valid reason for using gem_free_object. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-3-daniel.vetter@ffwll.ch
2017-07-18drm/pl111: Use gem_free_object_unlockedDaniel Vetter
CMA helpers are struct_mutex free, and so is the pl111 itself. And that's the only valid reason for using gem_free_object. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-2-daniel.vetter@ffwll.ch
2017-07-18drm/mxsfb: Use gem_free_object_unlockedDaniel Vetter
CMA helpers are struct_mutex free, and so is the mxsfb itself. And that's the only valid reason for using gem_free_object. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-1-daniel.vetter@ffwll.ch
2017-07-17drm/vmwgfx: Fix NULL pointer comparisonRavikant B Sharma
Replace direct comparisons to NULL i.e. 'x == NULL' with '!x'. As per coding standard. Signed-off-by: Ravikant B Sharma <ravikant.s2@samsung.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Sinclair Yeh <syeh@vmware.com>
2017-07-18drm/i915: Consistently use enum pipe for PCH transcodersMatthias Kaehlcke
The current code uses in some instances enum transcoder for PCH transcoders and enum pipe in others. This is error prone and clang raises warnings like this: drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion from enumeration type 'enum pipe' to different enumeration type 'enum transcoder' [-Wenum-conversion] intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); Consistently use the type enum pipe for PCH transcoders. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170717181403.57324-1-mka@chromium.org
2017-07-18drm/bridge/synopsys: Add MIPI DSI host controller bridgePhilippe CORNU
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Signed-off-by: Philippe CORNU <philippe.cornu@st.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-5-git-send-email-philippe.cornu@st.com
2017-07-18drm/stm: ltdc: Add panel-bridge supportPhilippe CORNU
Add the panel-bridge support for both panels & bridges (used by DSI host & HDMI/LVDS bridges). Signed-off-by: Philippe CORNU <philippe.cornu@st.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-3-git-send-email-philippe.cornu@st.com
2017-07-18drm/stm: ltdc: Fix leak of px clk enable in some error pathsPhilippe CORNU
The pixel clock gets enabled early during init, since it's required in order to read registers. This pixel clock must be disabled if errors during this init phase. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-2-git-send-email-philippe.cornu@st.com
2017-07-17drm/vgem: add compat_ioctl supportBrian Norris
DRM drivers should supply a compat version if they're going to provide an ioctl implementation at all. This can confuse 32-bit user space on a 64-bit system. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170715031212.108695-1-briannorris@chromium.org
2017-07-17drm/crc: Only open CRC on atomic drivers when the CRTC is active.Maarten Lankhorst
Commit e8fa5671183c ("drm: crc: Wait for a frame before returning from open()") adds a wait for CRC frame, but with the CRTC off this will never be generated. For atomic drivers we know if a CRTC is active through crtc_state->active, so when inactive reject the open with -EIO. Just like with the previous patch changing debugfs opening semantics, this patch has been tested against igt. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from open()") Testcase: debugfs_test.read_all_entries Link: http://patchwork.freedesktop.org/patch/msgid/15f9d300-65d3-63aa-00e3-e83f5e4d5a7a@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-17drm/crc: Handle opening and closing crc betterMaarten Lankhorst
When I was doing a grep . -r /sys/kernel/debug/dri/0 I noticed a WARN appearing when I aborted the grep with ^C. After investigating I've also noticed that the error handling was lacking and there are race conditions involving multiple calls to open/close simultaneously. Fix this by setting the opened flag first and using crc->entries to decide when crc can be collected. Also call unset crc source before cleaning up, this way there is no race with a future open(). This patch has been tested with all the tests in igt with CRC in their name. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170621110007.11674-1-maarten.lankhorst@linux.intel.com Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> [mlankhorst: Add description that this patch has been tested with IGT, based on tomeu's feedback]
2017-07-17drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failurePhilipp Zabel
The parallel panel driver should continue to work without having an endpoint linking to an panel in DT for backwards compatibility. With the recent switch to drm_of_find_panel_or_bridge, an absent panel results in a failure with -ENODEV error return code. To restore the old behaviour, ignore the -ENODEV return code. Reported-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge") Tested-by: Chris Healy <cphealy@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-14 13:24:19 +0000