- 27 Dec, 2016 11 commits
-
-
Chris Wilson authored
Exercise drm_mm_insert_node(), check that we can't overfill a range and that the lists are correct after reserving/removing. v2: Extract helpers for the repeated tests v3: Iterate over all allocation flags Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161222083641.2691-11-chris@chris-wilson.co.uk
-
Chris Wilson authored
Exercise drm_mm_reserve_node(), check that we can't reserve an already occupied range and that the lists are correct after reserving/removing. v2: Check for invalid node reservation. Signed-off-by:
-
Chris Wilson authored
Simple test to just exercise calling the debug dumper on the drm_mm. Signed-off-by:
-
Chris Wilson authored
Simple first test to just exercise initialisation of struct drm_mm. Signed-off-by:
-
Chris Wilson authored
First we introduce a smattering of infrastructure for writing selftests. The idea is that we have a test module that exercises a particular portion of the exported API, and that module provides a set of tests that can either be run as an ensemble via kselftest or individually via an igt harness (in this case igt/drm_mm). To accommodate selecting individual tests, we export a boolean parameter to control selection of each test - that is hidden inside a bunch of reusable boilerplate macros to keep writing the tests simple. v2: Choose a random random_seed unless one is specified by the user. v3: More parameters to control max_iterations and max_prime of the tests. Testcase: igt/drm_mm Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Chris Wilson authored
When testing, we want a random but yet reproducible order in which to process elements. Here we create an array which is a random (using the Tausworthe PRNG) permutation of the order in which to execute. Note these are simple helpers intended to be merged upstream in lib/ v2: Tidier code by David Herrmann v3: Add reminder that this code is intended to be temporary, with at least the bulk of the prandom changes going to lib/ Signed-off-by:
-
Chris Wilson authored
Prime numbers are interesting for testing components that use multiplies and divides, such as testing DRM's struct drm_mm alignment computations. v2: Move to lib/, add selftest v3: Fix initial constants (exclude 0/1 from being primes) v4: More RCU markup to keep 0day/sparse happy v5: Fix RCU unwind on module exit, add to kselftests v6: Tidy computation of bitmap size v7: for_each_prime_number_from() v8: Compose small-primes using BIT() for easier verification v9: Move rcu dance entirely into callers. v10: Improve quote for Betrand's Postulate (aka Chebyshev's theorem) Signed-off-by:
-
Chris Wilson authored
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and validation checking using BUG_ON. Ideally these paths should all be exercised by CI selftests (with the asserts enabled). Signed-off-by:
-
Chris Wilson authored
Fairly commonly we want to inspect the node list on the struct drm_mm, which is buried within an embedded node. Bring it to the surface with a bit of syntatic sugar. Note this was intended to be split from commit ad579002 ("drm: Add drm_mm_for_each_node_safe()") before being applied, but my timing sucks. Signed-off-by:
-
Dhinakaran Pandiyan authored
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values are tracked in the state structures. v2: Included header Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by:
-
- 19 Dec, 2016 5 commits
-
-
Maarten Lankhorst authored
Do something similar to vc4, only allow updating the cursor state in-place through a fastpath when the watermarks are unaffected. This will allow cursor movement to be smooth, but changing cursor size or showing/hiding cursor will still fall back so watermarks can be updated. Only moving and changing fb is allowed. Changes since v1: - Set page flip to always_unused for trybot. - Copy fence correctly, ignore plane_state->state, should be NULL. - Check crtc_state for !active and modeset, go to slowpath if the case. Changes since v2: - Make error handling work correctly. (Matthew Auld) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
This function is now completely unused, zap it. Signed-off-by:
-
Maarten Lankhorst authored
There's 2 reasons for doing a vblank wait: - To fulfill uabi expectations, but the legacy ioctls are ill-defined enough that we really only need this when we do send out an event. - To make sure we don't tear down mappings before the scanout engine stops accessing it. The later is problematic with the current code since e.g. rotation might need a different mapping than normal orientation. And rotation is a plane property, and not on the fb. Hence we need to remove this optimization. Signed-off-by:
-
Maarten Lankhorst authored
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch crtc_state after commit. Move it to atomic_state->crtcs. Also stop re-using new_crtc_state->enable, we can now simply set a bitmask with crtc_crtc_mask. Changes since v1: - Keep last_vblank_count in __drm_crtc_state. Signed-off-by:
-
Maarten Lankhorst authored
Atomic drivers may set properties like rotation on the same fb, which may require a call to prepare_fb even when framebuffer stays identical. Instead of handling all the special cases in the core, let the driver decide when prepare_fb and cleanup_fb are noops. This is a revert of: commit fcc60b41 Author: Keith Packard <keithp@keithp.com> Date: Sat Jun 4 01:16:22 2016 -0700 drm: Don't prepare or cleanup unchanging frame buffers [v3] The original commit mentions that this prevents waiting in i915 on all previous rendering during cursor updates, but there are better ways to fix this. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 18 Dec, 2016 20 commits
-
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by:
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by:
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by:
-
Peter Meerwald-Stadler authored
Signed-off-by:
Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: trivial@kernel.org Signed-off-by:
-
Peter Meerwald-Stadler authored
Signed-off-by:
-
Daniel Vetter authored
- Modeset state needs mode_config->connection mutex, that covers figuring out the encoder, and reading properties (since in the atomic case those need to look at connector->state). - Don't hold any locks for stuff that's invariant (i.e. possible connectors). - Same for connector lookup and unref, those don't need any locks. - And finally the probe stuff is only protected by mode_config->mutex. While at it updated the kerneldoc for these fields in drm_connector and add docs explaining what's protected by which locks. Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-10-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
If we're unlucky then the registration from a hotplugged connector might race with the final registration step on driver load. And since MST topology discover is asynchronous that's even somewhat likely. v2: Also update the kerneldoc for @registered! v3: Review from Chris: - Improve kerneldoc for late_register/early_unregister callbacks. - Use mutex_destroy. Reviewed-by:
-
Daniel Vetter authored
Only static connectors should be left at this point, and we should be able to clean them out by simply dropping that last reference still around from drm_connector_init. If that leaves anything behind then we have a driver bug. Doing the final cleanup this way also allows us to use drm_connector_iter, removing the very last place where we walk connector_list explicitly in drm core&helpers. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
Mostly nothing special (except making sure that really all error paths and friends call iter_put). v2: Don't forget the raw connector_list walking in drm_helper_move_panel_connectors_to_head. That one unfortunately can't be converted to the iterator helpers, but since it's just some list splicing best to just wrap the entire thing up in one critical section. v3: Bail out after iter_put (Harry). Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
The requirements for connector_list locking are a bit tricky: - We need to be able to jump over zombie conectors (i.e. with refcount == 0, but not yet removed from the list). If instead we require that there's no zombies on the list then the final kref_put must happen under the list protection lock, which means that locking context leaks all over the place. Not pretty - better to deal with zombies and wrap the locking just around the list_del in the destructor. - When we walk the list we must _not_ hold the connector list lock. We walk the connector list at an absolutely massive amounts of places, if all those places can't ever call drm_connector_unreference the code would get unecessarily complicated. - connector_list needs it own lock, again too many places that walk it that we could reuse e.g. mode_config.mutex without resulting in inversions. - Lots of code uses these loops to look-up a connector, i.e. they want to be able to call drm_connector_reference. But on the other hand we want connectors to stay on that list until they're dead (i.e. connector_list can't hold a full reference), which means despite the "can't hold lock for the loop body" rule we need to make sure a connector doesn't suddenly become a zombie. At first Dave&I discussed various horror-show approaches using srcu, but turns out it's fairly easy: - For the loop body we always hold an additional reference to the current connector. That means it can't zombify, and it also means it'll stay on the list, which means we can use it as our iterator to find the next connector. - When we try to find the next connector we only have to jump over zombies. To make sure we don't chase bad pointers that entire loop is protected with the new connect_list_lock spinlock. And because we know that we're starting out with a non-zombie (need to drop our reference for the old connector only after we have our new one), we're guranteed to still be on the connector_list and either find the next non-zombie or complete the iteration. - Only downside is that we need to make sure that the temporary reference for the loop body doesn't leak. iter_get/put() functions + lockdep make sure that's the case. - To avoid a flag day the new iterator macro has an _iter postfix. We can rename it back once all the users of the unsafe version are gone (there's about 100 list walkers for the connector_list). For now this patch only converts all the list walking in the core, leaving helpers and drivers for later patches. The nice thing is that we can now finally remove 2 FIXME comments from the register/unregister functions. v2: - use irqsafe spinlocks, so that we can use this in drm_state_dump too. - nuke drm_modeset_lock_all from drm_connector_init, now entirely cargo-culted nonsense. v3: - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave). - pretty kerneldoc - add EXPORT_SYMBOL, helpers&drivers are supposed to use this. v4: Change lockdep annotations to only check whether we release the iter fake lock again (i.e. make sure that iter_put is called), but not check any locking dependecies itself. That seams to require a recursive read lock in trylock mode. Cc: Dave Airlie <airlied@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: -
Daniel Vetter authored
This is single-threaded setup code, no need for locks. And anyway, all properties need to be set up before the driver is registered anyway, they can't be hot-added. Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
-
Daniel Vetter authored
The list walk will shortcircuit anyway. Cc: Alex Deucher <alexdeucher@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
This is not driver interface stuff. Fixes: 6559c901 ("drm/atomic: add debugfs file to dump out atomic state") Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Spotted while auditing our ioctl table. Also nuke the not-really-kerneldoc comments, we don't document internals and definitely don't want to mislead people with the old dragons. I think with this all the legacy ioctls now have proper drm_legacy_ prefixes. Reviewed-by:
-
Laurent Pinchart authored
Instead of detaching only the bridge directly connected to the encoder, detach all bridges in the chain. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-6-git-send-email-laurent.pinchart+renesas@ideasonboard.com
-
Laurent Pinchart authored
Most drivers that use bridges forgot to detach them at cleanup time. Instead of fixing them one by one, detach the bridge in the core drm_encoder_cleanup() function. Signed-off-by:
-
Laurent Pinchart authored
Instead of linking encoders and bridges in every driver (and getting it wrong half of the time, as many drivers forget to set the drm_bridge encoder pointer), do so in core code. The drm_bridge_attach() function needs the encoder and optional previous bridge to perform that task, update all the callers. Signed-off-by:
-
Laurent Pinchart authored
The drm_crtc_mask() function used in <drm/drm_encoder.h> is a static inline defined in <drm/drm_crtc.h>. If the first header is included in a compilation unit without the second one, the following compilation warning will be issued. In file included from <linux>/drivers/gpu/drm/drm_bridge.c:29:0: <linux>/include/drm/drm_encoder.h:192:95: warning: ‘drm_crtc_mask’ used but never defined static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc); Fix this by including the header defining the function instead of using a forward declaration. Signed-off-by:
-
Laurent Pinchart authored
<drm/drm_crtc.h> used to define most of the in-kernel KMS API. It has now been split into separate files for each object type, but still includes most other KMS headers to avoid breaking driver compilation. As a step towards fixing that problem, remove the inclusion of <drm/drm_encoder.h> from <drm/drm_crtc.h> and include it instead where appropriate. Also remove the forward declarations of the drm_encoder and drm_encoder_helper_funcs structures from <drm/drm_crtc.h> as they're not needed in the header. <drm/drm_encoder.h> now has to include <drm/drm_mode.h> and contain a forward declaration of struct drm_encoder in order to allow including it as the first header in a compilation unit. Signed-off-by:
-
- 16 Dec, 2016 4 commits
-
-
Chris Wilson authored
If we remember that node_list is a circular list containing the fake head_node, we can use a simple list_next_entry() and skip the NULL check for the allocated check against the head_node. Signed-off-by:
-
Chris Wilson authored
Mark up the pointers as constant through the API where appropriate. Signed-off-by:
-
Chris Wilson authored
A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe() for walking the list of nodes safe against removal. Note from Joonas: "Most of the diff is about __drm_mm_nodes(mm), which could be split into own patch and keep the R-b's." But I don't feel like insisting on the resend. Signed-off-by:
-
Jason A. Donenfeld authored
On most platforms, there exists this ifdef: #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) This makes this patch functionally useless. However, on PPC, there is actually an explicit definition of atomic_inc_not_zero with its own assembly that is slightly more optimized than atomic_add_unless. So, this patch changes kref to use atomic_inc_not_zero instead, for PPC and any future platforms that might provide an explicit implementation. This also puts this usage of kref more in line with a verbatim reading of the examples in Paul McKenney's paper [1] in the section titled "2.4 Atomic Counting With Check and Release Memory Barrier", which uses atomic_inc_not_zero. [1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2167.pdfSigned-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
