- 29 Dec, 2016 1 commit
-
-
Daniel Vetter authored
Our style guide should only be the delta compared to the overall one. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483008275-29383-1-git-send-email-daniel.vetter@ffwll.ch
-
- 28 Dec, 2016 13 commits
-
-
Chris Wilson authored
A couple of parameters slipped through the kerneldoc net. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161228105120.14500-1-chris@chris-wilson.co.uk
-
Daniel Vetter authored
Drivers need to take care. Motivated by a discussion between Mark and Rob on dri-devel. Cc: Mark yao <mark.yao@rock-chips.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Chris Wilson authored
Remove a superfluous helper as drm_mm_insert_node is equivalent to insert_node_in_range with a range of [0, U64_MAX]. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction. Signed-off-by:
-
Chris Wilson authored
Insulate users from changes to the internal hole tracking within struct drm_mm_node by using an accessor for hole_follows. Signed-off-by:
-
Chris Wilson authored
Using mm->color_adjust makes the eviction scanner much tricker since we don't know the actual neighbours of the target hole until after it is created (after scanning is complete). To work out whether we need to evict the neighbours because they impact upon the hole, we have to then check the hole afterwards - requiring an extra step in the user of the eviction scanner when they apply color_adjust. v2: Massage kerneldoc. Signed-off-by:
-
Chris Wilson authored
Since we mandate a strict reverse-order of drm_mm_scan_remove_block() after drm_mm_scan_add_block() we can further simplify the list manipulations when generating the temporary scan-hole. v2: Highlight the games being played with the lists to track the scan holes without allocation. Signed-off-by:
-
Chris Wilson authored
For power-of-two alignments, we can avoid the 64bit divide and do a simple bitwise add instead. v2: s/alignment_mask/remainder_mask/ Signed-off-by:
-
Chris Wilson authored
Compute the minimal required hole during scan and only evict those nodes that overlap. This enables us to reduce the number of nodes we need to evict to the bare minimum. Signed-off-by:
-
Chris Wilson authored
The range restriction should be applied after the color adjustment, or else we may inadvertently apply the color adjustment to the restricted hole (and not against its neighbours). Signed-off-by:
-
Chris Wilson authored
Doing the check is trivial (low cost in comparison to overall eviction) and helps simplify the code. Signed-off-by:
-
Chris Wilson authored
Acknowledging that we were building up the hole was more useful to me when reading the code, than knowing the relationship between this node and the previous node. Signed-off-by:
-
Daniel Vetter authored
Kbuild really doesn't like non-recursive Makefiles, but they do work as long as you build without O= Reported-by:
-
- 27 Dec, 2016 26 commits
-
-
Chris Wilson authored
The scan state occupies a large proportion of the struct drm_mm and is rarely used and only contains temporary state. That makes it suitable to moving to its struct and onto the stack of the callers. Signed-off-by:
-
Chris Wilson authored
A simple assert to ensure that we don't overflow start + size when initialising the drm_mm, or its scanner. In future, we may want to switch to tracking the value of ranges (rather than size) so that we can cover the full u64, for example like resource tracking. Signed-off-by:
-
Chris Wilson authored
Since commit ea7b1dd4 ("drm: mm: track free areas implicitly"), to test whether there are any nodes allocated within the range manager, we merely have to ask whether the node_list is empty. Signed-off-by:
-
Chris Wilson authored
Protect ourselves from a caller passing in node.start + node.size that will overflow and trick us into reserving that node. Signed-off-by:
-
Chris Wilson authored
The nodes must be removed in the *reverse* order. This is correct in the overview, but backwards in the function description. Whilst here add Intel's copyright statement and tweak some formatting. Signed-off-by:
-
Chris Wilson authored
In places (e.g. i915.ko), the alignment is exported to userspace as u64 and there now exists hardware for which we can indeed utilize a u64 alignment. As such, we need to keep 64bit integers throughout when handling alignment. Testcase: igt/drm_mm/align64 Testcase: igt/gem_exec_alignment Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chris Wilson authored
Check that after applying the driver's color adjustment, restricted eviction scanning finds a suitable hole. Signed-off-by:
-
Chris Wilson authored
Check that after applying the driver's color adjustment, eviction scanning finds a suitable hole. Signed-off-by:
-
Chris Wilson authored
Check that after applying the driver's color adjustment, fitting of the node and its alignment are still correct. v2: s/no_color_touching/separate_adjacent_colors/ Signed-off-by:
-
Chris Wilson authored
Check that if we request top-down allocation from drm_mm_insert_node() we receive the next available hole from the top. v2: Flip sign on conditional assert. Signed-off-by:
-
Chris Wilson authored
Check that we add arbitrary blocks to a restrited eviction scanner in order to find the first minimal hole that matches our request. Signed-off-by:
-
Chris Wilson authored
Check that we add arbitrary blocks to the eviction scanner in order to find the first minimal hole that matches our request. v2: Refactor out some common eviction code for later Signed-off-by:
-
Chris Wilson authored
Check that we can request alignment to any power-of-two or prime using a plain drm_mm_node_insert(), and also handle a reasonable selection of primes. v2: Exercise all allocation flags Signed-off-by:
-
Chris Wilson authored
Exercise drm_mm_insert_node_in_range(), check that we only allocate from the specified range. v2: Use all allocation flags v3: Don't pass in invalid ranges - these will be asserted later. Signed-off-by:
-
Chris Wilson authored
Reuse drm_mm_insert_node() with a temporary node to exercise drm_mm_replace_node(). We use the previous test in order to exercise the various lists following replacement. v2: Check that we copy across the important (user) details of the node. The internal details (such as lists and hole tracking) we hope to detect errors by exercise. Signed-off-by:
-
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 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:
-
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:
-
