- 13 Jun, 2016 10 commits
-
-
Gustavo Padovan authored
We don't need to use &amdgpu_crtc->base there as crtc is available in the function. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-9-git-send-email-gustavo@padovan.org
-
Gustavo Padovan authored
Replace the legacy drm_vblank_{on,off}() with the new helper functions. Signed-off-by: -
Gustavo Padovan authored
Replace the legacy drm_vblank_{on,off}() with the new helper functions. Signed-off-by: -
Gustavo Padovan authored
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by:
-
Gustavo Padovan authored
We don't have any user of this function anymore, let's remove it. Signed-off-by:
-
Gustavo Padovan authored
We don't have any user of this function anymore, let's remove it. Signed-off-by:
-
Gustavo Padovan authored
Replace the legacy drm_send_vblank_event(), drm_arm_vblank_event() and drm_vblank_{get,put}() with the new helper functions. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Signed-off-by: -
Rob Clark authored
There were a couple messed up things about this fail path. (1) it would drop object_name_lock twice (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles()) needs to grab prime_lock Reported-by:Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Thierry Reding authored
Implement a uevent callback for devices on the MIPI DSI bus. This callback will append MODALIAS information to the uevent and allow modules to be loaded when devices are added to the bus. Reviewed-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
Thierry Reding <treding@nvidia.com>
-
Sudip Mukherjee authored
We may have a situation that the memory allocation for fbdefio fails and then the allocation for fbops may succeed as some memory has been freed somewhere. Lets free fbops also to face these rare situtation. Since kfree can handle arguments as NULL, there should not be any problem in calling both the kfree(). Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Fixes: 199c7717 ("drm/fb-cma-helper: Add fb_deferred_io support") Signed-off-by:
-
- 10 Jun, 2016 30 commits
-
-
Boris Brezillon authored
For all outputs except dp_mst, we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Noralf Trønnes authored
Provides helper functions for drivers that have a simple display pipeline. Plane, crtc and encoder are collapsed into one entity. Changes since v4: - Remove drm_connector_register() call - Forgot to assign pipe->connector Changes since v3: - (struct drm_simple_display_pipe *)->funcs should be const Changes since v2: - Drop Kconfig knob DRM_KMS_HELPER - Expand documentation Changes since v1: - Add DOC header and add to gpu.tmpl - Fix docs: @funcs is optional, "negative error code", "This hook is optional." - Add checks to drm_simple_kms_plane_atomic_check() Cc: jsarha@ti.com Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders, which means we can rely on the drm_atomic_helper_best_encoder() behavior. We still have to explicitly assign ->best_encoder() to drm_atomic_helper_best_encoder(), because the automated fallback to drm_atomic_helper_best_encoder() when ->best_encoder() is NULL is only available when the DRM device is using the atomic helpers, and this bridge is compatible with non-atomic and atomic devices. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Boris Brezillon authored
The virtgpu output exposes a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Signed-off-by:
-
Boris Brezillon authored
All outputs have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
-
Boris Brezillon authored
We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
-
Liviu Dudau authored
Documentation for drm_atomic_crtc_for_each_plane() makes reference to a function called drm_crtc_for_each_pending_plane(). I've guessed that the actual function name is drm_atomic_crtc_state_for_each_plane() as that matches best the intent of the comment. Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Tomeu Vizoso authored
The DP needs to have resumed once the DRM driver calls drm_atomic_helper_resume, otherwise the DP clock is still disabled when the DRM core enables the DP bridge. Would be nice to use device_pm_wait_for_dev to synchronize these devices, but the DRM device doesn't know what specific implementation this bridge has. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Caesar Wang <wxt@rock-chips.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Yakir Yang <ykk@rock-chips.com> Signed-off-by:
-
Tomeu Vizoso authored
This driver was still using the old legacy helpers and that caused a few NULL dereferences when trying to call empty callbacks. Signed-off-by:
-
Daniel Vetter authored
This is now handled by the core, drivers can totally ignore lifetime issues of drm events. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark yao <mark.yao@rock-chips.com> Tested-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-11-git-send-email-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
With the various bits fixed rockchip now has an atomic compliant handling/signalling of crtc_state->event, which means we can just switch over to the new nonblocking helpers and remove some code. v2: Fixes from Tomeu. v3: Send out vblank events correctly when shutting down a crtc for good. This is part of the atomic interface contract. v4: Properly protect vop->event. v5: Add more WARN_ON to check vop->event isn't clobbered. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark yao <mark.yao@rock-chips.com> Tested-by:
-
Daniel Vetter authored
It's not permissible to look at plane->state from interrupt context, since doing that would need the irq handler to acquire the plane->mutex lock. The other problem is that if we pipeline updates using the new nonblocking atomic helpers new state gets commit before the irq handler fires, resulting in a lost event. Fix both issues by caching the necessary values in vop_win, protected by dev->event_lock. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark yao <mark.yao@rock-chips.com> Tested-by:
-
Daniel Vetter authored
With atomic helpers there's no need to track the enabled state of a pipe any more, because atomic helpers track this accurately already. Just disable the early returns, since the debug checks might be useful. v2: Don't call drm_helper_disable_unused_functions, it blows up without this check. At least explains why rockchip still needed this old legacy-style state tracing - to work around issues from calling other legacy style functions! Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark yao <mark.yao@rock-chips.com> Tested-by:
-
Daniel Vetter authored
With the fixed up drm event handling for crtc_state->event we can just use the helper support for nonblocking commits. Cc: Liviu Dudau <Liviu.Dudau@arm.com> Tested-by:
-
Daniel Vetter authored
Committing with block it is not. Thanks to the fixed up vblank event handling we can just use the helper support for nonblocking commits now. Cc: Carlos Palminha <palminha@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
Design ideas: - split up the actual commit into different phases, and have completions for each of them. This will be useful for the future when we want to interleave phases much more aggressively, for e.g. queue depth > 1. For not it's just a minimal optimization compared to current common nonblocking implementation patterns from drivers, which all stall for the entire commit to complete, including vblank waits and cleanups. - Extract a separate atomic_commit_hw hook since that's the part most drivers will need to overwrite, hopefully allowing even more shared code. - Enforce EBUSY seamntics by attaching one of the completions to the flip_done vblank event. Side benefit of forcing atomic drivers using these helpers to implement event handlign at least semi-correct. I'm evil that way ;-) - Ridiculously modular, as usual. - The main tracking unit for a commit stays struct drm_atomic_state, and the ownership rules for that are unchanged. Ownership still gets transferred to the driver (and subsequently to the worker) on successful commits. What is added is a small, per-crtc, refcounted structure to track pending commits called struct drm_crtc_commit. No actual state is attached to that though, it's purely for ordering and waiting. - Dependencies are implicitly handled by assuming that any CRTC part of &drm_atomic_state is a dependency, and that the current commit must wait for any commits to complete on those CRTC. This way drivers can easily add more depencies using drm_atomic_get_crtc_state(), which is very natural since in most case a dependency exists iff there's some bit of state that needs to be cross checked. Removing depencies is not possible, drivers simply need to be careful to not include every CRTC in a commit if that's not necessary. Which is a good idea anyway, since that also avoids ww_mutex lock contention. - Queue depth > 1 sees some prep work in this patch by adding a stall paramater to drm_atomic_helper_swap_states(). To be able to push commits entirely free-standing and in a deeper queue through the back-end the driver must not access any obj->state pointers. This means we need to track the old state in drm_atomic_state (much easier with the consolidated arrays), and pass them all explicitly to driver backends (this will be serious amounts of churn). Once that's done stall can be set to false in swap_states. v2: Dont ask for flip_done signalling when the CRTC is off and stays off: Drivers don't handle events in that case. Instead complete right away. This way future commits don't need to have special-case logic, but can keep blocking for the flip_done completion. v3: Tons of fixes: - Stall for preceeding commit for real, not the current one by accident. - Add WARN_ON in case drivers don't fire the drm event. - Don't double-free drm events. v4: Make legacy cursor not stall. v5: Extend the helper hook to cover the entire commit tail. Some drivers need special code for cleanup and vblank waiting, this makes it a bit more useful. Inspired by the rockchip driver. v6: Add WARN_ON to catch drivers who forget to send out the drm event. v7: Fixup the stalls in swap_state for real!! v8: - Fixup trailing whitespace, spotted by Maarten. - Actually wait for flip_done in cleanup_done, like the comment says we should do. Thanks a lot for Tomeu for helping with debugging this on. v9: Now with awesome kerneldoc! v10: Split out drm_crtc_commit tracking infrastructure. v: - Add missing static (Gustavo). - Split out the sync functions, only do the actual nonblocking logic in this patch (Maarten). Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Tested-by:
-
Daniel Vetter authored
To facilitate easier reviewing this is split out from the overall nonblocking commit rework. It just rolls out the helper functions and uses them in the main drm_atomic_helper_commit() function to make it clear where in the flow they're used. The next patch will actually split drm_atomic_helper_commit() into 2 pieces, with the tail being run asynchronously from a worker. v2: Improve kerneldocs (Maarten). v3: Don't convert ERESTARTSYS to EINTR (Maarten). Also don't fail if the wait succeed in stall_check - we need to convert that case (it returns the remaining jiffies) to 0 for success. v4: Switch to long for wait_for_completion_timeout return value everywhere (Maarten). v5: Fix miscaped function in kerneldoc (Maarten). Reviewed-by:
-
Daniel Vetter authored
Split out from my big nonblocking atomic commit helper code as prep work. While add it, also add some neat asciiart to document how it's supposed to be used. v2: Resurrect misplaced hunk in the kerneldoc. v3: Wording improvements from Liviu. Tested-by:
-
Daniel Vetter authored
atomic_flush seems to be the right place, right after we commit the plane updates. Again use the fullproof version, since the pipe might be off. Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by:
-
