-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29439 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/1aa015d6/attachment-0001.gz>
On 16.12.2016 21:00, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote:
>> mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin
>> case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the
>> wait_lock.
>
> mutex_optimisti
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 27868 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/41ebf35a/attachment-0001.gz>
On Fri, Dec 16 2016, Matthew Wilcox wrote:
> From: Andrew Morton [mailto:akpm at linux-foundation.org]
>> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes
>> wrote:
>> > TL;DR: these patches save 250 KB of memory, with more low-hanging
>> > fruit ready to pick.
>> >
>> > While browsing throug
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/92dbdf81/attachment.sig>
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> On Fri, Dec 16 2016, Matthew Wilcox wrote:
> > Thanks for your work on this; you've really put some effort into
> > proving your work has value. My motivation was purely aesthetic, but
> > you've got some genuine savings here (admittedly
On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote:
> mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin
> case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the
> wait_lock.
mutex_optimistic_spin() is a no-op when !CONFIG_MUTEX_SPIN_ON_OWNE
On Fri, Dec 16, 2016 at 07:25:16PM +, Chris Wilson wrote:
> +static void __exit primes_exit(void)
> +{
> + const struct primes *p;
> +
> + mutex_lock(&lock);
> + p = rcu_dereference_protected(primes, lockdep_is_held(&lock));
> + if (p != &small_primes) {
> + kfree_rc
Oops. This is not a patch for alsa-lib, but for Linux kernel.
I'm sorry to confuse you...
On Dec 16 2016 18:26, Takashi Sakamoto wrote:
> This is a fix for Linux 4.10-rc1.
>
> In C language specification, a bit-field is interpreted as a signed or
> unsigned integer type consisting of the specified
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
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: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 166 ---
include/drm/drm_mm.h | 90 +
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16 ++--
1 f
Insulate users from changed to the internal hole tracking within
struct drm_mm_node by using an accessor for hole_follows.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 12 ++--
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
d
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 a
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
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertion
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 60 ++
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
i
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: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 inse
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c
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
Revie
Since commit ea7b1dd44867 ("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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 19 +-
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 34 +++
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-of
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
"Enable debug, become developer." - Joonas Lahtinen
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 116 +
Check that after applying the driver's color adjustment, eviction
scanning find a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 156 +++
2 f
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 119 +
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c |
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
d
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h |
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
v2: Use all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 264 +
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)
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/d
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1
Simple test to just exercise calling the debug dumper on the drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 35
2 files changed, 36 insertions(+
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 114 +++
2 files changed, 115 insertions(
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
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
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
Signed-off-by: C
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 45 +
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 ad579002c8ec ("drm: Add
drm_mm_for_each_node_safe()") before being applied, but my ti
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
v2: Pull together the 3 identical implements (ahem, a coup
With a lot of polish applied, Joonas has reviewed the series - all but
for [04/38] "lib: Add a simple prime number generator"
[lib/prime_numbers.c]. Anyone feel like poking around at a bit of number
theory?
Other than it would appear to be ready for Daniel to sort out the merge
between drm-misc/i9
> -Original Message-
> From: Liviu Dudau [mailto:liviu at dudau.co.uk]
> Sent: Friday, December 16, 2016 2:11 PM
> To: Daenzer, Michel; Deucher, Alexander
> Cc: Koenig, Christian; David Airlie; dri-devel at lists.freedesktop.org; amd-
> gfx at lists.freedesktop.org; Liviu Dudau
> Subject: [
From: Andrew Morton [mailto:a...@linux-foundation.org]
> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes
> wrote:
> > TL;DR: these patches save 250 KB of memory, with more low-hanging
> > fruit ready to pick.
> >
> > While browsing through the lib/idr.c code, I noticed that the code at
> > the
On 16.12.2016 18:20, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
@@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
spin_unlock_mutex(&lock->wait_lock, flags);
sche
On 16.12.2016 18:15, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
>> The concern about picking up a handoff that we didn't request is real,
>> though it cannot happen in the first iteration. Perhaps this __mutex_trylock
>> can be moved to the end of the l
Commit 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register when
necessary") did not cleanup correctly the old code for DCE v6 and v8.
As a consequence, cursor updates stopped working for my Radeon R9 1002:67b0
dual-monitor setup.
Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE
On 16/12/16 01:29 AM, Dmitriy Kryuk wrote:
> I have a laptop with a Radeon X200M card in it. I use Radeon DRM driver
> for graphics, and it makes the system hang with display off when trying
> to suspend (either to disk or to RAM). Using /sys/power/pm_test
> interface revealed that it freezes when
This is a fix for Linux 4.10-rc1.
In C language specification, a bit-field is interpreted as a signed or
unsigned integer type consisting of the specified number of bits.
In GCC manual, the range of a signed bit field of N bits is from
-(2^N) / 2 to ((2^N) / 2) - 1
https://www.gnu.org/software/gn
On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
> >>@@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state,
> >>unsigned int subclass,
> >>spin_unlock_mutex(&lock->wait_lock, flags);
> >>schedule_preempt_disabled();
> >>
> >>- if
On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
> The concern about picking up a handoff that we didn't request is real,
> though it cannot happen in the first iteration. Perhaps this __mutex_trylock
> can be moved to the end of the loop? See below...
> >>@@ -728,7 +800,7 @@ __mu
Hey Laurent,
On 13 December 2016 at 19:34, Laurent Pinchart
wrote:
> From: Laurent Pinchart
>
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the device nodes. Its usage is
> deprecated, inline it in the probe function and call drm_
ave slipped in there.
> >
> > Not sure how this could be fixed, so reporting the issue for now in case
> > it is not known yet.
I can confirm Alex' findings, though the symptoms seem to be slightly
different, which may be related to me testing on next-20161216 rather
than ne
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
---
drivers/gpu/drm/nouveau
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
---
drivers/gpu/drm/vmwgfx/
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
---
drivers/gpu/drm/amd/amd
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
---
drivers/gpu/drm/ttm/ttm
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
---
drivers/gpu/drm/virtio/
On Fri, 16 Dec 2016, Daniel Vetter wrote:
> On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
>> The two remaining patches from [1], rebased.
>>
>> BR,
>> Jani.
>>
>>
>> [1]
>> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare
>> at intel.com
>
> Just for
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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: Chris Wilson
I'm not purely against, so if you think
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, restricted
> eviction scanning find a suitable hole.
>
> Signed-off-by: Chris Wilson
Â
> +static int igt_color_evict_range(void *ignored)
> +{
> + for (mode = evict_modes; mo
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, eviction
> scanning find a suitable hole.
>
> Signed-off-by: Chris Wilson
> +static int evict_color(struct drm_mm *mm,
> + Â Â Â Â Â Â Â struct evict_node *nodes,
> +
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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 becau
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node_in_range(), check that we only allocate from
> the specified range.
>
> v2: Use all allocation flags
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source
On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> 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 Wi
Hi Tomi,
On Friday 16 Dec 2016 14:44:26 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > The drm driver .load() operation is prone to race conditions as it
> > initializes the driver after registering the device nodes. Its usage is
> > deprecated, inline it in the probe funct
On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
> Hi Peter and Chris,
>
> (trying to combine the handoff discussion here)
>
> On 06.12.2016 17:55, Peter Zijlstra wrote:
> >On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
> >>@@ -693,8 +748,12 @@ __mutex_lock_commo
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range effic
On pe, 2016-12-16 at 13:31 +, Chris Wilson wrote:
> On Fri, Dec 16, 2016 at 03:04:31PM +0200, Joonas Lahtinen wrote:
> >
> > On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > >
> > > Insulate users from changed to the internal hole tracking within
> >
> > changes ^
>
OR on next-20161215]
>> [cannot apply to v4.9]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all-helpers-to-drm_c
On 01.12.2016 16:59, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> debug_mutex_lock_common(lock, &waiter);
>> debug_mutex_add_waiter(lock, &w
Hi Peter and Chris,
(trying to combine the handoff discussion here)
On 06.12.2016 17:55, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>>
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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 exa
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> Insulate users from changed to the internal hole tracking within
changes ^
> struct drm_mm_node by using an accessor for hole_follows.
>
> Signed-off-by: Chris Wilson
The function name could be soemthing beginning with drm
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technolog
On Fri, Dec 16, 2016 at 04:02:12PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > 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
On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> 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
Reviewed-by: Joonas L
On Fri, Dec 16, 2016 at 04:38:12PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > Check that after applying the driver's color adjustment, eviction
> > scanning find a suitable hole.
> >
> > Signed-off-by: Chris Wilson
>
>
>
> > +static int evict_colo
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> The two remaining patches from [1], rebased.
>
> BR,
> Jani.
>
>
> [1]
> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare
> at intel.com
Just for the record, I think the only thing missing here is the Xo
On Fri, Dec 16, 2016 at 07:46:42AM +, Chris Wilson wrote:
> Mark up the pointers as constant through the API where appropriate.
>
> Signed-off-by: Chris Wilson
Ok merged this and the patch right before, then Chris told me on irc that
I need to stop because he's mixing a v3 of this series.
-D
_free_priv:
> + destroy_workqueue(priv->wq);
> + kfree(priv);
> +err_disconnect_dssdevs:
> + omap_disconnect_dssdevs();
> +err_crtc_uninit:
> + omap_crtc_pre_uninit();
> + return ret;
> }
>
> -static int pdev_remove(struct platform_device *device)
> +static int pdev_remove(struct platform_device *pdev)
> {
> + struct drm_device *ddev = platform_get_drvdata(pdev);
> + struct omap_drm_private *priv = ddev->dev_private;
> +
> DBG("");
>
> - drm_put_dev(platform_get_drvdata(device));
> + drm_dev_unregister(ddev);
> +
> + drm_kms_helper_poll_fini(ddev);
> +
> + if (priv->fbdev)
> + omap_fbdev_free(ddev);
> +
> + drm_mode_config_cleanup(ddev);
> +
> + omap_drm_irq_uninstall(ddev);
> + omap_gem_deinit(ddev);
> +
> + drm_dev_unref(ddev);
> +
> + destroy_workqueue(priv->wq);
> + kfree(priv);
>
> omap_disconnect_dssdevs();
> omap_crtc_pre_uninit();
>
The old code calls drm_vblank_cleanup(), and the probe's error handling
calls that, but not remove. Is that correct?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/7cdff755/attachment.sig>
On 06.12.2016 16:36, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> +static inline int __sched
>> +__ww_mutex_add_waiter(struct mutex_waiter *waiter,
>> + struct mutex *lock,
>> + struct ww_acquire_ctx *ww_ctx)
>> +{
>>
On Fri, Dec 16, 2016 at 11:06:25AM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:46 +, Chris Wilson wrote:
> > A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
> > for walking the list of nodes safe against removal.
> >
>
> Most of the diff is about __drm_mm
guess the
current implementation is better.
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/16a89e89/attachment-0001.sig>
On Fri, Dec 16, 2016 at 02:29:00PM +0100, Daniel Vetter wrote:
> On Fri, Dec 16, 2016 at 02:05:48PM +0530, Archit Taneja wrote:
> > Hi,
> >
> > On 12/14/2016 03:29 PM, Laurent Pinchart wrote:
> > > Instead of linking encoders and bridges in every driver (and getting it
> > > wrong half of the time
On Fri, Dec 16, 2016 at 02:05:48PM +0530, Archit Taneja wrote:
> Hi,
>
> On 12/14/2016 03:29 PM, Laurent Pinchart wrote:
> > 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
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 ad579002c8ec ("drm: Add
drm_mm_for_each_node_safe()") before being applied, but my ti
Signed-off-by: Peter Meerwald-Stadler
Cc: Xinliang Liu
Cc: Xinwei Kong
Cc: trivial at kernel.org
---
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-a
On Fri, Dec 16, 2016 at 04:14:30PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:47 +, Chris Wilson wrote:
> > 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
gs);
> - }
> + list_for_each_entry_safe(wait, n, &priv->wait_list, node) {
> + if (wait->irqmask & irqstatus)
> + omap_irq_wait_irq(wait);
> }
> spin_unlock_irqrestore(&list_lock, flags);
>
> @@ -275,7 +251,7 @@ int omap_drm_irq_install(struct drm_device *dev)
> unsigned int i;
> int ret;
>
> - INIT_LIST_HEAD(&priv->irq_list);
> + INIT_LIST_HEAD(&priv->wait_list);
>
> priv->irq_mask = DISPC_IRQ_OCP_ERR;
>
>
With the function rename change:
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161216/b8d02d52/attachment.sig>
Signed-off-by: Peter Meerwald-Stadler
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: trivial at kernel.org
---
include/drm/drm_connector.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ac9d7d8..819fcae 100644
--- a/
On 06.12.2016 16:25, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>
>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> struct mutex_waiter waiter;
>> unsigned long flags;
>> bool first
Hi,
On 12/14/2016 03:29 PM, Laurent Pinchart wrote:
> 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 opti
1 - 100 of 211 matches
Mail list logo
