On 10/23/2015 3:11 PM, Patrik Jakobsson wrote:
The current CSR loading code depends on the CSR program memory to be
cleared after boot. This is unfortunately not true on all hardware.
Instead make use of the FW_UNINITIALIZED state in init and check for
FW_LOADED to prevent init path from skippi
On Fri, 23 Oct 2015 13:35:21 +0200
Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 09:51:06AM +0100, Tvrtko Ursulin wrote:
> >
> > Hi,
> >
> > On 23/10/15 02:34, Vivek Kasireddy wrote:
> > >The main goal of this subtest is to trigger the following warning
> > >in the function i915_gem_object_get
On 21/10/15 19:27, yu@intel.com wrote:
From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that gem_request (so
the LRC associated with it) is freed early than moving the vma list
to inactive.
We are not seeing thi
On 08/10/15 21:50, Wayne Boyer wrote:
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied
On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
> (I have not looked for any pattern such
> as modifying PTE within the same page or cacheline as active PTE -
> though checking whether revoking neighbouring objects should be enough
> to test that theory.)
So, fwiw, I revoked the CPU
On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Do a dry run with rtcwake first to determine if the system even supports
> the intended suspend state. If not, skip the test.
>
> Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3.
>
> Signed-off
On Fri, Oct 23, 2015 at 08:08:34PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 09:41:29PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 23, 2015 at 07:29:08PM +0100, Chris Wilson wrote:
> > > On Fri, Oct 23, 2015 at 09:22:38PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 23, 2015 at 06:56
On Fri, Oct 23, 2015 at 2:28 AM, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 10:04:24AM +0200, Daniel Vetter wrote:
>> On Thu, Oct 22, 2015 at 04:23:09PM -0700, Kristian Høgsberg wrote:
>> > On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson
>> > wrote:
>> > > Pinning a userptr onto the hardware ra
On Fri, Oct 23, 2015 at 09:41:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 23, 2015 at 07:29:08PM +0100, Chris Wilson wrote:
> > On Fri, Oct 23, 2015 at 09:22:38PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 23, 2015 at 06:56:41PM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 23, 2015 at 08:50
On Fri, Oct 23, 2015 at 07:29:08PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 09:22:38PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 23, 2015 at 06:56:41PM +0100, Chris Wilson wrote:
> > > On Fri, Oct 23, 2015 at 08:50:42PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 23, 2015 at 06:43
WW43 Regression report.
There was no new reported regressions this week.
+---+---+++
| BugId | Summary | Created on | Bisect |
+---+---+---
On Fri, Oct 23, 2015 at 09:22:38PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 23, 2015 at 06:56:41PM +0100, Chris Wilson wrote:
> > On Fri, Oct 23, 2015 at 08:50:42PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 23, 2015 at 06:43:31PM +0100, Chris Wilson wrote:
> > > > As the HWS is mapped into the
On Fri, Oct 23, 2015 at 06:56:41PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 08:50:42PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 23, 2015 at 06:43:31PM +0100, Chris Wilson wrote:
> > > As the HWS is mapped into the GPU as uncached,
> >
> > Since when?
>
> Since it is embedded into e
On Fri, Oct 23, 2015 at 08:50:42PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 23, 2015 at 06:43:31PM +0100, Chris Wilson wrote:
> > As the HWS is mapped into the GPU as uncached,
>
> Since when?
Since it is embedded into execlists' default context which is allocated
using the system default cache
On Fri, Oct 23, 2015 at 06:43:31PM +0100, Chris Wilson wrote:
> As the HWS is mapped into the GPU as uncached,
Since when?
> writes into that page do
> not automatically snoop the CPU cache and therefore if we want to see
> coherent values we need to clear the stale cacheline first. Note, we
> al
When accessing through the GTT from one CPU whilst concurrently updating
the GGTT PTEs in another thread, the hardware likes to return random
data. As we have strong serialisation prevent us from modifying the PTE
of an active GTT mmapping, we have to conclude that it whilst modifying
other PTE's t
As the HWS is mapped into the GPU as uncached, writes into that page do
not automatically snoop the CPU cache and therefore if we want to see
coherent values we need to clear the stale cacheline first. Note, we
already had a workaround for BXT-A for an identical issue, but since we
never enabled sn
When clearing an execlist queue, instead of traversing it and unreferencing all
requests while holding the spinlock (which might lead to thread sleeping with
IRQs are turned off - bad news!), just move all requests to the retire request
list while holding spinlock and then drop spinlock and invoke
On Mon, Sep 21, 2015 at 11:41:18PM +0530, Kumar, Mahesh wrote:
> In case of Y-Tiling, "plane_blocks_per_line" calculation is different
> than X/None-Tiling case.
> This patch corrects this calculation according to Bspec.
> plane blocks per line = Plane memory format is Y tile ?
> ceil
From: "Kumar, Mahesh"
If ddb allocation for planes in current CRTC is changed, that doesn't
lead to ddb allocation change for other CRTCs, because our DDB allocation
is not dynamic according to plane parameters, ddb is allocated according
to number of CRTC enabled, & divided equally among CTRC's.
On Fri, Oct 23, 2015 at 04:42:19PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 3:33 PM, Ville Syrjälä
> wrote:
> > On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
> >> On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> >> > On Fri, 23 Oct 2015, Chris Wilson wr
On Fri, Oct 23, 2015 at 04:24:25PM +0200, Robert Fekete wrote:
> Extends i915_display_info so that for each active crtc also print
> all planes associated with the pipe. This patch shows information
> about each plane wrt format, size, position, rotation, and scaling.
> This is very useful when deb
On 23 October 2015 at 12:42, David Weinehall
wrote:
> Some tests should not be run by default, due to their slow,
> and sometimes superfluous, nature.
>
> We still want to be able to run these tests though in some cases.
> Until now there's been no unified way of handling this. Remedy
> this by in
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Tomas Elf
> Sent: Friday, October 23, 2015 2:09 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH v3 7/8] drm/i915: Grab execlist spinlock to avoid
> post-reset concur
On Fri, Oct 23, 2015 at 3:33 PM, Ville Syrjälä
wrote:
> On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
>> On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
>> > On Fri, 23 Oct 2015, Chris Wilson wrote:
>> > > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote
gem_concurrent_all is misspelled in the subject.
On 23 October 2015 at 12:42, David Weinehall
wrote:
> We'll both rename gem_concurrent_all over gem_concurrent_blit
> and change gem_concurrent_blit in this changeset. To make
> this easier to follow we first do the the rename.
Please add a Signed
On Fri, Oct 23, 2015 at 04:24:25PM +0200, Robert Fekete wrote:
> +static const char *plane_rotation(unsigned int rotation)
> +{
> + switch (rotation) {
> + case DRM_ROTATE_0:
> + return "0";
> + case DRM_ROTATE_90:
> + return "90";
> + case DRM_ROTATE_180:
>
Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a
On 23/10/15 10:14, Daniel Vetter wrote:
On Fri, Oct 23, 2015 at 10:03:50AM +0100, Chris Wilson wrote:
On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR agreeing. No idea what's going on th
On Fri, Oct 23, 2015 at 02:55:38PM +0100, Thomas Daniel wrote:
> A typo resulted in the watermarks for cursor planes not being calculated
> correctly. Fixed the typo.
>
> Cc: Ville Syrjälä
> Signed-off-by: Thomas Daniel
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insert
A typo resulted in the watermarks for cursor planes not being calculated
correctly. Fixed the typo.
Cc: Ville Syrjälä
Signed-off-by: Thomas Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/g
2015-10-23 9:42 GMT-02:00 David Weinehall :
> Some tests should not be run by default, due to their slow,
> and sometimes superfluous, nature.
>
> We still want to be able to run these tests though in some cases.
> Until now there's been no unified way of handling this. Remedy
> this by introducing
On Fri, Oct 23, 2015 at 02:40:31PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 04:33:52PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> > > > On Fri, 23 Oct 2015, Chris Wil
On Fri, Oct 23, 2015 at 04:33:52PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> > > On Fri, 23 Oct 2015, Chris Wilson wrote:
> > > > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel V
On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> > On Fri, 23 Oct 2015, Chris Wilson wrote:
> > > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
> > >> We get tons of cases where the master interrupt han
On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> +static void i915_gem_context_clean(struct intel_context *ctx)
> +{
> + struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
> + struct i915_vma *vma, *next;
> +
> + if (WARN_ON_ONCE(!ppgtt))
> + return;
> +
> + WARN
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.
* v2 (Chris Wilson):
Do execlist check and use simpler form of spinlock functions.
* v3 (Tvrtko Ursul
On 23/10/15 12:02, Tomas Elf wrote:
On 23/10/2015 09:59, Daniel Vetter wrote:
On Fri, Oct 23, 2015 at 09:42:27AM +0100, Tvrtko Ursulin wrote:
On 19/10/15 16:32, Tomas Elf wrote:
Grab execlist lock when cleaning up execlist queues after GPU reset
to avoid
concurrency problems between the conte
On Fri, Oct 23, 2015 at 12:58:45PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 02:42:33PM +0300, David Weinehall wrote:
> > Until now we've had no unified way to handle slow/combinatorial tests.
> > Most of the time we don't want to run slow/combinatorial tests, so this
> > should remain t
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Wednesday, October 21, 2015 9:08 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFCv2 DP-typeC 5/6] drm/i915/dp: Enable Upfront link
>training for typeC DP
>support
On Fri, Oct 23, 2015 at 02:42:33PM +0300, David Weinehall wrote:
> Until now we've had no unified way to handle slow/combinatorial tests.
> Most of the time we don't want to run slow/combinatorial tests, so this
> should remain the default, but when we do want to run such tests,
> it has been handl
On Fri, Oct 23, 2015 at 02:42:35PM +0300, David Weinehall wrote:
> Some tests should not be run by default, due to their slow,
> and sometimes superfluous, nature.
>
> We still want to be able to run these tests though in some cases.
> Until now there's been no unified way of handling this. Remedy
Chris Wilson writes:
> On Fri, Oct 23, 2015 at 02:07:35PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > Having flushed all requests from all queues, we know that all
>> > ringbuffers must now be empty. However, since we do not reclaim
>> > all space when retiring the request (to p
With the addition of unified command-line handling for
slow/combinatorial tests we no longer need the
gem_concurrent_blit/gem_concurrent_all magic. Delete the latter,
since the former has a more descriptive file name.
---
tests/Makefile.sources |1 -
tests/gem_concurrent_all.c | 1108 -
Until now we've had no unified way to handle slow/combinatorial tests.
Most of the time we don't want to run slow/combinatorial tests, so this
should remain the default, but when we do want to run such tests,
it has been handled differently in different tests.
This patch adds a --with-slow-combina
Some tests should not be run by default, due to their slow,
and sometimes superfluous, nature.
We still want to be able to run these tests though in some cases.
Until now there's been no unified way of handling this. Remedy
this by introducing the --with-slow-combinatorial option to
igt_core, and
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
---
tests/gem_concurrent_blit.c | 1116 ++-
1 file changed, 1108 insertions(+), 8 deleti
On Fri, 23 Oct 2015, Daniel Vetter wrote:
> Another CI fail we have for no reason. Totally unjustified since
> nothing fails at all.
Acked-by: Jani Nikula
I guess we could do the blind set here as well, but *shrug*.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_opregi
On Fri, Oct 23, 2015 at 09:51:06AM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 23/10/15 02:34, Vivek Kasireddy wrote:
> >The main goal of this subtest is to trigger the following warning in
> >the function i915_gem_object_get_fence():
> > if (WARN_ON(!obj->map_and_fenceable))
> >
> >To trigge
On Fri, Oct 23, 2015 at 01:56:40PM +0300, Mika Kuoppala wrote:
> Daniel Vetter writes:
>
> > DRM_ERROR an continue without any issues aren't allowed since that
> > causes noise in the CI system. But we absolutely want to have the
> > DRM_ERROR when we want to run with GuC.
> >
> > For simplicity
Not sure why all my CCs disappeared...
Animesh, is it true that CSR_PROGRAM(0) is cleared on bxt when no program is
loaded? This is not the case on skl. If it's not true on bxt either we can just
skip check CSR_PROGRAM(0) altogether.
Thanks
Patrik
On Fri, Oct 23, 2015 at 11:41:50AM +0200, Patrik
On Fri, Oct 23, 2015 at 02:07:35PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Having flushed all requests from all queues, we know that all
> > ringbuffers must now be empty. However, since we do not reclaim
> > all space when retiring the request (to prevent HEADs colliding
> > wit
Chris Wilson writes:
> Having flushed all requests from all queues, we know that all
> ringbuffers must now be empty. However, since we do not reclaim
> all space when retiring the request (to prevent HEADs colliding
> with rapid ringbuffer wraparound) the amount of available space
> on each ring
On 23/10/2015 09:59, Daniel Vetter wrote:
On Fri, Oct 23, 2015 at 09:42:27AM +0100, Tvrtko Ursulin wrote:
On 19/10/15 16:32, Tomas Elf wrote:
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the re
Daniel Vetter writes:
> DRM_ERROR an continue without any issues aren't allowed since that
> causes noise in the CI system. But we absolutely want to have the
> DRM_ERROR when we want to run with GuC.
>
> For simplicity just short-circuit all the loader code when it's not
> needed.
>
> v2: Mika&C
On Fri, Oct 23, 2015 at 01:39:24PM +0300, Mika Kuoppala wrote:
> Jani Nikula writes:
>
> > On Wed, 02 Sep 2015, Arun Siluvery wrote:
> >> On 20/08/2015 16:27, Chris Wilson wrote:
> >>> On Thu, Aug 20, 2015 at 05:34:59PM +0300, Mika Kuoppala wrote:
> If we leave the last_retired_head to pre-
Jani Nikula writes:
> On Wed, 02 Sep 2015, Arun Siluvery wrote:
>> On 20/08/2015 16:27, Chris Wilson wrote:
>>> On Thu, Aug 20, 2015 at 05:34:59PM +0300, Mika Kuoppala wrote:
If we leave the last_retired_head to pre-reset value, we might
end up in a situation where intel_ring_space() r
Use the new struct intel_dp_signal_levels to store voltage swing and pre
emphasis levels for DDI platforms.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git
Remove the old functions for maximum DP voltage swing and pre-emphasis
levels, now that all platforms use the new intel_dp_signal_values
struct.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 132 +-
1 file chang
Hi all,
New -testing cycle with cool stuff:
- 2nd attempt at atomic watermarks from Matt, but just prep for now
- fixes all over
Happy testing!
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx ma
No functional changes, just moving code around.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_dp.c | 517 -
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 534 ++
The logic for writing the DP register based on the vswing and pre emph
values is in that file for all other platforms, so follow suit and move
ddi_signal_levels() to intel_dp_signal_levels.c too.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c | 78 +
Move the check of whether the voltage changed into the function that
parses the sink adjust request, simplifying the voltage loop a bit.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 32 ++-
1 file changed, 17 insertions(+
Use the new struct intel_dp_signal_levels to store voltage swing and pre
emphasis levels for VLV.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 38 ++-
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/driver
In order to clarify which platforms support which combination of voltage
swing and pre emphasis level, introduce struct intel_dp_signal_levels.
With the new struct, the if ladder to determine the values used is put
in one place, intel_dp_init_signal_levels().
This also wires gens 4, 5 and non-eDP
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index fb449f5..63a6f3d 100644
--- a/driv
Add a function for retrieving the current voltage swing being used for
link training. Using that function in the clock recovery code makes it a
bit more readable.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 10 --
1 file changed, 8 inse
Use the new struct intel_dp_signal_levels to store voltage swing and pre
emphasis levels for eDP on SNB and IVB.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 132 ++
1 file changed, 91 insertions(+), 41 deletions(-)
diff
Use the new struct intel_dp_signal_levels to store voltage swing and pre
emphasis levels for CHV.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_signal_levels.c | 38 ++-
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/driver
When a failure to achieve clock recovery happens, the link training code
repeats the training process starting with initial values up to five
times before giving up. The logic for the so called "full retries" and
the "voltage tries" was convoluted into a single loop. This patch splits
it into two s
It makes it slightly easier to read.
v2: Add missing word in patch title. (Ander)
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_link_tr
No functional changes, just moving code around.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_dp.c | 321 +
drivers/gpu/drm/i915/intel_dp_link_training.c | 327 ++
The function name implies it should get intel_dp, and it mostly used
where there is an intel_dp in the context.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 19 +++
drivers/gpu/drm/i915/intel_dp_link_training.c | 4 +---
drivers
Move the setup code for the different phases of link training into
functions separate from the training loop. This shouldn't cause any
change in behavior, but make the code slightly less hard to read.
Note that the extra checks performed by calling setup_channel_eq()
instead of intel_dp_set_link_t
Move the call to intel_dp_get_adjust_train() out of
intel_dp_update_link_train() and call it instead from the clock recovery
and channel equalization features. A follow up patch will remove the DP
register write from that function, so that it handles only the DPCD
write.
Signed-off-by: Ander Conse
In order to prepare for a link training with DDI, the state machine
would call intel_ddi_prepare_link_retrain(). To remove the dependency to
the hardware information, replace that direct call with a callback.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c
Hi,
Here is an updated version of the DP patches I have pending. I updated
the first patch with the comments from Sivakumar, and that required a
rebase, so I'm sending the patches out again. Other than that, the order
of the first few patches changed slightly so that there is no need to
create the
Move the logic for checking if we have reached max voltage swing on all
lanes to a separate function to declutter the link training clock
recovery code.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 18 +-
1 file changed, 13 inser
Move register write from intel_dp_update_link_train() into
intel_dp_set_signal_levels(). This creates a better split between the
i915 specific code and the generic link training part. Note that this
causes an extra register write in intel_dp_reset_link_train(), since
both intel_dp_set_signal_levels
It just makes the code more confusing, so just reference intel_dp_>DP
directly.
Note that this also fix a bug where the value of intel_dp->DP could be
different than the last value written to the hw, due to an early return
that would skip the 'intel_dp->DP = DP' line.
v2: Don't preserve old DP va
Split the register write with the new link training pattern out of
intel_dp_set_link_train(), so that the i915 specific code is in a
separate function.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 18 +-
1 file changed, 13 insertions(+), 5 del
On 22/10/15 17:07, Chris Wilson wrote:
On Thu, Oct 22, 2015 at 03:15:55PM +0100, Tvrtko Ursulin wrote:
Hi,
On 21/10/15 16:24, Chris Wilson wrote:
Our GPUs impose certain requirements upon buffers that depend upon how
exactly they are used. Typically this is expressed as that they require
a la
The current CSR loading code depends on the CSR program memory to be
cleared after boot. This is unfortunately not true on all hardware.
Instead make use of the FW_UNINITIALIZED state in init and check for
FW_LOADED to prevent init path from skipping the actual programming.
v2: Move initialization
Hi
On Thu, Oct 22, 2015 at 7:11 PM, Daniel Vetter wrote:
> It's racy, creating mmap offsets is a slowpath, so better to remove it
> to avoid drivers doing broken things.
>
> The only user is i915, and it's ok there because everything (well
> almost) is protected by dev->struct_mutex in i915-gem.
On Fri, Oct 23, 2015 at 10:04:24AM +0200, Daniel Vetter wrote:
> On Thu, Oct 22, 2015 at 04:23:09PM -0700, Kristian Høgsberg wrote:
> > On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson
> > wrote:
> > > Pinning a userptr onto the hardware raises interesting questions about
> > > the lifetime of such
On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> On Fri, 23 Oct 2015, Chris Wilson wrote:
> > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
> >> We get tons of cases where the master interrupt handler apparently set
> >> a bit, with the SDEIIR agreeing. No idea what'
Hi Daniel,
[auto build test ERROR on drm-intel/for-linux-next -- if it's inappropriate
base, please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-i915-Shut-up-GuC-errors-when-it-s-disabled/20151023-165910
config: x
On Fri, 23 Oct 2015, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
>> We get tons of cases where the master interrupt handler apparently set
>> a bit, with the SDEIIR agreeing. No idea what's going on there, but
>> it's consistent on gen8+, no one seems to ca
On Fri, Oct 23, 2015 at 10:03:50AM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
> > We get tons of cases where the master interrupt handler apparently set
> > a bit, with the SDEIIR agreeing. No idea what's going on there, but
> > it's consistent on ge
DRM_ERROR an continue without any issues aren't allowed since that
causes noise in the CI system. But we absolutely want to have the
DRM_ERROR when we want to run with GuC.
For simplicity just short-circuit all the loader code when it's not
needed.
v2: Mika&Chris complained that I shouldn't hit s
On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
> We get tons of cases where the master interrupt handler apparently set
> a bit, with the SDEIIR agreeing. No idea what's going on there, but
> it's consistent on gen8+, no one seems to care about it and it's
> making CI results flaky.
Another CI fail we have for no reason. Totally unjustified since
nothing fails at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_op
On Fri, Oct 23, 2015 at 09:42:27AM +0100, Tvrtko Ursulin wrote:
>
> On 19/10/15 16:32, Tomas Elf wrote:
> >Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
> >concurrency problems between the context event interrupt handler and the
> >reset
> >path immediately followin
DRM_ERROR an continue without any issues aren't allowed since that
causes noise in the CI system. But we absolutely want to have the
DRM_ERROR when we want to run with GuC.
For simplicity just short-circuit all the loader code when it's not
needed.
v2: Mika&Chris complained that I shouldn't hit s
We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR agreeing. No idea what's going on there, but
it's consistent on gen8+, no one seems to care about it and it's
making CI results flaky.
Shut it up.
No idea what's going on here, but we've had fun with PCH
Hi,
On 23/10/15 02:34, Vivek Kasireddy wrote:
The main goal of this subtest is to trigger the following warning in
the function i915_gem_object_get_fence():
if (WARN_ON(!obj->map_and_fenceable))
To trigger this warning, the subtest first creates a Y-tiled object and
an associated frame
On Fri, Oct 23, 2015 at 10:33:56AM +0200, Daniel Vetter wrote:
> DRM_ERROR an continue without any issues aren't allowed since that
> causes noise in the CI system. But we absolutely want to have the
> DRM_ERROR when we want to run with GuC.
>
> For simplicity just short-circuit all the loader cod
On 19/10/15 16:32, Tomas Elf wrote:
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.
* v2 (Chris Wilson):
Do execlist check and use simpler form of
DRM_ERROR an continue without any issues aren't allowed since that
causes noise in the CI system. But we absolutely want to have the
DRM_ERROR when we want to run with GuC.
For simplicity just short-circuit all the loader code when it's not
needed.
Cc: Alex Dai
Cc: Dave Gordon
Signed-off-by: Da
On Thu, Oct 22, 2015 at 05:27:00PM -0700, Matt Roper wrote:
> Tell the kernel that we understand atomic and want to have access to
> atomic-only properties. If the kernel doesn't support atomic for i915
> yet (and i915.nuclear_pageflip=1 isn't passed on the kernel command
> line) this will silentl
1 - 100 of 102 matches
Mail list logo
