On Thu, Apr 21, 2016 at 09:48:36AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > The code to switch_mm() is already handled by i915_switch_context(), the
> > only difference required to setup the aliasing ppgtt is that we need to
> > emit te switch_mm() o
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> There is a construct in the linux kernel called 'struct fence' that is
> intended to keep track of work that is executed on hardware. I.e. it
> solves the basic problem that the drivers 'struct
> drm_i915_gem_request
On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> As the contexts are accessed by the hardware until the switch is completed
> to a new context, the hardware may still be writing to the context object
> after the breadcrumb is visible. We must not unpin/unbind/prune that
> object whilst still
On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > + if (!request->ctx->engine[engine->id].initialised) {
> > + ret = engine->init_context(request);
> > + if (ret) {
> > + intel_lr_cont
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
>
> +/* if (!lazy_coherency && req->engine->irq_seqno_barrier)
> + req->engine->irq_seqno_barrier(req->engine);*/
>
Why keep this hunk in i915_gem_request_is_completed?
___
Intel-gfx
On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> Similarly to i915_gem_object_pin_map on LLC platforms, we can
> use the new VMA based io mapping on !LLC to amoritize the cost
> of ringbuffer pinning and unpinning.
>
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Chris Wilson
> Cc: Tvrt
Typo in subject (redundant). ^
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> The change to the implementation of i915_gem_request_completed() means
> that the lazy coherency flag is no longer used. This can now be
> removed to simplify the interface.
>
> v6: Up
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> If an execbuff IOCTL call fails for some reason, it would leave the
> request in the client list. The request clean up code would remove
> this but only later on and only after the reference count has dropped
> to ze
On Thu, Apr 21, 2016 at 10:07:50AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > As the contexts are accessed by the hardware until the switch is completed
> > to a new context, the hardware may still be writing to the context object
> > after the breadcr
On Thu, Apr 21, 2016 at 08:01:37AM +0100, Chris Wilson wrote:
> Oh, this piece of code is earmarked to be removed and now I even have a
> bugzilla for it!
>
> https://bugs.freedesktop.org/show_bug.cgi?id=95023
> is an example where we are doing the wrong thing with the current
> i915_gem_init_seqn
On Wed, Apr 20, 2016 at 11:27:27PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > > Reason I ask is since I noticed a while ago a lot of drivers
> > > were using info->fix.sm
On to, 2016-04-21 at 08:01 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 09:48:36AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > The code to switch_mm() is already handled by i915_switch_context(), the
> > > only difference require
On to, 2016-04-21 at 08:22 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 10:07:50AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > As the contexts are accessed by the hardware until the switch is completed
> > > to a new context, the
Hi Dave, fixes all around, all but one are cc: stable material, the most
important ones are likely the Skylake hang fixes from Mika.
BR,
Jani.
The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
are available in the git repo
On 4/21/2016 12:24 PM, Chris Wilson wrote:
On Thu, Apr 21, 2016 at 12:33:40PM +0530, akash.g...@intel.com wrote:
From: Akash Goel
There are certain registers, which captures the time elapsed in the
in current Up/Down EI, for how long GT has been Idle/Busy/Avg in the
current Up/Down EI and al
On Thu, Apr 21, 2016 at 12:33:41PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> As a part of WaGsvDisableTurbo, Driver makes an early exit from the
> Gen9 Turbo enabling function, so doesn't program the Turbo Control register.
> But BIOS could leave the Hw Turbo as enabled, so need t
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> The intended usage model for struct fence is that the signalled status
> should be set on demand rather than polled. That is, there should not
> be a need for a 'signaled' function to be called everytime the status
>
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> The request structure is reference counted. When the count reached
> zero, the request was immediately freed and all associated objects
> were unrefereced/unallocated. This meant that the driver mutex lock
> must be
== Series Details ==
Series: Enable Gen 7 Observation Architecture (rev3)
URL : https://patchwork.freedesktop.org/series/3024/
State : success
== Summary ==
Series 3024v3 Enable Gen 7 Observation Architecture
http://patchwork.freedesktop.org/api/1.0/series/3024/revisions/3/mbox/
bdw-nuci7
On to, 2016-04-21 at 08:08 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > + if (!request->ctx->engine[engine->id].initialised) {
> > > + ret = engine->init_context(requ
Fi CI has ran with this patch approx 2 weeks at January.
All platforms acted the same with or without patch.
Tomi
On Wednesday 20 April 2016 20:49:56 Marius Vlad wrote:
> Signed-off-by: Marius Vlad
> ---
> lib/igt_aux.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff
On Thu, Apr 21, 2016 at 10:47:30AM +0300, Joonas Lahtinen wrote:
> On to, 2016-04-21 at 08:08 +0100, Chris Wilson wrote:
> > On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote:
> > >
> > > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > > >
> > > > + if (!request->ctx
On 20/04/16 19:42, Chris Wilson wrote:
From: Tvrtko Ursulin
This way in the following patch we can disconnect requests
from contexts.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Surely I didn't review my own patch? :)
Regards,
Tvrtko
Signed-off-by: Chris Wilson
---
dr
On ke, 2016-04-20 at 14:30 +0100, Dave Gordon wrote:
> The recently-added i915_gem_object_pin_map() can be further optimised
> for "small" objects. To facilitate this, and simplify the error paths
> before adding the new code, this patch pulls out the "mapping" part of
> the operation (involving lo
On Tue, Apr 19, 2016 at 01:00:36PM +0300, Imre Deak wrote:
> In commit 5f304c873634 ("drm/i915/kbl: Reset secondary power well requests
> left on by DMC/KVMR") I forgot about the fact that SKL==KBL most of the
> time and that a secondary MISC IO power well request left on by the DMC is
> "expected"
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, April 20, 2016 7:48 PM
> To: Ville Syrjälä
> Cc: Gore, Tim; Daniel Vetter; Thierry, Michel; intel-gfx@li
On 4/21/2016 1:07 PM, Chris Wilson wrote:
On Thu, Apr 21, 2016 at 12:33:41PM +0530, akash.g...@intel.com wrote:
From: Akash Goel
As a part of WaGsvDisableTurbo, Driver makes an early exit from the
Gen9 Turbo enabling function, so doesn't program the Turbo Control register.
But BIOS could lea
On 04/21/2016 06:44 AM, cac...@quantum-sci.com wrote:
>
> No one will just come out and just tell us the truth, so that users can quit
> wasting our time trying to make your Xen work. Your 4.2 kernel dumps core on
> i915, and Xen hangs on disk drive ID.
>
> Why don't you just take down the Xen
On to, 2016-04-21 at 08:56 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 10:47:30AM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-04-21 at 08:08 +0100, Chris Wilson wrote:
> > >
> > > On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote:
> > > >
> > > >
> > > > On ke, 2016
Replying for automated test request must be done only when we
are ready for the request. This patch extracts this reply to
separate function as it is needed in other places in the
upcoming patches.
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i91
IRQ bits are set by panel in DPCD 0x201 to perform various requests.
Current code clears all bits in one go and then handles them, but
this is not proper since some scenarios require full detection and
if we clear such bits the test request may not be detected in the
later part.
It is always good
This patch adds support for automated test requests during
short pulse handling in gen platforms.
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i915/intel_dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/driver
Automated test request will wait for ack or nak before proceeding.
Acknowledging them ahead of time is not always good especially for
link training related requests. Scenarios where we need to do
full detection it is likely that the new detect might not read the
automated request since we have alre
During automated test request for link training we are supposed to
read the TEST_LANE_COUNT and TEST_LINK_RATE dpcd registers and use
respective values in the next link training. This patch adds
reading and updating of these values.
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Sh
On Thu, Apr 21, 2016 at 04:31:42PM +0800, Jike Song wrote:
> On 04/21/2016 06:44 AM, cac...@quantum-sci.com wrote:
> >
> > No one will just come out and just tell us the truth, so that users can
> > quit wasting our time trying to make your Xen work. Your 4.2 kernel dumps
> > core on i915, and
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: Yishai
In a couple of places, we have an i915_address_space that we know is
really an i915_ggtt that we want to use. Create an inline helper to
convert from the i915_address_space subclass into its container.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtin
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
In order to force a reload of the context image upon resume, we first
need to mark its absence on suspend. Currently we are failing to restore
the golden context state and any context w/a to the default context
after resume.
One oversight corrected, is that we had forgotten to reapply the L3
remap
When setting up the overlay page, we pin it into the GGTT (when using
virtual addresses) and store the offset as overlay->flip_addr. Rather
than doing a lookup of the GGTT address everytime, we can use the known
address instead.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
The code to switch_mm() is already handled by i915_switch_context(), the
only difference required to setup the aliasing ppgtt is that we need to
emit te switch_mm() on the first context, i.e. when transitioning from
engine->last_context == NULL. This allows us to defer the
initialisation of the GPU
Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to amoritize the cost
of ringbuffer pinning and unpinning.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/
Move the i915_gem_l3_remap function such that it next to the context
switching, which is where we perform the L3 remap.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 31 ---
drivers/gpu/drm/i
Since we do the l3-remap on context switch, we can remove the redundant
early call to set the mapping prior to performing the first context
switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i91
We can use a single MI_LOAD_REGISTER_IMM command packet to write all the
L3 remapping registers, shrinking the number of bytes required to emit
the context switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++
Rather than reuse the current location of the context in the global GTT
for its hardware identifier, use the context's unique ID assigned to it
for its whole lifetime.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
drivers/gpu/
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assign pagefaults and the like to a particular context.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_de
Instead of allocating a new request when allocating a context, use the
request that initiated the allocation to emit the context
initialisation. This serves two purposes, it makes the initialisation
atomic with first use (simplifying scheduling and our own error
handling). Secondly, it enables us t
We can hide more details of execlists from higher level code by removing
the explicit call to create an execlist context from execbuffer and
into its first use by execlists.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8
dri
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the context handles the reference counting).
Thus we can eliminate the special case handling of the default context
that was required to m
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM requ
From: Tvrtko Ursulin
With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.
This is because the above now
From: Tvrtko Ursulin
This way in the following patch we can disconnect requests
from contexts.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
2 files changed, 4 inser
On Thu, Apr 21, 2016 at 08:58:20AM +0100, Tvrtko Ursulin wrote:
>
> On 20/04/16 19:42, Chris Wilson wrote:
> >From: Tvrtko Ursulin
> >
> >This way in the following patch we can disconnect requests
> >from contexts.
> >
> >Signed-off-by: Tvrtko Ursulin
> >Reviewed-by: Tvrtko Ursulin
>
> Surely
As the contexts are accessed by the hardware until the switch is completed
to a new context, the hardware may still be writing to the context object
after the breadcrumb is visible. We must not unpin/unbind/prune that
object whilst still active and so we keep the previous context pinned until
the f
On Wed, Apr 20, 2016 at 07:47:56PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 09:31:57PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 20, 2016 at 07:19:32PM +0100, Chris Wilson wrote:
> > > On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> > > >
> > > > Tim Gore
> > > > Intel
On Thu, Apr 21, 2016 at 08:19:46AM +, Gore, Tim wrote:
>
>
> Tim Gore
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
>
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Wednesday, April 20, 2016 7:48 PM
> >
On Wed, Apr 20, 2016 at 10:59:48AM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> Previously crtc0 was statically used for VBLANK tests, but
> that assumption is not valid for the VC4 platform.
> Instead we're now explicitly setting the mode.
>
> Also add support for testing all
On Wed, Apr 20, 2016 at 10:59:49AM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> Change DRIVER_INTEL to DRIVER_ANY to enable tests/kms_flip_event_leak
> on any driver.
> Switch the tiling format to something intel indenpendant.
>
> Signed-off-by: Robert Foss
I thought we need
On Wed, Apr 20, 2016 at 12:25:50PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss
>
> This series enables tests/core_getversion to test vc4.
> It's been tested on rpi2 hardware and kernel 4.6.0-rc1.
Ack on both from my side.
-Daniel
>
> Changes since v1:
> - Improved commit messag
On Wed, Apr 20, 2016 at 08:49:57PM +0300, Marius Vlad wrote:
> basic-flip-vs-dpms and basic-flip-vs-modeset together take roughly 2m
> to run. Adjust the duration time to a maximum of 500ms.
Can we have a notch more please? Ime it takes generally a few modesets for
this thing to fall over (2-3 mod
Hi Dave,
drm-intel-next-2016-04-11:
- make modeset hw state checker atomic aware (Maarten)
- close races in gpu stuck detection/seqno reading (Chris)
- tons&tons of small improvements from Chris Wilson all over the gem code
- more dsi/bxt work from Ramalingam&Jani
- macro polish from Joonas
- guc
Hi Dave,
struct_mutex cleanups and error paths fixes. Unfortunately I didn't manage
to get acks from everyone, but this stuff has been hanging out for months
now and imo simple enough to just land the remaining few patches. But
separate pull request so that you can take a look yourself.
Cheers, D
Hi Dave,
misc pull req all over. Biggest thing is the
drm_connector_(un)register_all cleanup from Alexey for drivers without the
load/unload midlayer hooks. I.e. all the new ones, and a bunch of the
pending new atomic drivers depend upon this. Or at least I asked them to
rebase ;-)
For 4.7 I'd li
== Series Details ==
Series: GPU scheduler for i915 driver (rev2)
URL : https://patchwork.freedesktop.org/series/3585/
State : success
== Summary ==
Series 3585v2 GPU scheduler for i915 driver
http://patchwork.freedesktop.org/api/1.0/series/3585/revisions/2/mbox/
bdw-ultratotal:194
On 20 April 2016 at 16:59, wrote:
> From: Robert Foss
>
> Fix issue where the plane counting fails due to the number and
> configuration of planes being unlike the intel configuration.
>
> Signed-off-by: Robert Foss
> ---
> lib/igt_kms.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletio
On 12/04/16 16:18, Chris Wilson wrote:
On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote:
When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
with a plain i915_gem_object_pin_map(). This raised
On Thu, Apr 21, 2016 at 10:21:59AM +0530, Shashank Sharma wrote:
> This patch does the following:
> - Fakes live status of HDMI as connected (even if that's not).
> While testing certain (monitor + cable) combinations with
> various intel platforms, it seems that live status register
> doesn
Grr, both of them take 2minutes, 1 minute each. What I meant was 30s
each. Got distracted a little bit, that the duration is adjusted to ms
further down the call.
On Thu, Apr 21, 2016 at 11:23:26AM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 08:49:57PM +0300, Marius Vlad wrote:
> > basic
On Thu, Apr 21, 2016 at 08:56:09AM +0200, Tomeu Vizoso wrote:
> On 20 April 2016 at 20:16, wrote:
> > From: Ville Syrjälä
> >
> > create_bo_for_fb() expects the drm format as a parameter since
> > commit 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
> > but not all callers were updated
On 21/04/2016 08:20, Maarten Lankhorst wrote:
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
From: John Harrison
If an execbuff IOCTL call fails for some reason, it would leave the
request in the client list. The request clean up code would remove
this but only later on and only after
On 21/04/2016 08:19, Maarten Lankhorst wrote:
Typo in subject (redundant). ^
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
From: John Harrison
The change to the implementation of i915_gem_request_completed() means
that the lazy coherency flag is no longer used. This can now be
remov
On 21/04/2016 08:06, Maarten Lankhorst wrote:
Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that th
== Series Details ==
Series: drm/i915/bxt: Fixes for runtime and system suspend/resume
URL : https://patchwork.freedesktop.org/series/6009/
State : success
== Summary ==
Series 6009v1 drm/i915/bxt: Fixes for runtime and system suspend/resume
http://patchwork.freedesktop.org/api/1.0/series/6009
On 20 April 2016 at 16:59, wrote:
> From: Robert Foss
>
> Avoid overwriting planes with statically asigned indices
> with planes that have dynamically assigned indices.
>
> Signed-off-by: Robert Foss
> ---
> lib/igt_kms.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/igt_kms.c
On Thu, 21 Apr 2016, Shashank Sharma wrote:
> This patch does the following:
> - Fakes live status of HDMI as connected (even if that's not).
> While testing certain (monitor + cable) combinations with
> various intel platforms, it seems that live status register
> doesn't work reliably on
== Series Details ==
Series: drm/i915/bxt: Fix PHY init with partial BIOS config
URL : https://patchwork.freedesktop.org/series/6010/
State : success
== Summary ==
Series 6010v1 drm/i915/bxt: Fix PHY init with partial BIOS config
http://patchwork.freedesktop.org/api/1.0/series/6010/revisions/1
On 20 April 2016 at 16:59, wrote:
> From: Robert Foss
>
> Avoid moving the cursor plane when on non-intel hardware.
> Running the move block on hardware with more than IGT_PLANE_CURSOR
> number of planes causes planes do be zeroed out.
>
> Signed-off-by: Robert Foss
> ---
> lib/igt_kms.c | 2 +
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
While testing certain (monitor + cable) combinations with
various intel platforms, it seems that live status register
doesn't work reliably on some older devices. So limit the
live_status check fo
Op 21-04-16 om 12:26 schreef John Harrison:
> On 21/04/2016 08:06, Maarten Lankhorst wrote:
>> Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
>>> From: John Harrison
>>>
>>> There is a construct in the linux kernel called 'struct fence' that is
>>> intended to keep track of work that is e
From: Tim Gore
This patch applies a performance enhancement workaround
based on analysis of DX and OCL S-Curve workloads. We
increase the General Priority Credits for L3SQ from the
hardware default of 56 to the max value 62, and decrease
the High Priority credits from 8 to 2.
v2: Only apply to B
== Series Details ==
Series: series starting with [01/19] drm/i915/overlay: Replace
i915_gem_obj_ggtt_offset() with the known flip_addr
URL : https://patchwork.freedesktop.org/series/6017/
State : success
== Summary ==
Series 6017v1 Series without cover letter
http://patchwork.freedesktop.org
On 4/21/2016 12:23 PM, tim.g...@intel.com wrote:
From: Tim Gore
This patch applies a performance enhancement workaround
based on analysis of DX and OCL S-Curve workloads. We
increase the General Priority Credits for L3SQ from the
hardware default of 56 to the max value 62, and decrease
the High
On 20/04/2016 18:44, Chris Wilson wrote:
On Wed, Apr 20, 2016 at 06:09:50PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The fence object used inside the request structure requires a sequence
number. Although this is not used by the i915 driver itself, it could
potentially be us
Op 20-04-16 om 04:26 schreef Matt Roper:
> This will eventually allow us to re-use old values without
> re-calculating them for unchanged planes (which also helps us avoid
> re-grabbing extra plane states).
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_drv.h | 4
> drivers
From: Tvrtko Ursulin
Only caller is i915_gem_obj_ggtt_size which only cares about
GGTT so simplify it and implement under that name.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++--
drivers/gpu/drm/i915/i915_gem.c | 13 -
2 files changed, 6 inser
== Series Details ==
Series: drm/i915/bxt: Fixes for runtime and system suspend/resume
URL : https://patchwork.freedesktop.org/series/6009/
State : failure
== Summary ==
Series 6009v1 drm/i915/bxt: Fixes for runtime and system suspend/resume
http://patchwork.freedesktop.org/api/1.0/series/6009
== Series Details ==
Series: drm/i915/bxt: Fix PHY init with partial BIOS config
URL : https://patchwork.freedesktop.org/series/6010/
State : failure
== Summary ==
Series 6010v1 drm/i915/bxt: Fix PHY init with partial BIOS config
http://patchwork.freedesktop.org/api/1.0/series/6010/revisions/1
From: Tvrtko Ursulin
Can use the new vma->is_ggtt to simplify the check and
remove the local variables.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i9
From: Tvrtko Ursulin
Can use vma->is_ggtt to simplify the check and also switch the
BUG_ON to GEM_BUG_ON which is more appropriate for this.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu
From: Tvrtko Ursulin
Can use the new vma->is_gtt to simplify the check and
get rid of the local variables.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/
== Series Details ==
Series: series starting with [01/19] drm/i915/overlay: Replace
i915_gem_obj_ggtt_offset() with the known flip_addr
URL : https://patchwork.freedesktop.org/series/6017/
State : failure
== Summary ==
Series 6017v1 Series without cover letter
http://patchwork.freedesktop.org
From: Tvrtko Ursulin
Using four bits for the pin count in the middle of the data
structure just makes the compiler generate verbose code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
From: Tvrtko Ursulin
This allows trivial (non-iterating) i915_gem_obj_is_pinned
implementation which in turns prevents i915_gem_madvise_ioctl
showing up in profiles in benchmarks like SynMark2/OglDrvCtx.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 9
From: Tvrtko Ursulin
i915_gem_obj_to_vma is one of the most expensive functions in
our profiles. Could avoiding some branching by replacing it
with arithmetic be beneficial? Some benchmarks suggest it
slightly might.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 14 ++
On Wed, Apr 20, 2016 at 08:46:05PM +0300, Imre Deak wrote:
> If we skipped PHY0 initialization because it was already enabled by
> BIOS, we still have to wait for the PHY1 GRC calibration as that is
> done as part of the PHY0 init.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_
Hey,
Op 20-04-16 om 04:26 schreef Matt Roper:
> We eventually want to calculate watermark values at atomic 'check' time
> instead of atomic 'commit' time so that any requested configurations
> that result in impossible watermark requirements are properly rejected.
> The first step along this path
On Wed, Apr 20, 2016 at 08:46:06PM +0300, Imre Deak wrote:
> It's possible that BIOS enables PHY0, but it programmes only the first
> channel on it. Since we program the PHYs only during driver loading this
> is an incorrect configuration from the driver's point of view, since we
> may use both cha
On Thu, Apr 21, 2016 at 04:48:32PM +0530, Shashank Sharma wrote:
> This patch does the following:
> - Fakes live status of HDMI as connected (even if that's not).
> While testing certain (monitor + cable) combinations with
> various intel platforms, it seems that live status register
> doesn
On Thu, Apr 21, 2016 at 01:05:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This allows trivial (non-iterating) i915_gem_obj_is_pinned
> implementation which in turns prevents i915_gem_madvise_ioctl
> showing up in profiles in benchmarks like SynMark2/OglDrvCtx.
madvise doesn't ne
1 - 100 of 218 matches
Mail list logo
