When mixing lots of vmallocs and set_memory_*() (which calls
vm_unmap_aliases()) I encountered situations where the performance
degraded severely due to the walking of the entire vmap_area list each
invocation. One simple improvement is to add the lazily freed vmap_area
to a separate lockless free
Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"),
the status of a DP connector depends on its sink count value.
However, some eDP panels don't set that value appropriately,
causing them to be reported as disconnected.
Fix this by ignoring sink count for eDP.
v2: Rephrased commit
After mi_set_context() succeeds, we need to update the state of the
engine's last_context. This ensures that we hold a pin on the context
whilst the hardware may write to it. However, since we didn't complete
the post-switch setup of the context, we need to force the subsequent
use of the same cont
On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
> Is there any reason for calling set_machine_constraints() after
> device_register() in regulator_register()?
I'm not sure there's a strong one, we don't really use the class device
for anything, but without doing a full audit I co
Hi,
> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
>
> Not quite completely, it seems ...
>
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]
pin
Hi Thierry,
On Wed, 30 Mar 2016 22:03:23 +0200
Boris Brezillon wrote:
> Hello,
>
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
>
> It also adds support for initi
NAK. Try plugging in an MST display, suspending the machine, then resuming it.
Hotplugging still breaks (which I've traced down to this patch)
I wouldn't worry about fixing this up. I'm probably going to be sending a revert
for this anyway soon along with probably some of the other patches.
On Mo
On Mon, Apr 11, 2016 at 07:47:12PM +0100, Dave Gordon wrote:
> Hi,
>
> background to this is that one of our validation engineers has written
> a test that creates a batch that loops by jumping backwards using
> MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
> whatever instru
Daniel Vetter composed on 2016-04-11 21:45 (UTC+0200):
New -testing cycle with cool stuff:...
What exactly is a "testing cycle? Last Intel Xorg driver (e.g. openSUSE 42.1
released in November: xf86-video-intel; Ubuntu 16.04, due out this month:
xserver-xorg-video-intel) release was, what, 19
Hi all,
New -testing cycle with cool stuff:
- 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 Joona
Hi,
background to this is that one of our validation engineers has written
a test that creates a batch that loops by jumping backwards using
MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
whatever instruction sequence is being tested inside the loop.
This works perfectly wel
When testing multple outputs, make sure to set the gamma values before
testing the output. Otherwise we're testing using the gamma values
that were reset after last output was tested. Without this, the first
output passes, but each output after that will fail.
Signed-off-by: Bob Paauwe
---
tes
On Mon, 11 Apr 2016 14:43:39 +0100
Lionel Landwerlin wrote:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc
In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
much needed clean-up was done, but unfortunately part of the change
broke DP MST. The real issue was setting the connector state to
disconnected in the MST case, which is good, but the code then (after
a goto) checks if the conne
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.
The RCS registers and the L3CC registers are s
== Series Details ==
Series: Minor i915_dp_mst_info output enhancements (rev4)
URL : https://patchwork.freedesktop.org/series/5346/
State : failure
== Summary ==
CC net/ipv4/tcp_cubic.o
CC net/ipv4/xfrm4_policy.o
CC net/ipv6/xfrm6_input.o
CC net/ipv4/xfrm4_state.o
On Mon, Apr 11, 2016 at 03:57:21PM +0100, Tvrtko Ursulin wrote:
>
> On 11/04/16 15:44, Chris Wilson wrote:
> >On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/04/16 12:11, Chris Wilson wrote:
> >>>When called because we have run out of vmap address space, we only need
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We expect vlv_display_irq_reset() to have been called prior to
> vlv_display_irq_postinstall() so let's WARN if that isn't the case.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
On Mon, 11 Apr 2016, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote:
+ for (index = 0, offset = 0; index < size; index++, offset += 4)
+ {
+ batch[offset] = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
+ batch[offset+1] = reg_ba
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled IMR/IER setup in
> vlv_display_irq_postinstall()
> with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to
> avoid
> consusion since we no longer deal with IIR here.
>
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> For a bit of extra paranoia make sure the display irqs are all
> cleared
> before we enabled them when turning on the power well. This should
> really be the case already since the power well was off
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Reshuffle the code a bit to move the vlv/chv display irq functions
> away
> from the main irq hooks, next to the other sub (de,gt,etc.) hooks.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Dea
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> During runtime PM we'll be reinitializing interrupt support from the
> ground up. However since the display power well will be off at that
> time, well end up with a ton of unclaimed register accesses
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The vlv/chv display irq setup was a bit of mess after I ran out of steam
> when working on it last. Fix it up so that we just have a _reset() and
> _postinstall() hooks for the display irqs, and use t
In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file where the rest of the EDID helper
functions are implemented.
v2: Refactor to have drm_edid_get_monitor_name(
Modify the debugfs output for i915_dp_mst_info to list the source port for
the DP MST topology in question.
v2: rebase
v3: rebase
cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.
v2: Rebase + change drm_edid_get_monitor_name() call to reflect
On Mon, Apr 11, 2016 at 06:20:04PM +0300, Imre Deak wrote:
> On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > No clue what this is supposed to achieve. I think it's been there
> > since
> > the very beginning, so presumably some kind of kludge
On Mon, Apr 11, 2016 at 09:19:40AM +0100, Chris Wilson wrote:
> On Mon, Apr 11, 2016 at 10:29:29AM +0300, Ville Syrjälä wrote:
> > On Mon, Mar 07, 2016 at 05:57:00PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > There's no real reason the user should care
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No clue what this is supposed to achieve. I think it's been there
> since
> the very beginning, so presumably some kind of kludge for very early
> silicon. Let's just throw it out.
>
> Signed-off-by:
On Mon, Apr 11, 2016 at 05:06:24PM +0200, Maarten Lankhorst wrote:
> Op 11-04-16 om 16:43 schreef Ville Syrjälä:
> > On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
> >> This function is useful for gen2 intel devices which have no frame
> >> counter, but need a way to determine t
On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote:
> >>+ for (index = 0, offset = 0; index < size; index++, offset += 4)
> >>+ {
> >>+ batch[offset] = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
> >>+ batch[offset+1] = reg_base + (index * sizeof(uint32_t));
> >>+
On Fri, Apr 08, 2016 at 06:31:45PM +0300, Ander Conselvan de Oliveira wrote:
> The only difference between the DP and HDMI versions was the lane count.
> Since lane_count is now set appropriately for HDMI too, get rid of the
> duplication and move this to intel_dpio_phy.c
>
> Signed-off-by: Ander
On Fri, Apr 08, 2016 at 06:31:42PM +0300, Ander Conselvan de Oliveira wrote:
> The code for programming voltage swing and emphasis was duplicated
> between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/
Op 11-04-16 om 16:43 schreef Ville Syrjälä:
> On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
>> This function is useful for gen2 intel devices which have no frame
>> counter, but need a way to determine the current vblank count without
>> racing with the vblank interrupt handler
On Mon, 11 Apr 2016, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote:
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second
On 11/04/16 15:44, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
On 08/04/16 12:11, Chris Wilson wrote:
When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.
v2: Start using is_vmalloc
On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
>
> On 08/04/16 12:11, Chris Wilson wrote:
> >When called because we have run out of vmap address space, we only need
> >to recover objects that have vmappings and not all.
> >
> >v2: Start using is_vmalloc_addr()
> >
> >Signed-off-by
On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
>
> intel_pipe_update_start checks if no vblan
On 08/04/16 12:11, Chris Wilson wrote:
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is compatible.
v2: Use is_vmalloc_addr()
Signed-off-by: Chris Wilson
Cc: Tvrtk
== Series Details ==
Series: drm/i915: Fix VLV/CHV unclaimed register errors
URL : https://patchwork.freedesktop.org/series/5531/
State : failure
== Summary ==
Series 5531v1 drm/i915: Fix VLV/CHV unclaimed register errors
http://patchwork.freedesktop.org/api/1.0/series/5531/revisions/1/mbox/
On 08/04/16 12:11, Chris Wilson wrote:
When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.
v2: Start using is_vmalloc_addr()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h |
On 08/04/16 12:11, Chris Wilson wrote:
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the mapping into the
obj->pages lifetime, then we can reuse an obj->mapping for both and at
the same time couple it into the shrinker. Ther
On Mon, Apr 11, 2016 at 02:50:17PM +0100, Tvrtko Ursulin wrote:
>
> On 09/04/16 10:27, Chris Wilson wrote:
> >Conceptually, each request is a record of a hardware transaction - we
> >build up a list of pending commands and then either commit them to
> >hardware, or cancel them. However, whilst bui
== Series Details ==
Series: Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"
URL : https://patchwork.freedesktop.org/series/5528/
State : failure
== Summary ==
Series 5528v1 Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"
http://patchwork.freedesktop.org/a
From: Ville Syrjälä
The registers frobbed by vlv_init_display_clock_gating() libve inside
the disp2d power well, so frobbing them while the power well is down
results in unclaimed register access warning (and of course the values
won't stick). Let's do this setup after we know the power well is
e
From: Ville Syrjälä
There were two main causes for the VLV/CHV unclaimed register errors during
runtime PM transitons: dipslay irq setup and vlv_init_display_clock_gating().
This series reorganizes those things so that we only do them when the
disp2d power well is actually enabled.
Ville Syrjälä
From: Ville Syrjälä
DPINVGTT lives inside the disp2d power well so we can't frob it unless
we know the power well is active. Let's this stuff into
vlv_display_irq_reset() which is only called at the right times so that
we don't get unclaimed register access errors.
Bugzilla: https://bugs.freedes
From: Ville Syrjälä
For a bit of extra paranoia make sure the display irqs are all cleared
before we enabled them when turning on the power well. This should
really be the case already since the power well was off which resets
everything.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i
From: Ville Syrjälä
Enable the unclaimd register detection stuff on vlv/chv since we've now
fixed the known problems during suspend.
This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_uncore.c | 9 -
1 file changed
From: Ville Syrjälä
We expect vlv_display_irq_reset() to have been called prior to
vlv_display_irq_postinstall() so let's WARN if that isn't the case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i9
From: Ville Syrjälä
Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall()
with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid
consusion since we no longer deal with IIR here.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 20 -
From: Ville Syrjälä
Reshuffle the code a bit to move the vlv/chv display irq functions away
from the main irq hooks, next to the other sub (de,gt,etc.) hooks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 98 -
1 file changed, 49 ins
From: Ville Syrjälä
During runtime PM we'll be reinitializing interrupt support from the
ground up. However since the display power well will be off at that
time, well end up with a ton of unclaimed register accesses from the
display irq setup. Since we turned off the power well already before
ru
From: Ville Syrjälä
The vlv/chv display irq setup was a bit of mess after I ran out of steam
when working on it last. Fix it up so that we just have a _reset() and
_postinstall() hooks for the display irqs, and use those consistently.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_
From: Ville Syrjälä
No clue what this is supposed to achieve. I think it's been there since
the very beginning, so presumably some kind of kludge for very early
silicon. Let's just throw it out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 6 dele
On Mon, Apr 11, 2016 at 02:37:09PM +0100, Chris Wilson wrote:
> On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> > > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
> >
> > Not quite yet. I have patches
On 09/04/16 10:27, Chris Wilson wrote:
Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the r
Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.
v2: Update non atomic values only if commit succeeds (Bob Paa
On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
>
> Not quite yet. I have patches pretty much line up to fix the resulting
> spew. Just got a bit sidetra
On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote:
> The MOCS registers were added in Gen9 and define the caching policy.
> The registers are split into two sets. The first set controls the
> EDRAM policy and have a set for each engine, the second set controls
> the L3 policy. The two s
On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
Not quite yet. I have patches pretty much line up to fix the resulting
spew. Just got a bit sidetracked by the CHV irq problems.
> ---
> drivers/gpu/drm/i915/intel_uncore
On Thu, Mar 17, 2016 at 12:23:10PM +0200, Mika Kahola wrote:
> It was noticed on bug #94087 that module parameter
> i915.edp_vswing=2 that should override the VBT setting
> to use default voltage swing (400 mV) was not applied
> for Broadwell.
>
> This patch provides a fix for this by checking if
Imre Deak writes:
> [ text/plain ]
> When determining whether CDCLK is enabled by BIOS and so we should skip
> reprogramming it, we didn't check the related DBUF power request and
> state. In theory BIOS could enable one without the other so check for
> this case and reprogram things if something
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, April 11, 2016 6:06 PM
>To: R, Durgadoss ; intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic
>fun
This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
---
drivers/gpu/drm/i915/intel_uncore.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index ac2ac07b505b..2f7fb7d169b8 100644
--- a/drivers/gpu/drm
On Mon, 11 Apr 2016, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote:
On Fri, 8 Apr 2016, Chris Wilson wrote:
+ execbuf.flags = I915_EXEC_SECURE | engine_id;
+
+ gem_execbuf(fd, &execbuf);
+ gem_sync(fd, handle);
^ Papering over a bug
On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote:
> On Fri, 8 Apr 2016, Chris Wilson wrote:
> >>+ execbuf.flags = I915_EXEC_SECURE | engine_id;
> >>+
> >>+ gem_execbuf(fd, &execbuf);
> >>+ gem_sync(fd, handle);
> >
> > ^ Papering over a bug in your code.
> >
> >Hint: did yo
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.
The RCS registers and the L3CC registers are s
On Fri, 8 Apr 2016, Chris Wilson wrote:
On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote:
+static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
+uint32_t *batch,
+uint32_t dst_handle,
+
Imre Deak writes:
> [ text/plain ]
> DMC version 1.06 has a known bug, where the firmware polls forever for a port
> PLL to lock, if the PLL was disabled when entering DC5. Version 1.07 fixes
> this, so make that the minimum required version on BXT.
>
If this would be for already released hw, we
== Series Details ==
Series: series starting with [CI-ping,01/10] drm/i915: Force clean compilation
with -Werror
URL : https://patchwork.freedesktop.org/series/5518/
State : failure
== Summary ==
Series 5518v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5518/re
On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
> Currently, the required shared dpll is saved in the crtc_state.
> Similarly, this patch saves the dpll config values also, so that
> these values (through crtc_state->shared_dpll->config.hw_state)
> can be used for upfront link training.
>
>
On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
> Looping over the crtc list and finding an unused crtc
> has other users like upfront link training. Hence move it to
> a common function to re-use the logic.
>
> v3:
> * Added kernel Doc and removed an invalid comment (Ander)
> * Rebased on t
On Mon, Apr 11, 2016 at 11:32:20AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id
> for legacy mode
> URL : https://patchwork.freedesktop.org/series/5515/
> State : failure
>
> == Summary ==
>
> Series 5515v1 Serie
== Series Details ==
Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for
legacy mode
URL : https://patchwork.freedesktop.org/series/5515/
State : failure
== Summary ==
Series 5515v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5515/rev
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to
If we, when we store the reset_counter for the operation, we ensure that
it is not in a wedged or in the middle of a reset, we can then assert that
if any reset occurs the reset_counter must change. Later we can just
compare the operation's reset epoch against the current counter to see
if we need
Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to enable - with the usual
caveats of not enabl
Now that the reset_counter is stored on the request, we can rearrange
the code to handle reading the counter versus waiting during the atomic
modesetting for readibility (by deleting the hairiest of codes).
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gp
In the reset_counter, we use two bits to track a GPU hang and reset. The
low bit is a "reset-in-progress" flag that we set to signal when we need
to break waiters in order for the recovery task to grab the mutex. As
soon as the recovery task has the mutex, we can clear that flag (which
we do by inc
Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.
If the we reset the GPU or have detected a hang and wish to reset the
GPU, t
If we do not have lowlevel support for reseting the GPU, or if the user
has explicitly disabled reseting the device, the failure is expected.
Since it is an expected failure, we should be using a lower priority
message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just
emit the expect
Separate out the layers of includes (linux, drm, intel, i915) so that it
is a little easier to order our definitions between our multiple
reentrant headers. A couple of headers needed fixes to make them more
standalone (forgotten includes, forward declarations etc).
Signed-off-by: Chris Wilson
Re
This is principally a little bit of syntatic sugar to hide the
atomic_read()s throughout the code to retrieve the current reset_counter.
It also provides the other utility functions to check the reset state on the
already read reset_counter, so that (in later patches) we can read it once
and do mul
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
On 22/03/16 07:32, Patchwork wrote:
== Series Details ==
Series: drm/i915: implement WaClearTdlStateAckDirtyBits (rev3)
URL : https://patchwork.freedesktop.org/series/4282/
State : warning
== Summary ==
Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits
http://patchwork.freedeskt
Op 11-04-16 om 12:37 schreef Lionel Landwerlin:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc object.
>
> v2
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.
v2: Restrict w/a to non-RCS rings (RCS works correctly apparently).
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/int
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.
Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson
C
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f209ecfdcb5c..53b0ffed2501 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -259,10 +259,6 @@
We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 deletio
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
1 file changed, 1 inserti
Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.
v2: Update non atomic values only if commit succeeds (Bob Paa
On Mon, Apr 11, 2016 at 10:19:29AM +0100, Tvrtko Ursulin wrote:
>
> On 09/04/16 09:03, Chris Wilson wrote:
> >On Fri, Apr 08, 2016 at 02:54:54PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Retired request queue coupled with retired work handler is a scalability
> >>concern on s
On to, 2016-03-17 at 11:05 -0700, dw kim wrote:
> On Thu, Mar 17, 2016 at 01:03:36PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
> > (rev2)
> > URL : https://patchwork.freedesktop.org/series/4491/
> > State : failure
>
On 21/03/2016 14:37, tim.g...@intel.com wrote:
From: Tim Gore
This is to fix a GPU hang seen with mid thread pre-emption
and pooled EUs.
v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID
v3. And use correct type for register addresses
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i
On ke, 2016-03-16 at 18:06 -0700, Dongwon Kim wrote:
> For BXT, description of polarities of PORT_PLL_REF_SEL
> has been reversed for newer Gen9LP steppings according to the
> recent update in Bspec. This bit now should be set for
> "Non-SSC" mode for all Gen9LP starting from B0 stepping.
>
> v2:
On Mon, 11 Apr 2016, Dave Gordon wrote:
> For this reason, I'd like to recommend that anyone doing this sort of
> bulk transformation with Cocci or awk or just sed should /always/
> include the transformation script to help those with patches in flight.
I think that's generally the expectation
On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When the GMBUS based i2c transfer times out, we try to fall back to
> bit-banging and retry the operation that way. However if the bit-banging
> attempt also fails, we should probably go back to the GMBUS method fo
1 - 100 of 134 matches
Mail list logo
