Re: [Intel-gfx] [PATCH] drm/atomic-helper: Also update legacy dpms state

On Wed, Jul 15, 2015 at 04:48:33PM +0100, Daniel Stone wrote: > On 15 July 2015 at 16:44, Daniel Vetter wrote: > > Avoids legacy userspace/code getting confused when dpms doesn't > > reflect reality of what's going on. > > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Daniel Stone Applied

[Intel-gfx] [PATCH] drm/fbdev: Return -EBUSY when oopsing

Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing. There wa

Re: [Intel-gfx] [PATCH i-g-t v2] Android.mk: Disable tools that do not build for android

Bump Can this patch be merged? It only affects android and it only disables tools that fail to build anyway. Fixing the broken tools for android require non trivial fixes so need to be addressed as separate patches. This patch is required to allow the other tools to build for android in the mea

[Intel-gfx] [PATCH 03/13] drm/i915: Make the force_thru workaround atomic.

Set active_changed to force a modeset if the panel fitter's force enabled. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_debugfs.c | 82 +++- drivers/gpu/drm/i915/intel_display.c | 3 ++ 2 files changed, 27 insertions(+), 58 deletions(-) diff -

[Intel-gfx] [PATCH 07/13] drm/i915: Get rid of dpms handling.

This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 97 drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.

This is required for DPMS to work correctly, during a modeset the DPMS property should be turned off, unless the crtc is made active in which case it should be set to DPMS on. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 16 ++

[Intel-gfx] [PATCH 06/13] drm/i915: Remove special dpms handling from intel_sdvo.c

There's not much point in handling anything but DPMS on/off, no need to get smart about it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_sdvo.c | 47 +-- 1 file changed, 1 insertion(+), 46 deletions(-) diff --git a/drivers/gpu/drm/i915/inte

[Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 0898afbc9e23..70e69904291d 10064

[Intel-gfx] [PATCH 04/13] drm/i915: Remove special dpms handling from intel_crt.c

There's not much point in handling anything but DPMS ON/OFF, no need to get smart about it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 49 +--- 1 file changed, 1 insertion(+), 48 deletions(-) diff --git a/drivers/gpu/drm/i915/inte

[Intel-gfx] [PATCH 08/13] drm/i915: Use proper locking for intel_dp_check_link_status.

To look at encoder->crtc->state the crtc mutex is required. Get rid of connectors_active, and only check crtc state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 34 +- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/driver

[Intel-gfx] [PATCH 00/13] Make i915 dpms atomic.

Now that i915 is fully atomic lets get rid of the special i915 dpms handling, and get rid of intel_crtc_control. Maarten Lankhorst (13): drm/atomic: Only update crtc->x/y if it's part of the state. drm/atomic: Update legacy DPMS state during modesets. drm/i915: Make the force_thru workaround

[Intel-gfx] [PATCH 11/13] drm/i915: Remove connectors_active from sanitization.

connectors_active will be removed, so just calculate this right here. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/inte

[Intel-gfx] [PATCH 09/13] drm/i915: Remove some unneeded checks from check_crtc_state.

This is handled by the atomic core now, no need to check this for ourself. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 05/13] drm/i915: Remove special dpms handling from intel_crtc.c

There's not much point in handling anything but DPMS on/off, no need to get smart about it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dvo.c | 46 +--- 1 file changed, 1 insertion(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/inte

[Intel-gfx] [PATCH 10/13] drm/i915: Remove connectors_active from state checking.

Connectors are updated atomically now, so the only interaction with the encoder is through base.crtc. If it's NULL the encoder's not part of any crtc, and if it's not NULL then active should be equal to crtc_state->active. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.

[Intel-gfx] [PATCH 12/13] drm/i915: Remove connectors_active from intel_dp.c.

Now that everything's atomic, checking encoder->base.crtc is enough. Cc: Ville Syrjälä Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index

[Intel-gfx] [PATCH 13/13] drm/i915: Remove connectors_active.

There are no more users, byebye! Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 44 +--- drivers/gpu/drm/i915/intel_drv.h | 1 - 2 files changed, 1 insertion(+), 44 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH] tests/gem_reg_read: Extend and check for valid 36b counter

When reading the timestamp register with single 64b read, we're observing invalid values on x86_64: [f = valid counter value | X = garbage] i386: 0x000f x86_64: 0x Test checks if the counter is moving and increasing. Add a check to see if we can use (reg | 1) flag t

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote: > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_atomic_helper.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helpe

Re: [Intel-gfx] [PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.

On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote: > This is required for DPMS to work correctly, during a modeset > the DPMS property should be turned off, unless the crtc > is made active in which case it should be set to DPMS on. > > Cc: dri-de...@lists.freedesktop.org > Signed-

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

Op 16-07-15 om 11:19 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote: >> Cc: dri-de...@lists.freedesktop.org >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/drm_atomic_helper.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Remove some unneeded checks from check_crtc_state.

On Thu, Jul 16, 2015 at 10:59:22AM +0200, Maarten Lankhorst wrote: > This is handled by the atomic core now, no need to check this for ourself. > > Signed-off-by: Maarten Lankhorst For all these "Remove ..." patches I think it'd be better to rewrite the changed code to use atomic state for whate

Re: [Intel-gfx] [PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.

Op 16-07-15 om 11:19 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote: >> This is required for DPMS to work correctly, during a modeset >> the DPMS property should be turned off, unless the crtc >> is made active in which case it should be set to DPMS on. >

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote: > Op 16-07-15 om 11:19 schreef Daniel Vetter: > > On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote: > >> Cc: dri-de...@lists.freedesktop.org > >> Signed-off-by: Maarten Lankhorst > >> --- > >> drivers/gpu/drm/drm_

Re: [Intel-gfx] [PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.

On Thu, Jul 16, 2015 at 11:24:02AM +0200, Maarten Lankhorst wrote: > Op 16-07-15 om 11:19 schreef Daniel Vetter: > > On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote: > >> This is required for DPMS to work correctly, during a modeset > >> the DPMS property should be turned off, unl

[Intel-gfx] [PATCH v5 09/19] drm/i915/gen8: Pass sg_iter through pte inserts

As a step towards implementing 4 levels, while not discarding the existing pte insert functions, we need to pass the sg_iter through. The current function understands to the page directory granularity. An object's pages may span the page directory, and so using the iter directly as we write the PTE

[Intel-gfx] [PATCH v5 00/19] 48-bit PPGTT

This clean-up version delays the 48-bit work to later patches and includes other review comments from Akash and Chris Wilson. The first 4 patches prepare the dynamic page allocation code to handle independent pdps, but no specific code for 48-bit mode is added before the 5th patch. In order expand

[Intel-gfx] [PATCH v5 13/19] drm/i915/gen8: Add ppgtt info and debug_dump

v2: Clean up patch after rebases. v3: gen8_dump_ppgtt for 32b and 48b PPGTT. v4: Use used_pml4es/pdpes (Akash). v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series. v6: Rely on used_px bits instead of null checking (Akash) Cc: Akash Goel Signed-off-by: Ben Widawsky Signed-off-by:

[Intel-gfx] [PATCH v5 11/19] drm/i915/gen8: Initialize PDPs

Similar to PDs, while setting up a page directory pointer, make all entries of the pdp point to the scratch pd before mapping (and make all its entries point to the scratch page); this is to be safe in case of out of bound access or proactive prefetch. v2: Handle scratch_pdp allocation failure cor

[Intel-gfx] [PATCH v5 01/19] drm/i915: Remove unnecessary gen8_clamp_pd

gen8_clamp_pd clamps to the next page directory boundary, but the macro gen8_for_each_pde already has a check to stop at the page directory boundary. Furthermore, i915_pte_count also restricts to the next page table boundary. v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series. Su

[Intel-gfx] [PATCH v5 08/19] drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT

The insert_entries function was the function used to write PTEs. For the PPGTT it was "hardcoded" to only understand two level page tables, which was the case for GEN7. We can reuse this for 4 level page tables, and remove the concept of insert_entries, which was never viable past 2 level page tabl

[Intel-gfx] [PATCH v5 17/19] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

There are some allocations that must be only referenced by 32-bit offsets. To limit the chances of having the first 4GB already full, objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ DRM_MM_CREATE_TOP flags In specific, any resource used with flat/heapless (0x-0xf000) Gen

[Intel-gfx] [PATCH v5 10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range

When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map Level 4 (PML4), before it selects which Page Directory Pointer (PDP) it will write to. Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range. This patch was inspired by Ben's "Depend exclusively on map and

[Intel-gfx] [PATCH v5 12/19] drm/i915: Expand error state's address width to 64b

v2: For semaphore errors, object is mapped to GGTT and offset will not be > 4GB, print only lower 32-bits (Akash) v3: Print gtt_offset in groups of 32-bit (Chris) Cc: Akash Goel Cc: Chris Wilson Signed-off-by: Ben Widawsky Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v5 18/19] drm/i915/gen8: Flip the 48b switch

Use 48b addresses if hw supports it (i915.enable_ppgtt=3). Note, aliasing PPGTT remains 32b only. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++--- drivers/gpu/drm/i915/i915_params.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/g

[Intel-gfx] [PATCH v5 14/19] drm/i915: object size needs to be u64

In a 48b world, users can try to allocate buffers bigger than 4GB; in these cases it is important that size is a 64b variable. v2: Drop the warning about bind with size 0, it shouldn't happen anyway. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_gem.c | 5 +++-- 1 file changed, 3

[Intel-gfx] [PATCH v5 15/19] drm/i915: batch_obj vm offset must be u64

Otherwise it can overflow in 48-bit mode, and cause an incorrect exec_start. Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce ("drm/i915: Merged the many do_execbuf() parameters into a structure"), it was already an u64. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH v5 03/19] drm/i915/gen8: Abstract PDP usage

Up until now, ppgtt->pdp has always been the root of our page tables. Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs. In preparation for 4 level page tables, we need to stop use ppgtt->pdp directly unless we know it's what we want. The future structure will use ppgtt->pml4 for the top l

[Intel-gfx] [PATCH v5 06/19] drm/i915/gen8: implement alloc/free for 4lvl

PML4 has no special attributes, and there will always be a PML4. So simply initialize it at creation, and destroy it at the end. The code for 4lvl is able to call into the existing 3lvl page table code to handle all of the lower levels. v2: Return something at the end of gen8_alloc_va_range_4lvl

[Intel-gfx] [PATCH v5 05/19] drm/i915/gen8: Add PML4 structure

Introduces the Page Map Level 4 (PML4), ie. the new top level structure of the page tables. To facilitate testing, 48b mode will be available on Broadwell and GEN9+, when i915.enable_ppgtt = 3. v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already 32/64-bit safe (Chris). v3: Add goto

[Intel-gfx] [PATCH v5 19/19] drm/i915: Save some page table setup on repeated binds

Check if the required page tables are already allocated, if so, we can skip altogether the inner loop of pdes, and move to the next page directory. If the new allocation is different than the existing one (i.e. new allocation spans more ptes than already covered from earlier allocations), the used

[Intel-gfx] [PATCH v5 16/19] drm/i915/userptr: Kill user_size limit check

GTT was only 32b and its max value is 4GB. In order to allow objects bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check against max 48b range (1ULL << 48). But since the check no longer applies, just kill the limit. v2: Use the default ctx to infer the ppgtt max size (Akash). v3:

[Intel-gfx] [PATCH v5 04/19] drm/i915/gen8: Add dynamic page trace events

The dynamic page allocation patch series added it for GEN6, this patch adds them for GEN8. v2: Consolidate pagetable/page_directory events v3: Multiple rebases. v4: Rebase after s/page_tables/page_table/. v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series. v6: Rebase after gen8_map

[Intel-gfx] [PATCH v5 07/19] drm/i915/gen8: Add 4 level switching infrastructure and lrc support

In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains the base address to PML4, while the other PDP registers are ignored. In LRC, the addressing mode must be specified in every context descriptor, and the base address to PML4 is stored in the reg state. v2: PML4 update in legacy

[Intel-gfx] [PATCH v5 02/19] drm/i915/gen8: Make pdp allocation more dynamic

This transitional patch doesn't do much for the existing code. However, it should make upcoming patches to use the full 48b address space a bit easier. v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp). v3: To facilitate testing, 48b mode will be available on Broadwell and GEN9+,

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

Op 16-07-15 om 11:29 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote: >> Op 16-07-15 om 11:19 schreef Daniel Vetter: >>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote: Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Remove some unneeded checks from check_crtc_state.

Hey, Op 16-07-15 om 11:24 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 10:59:22AM +0200, Maarten Lankhorst wrote: >> This is handled by the atomic core now, no need to check this for ourself. >> >> Signed-off-by: Maarten Lankhorst > For all these "Remove ..." patches I think it'd be better to

[Intel-gfx] [PATCH 14/13] drm/i915: Only update mode related state if a modeset happened.

The rest will be a noop anyway, since without modeset there will be no updated dplls and no modeset state to update. Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 45fbbbf478ab..fcbde8a1a4c5 100644 --- a/drivers

Re: [Intel-gfx] [PATCH] tests/gem_reg_read: Extend and check for valid 36b counter

On Thu, Jul 16, 2015 at 11:06:59AM +0200, Michał Winiarski wrote: > When reading the timestamp register with single 64b read, we're observing > invalid values on x86_64: > > [f = valid counter value | X = garbage] > > i386: 0x000f > x86_64: 0x > > Test checks if the

[Intel-gfx] [drm-intel:topic/drm-misc 14/14] drivers/gpu/drm/drm_fb_helper.c:400:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 6066677cfd9d73734ab678b9d14013c860f0f732 commit: 6066677cfd9d73734ab678b9d14013c860f0f732 [14/14] drm/fb: drop panic handling config: x86_64-randconfig-i0-201528 (attached as .config) reproduce: git checkout 6066677cfd9d73734

[Intel-gfx] [PATCH v2] tests/gem_reg_read: Extend and check for valid 36b counter

When reading the timestamp register with single 64b read, we are observing invalid values on x86_64: [f = valid counter value | X = garbage] i386: 0x000f x86_64: 0x Test checks if the counter is moving and increasing. Add a check to see if we can use (re

Re: [Intel-gfx] [PATCH v2] tests/gem_reg_read: Extend and check for valid 36b counter

On Thu, Jul 16, 2015 at 12:37:55PM +0200, Michał Winiarski wrote: > When reading the timestamp register with single 64b read, we are observing > invalid values on x86_64: > > [f = valid counter value | X = garbage] > > i386: 0x000f > x86_64: 0x > > Test

[Intel-gfx] [PATCH i-g-t 0/2] Enabling intel_reg on Android

intel_reg replaces various other register tools, so these patches attempt to enable building it on Android platforms. Thomas Wood (2): intel_reg: support platforms without sys/io.h tools/Android.mk: add any extra program sources configure.ac | 2 +- tools/Android.mk | 4 ++-- tools/i

[Intel-gfx] [PATCH i-g-t 1/2] intel_reg: support platforms without sys/io.h

Based on an idea from Jani Nikula. Cc: Jani Nikula Cc: Derek Morton Signed-off-by: Thomas Wood --- configure.ac | 2 +- tools/intel_reg.c | 17 - 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f3603c1..3770b2f 100644 ---

[Intel-gfx] [PATCH i-g-t 2/2] tools/Android.mk: add any extra program sources

Cc: Derek Morton Signed-off-by: Thomas Wood --- tools/Android.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/Android.mk b/tools/Android.mk index 39f4512..f7dc3bb 100644 --- a/tools/Android.mk +++ b/tools/Android.mk @@ -1,13 +1,13 @@ LOCAL_PATH := $(call my-dir)

[Intel-gfx] [PATCH v3] tests/gem_reg_read: Extend and check for valid 36b counter

When reading the timestamp register with single 64b read, we are observing invalid values on x86_64: [f = valid counter value | X = garbage] i386: 0x000f x86_64: 0x Test checks if the counter is moving and increasing. Add a check to see if we can use (re

Re: [Intel-gfx] [PATCH v3] tests/gem_reg_read: Extend and check for valid 36b counter

On Thu, Jul 16, 2015 at 01:19:09PM +0200, Michał Winiarski wrote: > When reading the timestamp register with single 64b read, we are observing > invalid values on x86_64: > > [f = valid counter value | X = garbage] > > i386: 0x000f > x86_64: 0x > > Test

[Intel-gfx] [PATCH v3] drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls

Since the hardware sometimes mysteriously totally flummoxes the 64bit read of a 64bit register when read using a single instruction, split the read into two instructions. Since the read here is of automatically incrementing timestamp counters, we also have to be very careful in order to make sure t

Re: [Intel-gfx] [PATCH v3] tests/gem_reg_read: Extend and check for valid 36b counter

On Thu, Jul 16, 2015 at 12:24:19PM +0100, Chris Wilson wrote: > On Thu, Jul 16, 2015 at 01:19:09PM +0200, Michał Winiarski wrote: > > When reading the timestamp register with single 64b read, we are observing > > invalid values on x86_64: > > > > [f = valid counter value | X = garbage] > > >

Re: [Intel-gfx] [PATCH] drm/i915: Don't clear all watermarks when updating.

On Wed, Jul 08, 2015 at 09:05:53AM -0700, Bob Paauwe wrote: > Clearing the watermarks for all pipes/planes when updating the > watermarks for a single CRTC change seems like the wrong thing to > do here. As is, this code will update any pipe/plane watermarks > that need updating and leave the remai

Re: [Intel-gfx] [PATCH] drm/i915: Don't clear all watermarks when updating.

On Wed, Jul 08, 2015 at 09:05:53AM -0700, Bob Paauwe wrote: > Clearing the watermarks for all pipes/planes when updating the > watermarks for a single CRTC change seems like the wrong thing to > do here. As is, this code will update any pipe/plane watermarks > that need updating and leave the remai

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote: > Op 16-07-15 om 11:29 schreef Daniel Vetter: > > On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote: > >> Op 16-07-15 om 11:19 schreef Daniel Vetter: > >>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst

[Intel-gfx] [PATCH 4/5] drm/i915: Remove wait_for_pending_flips from disable_noatomic.

Now that intel_display_suspend is atomic it's safe to remove wait_for_pending_flips from intel_crtc_disable_noatomic. It will only be used during hw load or resume, in which case there will be no pending flips anyway. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 4

[Intel-gfx] [PATCH 3/5] drm/i915: Make prepare_plane_fb fully interruptible.

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3f82214b737b..d3a857ce1cb6 100644 --- a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 5/5] drm/i915: Make wait_for_flips interruptible.

Move it from intel_crtc_atomic_commit to prepare_plane_fb. Waiting is done before committing, otherwise it's too late to undo the changes. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic.c | 2 - drivers/gpu/drm/i915/intel_display.c | 72 +

[Intel-gfx] [PATCH 1/5] drm/i915: Handle return value in intel_pin_and_fence_fb_obj.

-EDEADLK has special meaning in atomic, but get_fence may call i915_find_fence_reg which can return -EDEADLK. This has special meaning in the atomic world, so convert the error to -EBUSY for this case. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 5 - 1 file c

[Intel-gfx] [PATCH 2/5] drm/atomic: Make prepare_fb/cleanup_fb only take state.

This removes the need to separately track fb changes i915. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c | 21 +++--- drivers/gpu/drm/drm_plane_helper.c | 6 +-- drivers/gpu/drm/i915

[Intel-gfx] [PATCH 0/5] drm/i915: Make waiting interruptible.

Now that i915 is fully atomic it's time to make the waits interruptible. This can be done by making sure prepare_plane_fb is always called, because it's the logical place to put such waits in. This also cleans up the disabled_planes hack, the disabling planes case is now handled by prepare_plane_

Re: [Intel-gfx] [PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.

Op 16-07-15 om 14:34 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote: >> Op 16-07-15 om 11:29 schreef Daniel Vetter: >>> On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote: Op 16-07-15 om 11:19 schreef Daniel Vetter: > On Thu, Jul 1

[Intel-gfx] [PATCH v1.1 01/13] drm/atomic: Only update crtc->x/y if it's part of the state, v2.

Universal planes may not be assigned to the current crtc, so only update crtc->x/y when the primary is part of the state and bound to the current crtc. Changes since v1: - Add the crtc check. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/dr

[Intel-gfx] [PATCH v1.1 2/5] drm/atomic: Make prepare_fb/cleanup_fb only take state, v2.

This removes the need to separately track fb changes i915. Changes since v1: - Add dri-devel to cc. - Fix a check in intel's prepare and cleanup fb to take rotation into account. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/atmel

Re: [Intel-gfx] [PATCH i-g-t 2/2] tools/Android.mk: add any extra program sources

Hi Thomas, I tried these patches on Android. They worked with some modifications. See comments below. //Derek > > >-Original Message- >From: Wood, Thomas >Sent: Thursday, July 16, 2015 12:08 PM >To: intel-gfx@lists.freedesktop.org >Cc: Morton, Derek J >Subject: [PATCH i-g-t 2/2] tools/

[Intel-gfx] [PATCH] drm/i915: Do kunmap if renderstate parsing fails

Kunmap the renderstate page on error path. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_render_state.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c ind

[Intel-gfx] [PATCH 1/2] drm: Stop resetting connector state to unknown

It's causing piles of issues since we've stopped forcing full detect cycles in the sysfs interfaces with commit c484f02d0f02fbbfc6decc945a69aae011041a27 Author: Chris Wilson Date: Fri Mar 6 12:36:42 2015 + drm: Lighten sysfs connector 'status' The original justification for this was t

[Intel-gfx] [PATCH 2/2] drm/i915: Don't reprobe on resume

If we don't force the connector state to unknown there's no reason any more to force a reprobe. Also no other driver bothers with this, so probably it's not required - userspace handles lid/resume events through other channels already. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_d

[Intel-gfx] [PATCH] drm/fbdev: Return -EBUSY when oopsing

Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing. There wa

Re: [Intel-gfx] [PATCH v1.1 01/13] drm/atomic: Only update crtc->x/y if it's part of the state, v2.

On Thu, Jul 16, 2015 at 03:51:01PM +0200, Maarten Lankhorst wrote: > Universal planes may not be assigned to the current crtc, so only > update crtc->x/y when the primary is part of the state and bound > to the current crtc. > > Changes since v1: > - Add the crtc check. > > Cc: dri-de...@lists.fr

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Remove some unneeded checks from check_crtc_state.

Op 16-07-15 om 17:01 schreef Daniel Vetter: > On Thu, Jul 16, 2015 at 11:38:33AM +0200, Maarten Lankhorst wrote: >> Hey, >> >> Op 16-07-15 om 11:24 schreef Daniel Vetter: >>> On Thu, Jul 16, 2015 at 10:59:22AM +0200, Maarten Lankhorst wrote: This is handled by the atomic core now, no need to c

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Remove some unneeded checks from check_crtc_state.

On Thu, Jul 16, 2015 at 11:38:33AM +0200, Maarten Lankhorst wrote: > Hey, > > Op 16-07-15 om 11:24 schreef Daniel Vetter: > > On Thu, Jul 16, 2015 at 10:59:22AM +0200, Maarten Lankhorst wrote: > >> This is handled by the atomic core now, no need to check this for ourself. > >> > >> Signed-off-by:

[Intel-gfx] [PATCH] drm/i915: Change SRM, LRM instructions to use correct length

MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects (reg, addr) pairs so use fixed length for these instructions. Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_cmd_parser.c

Re: [Intel-gfx] [PATCH] drm/i915: Do kunmap if renderstate parsing fails

On 16/07/2015 15:36, Mika Kuoppala wrote: Kunmap the renderstate page on error path. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_render_state.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/dr

Re: [Intel-gfx] [PATCH i-g-t 2/2] tools/Android.mk: add any extra program sources

On 16 July 2015 at 15:13, Morton, Derek J wrote: > > Hi Thomas, > > I tried these patches on Android. They worked with some modifications. See > comments below. > > //Derek > > > > > > >-Original Message- > >From: Wood, Thomas > >Sent: Thursday, July 16, 2015 12:08 PM > >To: intel-gfx@lis

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't reprobe on resume

On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > If we don't force the connector state to unknown there's no reason any > more to force a reprobe. Also no other driver bothers with this, so > probably it's not required - userspace handles lid/resume events > through other channels a

[Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

Fix divide by zero if we end up updating the watermarks with zero dotclock. This is a stop gap measure to allow module load in cases where our state keeping fails. Cc: Damien Lespiau Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 d

Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

2015-07-16 13:00 GMT-03:00 Mika Kuoppala : > Fix divide by zero if we end up updating the watermarks > with zero dotclock. > > This is a stop gap measure to allow module load in cases > where our state keeping fails. Shouldn't we WARN() here? > > Cc: Damien Lespiau > Signed-off-by: Mika Kuoppala

[Intel-gfx] [PATCH 1/2] drm/i915/skl: Don't expose the top most plane on gen9 display

on SKL/BXT, the top most plane hardware is shared between the legacy cursor registers and an actual plane. Daniel and Ville don't want to expose 2 DRM planes and would rather expose a CURSOR plane that has all the usual plane properties, and that's a blocker for lifting the prelimary_hw_support fla

[Intel-gfx] [PATCH 2/2] drm/i915/skl: Drop the preliminary_hw_support flag

Time to light a candle and remove the preliminary_hw_support flag. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e44dc0d..c8daa2d 100644 --- a/drivers/

[Intel-gfx] [RFC] drm/i915/gtt: Allow >= 4GB offsets in X86_32

Commit c44ef60e4370 ("drm/i915/gtt: Allow >= 4GB sizes for vm.") took care of most of this changes, but i915_gem_obj_offset still returned an unsigned long, which in only 4-bytes long in 32-bit kernels. Change return type (and other related offset variables) to u64. Since Global GTT is always lim

Re: [Intel-gfx] [RFC] drm/i915/gtt: Allow >= 4GB offsets in X86_32

On Thu, Jul 16, 2015 at 05:18:18PM +0100, Michel Thierry wrote: > Commit c44ef60e4370 ("drm/i915/gtt: Allow >= 4GB sizes for vm.") took care > of most of this changes, but i915_gem_obj_offset still returned an unsigned > long, which in only 4-bytes long in 32-bit kernels. > > Change return type (a

[Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

Fix divide by zero if we end up updating the watermarks with zero dotclock. This is a stop gap measure to allow module load in cases where our state keeping fails. v2: WARN_ON added (Paulo) Cc: Paulo Zanoni Cc: Damien Lespiau Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c |

Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

2015-07-16 13:36 GMT-03:00 Mika Kuoppala : > Fix divide by zero if we end up updating the watermarks > with zero dotclock. > > This is a stop gap measure to allow module load in cases > where our state keeping fails. > > v2: WARN_ON added (Paulo) Since we're not hiding the problem (due to the WARN

Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

On Thu, Jul 16, 2015 at 07:36:51PM +0300, Mika Kuoppala wrote: > Fix divide by zero if we end up updating the watermarks > with zero dotclock. > > This is a stop gap measure to allow module load in cases > where our state keeping fails. > > v2: WARN_ON added (Paulo) > > Cc: Paulo Zanoni > Cc: D

[Intel-gfx] [PATCH i-g-t] lib: exit immediately if igt_fail is called in an exit handler

Exit immediately if the test is already exiting and igt_fail is called. This can happen if an igt_assert fails in an exit handler. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91349 Signed-off-by: Thomas Wood --- lib/igt_core.c | 8 1 file changed, 8 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Don't clear all watermarks when updating.

On Thu, 16 Jul 2015 13:30:11 +0100 Damien Lespiau wrote: > On Wed, Jul 08, 2015 at 09:05:53AM -0700, Bob Paauwe wrote: > > Clearing the watermarks for all pipes/planes when updating the > > watermarks for a single CRTC change seems like the wrong thing to > > do here. As is, this code will update

Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update

On Thu, Jul 16, 2015 at 05:44:17PM +0100, Damien Lespiau wrote: > On Thu, Jul 16, 2015 at 07:36:51PM +0300, Mika Kuoppala wrote: > > Fix divide by zero if we end up updating the watermarks > > with zero dotclock. > > > > This is a stop gap measure to allow module load in cases > > where our state

Re: [Intel-gfx] [PATCH v3 00/20] Convert to atomic, part 4.

Hi, On Monday, July 13, 2015, Maarten Lankhorst < maarten.lankho...@linux.intel.com> wrote: > Atomic suspend/resume, full hardware readout and atomic ioctl support. > > Changes from the previous version: > - The fastboot changes from the previous patch have been removed, > fastboot will have to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't reprobe on resume

On Thu, Jul 16, 2015 at 07:41:14PM +0200, Rui Tiago Cação Matos wrote: > On Thu, Jul 16, 2015 at 5:32 PM, Chris Wilson > wrote: > > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > >> If we don't force the connector state to unknown there's no reason any > >> more to force a repro

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't reprobe on resume

On Thu, Jul 16, 2015 at 04:32:44PM +0100, Chris Wilson wrote: > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > > If we don't force the connector state to unknown there's no reason any > > more to force a reprobe. Also no other driver bothers with this, so > > probably it's not req

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: WA for swapped HPD pins in A stepping

On 7/15/2015 2:37 PM, Daniel Vetter wrote: On Wed, Jul 15, 2015 at 01:34:29PM +0530, Jindal, Sonika wrote: On 7/15/2015 12:05 PM, Jindal, Sonika wrote: On 7/14/2015 7:52 PM, Imre Deak wrote: On ti, 2015-07-14 at 11:18 +0530, Sonika Jindal wrote: As per bspec, on BXT A0/A1, sw needs to a

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't reprobe on resume

On Thu, Jul 16, 2015 at 04:32:44PM +0100, Chris Wilson wrote: > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > > If we don't force the connector state to unknown there's no reason any > > more to force a reprobe. Also no other driver bothers with this, so > > probably it's not req

  1   2   >