[Intel-gfx] [PATCH 2/3] drm/i915: Unwind vma->pages allocation upon failure

If we fail to allocate the ppgtt range after allocating the pages for the vma, we should unwind the local allocation before reporting back the failure. Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT") Signed-off-by: Chris Wilson Cc: Matthew Auld

[Intel-gfx] [PATCH 1/3] drm/i915: Only unwind the local pgtable layer if empty

Only if we allocated the layer and the lower level failed should we remove this layer when unwinding. Otherwise we ignore the overlapping entries by overwritting the old layer with scratch. Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4") Fixes: e2b763caa6eb ("drm/i915:

[Intel-gfx] [PATCH 3/3] drm/i915: Remove the vma from the drm_mm if binding fails

As we track whether a vma has been inserted into the drm_mm using the vma->flags, if we fail to bind the vma into the GTT we do not update those bits and will attempt to reinsert the vma into the drm_mm on future passes. To prevent that, we want to unwind i915_vma_insert() if we fail in our

Re: [Intel-gfx] [PATCH] drm/i915: Only unwind the local pgtable layer if empty

On Sat, Feb 25, 2017 at 09:41:56PM +, Chris Wilson wrote: > On Sat, Feb 25, 2017 at 09:19:59PM +, Chris Wilson wrote: > > Only if we allocated the layer and the lower level failed should we > > remove this layer when unwinding. Otherwise we ignore the overlapping > > entries by

Re: [Intel-gfx] [PATCH] drm/i915: Only unwind the local pgtable layer if empty

On Sat, Feb 25, 2017 at 09:19:59PM +, Chris Wilson wrote: > Only if we allocated the layer and the lower level failed should we > remove this layer when unwinding. Otherwise we ignore the overlapping > entries by overwritting the old layer with scratch. > > Fixes: c5d092a4293f ("drm/i915:

[Intel-gfx] [PATCH] drm/i915: Only unwind the local pgtable layer if empty

Only if we allocated the layer and the lower level failed should we remove this layer when unwinding. Otherwise we ignore the overlapping entries by overwritting the old layer with scratch. Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4") Fixes: e2b763caa6eb ("drm/i915:

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Assert all sg are initialised in fake_dma_object for selftests

On Sat, Feb 25, 2017 at 06:52:24PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/4] drm/i915: Assert all sg are initialised > in fake_dma_object for selftests > URL : https://patchwork.freedesktop.org/series/20251/ > State : success > > == Summary == >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Assert all sg are initialised in fake_dma_object for selftests

== Series Details == Series: series starting with [CI,1/4] drm/i915: Assert all sg are initialised in fake_dma_object for selftests URL : https://patchwork.freedesktop.org/series/20251/ State : success == Summary == Series 20251v1 Series without cover letter

Re: [Intel-gfx] i915: Dealing with 90° rotated display ?

Hi, On 20-02-17 14:24, Hans de Goede wrote: So when userspace (e.g. the Xorg server + modesetting driver) asks for 0° degree rotation under the hood they get 90 applied, when they aks for the panel resolution they get 1280x720 instead of 720x1280. The idea was that userspace will inherit

[Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

Several cherrytrail devices (all of which ship with windows 10) hide the lpss pwm controller in ACPI, typically the _STA method looks like this: Method (_STA, 0, NotSerialized) // _STA: Status { If (OSID == One) { Return (Zero) } Return (0x0F)

[Intel-gfx] [CI 4/4] drm/i915: Advance start address on crossing PML (48b ppgtt) boundary

When advancing onto the next 4th level page table entry, we need to reset our indices to 0. Currently we restart from the original address which means we start with an offset into the next PML table. Fixes: 894ccebee2b0 ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()") Reported-by: Matthew

[Intel-gfx] [CI 3/4] drm/i915: Sanity check the vma->node prior to binding into the GTT

We rely on the VMA being allocated inside the drm_mm and for its allotted node being large enough to accommodate all the vma->pages. Signed-off-by: Chris Wilson Cc: Matthew Auld Reviewed-by: Matthew Auld

[Intel-gfx] [CI 1/4] drm/i915: Assert all sg are initialised in fake_dma_object for selftests

Double check that we allocated the right amount of scatterlist elements for our obj->size. Signed-off-by: Chris Wilson Cc: Matthew Auld Reviewed-by: Matthew Auld ---

[Intel-gfx] [CI 2/4] drm/i915: Assert we do not overflow 4lvl page directories

Before looking up the page directory entry, check we are still within bounds. Signed-off-by: Chris Wilson Cc: Matthew Auld Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++--- 1

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW

Op 24-02-17 om 14:11 schreef Ville Syrjälä: > On Mon, Feb 20, 2017 at 03:30:58PM +0100, Maarten Lankhorst wrote: >> Op 20-02-17 om 14:38 schreef Ville Syrjälä: >>> On Mon, Feb 20, 2017 at 10:04:06AM +0100, Maarten Lankhorst wrote: Op 17-02-17 om 16:01 schreef ville.syrj...@linux.intel.com:

Re: [Intel-gfx] [PATCH] drm/i915: Advance start address on crossing PML (48b ppgtt) boundary

On 24 February 2017 at 22:37, Chris Wilson wrote: > When advancing onto the next 4th level page table entry, we need to > reset our indices to 0. Currently we restart from the original address > which means we start with an offset into the next PML table. > > Fixes:

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check the vma->node prior to binding into the GTT

On 24 February 2017 at 21:16, Chris Wilson wrote: > We rely on the VMA being allocated inside the drm_mm and for its alloted s/alloted/allotted > node being large enough to accommodate all the vma->pages. > > Signed-off-by: Chris Wilson > Cc:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Assert we do not overflow 4lvl page directories

On 24 February 2017 at 20:13, Chris Wilson wrote: > Before looking up the page directory entry, check we are still within > bounds. > > Signed-off-by: Chris Wilson > Cc: Matthew Auld Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Assert all sg are initialised in fake_dma_object for selftests

On 24 February 2017 at 20:13, Chris Wilson wrote: > Double check that we allocated the right amount of scatterlist elements > for our obj->size. > > Signed-off-by: Chris Wilson > Cc: Matthew Auld Reviewed-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/5] drm/i915: Report both waiters and success from intel_engine_wakeup() (rev2)

== Series Details == Series: series starting with [v3,1/5] drm/i915: Report both waiters and success from intel_engine_wakeup() (rev2) URL : https://patchwork.freedesktop.org/series/20218/ State : success == Summary == Series 20218v2 Series without cover letter

Re: [Intel-gfx] [PATCH resend 15/15] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

HI, On 24-02-17 18:02, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:45 +0100 Hans de Goede wrote: For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede

Re: [Intel-gfx] [PATCH resend 14/15] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

Hi, On 24-02-17 18:02, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:44 +0100 Hans de Goede wrote: According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel

Re: [Intel-gfx] [PATCH resend 13/15] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

Hi, On 24-02-17 18:02, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:43 +0100 Hans de Goede wrote: For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop. Isn't this only for command mode? Or is there conflicting

Re: [Intel-gfx] [PATCH resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

Hi, On 24-02-17 18:02, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:42 +0100 Hans de Goede wrote: According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has

Re: [Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

Hi, On 24-02-17 18:00, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:41 +0100 Hans de Goede wrote: Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de

Re: [Intel-gfx] [PATCH resend 07/15] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

Hi, On 24-02-17 18:00, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:37 +0100 Hans de Goede wrote: MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons: 1) The reset should already be asserted before intel_dsi_pre_enable() gets called 2) Most (some?)

Re: [Intel-gfx] [PATCH resend 05/15] drm/i915/dsi: Document the panel enable / disable sequences from the spec

Hi Bob, Thank you for the review of this patch-set. On 24-02-17 18:00, Bob Paauwe wrote: On Mon, 20 Feb 2017 15:08:35 +0100 Hans de Goede wrote: Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec.

[Intel-gfx] [PATCH v4] drm/i915: Signal first fence from irq handler if complete

As execlists and other non-semaphore multi-engine devices coordinate between engines using interrupts, we can shave off a few 10s of microsecond of scheduling latency by doing the fence signaling from the interrupt as opposed to a RT kthread. (Realistically the delay adds about 1% to an individual