> == Series Details ==
>
> Series: drm/i915: VLV/CHV two-stage watermarks
> URL : https://patchwork.freedesktop.org/series/16712/
> State : warning
>
> == Summary ==
>
> Series 16712v1 drm/i915: VLV/CHV two-stage watermarks
> https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/1/m
On 12.12.2016 22:50, Lyude wrote:
> Many GPUs have more then 3 pipes available, so hard limiting this to
> I915_MAX_PIPES prevents us from using anything that relies on
> igt_display_init() on non-intel systems (since we end up writing out of
> bounds and seg faulting). Fix this by dynamically al
If (!shared_host) simply return 0, this avoids delaying the probe if
iosf_mbi_available() returns false when an i2c bus is not using the
punit semaphore.
Also move the if (!iosf_mbi_available()) check to above the
dev_info, so that we do not repeat the dev_info on every probe
until iosf_mbi_availa
The cherrytrail punit has the pmic i2c bus access semaphore at a
different register address.
Signed-off-by: Hans de Goede
Reviewed-by: Takashi Iwai
Tested-by: Takashi Iwai
Reviewed-by: Andy Shevchenko
---
Changes in v2:
-Adjust for accessor_flags -> flags rename
-Add flags field to struct dw_p
On my cherrytrail tablet with axp288 pmic, just doing a bunch of repeated
reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet in
1 - 3 runs guaranteed.
This seems to be causes by the cpu trying to enter C6 or C7 while we hold
the punit bus semaphore, at which point everything ju
Rename accessor_flags to flags, so that we can use the field for
other flags too. This is a preparation patch for adding cherrytrail
support to the punit semaphore code.
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
Tested-by: Takashi Iwai
---
drivers/i2c/b
Pass dw_i2c_dev into the helper functions, this is a preparation patch
for the punit semaphore fixes done in the other patches in this set.
Signed-off-by: Hans de Goede
Reviewed-by: Takashi Iwai
Tested-by: Takashi Iwai
Reviewed-by: Andy Shevchenko
Acked-by: Jarkko Nikula
---
drivers/i2c/buss
== Series Details ==
Series: drm/i915: VLV/CHV two-stage watermarks
URL : https://patchwork.freedesktop.org/series/16712/
State : warning
== Summary ==
Series 16712v1 drm/i915: VLV/CHV two-stage watermarks
https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/1/mbox/
Test drv_modul
On Mon, 2016-12-12 at 16:21 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV apparently gets upset if the PPS for a pipe currently driving an
> external DP port gets used for VDD stuff on another eDP port. The DP
> port falls over and fails to retrain when this happens, l
Many GPUs have more then 3 pipes available, so hard limiting this to
I915_MAX_PIPES prevents us from using anything that relies on
igt_display_init() on non-intel systems (since we end up writing out of
bounds and seg faulting). Fix this by dynamically allocating
igt_display->pipes using the number
From: Ville Syrjälä
Since the watermark registers arent double buffered on VLV/CHV, we'll
need to play around with intermediate watermarks same was as we do on
ILK-BDW.
The watermark registers on VLV/CHV contain inverted values, so to find
the intermediate watermark value we just take the minimu
From: Ville Syrjälä
Add a test to try out all the different plane enable/disable
order permutations.
Signed-off-by: Ville Syrjälä
---
tests/Makefile.sources| 1 +
tests/kms_plane_blinker.c | 529 ++
2 files changed, 530 insertions(+)
create mo
From: Ville Syrjälä
On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
lead to an underrun. This only happens when sprite0 FIFO size is zero
prior to enabling it. Hence an effective workaround is to always
allocate at least one cacheline for sprite0 when sprite1 is active.
I'v
From: Ville Syrjälä
Clear out the watermark for all disabled planes to 0. This is required
to avoid falsely thinking that the inherited watermarks are bogus in
case the watermark is actually higher than the FIFO size.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 17 +
From: Ville Syrjälä
Move the vlv/chv FIFO size tracking into the crtc_state. As with the wms
for now this just acts as temporary storage.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 11 +--
drivers/gpu/drm/i915/intel_pm.c | 26 +++---
2 file
From: Ville Syrjälä
Remove crtc->wm.cxsr_allowed and just rely on crtc_state->disable_cxsr
instead. This was used only by vlv/chv to indicate whether to enable
cxsr in the wm computation. That doesn't really work anymore, and as far
as the optimal watermarks go we'll just consider the number of p
From: Ville Syrjälä
Let's compute the watermarks first and the FIFO size second. This way we
can make sure the FIFO split is the most accommodating to the watermarks.
Previously we could have potentially computed a FIFO split that couldn't
accommodate the PM2 watermarks simply due to a bad split
From: Ville Syrjälä
Check whether anything relevant has actually change when we compute new
watermarks for each plane in the state. If the watermarks for no
primary/sprite planes changed we don't have to recompute the FIFO split
or reprogram the DSBARB registers. And even the cursor watermarks di
From: Ville Syrjälä
Now that vlv/chv have more proper wm programming support, let's reduce
the the update_wm_{pre,post} flags to only cover the pre-ilk platforms.
When we finally convert those as well we can drop these flags entirely.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel
From: Ville Syrjälä
We now compute the watermarks correctly, so just return an error if we
can't support the configuration.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/
From: Ville Syrjälä
Start computing the vlv/chv watermarks the atomic way, from the
.compute_pipe_wm() hook. We'll recompute the actual watermarks
for only planes that are part of the state, the other planes will
keep their watermark from the last time it was computed.
And the actual watermark p
From: Ville Syrjälä
OK, so finally managed to beat the HW mostly into submission
and got the two stage watermark programming to work on VLV/CHV.
So the hardware has the following features:
* single buffered watermark registers, hence we need the two-stage programming
* inverted watermark registe
From: Ville Syrjälä
Relocate the vlv/chv wm state to live under intel_crtc_state. Note
that for now this just behaves as a temporary storage. But it'll be
easier to conver the thing over to properly pre-computing the state
when it's already in the right place.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Track the plane fifo sizes under intel_crtc instead of under each
intel_plane. Avoids looping over the planes in a bunch of places,
and later we'll move this tracking into the crtc state properly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 7 ++-
From: Ville Syrjälä
In an effort to make the vlv/chv wm code look and behave more like the
ilk+ code, let's move the current active wms next to the
corresponding ilk wms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_pm.c | 10 +
From: Ville Syrjälä
In a lot of place we wish to know which planes on the crtc are actually
visible, or how many of them there are. Let's start tracking that in a
bitmask in the crtc state.
We already track enabled planes (ie. ones with an fb and crtc specified by
the user) but that's not quite
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Chris Wilson
>Sent: Monday, December 12, 2016 7:17 AM
>To: Hiler, Arkadiusz
>Cc: intel-gfx@lists.freedesktop.org; Michal Wajdeczko
>
>Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_para
Hi all,
Executive decision required below:
On 08/12/2016 23:02, anushasr wrote:
[snip]
+
+/**
+ * DOC: HuC Firmware
+ *
+ * Motivation:
+ * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
+ * Efficiency Video Coding) operations. Userspace can use the firmware
+ * capab
== Series Details ==
Series: drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV
URL : https://patchwork.freedesktop.org/series/16698/
State : failure
== Summary ==
Series 16698v1 drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV
https://patchwork.freedesktop.org/api/
On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta wrote:
> On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
>> From: Swati Dhingra
>>
>> Currently, we don't have a stable ABI which can be used for the purpose of
>> providing output debug/loggging/crc and other such data from DRM.
>> The ABI i
On Mon, Dec 12, 2016 at 03:17:16PM +, Chris Wilson wrote:
> On Mon, Dec 12, 2016 at 03:52:05PM +0100, Arkadiusz Hiler wrote:
> > On Mon, Dec 12, 2016 at 02:21:41PM +, Chris Wilson wrote:
> > > As for userspace simply asking where huc is enabled, we already have
> > > that in the ABI via the
On Thu, 08 Dec 2016, Jani Nikula wrote:
> From: Vidya Srinivas
>
> Currently the backlight controller is taken as 0. It needs to derive
> value from the VBT. Adding the necessary changes.
>
> v2 by Jani:
> - drop obsolete comments, drop redundant initialization (Bob)
> - merge debug logging int
On Mon, Dec 12, 2016 at 03:52:05PM +0100, Arkadiusz Hiler wrote:
> On Mon, Dec 12, 2016 at 02:21:41PM +, Chris Wilson wrote:
> > As for userspace simply asking where huc is enabled, we already have
> > that in the ABI via the module parameter, so you need to justify why
> > this is preferred (i
On Fri, 09 Dec 2016, Erik Jacobson wrote:
> I hope this email finds you well. I apologize as I'm not a graphics kernel
> developer. I've tried to search for answers and indeed tried several things
> before posting this. That doesn't mean I didn't miss something so I'm
> happy to be pointed to what
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> 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 Lah
On Mon, Dec 12, 2016 at 02:21:41PM +, Chris Wilson wrote:
> On Mon, Dec 12, 2016 at 03:13:17PM +0100, Arkadiusz Hiler wrote:
> > On Fri, Dec 09, 2016 at 01:59:45PM +0100, Michal Wajdeczko wrote:
> > > On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> > > > From: Peter Antoine
> > > >
On Mon, Dec 12, 2016 at 03:13:17PM +0100, Arkadiusz Hiler wrote:
> On Fri, Dec 09, 2016 at 01:59:45PM +0100, Michal Wajdeczko wrote:
> > On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> > > From: Peter Antoine
> > >
> > > This patch will allow for getparams to return the status of the
From: Ville Syrjälä
VLV apparently gets upset if the PPS for a pipe currently driving an
external DP port gets used for VDD stuff on another eDP port. The DP
port falls over and fails to retrain when this happens, leaving the
user staring at a black screen.
Let's fix it by also tracking which pi
On Fri, Dec 09, 2016 at 01:59:45PM +0100, Michal Wajdeczko wrote:
> On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> > From: Peter Antoine
> >
> > This patch will allow for getparams to return the status of the HuC.
> > As the HuC has to be validated by the GuC this patch uses the vali
== Series Details ==
Series: drm/i915/debugfs: Move out pipe CRC code
URL : https://patchwork.freedesktop.org/series/16690/
State : success
== Summary ==
Series 16690v1 drm/i915/debugfs: Move out pipe CRC code
https://patchwork.freedesktop.org/api/1.0/series/16690/revisions/1/mbox/
fi-bdw-55
On 10 December 2016 at 21:52, Daniel Vetter wrote:
> No one looks at the major/minor versions except the unique/busid
> stuff. If we protect that with the master_mutex (since it also affects
> the unique of each master, oh well) we can mark these two IOCTL with
> DRM_UNLOCKED.
>
> While doing this
Am 12.12.2016 um 12:53 schrieb Chris Wilson:
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/ali
2016-12-09 Daniel Vetter :
> This was missed when adding a dma_fence_get call. While at it also
> remove the kerneldoc for the static inline helper - no point
> documenting internals down to every detail.
>
> Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when
> creating sync_f
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
v9: Have intel_display_cr
Hi Daniel,
2016-12-09 Daniel Vetter :
> Just prep work to polish and consolidate all the dma-buf related
> documenation.
>
> Unfortunately I didn't discover a way to both integrate this new file
> into the overall toc while keeping it at the current place. Work
> around that by moving it into th
== Series Details ==
Series: series starting with [01/34] drm/i915: Use the MRU stack search after
evicting
URL : https://patchwork.freedesktop.org/series/16688/
State : success
== Summary ==
Series 16688v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16688/rev
On Mon, Dec 12, 2016 at 12:48:45PM +0100, Michał Winiarski wrote:
> Since we've introduced ppgtt shrinking, most of the vmas should already
> be unbounded when ppgtt is being released.
> This allows us to take care of leftovers and assert that all vmas are
> unbounded, removing the iteration during
For power-of-two alignments, we can avoid the 64bit divide and do a
simple bitwise add instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers
On 09/12/2016 15:05, Chris Wilson wrote:
Some object retain an extra pin whilst they are active (e.g. contexts).
This excludes them from being considered for eviction unless we idle the
GPU. If before we look at the active list, before we retire we can
hopefully remove a few excess pins and redu
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
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 89
2 files
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
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
On Fri, Dec 09, 2016 at 09:42:06PM +, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com]
> >Sent: Friday, December 9, 2016 3:56 AM
> >To: Srivatsa, Anusha
> >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter
> >A
On Mon, Dec 12, 2016 at 12:44:10PM +0100, Michał Winiarski wrote:
> It's not operating on ppgtt, and it also makes things consistent with
> analogous ppgtt_cleanup_3lvl function.
Nah, if you've looked at my series accomplishing the same thing and
more, you'll see that we do want to pass struct i91
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
---
drivers/gpu/drm/drm_mm.c| 60 +++--
drivers/gpu/d
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 22 +-
include/drm/drm_mm.h
Mark up the pointers as constant through the API where appropriate.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 20 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 2 +-
include/drm/drm_mm.h
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
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
dif
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
---
drivers/gpu/drm/drm_mm.c | 19 +--
include/drm/drm_mm.h | 14 +-
2 files changed, 14 insertions(+), 19 del
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 252 +++
2 fil
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 2 +
drivers/gpu/drm/selftests/test-drm_mm.c | 83
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm
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
---
drivers/gpu/drm/drm_mm.c | 45 +++--
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 209 +++
2 fil
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 205 +++
2 files changed, 206 i
Check that after applying the driver's color adjustment, eviction
scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 198 +++
2 files changed, 199 insertions(+
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
---
drivers/gpu/drm/drm_mm.c| 128 ++
Hi,
On 05-12-16 14:23, Hans de Goede wrote:
Hi,
On 05-12-16 11:59, Thierry Reding wrote:
On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote:
Hi,
On 05-12-16 08:46, Thierry Reding wrote:
On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
The primary consumer of the lp
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
1 file changed, 2 insertion
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 183 +++
2 files changed,
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c
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
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
include/drm/drm_mm.h
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
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file changed, 9 insertions(+), 6 d
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
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 597648c7a645..5
A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
for walking the list of nodes safe against removal.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 19 ---
2 files changed, 20 insertions(+), 8 deletions(
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing struct drm_mm alignment computations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/lib/drm_pr
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 132
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i91
Check that if we request top-down allocation with a particular alignment
from drm_mm_insert_node() that the start of the node matches our
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 92 ++
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 188 +++
2 files changed, 189 insertions(+)
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_mm.c | 104
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
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 189 ++
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
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 97
2 files cha
For testing, we want a reproducible PRNG, a plain linear congruent
generator is suitable for our very limited selftests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig| 5 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/lib/drm_rand.c | 51 +
For a long time, we've known DRM_MM_SEARCH_HIGH/CREATE_TOP to be slow and
broken (both not returning the right hole nor the right alignment). This
series ends by fixing that but takes a quick detour through adding a set
of testcases to catch the broken behaviour and hopefully keep the working
set,
On Fri, Dec 09, 2016 at 11:56:20PM +, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com]
> >Sent: Friday, December 9, 2016 4:18 AM
> >To: Srivatsa, Anusha
> >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter
> >A
All of the page tracking structures contain a bitmap holding currently
used entries.
It's redundant, since we can just inspect the pointer.
The only actual place where we're taking advantage of bitmaps is during
ppgtt cleanup - since we're able to reduce the number of iterations.
Still, we can impr
Since we've introduced ppgtt shrinking, most of the vmas should already
be unbounded when ppgtt is being released.
This allows us to take care of leftovers and assert that all vmas are
unbounded, removing the iteration during ppgtt release.
Cc: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Joonas Lahtine
There's no fast way to provide the info on which entries are present for
this tracepoint once bitmaps dissapear. Let's just pass the counter
instead.
Cc: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
drivers/gpu
Temp bitmaps were being used to revert the page tracking structures to
original state after error arises in the middle of the process.
We could just use the range though, and indeed, right now temp bitmaps
are not used for anything useful. We can simply remove them without any
functional changes.
We can just operate on ranges and make use of cleanup functions
introduced with ppgtt shrinking.
Cc: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 82 ++-
In case of error during allocation we should free the entries allocated
during the current "transaction".
We can't simply reuse the clear_range, since for gen6 we're not
shrinking ppgtt. We can extract unwind to a function though, and use
range rather than bitmaps.
Cc: Arkadiusz Hiler
Cc: Chris W
It seems that bitmaps are redundant and we can remove them without causing much
trouble.
Let's try to do that!
There should be no functional changes, but it may be helpful if anyone can point
out tests/benchmarks that could show any difference in performance.
Michał Winiarski (8):
drm/i915/gtt:
Small rename to make things consistent with naming for gen6.
Let's also remove redundant start_in/length_in vars in gen6 path.
Cc: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.
It's not operating on ppgtt, and it also makes things consistent with
analogous ppgtt_cleanup_3lvl function.
Cc: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michel Thierry
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++
On Mon, 12 Dec 2016, Daniel Vetter wrote:
> On Mon, Dec 12, 2016 at 10:14:29AM +0200, Jani Nikula wrote:
>> On Fri, 09 Dec 2016, Daniel Vetter wrote:
>> > On Thu, Dec 08, 2016 at 11:53:07PM +0200, Jani Nikula wrote:
>> >> On Thu, 08 Dec 2016, Daniel Vetter wrote:
>> >> > It's been years since dr
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 chang
Op 08-12-16 om 16:43 schreef Daniel Vetter:
> On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
>> The current api doesn't take into account that whenever properties like
>> rotation or z-pos change we have to wait for vblank. To make sure
>> that we wait correctly, err on the side
On Mon, 12 Dec 2016, Daniel Vetter wrote:
> On Fri, Dec 09, 2016 at 12:41:08PM +, Robert Bragg wrote:
>> As a bit of an asside; last year for another project of mine I once
>> wrote an experimental tool for extracting gtk-doc comments from code
>> to using the python clang bindings:
>> https:/
1 - 100 of 110 matches
Mail list logo
