Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Currently we try to reduce the number of synchronisations (now the
number of requests we need to wait upon) by noting that if we have
earlier waited upon a request, all subsequent requests in the timeline
will be after the wait. This only applies to requests in this timeline,
as other timelines wil
Though we will have multiple timelines, we still have a single timeline
of execution. This we can use to provide an execution and retirement order
of requests. This keeps tracking execution of requests simple, and vital
for preserving a single waiter (i.e. so that we can order the waiters so
that o
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is th
After combining the dma-buf reservation object and the GEM reservation
object, we lost the ability to do a nonblocking wait on the i915 request
(as we blocked upon the reservation object during prepare_fb). We can
instead convert the reservation object into a fence upon which we can
asynchronously
In future patches, we will no longer be able to wait on a static global
seqno and instead have to break our wait up into phases. First we wait
for the global seqno assignment (upon submission to hardware), and once
submitted we wait for the hardware to complete.
Signed-off-by: Chris Wilson
---
d
With the infrastructure converted over to tracking multiple timelines in
the GEM API whilst preserving the efficiency of using a single execution
timeline internally, we can now assign a separate timeline to every
context with full-ppgtt.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
Since we only use the more generic unlocked variant, just rename it as
the normal i915_gem_active_wait(). The temporary cost is that we need to
always acquire the reference in a RCU safe manner, but the benefit is
that we will combine the common paths.
Signed-off-by: Chris Wilson
---
drivers/gpu
In forthcoming patches, we want to be able to dynamically allocate the
wait_queue_t used whilst awaiting. This is more convenient if we extend
the i915_sw_fence_await_sw_fence() to perform the allocation for us if
we pass in a gfp mask rather than a preallocate struct.
Signed-off-by: Chris Wilson
In the next patch, we will use deferred request emission. That requires
reserving sufficient space in the ringbuffer to emit the request, which
first requires us to know how large the request is.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 1 +
drivers/gpu/drm/i915
A restriction on our global seqno is that they cannot wrap, and that we
cannot use the value 0. This allows us to detect when a request has not
yet been submitted, its global seqno is still 0, and ensures that
hardware semaphores are monotonic as required by older hardware. To
meet these restrictio
We will need to wait on DMA completion (as signaled via struct fence)
before executing our i915_gem_request. Therefore we want to expose a
method for adding the await on the fence itself to the request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 40
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
Our low-level wait routine has evolved from our generic wait interface
that handled unlocked, RPS boosting, waits with time tracking. If we
push our GEM fence tracking to use reservation_objects (required for
handling multiple timelines), we lose the ability to pass the required
information down to
This will be used for communicating issues with this context to
userspace, so we want to identify the parent process and the individual
context. Note that the name isn't quite unique, it makes the presumption
of there only being a single device fd per process.
Signed-off-by: Chris Wilson
---
dri
Our timelines are more than just a seqno. They also provide an ordered
list of requests to be executed. Due to the restriction of handling
individual address spaces, we are limited to a timeline per address
space but we use a fence context per engine within.
Our first step to introducing independe
Move the actual emission of the request (the closing breadcrumb) from
i915_add_request() to the submit callback. (It can be moved later when
required.) This allows us to defer the allocation of the global_seqno
from request construction to actual submission, allowing us to emit the
requests out of
Here's how I think we can handle multiple timelines whilst preserving
the efficiency of retirement ordering of requests and the single waiter
property.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
== Series Details ==
Series: Remaining patches for upfront link training on DDI platforms
URL : https://patchwork.freedesktop.org/series/12425/
State : success
== Summary ==
Series 12425v1 Remaining patches for upfront link training on DDI platforms
https://patchwork.freedesktop.org/api/1.0/se
== Series Details ==
Series: drm/i915: Add ddb size field to device info structure
URL : https://patchwork.freedesktop.org/series/12427/
State : success
== Summary ==
Series 12427v1 drm/i915: Add ddb size field to device info structure
https://patchwork.freedesktop.org/api/1.0/series/12427/rev
== Series Details ==
Series: drm/i915: Standardize port type for DVO encoders
URL : https://patchwork.freedesktop.org/series/12418/
State : failure
== Summary ==
Series 12418v1 drm/i915: Standardize port type for DVO encoders
https://patchwork.freedesktop.org/api/1.0/series/12418/revisions/1/m
== Series Details ==
Series: SKL/KBL watermark fixes (rev2)
URL : https://patchwork.freedesktop.org/series/12082/
State : failure
== Summary ==
Series 12082v2 SKL/KBL watermark fixes
https://patchwork.freedesktop.org/api/1.0/series/12082/revisions/2/mbox/
Test kms_pipe_crc_basic:
Subg
== Series Details ==
Series: dma-buf/sync_file: Always increment refcount when merging fences.
URL : https://patchwork.freedesktop.org/series/12414/
State : failure
== Summary ==
Series 12414v1 dma-buf/sync_file: Always increment refcount when merging fences.
https://patchwork.freedesktop.org/
== Series Details ==
Series: drm/i915: Only expand COND once in wait_for()
URL : https://patchwork.freedesktop.org/series/12403/
State : failure
== Summary ==
Series 12403v1 drm/i915: Only expand COND once in wait_for()
https://patchwork.freedesktop.org/api/1.0/series/12403/revisions/1/mbox/
Adding the ddb size into the devide info will avoid
platform checks while computing wm.
Suggested-by: Ander Conselvan de Oliveira
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 5 +
drivers/gpu/drm/i915/intel_pm.c | 13 +
From: Jim Bride
Add upfront link training to intel_dp_mst_mode_valid() so that we know
topology constraints before we validate the legality of modes to be
checked.
v3:
* Reset the upfront values but dont unset the EDID for MST. (Manasi)
v2:
* Rebased on new revision of link training patch. (Mana
These static helper functions are required to be used within upfront
link training related functions so they need to be placed at the top
of the file. It also changes macro dev to dev_priv.
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
Signed-off-by: Manasi Navare
---
According to the DisplayPort Spec, in case of Clock Recovery failure
the link training sequence should fall back to the lower link rate
followed by lower lane count until CR succeeds.
On CR success, the sequence proceeds with Channel EQ.
In case of Channel EQ failures, it should fallback to
lower l
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes. To address these sce
This patch series includes some of the remaining patches to enable
upfront link training on DDI platforms for DP SST and MST.
They are based on some of the patches submitted earlier by
Ander and Durgadoss.
The upfront link training had to be factored out of long pulse
hanlder because of deadlock i
While configuring the pipe during modeset, it should use
max clock and max lane count and reduce the bpp until
the requested mode rate is less than or equal to
available link BW.
This is required to pass DP Compliance.
v3:
* Add Debug print if requested mode cannot be supported
during modeset (Dhi
On Mon, Sep 12, 2016 at 06:14:00PM -0700, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-09-08 at 13:02 -0700, Manasi Navare wrote:
> > While configuring the pipe during modeset, it should use
> > max clock and max lane count and reduce the bpp until
> > the requested mode rate is less than or equal to
This should affect linear and X tiled planes on really small htotal
cases. It doesn't seem to be a very feasible case, but let's implement
it since it's on the specification and it's better to have it and
never need than not have it and realize we needed it.
Reviewed-by: Lyude
Signed-off-by: Paul
Bspec says:
"The mailbox response data may not account for memory read latency.
If the mailbox response data for level 0 is 0us, add 2 microseconds
to the result for each valid level."
This means we should only do the +2 in case wm[0] == 0, not always.
So split the sanitizing implementati
And use it to move knowledge about the SAGV-supporting platforms from
the callers to the SAGV code.
We'll add more platforms to intel_has_sagv(), so IMHO it makes more
sense to move all this to a single function instead of patching all
the callers every time we add SAGV support to a new platform.
We forgot the "res_blocks += y_tile_minimum" that's described on step
V of our documentation.
Again, this should only affect the Y tiling cases.
It looks like the relevant code was introduced in 0fda65680e92, but
there's always the possibility that it matched our specification when
it was introdu
The confusing thing is that plane_blocks_per_line is listed as part of
the method 2 calculation but is also used for other things. We
calculated it in two different places and different ways: one inside
skl_wm_method2() and the other inside skl_compute_plane_wm(). The
skl_wm_method2() implementatio
During watermarks calculations, this value is used in 3 different
places. Only one of them was not using a hardcoded 4. Move the code up
so everybody can benefit from the actual value.
This should only help on situations with Y tiling + 90/270 rotation +
1 or 2 bpp or NV12.
Signed-off-by: Paulo Z
Now that this code is part of the compute stage we can return -EINVAL
to prevent the modeset instead of giving a WARN and trying anyway.
Reported-by: Lyude
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
According to BSpec, it's the "core CPUs" that need the code, which
means SKL and KBL, but not BXT.
I don't have a KBL to test this patch on it.
v2: Only SKL should have I915_SAGV_NOT_CONTROLLED.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 14 ++
1 file changed
The plan is to introduce intel_has_sagv() and then use it to discover
which platforms actually support it.
I thought about keeping the functions with their current skl names,
but found two problems: (i) skl_has_sagv() would become a very
confusing name, and (ii) intel_atomic_commit_tail() doesn't
Hi
Here's the series with the reviews implemented. There's a new patch,
based on the additional issue spotted by Lyude.
Thanks for all the reviews,
Paulo
Paulo Zanoni (9):
drm/i915: SAGV is not SKL-only, so rename a few things
drm/i915: introduce intel_has_sagv()
drm/i915/kbl: KBL also nee
Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.
Removing the last conditional that handles invalid port because dvo_reg is
intialized to
This test creates an already expired fence, then creates a merged fence
out of that expired one (passed twice to the merge operation), and
finally closes the merged fence. It shows that if the refcounts are
wrong on the original expired fence, it might get freed while still in
use. Usually a kernel
The refcount of a fence should be increased whenever it is added to a merged
fence, since it will later be decreased when the merged fence is destroyed.
Failing to do so will cause the original fence to be freed if the merged fence
gets freed, but other places still referencing won't know about it.
Em Ter, 2016-09-13 às 20:40 +0100, Chris Wilson escreveu:
> I was looking at some wait_for() timeouts on a slow system, with lots
> of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing CO
Hi!
> I have
>
> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> Integrated Graphics Controller (rev 03)
>
> In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> in 10 resumes?) get in state where primary monitor (DVI) is dead (in
> powersave) and all w
Hi.
Am Dienstag, 13. September 2016, 22:23:50 CEST schrieb Pavel Machek:
> I have
>
> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> Integrated Graphics Controller (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation
Core Processor Family
Hi!
I have
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
in 10 resumes?) get in state where primary monitor (DVI) is dead (in
powersave) and all windows move to s
Em Qua, 2016-09-07 às 19:03 -0400, Lyude escreveu:
> On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> >
> > During watermarks calculations, this value is used in 3 different
> > places. Only one of them was not using a hardcoded 4. Move the code
> > up
> > so everybody can benefit from the
I was looking at some wait_for() timeouts on a slow system, with lots of
debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
mishandling the timeout, I tried to ensure that we loop at least once
after first testing COND. However, the double test of COND either side
of the timeout chec
Em Qua, 2016-09-07 às 12:17 -0400, Lyude escreveu:
> I'm not sure that kbl has this either. The kbl machine I've been
> working with thus-far has passed a few modesetting stress tests with
> the chameleon, and I don't have anything trying to control sagv stuff
> on it.
>
> This being said though t
On Mon, 2016-09-12 at 18:00 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> access and handles M
From: Robert Foss
This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 66 +
1 file changed, 66 insertions
From: Robert Foss
This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 139
1 file changed,
From: Robert Foss
This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 73
From: Robert Foss
Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 67 +
1 file changed, 67 insertions(+)
From: Robert Foss
Add initial tests for sw_sync.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
tests/Makefile.sources | 1 +
tests/sw_sync.c| 52 ++
2 files changed, 53 insertions(+)
create
From: Robert Foss
This subtest verifies that waiting on fences works properly.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 5a2c53e
From: Robert Foss
This subtest verifies the access ordering of multiple consumer threads.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c
From: Robert Foss
This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.
Signed-off-by: Robert Foss
Revie
From: Robert Foss
Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 16
1 file changed, 16 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
inde
From: Robert Foss
This subtest verifies merging a fence with itself does not fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_s
From: Robert Foss
This subtests tests that creating fences on negative timelines fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 8f6208b..0bc5026 100644
--- a/te
From: Robert Foss
This subtest verifies that merging two fences works in the simples possible
case.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 0
From: Robert Foss
Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
lib/
From: Robert Foss
This series implements the sw_sync test and the lib/sw_sync helper functions
for said test.
Gustavo Padovans sw_sync series was just de-staged in
gregkh-staging/staging-next [1], and this test is targeted at verifying the
functionality implemented in that series.
The sw_sync s
Looks good to me.
Reviewed-by: Dhinakaran Pandiyan
On Tue, 2016-09-13 at 10:38 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FB
Patch merged to dinq. Thanks for the patch.
On Mon, Sep 12, 2016 at 10:02 PM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Mon, Sep 12, 2016 at 6:04 PM, Manasi Navare
> wrote:
>> This adds support for KBL in the new function added in commit ID:
>> commit that returns a
>> shared pll
Patches 1 to 10 merged on dinq last week. Thanks for patches and
reviews and sorry for the delayed update.
On Wed, Sep 7, 2016 at 12:50 AM, Mika Kahola wrote:
> Reviewed-by: Mika Kahola
>
> On Fri, 2016-09-02 at 22:05 +0300, Pandiyan, Dhinakaran wrote:
>> On Fri, 2016-09-02 at 14:20 +0300, Mika
All patches reviewed and merged to dinq last week. Thanks for the
patches and sorry by the delayed update.
On Wed, Aug 17, 2016 at 12:30 PM, Carlos Santa wrote:
> - organize most GPU features so that they are easy to group by platforms.
>It seems some of the ground work was already done for
On 2016-09-13 07:03 AM, Chris Wilson wrote:
On Mon, Sep 12, 2016 at 06:08:30PM -0400, robert.f...@collabora.com wrote:
From: Robert Foss
Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destr
== Series Details ==
Series: drm/i915/fbc: disable FBC on FIFO underruns (rev4)
URL : https://patchwork.freedesktop.org/series/8575/
State : warning
== Summary ==
Series 8575v4 drm/i915/fbc: disable FBC on FIFO underruns
https://patchwork.freedesktop.org/api/1.0/series/8575/revisions/4/mbox/
On Sun, 11 Sep 2016, James Hogan wrote:
> I've just bisected a similar (same?) problem (slow increase and
> decrease of screen brightness with a period of a few seconds) to the
> same commit (this is on a Dell XPS 13 laptop)
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjä
On Tue, Sep 13, 2016 at 10:38:57AM -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black sc
Ever since I started working on FBC I was already aware that FBC can
really amplify the FIFO underrun symptoms. On systems where FIFO
underruns were harmless error messages, enabling FBC would cause the
underruns to give black screens.
We recently tried to enable FBC on Haswell and got reports of
Op 13-09-16 om 14:15 schreef Kumar, Mahesh:
> From: Mahesh Kumar
>
> This patch implements new DDB allocation algorithm as per HW team
> suggestion. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It
Op 07-09-16 om 02:52 schreef Paulo Zanoni:
> Bspec says:
> "The mailbox response data may not account for memory read latency.
>If the mailbox response data for level 0 is 0us, add 2 microseconds
>to the result for each valid level."
>
> This means we should only do the +2 in case wm[0] =
Mika Kuoppala writes:
> "Zanoni, Paulo R" writes:
>
>> Hi
>>
>> Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
>>> In the next patch we want to handle reset directly by a locked waiter
>>> in
>>> order to avoid issues with returning before the reset is handled. To
>>> handle the reset
From: Mahesh Kumar
This patch implements new DDB allocation algorithm as per HW team
suggestion. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
On Thu, 08 Sep 2016, Mika Kahola wrote:
> This compiler warning is fixed with the next patch of the series.
>
> drivers/gpu/drm/i915/intel_dp_link_training.c: In function
> ‘intel_dp_link_training_clock_recovery’:
> drivers/gpu/drm/i915/intel_dp_link_training.c:131:6: warning: unused
> variable ‘i
On ti, 2016-09-13 at 08:38 +0100, Chris Wilson wrote:
> On Mon, Sep 12, 2016 at 11:57:54PM +0300, Imre Deak wrote:
> > On Mon, 2016-09-12 at 21:04 +0100, Chris Wilson wrote:
> > > On Mon, Sep 12, 2016 at 05:47:57PM +0300, Imre Deak wrote:
> > > > Even in an otherwise quiescent system there may be u
On 13/09/16 11:31, Imre Deak wrote:
On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote:
On 12/09/16 15:09, Imre Deak wrote:
While user space has control over the scheduling priority of its
page
flipping thread, the corresponding work the driver schedules for
MMIO
flips always runs with nor
On Tue, Sep 13, 2016 at 10:49:50AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Ignore OpRegion panel type except on select machines
> URL : https://patchwork.freedesktop.org/series/12380/
> State : failure
>
> == Summary ==
>
> Series 12380v1 drm/i915: Ignore OpRegion
On Mon, Sep 12, 2016 at 06:08:30PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> Base functions to help testing the Sync File Framework (explicit fencing
> mechanism ported from Android).
> These functions allow you to create, use and destroy timelines and fences.
>
> Signed-of
"Zanoni, Paulo R" writes:
> Hi
>
> Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
>> In the next patch we want to handle reset directly by a locked waiter
>> in
>> order to avoid issues with returning before the reset is handled. To
>> handle the reset, we must first know whether we ho
== Series Details ==
Series: drm/i915: Ignore OpRegion panel type except on select machines
URL : https://patchwork.freedesktop.org/series/12380/
State : failure
== Summary ==
Series 12380v1 drm/i915: Ignore OpRegion panel type except on select machines
https://patchwork.freedesktop.org/api/1.
On ti, 2016-09-13 at 11:32 +0100, Chris Wilson wrote:
> On Tue, Sep 13, 2016 at 11:24:52AM +0100, Tvrtko Ursulin wrote:
> >
> > On 12/09/16 15:09, Imre Deak wrote:
> > > While user space has control over the scheduling priority of its
> > > page
> > > flipping thread, the corresponding work the dr
On Tue, Sep 13, 2016 at 11:24:52AM +0100, Tvrtko Ursulin wrote:
>
> On 12/09/16 15:09, Imre Deak wrote:
> >While user space has control over the scheduling priority of its page
> >flipping thread, the corresponding work the driver schedules for MMIO
> >flips always runs with normal scheduling prio
On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote:
> On 12/09/16 15:09, Imre Deak wrote:
> > While user space has control over the scheduling priority of its
> > page
> > flipping thread, the corresponding work the driver schedules for
> > MMIO
> > flips always runs with normal scheduling prio
On 12/09/16 15:09, Imre Deak wrote:
While user space has control over the scheduling priority of its page
flipping thread, the corresponding work the driver schedules for MMIO
flips always runs with normal scheduling priority. This would hinder an
application that wants more stringent guarantees
On Tue, Sep 13, 2016 at 12:51:05PM +0300, Jani Nikula wrote:
> On Mon, 12 Sep 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Decode the PSR block (9) from VBT. Looks like the same block ID may have
> > been used for something else in the past, so a version check is also
On Mon, 12 Sep 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Decode the PSR block (9) from VBT. Looks like the same block ID may have
> been used for something else in the past, so a version check is also
> needed.
>
> The wakeup times part is still up in the air due to the
On Tue, 13 Sep 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Turns out
> commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
> details") has regressed quite a few machines. So it looks like we
> can't use the panel type from OpRegion on all systems, and yet we
On Sun, 11 Sep 2016, Adrien Vergé wrote:
> On Terra Mobile Ultrabook 1450 II (Core i5-3337U, i915 devid = 0x166),
> the screen is tiled in many 480×320 screens (like a mosaic) since v4.7.
> This laptop is simply unusable.
>
> I have bisected the cause to commit a05628195a0d ("drm/i915: Get
> panel
From: Ville Syrjälä
Turns out
commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.
Despite trying, I
On Sat, 10 Sep 2016, Dave Gordon wrote:
> Thanks, the other things I was thinking of fixing in the remaining files
> were generally things like
>
>if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))
Is that a real or a made up example? IS_G33() would be redundant. But
I'd like to see the semantic p
Loading the module i915 on my IBM Thinkpad X40 fails in the function
intel_dvo_init(). The function tries to cleanup the struct drm_encoder
that was never initialized. This happens when all intel_dvo_devices
failed to be probed in the for loop. The backtrace was:
BUG: unable to handle kernel N
On Thu, 08 Sep 2016, Jani Nikula wrote:
> On Thu, 08 Sep 2016, Ville Syrjälä wrote:
>> On Wed, Sep 07, 2016 at 05:42:31PM -0700, Rodrigo Vivi wrote:
>>> This reverts commit 1c80c25fb622973dd135878e98d172be20859049.
>>>
>>> There are panels that needs 4 idle frames before entering PSR,
>>> but VB
1 - 100 of 102 matches
Mail list logo