- 03 Jul, 2017 6 commits
-
-
Arvind Yadav authored
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 3485 184 264 3933 f5d drivers/gpu/drm/qxl/qxl_ttm.o File size After adding 'const': text data bss dec hex filename 3501 152 264 3917 f4d drivers/gpu/drm/qxl/qxl_ttm.o Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/a4f21d3bd2497129f084b8055ecf27f0d3ff1bba.1499013516.git.arvind.yadav.cs@gmail.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Arvind Yadav authored
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 2315 184 0 2499 9c3 drivers/gpu/drm/virtio/virtgpu_ttm.o File size After adding 'const': text data bss dec hex filename 2347 152 0 2499 9c3 drivers/gpu/drm/virtio/virtgpu_ttm.o Signed-off-by:
-
Arvind Yadav authored
dma_buf_ops are not supposed to change at runtime. All functions working with dma_buf_ops provided by <linux/dma-buf.h> work with const dma_buf_ops. So mark the non-const structs as const. File size before: text data bss dec hex filename 2002 112 0 2114 842 drivers/gpu/drm/udl/udl_dmabuf.o File size After adding 'const': text data bss dec hex filename 2114 0 0 2114 842 drivers/gpu/drm/udl/udl_dmabuf.o Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/cb4dfac90e85e2270779331f8cb10b635042bad7.1498912415.git.arvind.yadav.cs@gmail.com
-
Arvind Yadav authored
drm_prop_enum_lists are not supposed to change at runtime. All functions working with drm_prop_enum_list provided by <drm/drm_property.h> work with const drm_prop_enum_list. So mark the non-const structs as const. File size before: text data bss dec hex filename 3594 176 0 3770 eba drivers/gpu/drm/armada/armada_overlay.o File size After adding 'const': text data bss dec hex filename 3722 48 0 3770 eba drivers/gpu/drm/armada/armada_overlay.o Signed-off-by:
-
Arvind Yadav authored
drm_prop_enum_lists are not supposed to change at runtime. All functions working with drm_prop_enum_list provided by <drm/drm_property.h> work with const drm_prop_enum_list. So mark the non-const structs as const. File size before: text data bss dec hex filename 9629 744 0 10373 2885 drivers/gpu/drm/armada/armada_crtc.o File size After adding 'const': text data bss dec hex filename 9757 616 0 10373 2885 drivers/gpu/drm/armada/armada_crtc.o Signed-off-by:
-
Gustavo Padovan authored
In some cases, like cursor updates, it is interesting to update the plane in an asynchronous fashion to avoid big delays. The current queued update could be still waiting for a fence to signal and thus block any subsequent update until its scan out. In cases like this if we update the cursor synchronously through the atomic API it will cause significant delays that would even be noticed by the final user. This patch creates a fast path to jump ahead the current queued state and do single planes updates without going through all atomic steps in drm_atomic_helper_commit(). We take this path for legacy cursor updates. For now only single plane updates are supported, but we plan to support multiple planes updates and async PageFlips through this interface as well in the near future. v6: - move check code to drm_atomic_helper.c (Daniel Vetter) v5: - improve comments (Eric Anholt) v4: - fix state->crtc NULL check (Archit Taneja) v3: - fix iteration on the wrong crtc state - put back code to forbid updates if there is a queued update for the same plane (Ville Syrjälä) - move size checks back to drivers (Ville Syrjälä) - move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä) v2: - allow updates even if there is a queued update for the same plane. - fixes on the documentation (Emil Velikov) - unconditionally call ->atomic_async_update (Emil Velikov) - check for ->atomic_async_update earlier (Daniel Vetter) - make ->atomic_async_check() the last step (Daniel Vetter) - add ASYNC_UPDATE flag (Eric Anholt) - update state in core after ->atomic_async_update (Eric Anholt) - update docs (Eric Anholt) Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:Gustavo Padovan <gustavo.padovan@collabora.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> (v5) Acked-by: Eric Anholt <eric@anholt.net> (v5) Reviewed-by:
-
- 30 Jun, 2017 3 commits
-
-
Daniel Vetter authored
Core code should never have to look at helper stuff, to make sure that all helper code is 100% optional and can be overriden. Cc: Gustavo Padovan <gustavo@padovan.org> Reviewed-by:
-
Laurent Pinchart authored
The CRTC .disable() helper operation is deprecated for atomic drivers, the new .atomic_disable() helper operation being preferred. Convert all atomic drivers to .atomic_disable() to avoid cargo-cult use of .disable() in new drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # for sun4i Acked-by: Philipp Zabel <p.zabel@pengutronix.de> # for mediatek Acked-by: Alexey Brodkin <abrodkin@synopsys.com> # for arcpgu Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # for atmel-hlcdc Tested-by: Philippe Cornu <philippe.cornu@st.com> # for stm Acked-by: Philippe Cornu <philippe.cornu@st.com> # for stm Acked-by: Vincent Abriou <vincent.abriou@st.com> # for sti Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> # for vmwgfx Signed-off-by:
-
Laurent Pinchart authored
The old state is useful for drivers that need to perform operations at enable time that depend on the transition between the old and new states. While at it, rename the operation to .atomic_enable() to be consistent with .atomic_disable(), as the .enable() operation is used by atomic helpers only. Signed-off-by:
-
- 29 Jun, 2017 7 commits
-
-
Chris Wilson authored
Reduce the list iteration when incrementing the timeline by storing the fences in increasing order. v2: Prevent spinlock recursion on free during create v3: Fixup rebase conflict inside comments that escaped the compiler. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Gustavo Padovan <gustavo@padovan.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Chris Wilson authored
The sync_pt were not adding themselves atomically to the timeline lists, corruption imminent. Only a single list is required to track the unsignaled sync_pt, so reduce it and rename the lock more appropriately along with using idiomatic names to distinguish a list from links along it. v2: Prevent spinlock recursion on free during create (next patch) and fixup crossref in kerneldoc Signed-off-by:
-
Chris Wilson authored
Since sync_pt is only allocated from a single location and is no longer the base class for fences (that is struct dma_fence) it no longer needs a generic unsized allocator. Signed-off-by:
-
Chris Wilson authored
If we know the context under which we are called, then we can use the simpler form of spin_lock_irq (saving the save/restore). Signed-off-by:
-
Chris Wilson authored
The timeline is u32, which limits any single advance to INT_MAX so that we can detect all fences that need signaling. Signed-off-by:
-
Chris Wilson authored
Use the canonical __dma_fence_is_later() to compare the fence seqno against the timeline seqno to check if the fence is signaled. Signed-off-by:
-
Chris Wilson authored
Often we have the task of comparing two seqno known to be on the same context, so provide a common __dma_fence_is_later(). Signed-off-by:
-
- 28 Jun, 2017 10 commits
-
-
Dan Carpenter authored
"connector" is the list iterator and it can't be NULL. It causes a static checker warning because we dereference the iterator to get the next item in the list. Let's remove this check. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Laurent Pinchart authored
The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by:
-
Laurent Pinchart authored
The CRTC .prepare() helper operation is part of the legacy helpers and is deprecated in favour of the .disable() helper operation. As the vmwgfx driver provides a .disable() helper operation, and as the .prepare() helper operation implementation is empty, we can remove it. Signed-off-by:
-
Laurent Pinchart authored
The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. Replace the .commit() helper operation with .enable() in the driver. Signed-off-by:
-
Laurent Pinchart authored
The CRTC .dpms() helper operation is called by the atomic helpers only when no .prepare(), .atomic_disable() or .disable() operation is provided. As the qxl driver provides a .disable() operation, the .dpms() operation is unused and can be removed. Signed-off-by:
-
Laurent Pinchart authored
The CRTC helper .prepare() operation is legacy code, the atomic helpers prefer the .disable() operation. As the arcpgu driver implements the .disable() and .prepare() operations identicallly, .prepare() can be removed. Signed-off-by:
-
Laurent Pinchart authored
The CRTC helper .commit() operation is legacy code, the atomic helpers prefer the .enable() operation. As the arcpgu driver implements the .enable() operation, .commit() is never used and can be removed. Signed-off-by:
-
Daniel Vetter authored
There's no reason for drivers to call this, and all the ones I've removed looked very fishy: - Proper quiescenting of the vblank machinery should be done by calling drm_crtc_vblank_off(), which is best done by shutting down the entire display engine with drm_atomic_helper_shutdown. - Releasing of allocated memory is done by the core already, it calls drm_vblank_cleanup as a fallback. - drm_vblank_cleanup also has checks for drivers which forget to clean up vblank interrupts. This essentially reverts commit e77cef9c Author: Jerome Glisse <jglisse@redhat.com> Date: Thu Jan 7 15:39:13 2010 +0100 drm: Avoid calling vblank function is vblank wasn't initialized which was done to fix a bug in radeon code with msi interrupts: commit 003e69f9 Author: Jerome Glisse <jglisse@redhat.com> Date: Thu Jan 7 15:39:14 2010 +0100 drm/radeon/kms: Don't try to enable IRQ if we have no handler installed Afaict from digging around in old code, this was needed to avoid blowing up in the ums fallback, and has stopped serving it's purpose long ago - if irq init fails, the driver fails to load, and there's really no way to blow up anymore. Long story short, this was most likely a small ums compat/fallback hack that became a thing of it's own and got cargo-cult duplicated all over the drm codebase for essentially no gain at all. v2: Mention that for drivers with a ->release callback cleanup is handled by drm_dev_fini() (Thierry). Cc: Thierry Reding <treding@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Cc: Jerome Glisse <jglisse@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
This was accidentally restored in commit de5cc815 Author: Liviu Dudau <Liviu.Dudau@arm.com> Date: Tue Jun 6 15:05:21 2017 +0100 drm/arm: hdlcd: Set the CRTC's port before binding the encoder Fixes: de5cc815 ("drm/arm: hdlcd: Set the CRTC's port before binding the encoder.") Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Acked-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Andrey Grodzovsky authored
Problem : While running IGT kms_atomic_transition test suite i encountered a hang in drmHandleEvent immediately following an atomic_commit. After dumping the atomic state I relized that in this case there was not even one CRTC attached to the state and only disabled planes. This probably due to a commit which hadn't changed any property which would require attaching crtc state. This means drmHandleEvent will never wake up from read since without CRTC in atomic state the event fd will not be signaled. Fix: Protect against this issue by failing atomic_commit early in drm_mode_atomic_commit where such probelm can be identified. v2: Fix typos and extra newlines. Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8 Signed-off-by:
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 27 Jun, 2017 3 commits
-
-
Sean Paul authored
Required for Daniel's drm_vblank_cleanup cleanup
-
Daniel Vetter authored
The crtc->commit_lock only protects commit_list and commit_entry. If we chase the pointer from the drm_atomic_state update structure, then we don't need any locks (since we hold a reference already). Simplify the locking accordingly. Noticed while reviewing a patch from Boris. Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by:
-
Daniel Vetter authored
Again stopping the vblank before uninstalling the irq handler is kinda the wrong way round, but the fb_off stuff should take care of disabling the dsiplay at least in most cases. So drop the drm_vblank_cleanup code since it's not really doing anything, it looks all cargo-culted. v2: Appease gcc better. v3: Simplify code (Sean Paul) Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
- 26 Jun, 2017 9 commits
-
-
Dave Airlie authored
Linux 4.12-rc7 Needed at least rc6 for drm-misc-next-fixes, may as well go to rc7
-
Daniel Vetter authored
udl doesn't shut down the display, so stopping the vblank isn't going to do much good either. Just drop it. Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Daniel Vetter authored
Either not relevant (in the load error paths) or done better already (in the unload code, by calling drm_atomic_helper_shutdown). Drop it. Cc: Mark Yao <mark.yao@rock-chips.com> Reviewed-by:
-
Daniel Vetter authored
nouveau_display_vblank_fini is called in the load error path (where it doesn't matter) and module unload (where vblanks have been shut down correctly already through drm_vblank_off), we can drop it. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by:
-
Daniel Vetter authored
Seems entirely cargo-culted. Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
Daniel Vetter authored
On the load error path we can't have pending vblank interrupts, and on unload we already call drm_atomic_helper_shutdown beforehand! So all good to nuke it. Reviewed-by:
-
Daniel Vetter authored
Again we probably want a drm_atomic_helper_shutdown somewhere, but that's a bit more analysis. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Reviewed-by:
-
Daniel Vetter authored
So this seems to be the first driver that does it the right way round, so fix it up by calling drm_atomic_helper_shutdown instead. We need to do that before the last kms user is gone (fbdev emulation), but before we start shutting down hw stuff like interrupts. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Reviewed-by:
-
Linus Torvalds authored
-
- 25 Jun, 2017 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Thomas Gleixner: "A single fix to unbreak the vdso32 build for 64bit kernels caused by excess #includes in the mshyperv header" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mshyperv: Remove excess #includes from mshyperv.h
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "A few fixes for timekeeping and timers: - Plug a subtle race due to a missing READ_ONCE() in the timekeeping code where reloading of a pointer results in an inconsistent callback argument being supplied to the clocksource->read function. - Correct the CLOCK_MONOTONIC_RAW sub-nanosecond accounting in the time keeping core code, to prevent a possible discontuity. - Apply a similar fix to the arm64 vdso clock_gettime() implementation - Add missing includes to clocksource drivers, which relied on indirect includes which fails in certain configs. - Use the proper iomem pointer for read/iounmap in a probe function" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting time: Fix clock->read(clock) race around clocksource changes clocksource: Explicitly include linux/clocksource.h when needed clocksource/drivers/arm_arch_timer: Fix read and iounmap of incorrect variable
-
