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
---
drivers/gpu/drm/i915/i915_gem_
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 attempt
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: Remov
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 overwritting
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: Remo
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: Remov
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 ==
>
== 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
https://patchwork.freedesktop.org/
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 th
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)
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
---
drivers/gpu/drm/i915/i915_vma.c | 15 +--
1 file changed, 9 insertions(+),
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
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftes
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 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_g
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
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:
>>>
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: 894ccebee2b0 ("drm/i915: Micro-
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: Matthew Auld
Didn't apply cleanly on tip.
Reviewed-
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
___
Intel-gfx mailing list
Intel-gfx@lists
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: Matthew Auld
___
Intel-gfx mailing list
In
== 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
https://patchwork.freedesktop.o
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
---
drivers/gpu/drm/i915/int
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 is a vid-mode panel.
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 information
on this?
In my (
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 known issues, we use the
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 Goede
I'm not sure that
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?) VBTs will ensure reset wa
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.
Signed-off-by: Hans de Goede
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
28 matches
Mail list logo
