Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: VLV/CHV two-stage watermarks

> == 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 >

Re: [Intel-gfx] [PATCH i-g-t] igt_kms: Dynamically allocate igt_display->pipes

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

[Intel-gfx] [PATCH v4 3/5] i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts

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

[Intel-gfx] [PATCH v4 5/5] i2c: designware-baytrail: Add support for cherrytrail

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 ---

[Intel-gfx] [PATCH v4 4/5] i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore

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

[Intel-gfx] [PATCH v4 1/5] i2c: designware: Rename accessor_flags to flags

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:

[Intel-gfx] [PATCH v4 2/5] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: VLV/CHV two-stage watermarks

== 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

Re: [Intel-gfx] [PATCH] drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV

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

[Intel-gfx] [PATCH i-g-t] igt_kms: Dynamically allocate igt_display->pipes

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

[Intel-gfx] [PATCH 09/14] drm/i915: Compute proper intermediate wms for vlv/cvh

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

[Intel-gfx] [PATCH i-g-t] tests: Add kms_plane_blinker

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

[Intel-gfx] [PATCH 13/14] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun

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

[Intel-gfx] [PATCH 12/14] drm/i915: Sanitize VLV/CHV watermarks properly

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ä

[Intel-gfx] [PATCH 05/14] drm/i915: Plop vlv/chv fifo sizes into crtc state

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 +--

[Intel-gfx] [PATCH 10/14] drm/i915: Nuke crtc->wm.cxsr_allowed

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

[Intel-gfx] [PATCH 06/14] drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks

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

[Intel-gfx] [PATCH 08/14] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed

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.

[Intel-gfx] [PATCH 11/14] drm/i915: Only use update_wm_{pre, post} for pre-ilk platforms

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ä

[Intel-gfx] [PATCH 14/14] drm/i915: Kill level 0 wm hack for VLV/CHV

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(-)

[Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way

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

[Intel-gfx] [PATCH 00/14] drm/i915: VLV/CHV two-stage watermarks

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

[Intel-gfx] [PATCH 04/14] drm/i915: Plop vlv wm state into crtc_state

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.

[Intel-gfx] [PATCH 02/14] drm/i915: Track plane fifo sizes under intel_crtc

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ä

[Intel-gfx] [PATCH 03/14] drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv

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ä ---

[Intel-gfx] [PATCH 01/14] drm/i915: Track visible planes in a bitmask

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

>-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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

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 + *

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV

== 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

Re: [Intel-gfx] [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Parse panel backlight controller from VBT

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

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

Re: [Intel-gfx] garbled external hdmi display on laptop, work around described

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

Re: [Intel-gfx] [PATCH 28/34] drm: Fix application of color vs range restriction when scanning drm_mm

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

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

[Intel-gfx] [PATCH] drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: Move out pipe CRC code

== 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/

Re: [Intel-gfx] [PATCH 1/4] drm: Protect master->unique with dev->master_mutex

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 >

Re: [Intel-gfx] [PATCH 21/34] drm: Promote drm_mm alignment to u64

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:

Re: [Intel-gfx] [PATCH 2/5] dma-buf: Update kerneldoc for sync_file_create

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

[Intel-gfx] [RESEND PATCH v12] drm/i915/debugfs: Move out pipe CRC code

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

Re: [Intel-gfx] [PATCH 1/5] dma-buf: Extract dma-buf.rst

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/34] drm/i915: Use the MRU stack search after evicting

== 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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Clear range when unbinding closed vma

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

[Intel-gfx] [PATCH 30/34] drm: Optimise power-of-two alignments in drm_mm_scan_add_block()

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Retire before attempting to evict from the active lists

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

[Intel-gfx] [PATCH 34/34] drm: kselftest for drm_mm and bottom-up allocation

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

[Intel-gfx] [PATCH 33/34] drm: Fix drm_mm search and insertion

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915/gtt: Don't pass ppgtt to ppgtt_cleanup_4lvl

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

[Intel-gfx] [PATCH 21/34] drm: Promote drm_mm alignment to u64

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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

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] [PATCH 29/34] drm: Compute tight evictions for drm_mm_scan

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

[Intel-gfx] [PATCH 31/34] drm: Simplify drm_mm scan-list manipulation

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

[Intel-gfx] [PATCH 22/34] drm: Constify the drm_mm API

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 +-

[Intel-gfx] [PATCH 26/34] drm: Rename prev_node to hole in drm_mm_scan_add_block()

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

[Intel-gfx] [PATCH 23/34] drm: Simplify drm_mm_clean()

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

[Intel-gfx] [PATCH 13/34] drm: kselftest for drm_mm and eviction

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

[Intel-gfx] [PATCH 05/34] drm: kselftest for drm_mm_init()

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(+)

[Intel-gfx] [PATCH 24/34] drm: Compile time enabling for asserts in drm_mm

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

[Intel-gfx] [PATCH 09/34] drm: kselftest for drm_mm_insert_node()

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

[Intel-gfx] [PATCH 19/34] drm: kselftest for drm_mm and restricted color eviction

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

[Intel-gfx] [PATCH 18/34] drm: kselftest for drm_mm and color eviction

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

[Intel-gfx] [PATCH 25/34] drm: Extract struct drm_mm_scan from struct drm_mm

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

Re: [Intel-gfx] [PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

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

[Intel-gfx] [PATCH 02/34] drm/i915: Simplify i915_gtt_color_adjust()

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 ++

[Intel-gfx] [PATCH 17/34] drm: kselftest for drm_mm and color adjustment

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

[Intel-gfx] [PATCH 10/34] drm: kselftest for drm_mm_replace_node()

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 +

[Intel-gfx] [PATCH 32/34] drm: Apply tight eviction scanning to color_adjust

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

[Intel-gfx] [PATCH 27/34] drm: Unconditionally do the range check in drm_mm_scan_add_block()

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 ++-

[Intel-gfx] [PATCH 28/34] drm: Fix application of color vs range restriction when scanning drm_mm

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

[Intel-gfx] [PATCH 04/34] drm: Add some kselftests for the DRM range manager (struct drm_mm)

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

[Intel-gfx] [PATCH 20/34] drm/i915: Build DRM range manager selftests for CI

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

[Intel-gfx] [PATCH 03/34] drm: Add drm_mm_for_each_node_safe()

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

[Intel-gfx] [PATCH 07/34] drm: Add a simple prime number generator

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 +

[Intel-gfx] [PATCH 08/34] drm: kselftest for drm_mm_reserve_node()

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

[Intel-gfx] [PATCH 01/34] drm/i915: Use the MRU stack search after evicting

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

[Intel-gfx] [PATCH 12/34] drm: kselftest for drm_mm and alignment

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 +

[Intel-gfx] [PATCH 16/34] drm: kselftest for drm_mm and top-down alignment

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 +

[Intel-gfx] [PATCH 11/34] drm: kselftest for drm_mm_insert_node_in_range()

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

[Intel-gfx] [PATCH 14/34] drm: kselftest for drm_mm and range restricted eviction

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

[Intel-gfx] [PATCH 15/34] drm: kselftest for drm_mm and top-down allocation

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

[Intel-gfx] [PATCH 06/34] drm: Add a simple linear congruent generator PRNG

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 |

[Intel-gfx] struct drm_mm fixes

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,

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

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] [PATCH 7/8] drm/i915/gtt: Purge page tracking bitmaps

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

[Intel-gfx] [PATCH 8/8] drm/i915: Clear range when unbinding closed vma

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:

[Intel-gfx] [PATCH 6/8] drm/i915: Prepare i915_page_table_entry_map tracepoint for bitmap purge

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

[Intel-gfx] [PATCH 5/8] drm/i915/gtt: Purge temp bitmaps

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.

[Intel-gfx] [PATCH 4/8] drm/i915/gtt: Don't use temp bitmaps to unwind gen8_alloc_va_range

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

[Intel-gfx] [PATCH 3/8] drm/i915/gtt: Extract unwind to separate function for gen6_alloc_va_range

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

[Intel-gfx] [PATCH 0/8] GTT bitmaps purge

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:

[Intel-gfx] [PATCH 2/8] drm/i915/gtt: Rename orig_start/orig_length

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

[Intel-gfx] [PATCH 1/8] drm/i915/gtt: Don't pass ppgtt to ppgtt_cleanup_4lvl

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

Re: [Intel-gfx] [PATCH] dim: Update docs for update-branches

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

[Intel-gfx] [PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.

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

Re: [Intel-gfx] [PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.

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

Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

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

  1   2   >