== Series Details ==
Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in
i915_guc_submission_disable
URL : https://patchwork.freedesktop.org/series/21090/
State : success
== Summary ==
Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/
Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and
Execlists. Updating it inside guc_interrupts_* routines as in those
routines GuC load/submission params are sanitized and it should not be set
based on HAS_GUC_SCHED during intel_irq_init.
Cc: Tvrtko Ursulin
Cc: Chris Wilson
"pm_intr_keep" is not conveying the intent that it is bitmask
of interrupts that must be zero(mbz) in GEN6_PMINTRMSK.
Name it "pm_intrmsk_mbz".
Cc: Chris Wilson
Cc: Radoslaw Szwichtenberg
Reviewed-by: Chris Wilson
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
Like capture of GuC interrupts while enabling GuC submission, release
them while disabling GuC submission.
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Oscar Mateo
Reviewed-by: Chris Wilson
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_guc_submission.c | 23 ++
On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
had the surprising behavior of doing a synchronized GTT mapping.
This is obviously not what the user of the API wanted.
Eric left a comment indicating a valid concern: if the CPU and GPU
caches are incoherent, we don't keep track of
Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
to zero after updating db_status before we call the GuC to release the
doorbell.
Kudos to Daniele for finding this out.
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i
When initializing the GuC log struct, there is an object we need to
allocate always, since the GuC needs its address at fw load time.
The rest is only needed during runtime, in the sense that we only
create if we actually enable GuC logging. Make that distinction
explicit by subdividing further the
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.
v2:
- Null execbuf client outside guc_client_free (Daniele)
- Assert if things try to get allocated twice (Daniele/Joonas)
- Null guc->log.buf_addr when destroyed (Daniele)
- Newline between returnin
While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one
firware interface field (s/ring_tail/submit_element_info, since it can contain
more than just the ring tail).
No change in functionality.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_guc_submission.c | 42
A GuC context and a HW context are in no way related, so the name "GuC context
descriptor"
is very unfortunate, because a new reader of the code gets overwhelmed very
quickly with
a lot of things called "context" that refer to different things. We can improve
legibility
a lot by simply renaming
Some recent refactoring patches have left the doorbell creation outside
the GuC client allocation, which does not make a lot of sense (a client
without a doorbell is something useless). Move it back there, and
refactor the init_doorbell_hw consequently.
Thanks to this, we can do some other improve
Prepare for an alternate GuC communication interface.
v2: Make a few functions static and name them correctly while we are at it
(Oscar), but
leave an intel_guc_send_mmio interface for users that require old-style
communication.
v3: Send intel_uc_init_early back to the top (Michal).
Signed-off
Started adding proper teardown to guc_client_alloc, ended up removing
quite a few dead ends where errors communicating with the GuC were
silently ignored. There also seemed to be quite a few erronous
teardown actions performed in case of an error (ordering wrong).
v2:
- Increase function symmetr
The GuC descriptor is big in size. If we use a local definition of
guc_desc we have a chance to overflow stack, so avoid it.
Also, Chris abhors scatterlists :)
v2: Rebased, helper function to retrieve the context descriptor,
s/ctx_pool_vma/ctx_pool/
v3: Zero out guc_context_desc before initializ
They have been discussed in various threads, but I am putting them together
as a series for clarity. They now include Joonas' "Sanitize GuC client
initialization" with a small tweak, plus an extra doorbell refactoring patch
at the end, so they are self-contained and... ready to merge?.
Oscar Mateo
This vma contains much more than just the additional data struct (ads)
and since we were already using the word "addon" as an object in
guc_addon_create, make it the preffered one. No need for the vma suffix
either, as that dependency is given by the type.
While at it, add an explanation of what t
On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote:
> The main thing are the DDI ports. If there's a VBT that says there are
> no outputs, we should trust that, and not have semi-random
> defaults. Unfortunately, the defaults have resulted in some Chromebooks
> without VBT to rely on this
== Series Details ==
Series: Enhancement to intel_dp_aux_backlight driver
URL : https://patchwork.freedesktop.org/series/21086/
State : failure
== Summary ==
Series 21086v1 Enhancement to intel_dp_aux_backlight driver
https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/1/mbox/
Te
This patch set contain 4 patches.
- First two patches allow enable DPCD backlight control when panel
can also do that via PWM pin and fix the usage of enable register.
- Next patch adds enable DBC by default
- Last patch makes the driver restore last brightness level after
turning display off a
Some panel will default to zero brightness when turning the
panel off and on again. This patch stores last brightness level
before turning off and set them back when panel is turning on.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 2 ++
1 file change
intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.
This patch fixed that by handling all cases of that register.
Change-Id: Ic6ee6508d7c4a564bd879f36c9d2b971c49e64bc
Signed-off-b
This patch enables dynamic backlight by default for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Change-Id: I7140d4e838c654b6527df38b5780ad1533848d6c
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/
Currently the intel_dp_aux_backlight driver requires eDP panel
to not also support backlight adjustment via PWM pin to use
this driver.
This force the eDP panel that support both ways of backlight
adjustment to do it via PWM pin.
This patch adds the new prefer DPCD mode in the i915_param
to make
== Series Details ==
Series: drm/i915: Restore engine->submit_request before unwedging (rev2)
URL : https://patchwork.freedesktop.org/series/20982/
State : success
== Summary ==
Series 20982v2 drm/i915: Restore engine->submit_request before unwedging
https://patchwork.freedesktop.org/api/1.0/s
When we wedge the device, we override engine->submit_request with a nop
to ensure that all in-flight requests are marked in error. However, igt
would like to unwedge the device to test -EIO handling. This requires us
to flush those in-flight requests and restore the original
engine->submit_request.
On Thu, Mar 09, 2017 at 07:27:24PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> GVTg has introduced the context status notifier to schedule the GVTg
> workload. At that time, the notifier is bound to GVTg context only,
> so GVTg is not aware of host workloads.
>
> Now we are going
== Series Details ==
Series: RFC: drm/i915: annote drop_caches debugfs interface with lockdep
URL : https://patchwork.freedesktop.org/series/21063/
State : failure
== Summary ==
CHECK usr/include/linux/hdlc/ (1 files)
CHECK usr/include/linux/spi/ (1 files)
CHECK usr/include/linux/h
== Series Details ==
Series: drm/i915/vbt: defaults handling for no VBT case
URL : https://patchwork.freedesktop.org/series/21061/
State : failure
== Summary ==
Series 21061v1 drm/i915/vbt: defaults handling for no VBT case
https://patchwork.freedesktop.org/api/1.0/series/21061/revisions/1/mbo
== Series Details ==
Series: drm/i915: Wait for reset to complete before returning from
debugfs/i915_wedged (rev2)
URL : https://patchwork.freedesktop.org/series/21030/
State : success
== Summary ==
Series 21030v2 drm/i915: Wait for reset to complete before returning from
debugfs/i915_wedged
On Fri, Mar 10, 2017 at 04:10:29PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Baytrail, we manually calculate busyness over the evaluation interval
> > to avoid issues with miscaluations with RC6 enabled. However, it turns
> > out that the DOWN_EI interrupt generator is completel
== Series Details ==
Series: GuC Scrub vol. 1 (rev11)
URL : https://patchwork.freedesktop.org/series/16856/
State : warning
== Summary ==
Series 16856v11 GuC Scrub vol. 1
https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/11/mbox/
Test gem_exec_flush:
Subgroup basic-batc
Copied as of commit
commit 496b575e3ccbf6fbe57a674c721af43dc8826361
Author: Chris Wilson
Date: Mon Feb 13 17:15:58 2017 +
drm/i915: Add initial selftests for hang detection and resets
The headers are used to enumerate available tests when the running
kernel does not support selftes
IGT subtest enumeration must work regardless of what the running
environment is. Kernel selftest launchers want to expose everything
the running kernel can execute.
These two things are mutually exclusive. This series is an attempt for
a best-of-both-worlds approach: After constructing subtests fo
Even when the running kernel does not support selftests, make subtest
enumeration list known kselftests. The list is generated using
selftest listing headers copied from the kernel.
If the running kernel gains new selftest subtests, they are listed
even without copying the headers over and rebuild
On Fri, Mar 10, 2017 at 04:10:29PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Baytrail, we manually calculate busyness over the evaluation interval
> > to avoid issues with miscaluations with RC6 enabled. However, it turns
> > out that the DOWN_EI interrupt generator is completel
Chris Wilson writes:
> To make our adjustments to RPS requires taking a mutex and potentially
> sleeping for an unknown duration - until we have completed our
> adjustments further RPS interrupts are immaterial (they are based on
> stale thresholds) and we can safely ignore them.
>
> Signed-off-b
Chris Wilson writes:
> On Baytrail, we manually calculate busyness over the evaluation interval
> to avoid issues with miscaluations with RC6 enabled. However, it turns
> out that the DOWN_EI interrupt generator is completely bust - it
> operates in two modes, continuous or never. Neither of whic
On Fri, Mar 10, 2017 at 03:27:57PM +0200, Jani Nikula wrote:
> We don't use the error return for anything other than reporting and
> logging that there is no VBT. We can pull the logging in the function,
> and remove the error status return. Moreover, if we needed the
> information for something la
On Fri, Mar 10, 2017 at 02:31:22PM +0100, Daniel Vetter wrote:
> The trouble we have is that we can't really test all the shrinker
> recursion stuff exhaustively in BAT because any kind of thrashing
> stress test just takes too long.
>
> But that leaves a really big gap open, since shrinker recurs
On Fri, Mar 10, 2017 at 01:06:51PM +, Tvrtko Ursulin wrote:
>
> On 08/03/2017 14:46, Chris Wilson wrote:
> >Sometimes we want to explicitly page out all available objects from igt,
> >i.e. call i915_gem_shrink_all() and check that subsequent operations
> >succeed. This adds DROP_SHRINK_ALL [0x
The trouble we have is that we can't really test all the shrinker
recursion stuff exhaustively in BAT because any kind of thrashing
stress test just takes too long.
But that leaves a really big gap open, since shrinker recursions are
one of the most annoying bugs. Now lockdep already has support f
This is my proposed alternative to [1].
BR,
Jani.
[1]
http://patchwork.freedesktop.org/patch/msgid/1488546102-27789-1-git-send-email-manasi.d.nav...@intel.com
Jani Nikula (2):
drm/i915/vbt: don't propagate errors from intel_bios_init()
drm/i915/vbt: split out defaults that are set when th
The main thing are the DDI ports. If there's a VBT that says there are
no outputs, we should trust that, and not have semi-random
defaults. Unfortunately, the defaults have resulted in some Chromebooks
without VBT to rely on this behaviour, so we split out the defaults for
the missing VBT case.
Cc
We don't use the error return for anything other than reporting and
logging that there is no VBT. We can pull the logging in the function,
and remove the error status return. Moreover, if we needed the
information for something later on, we'd probably be better off storing
the bit in dev_priv, and
On 10/03/2017 13:23, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 01:14:33PM +, Tvrtko Ursulin wrote:
On 10/03/2017 12:21, Chris Wilson wrote:
Provide some serialisation between user operations by waiting for the
reset initiated by setting i915_wedged to complete.
Signed-off-by: Chris Wil
On Fri, Mar 10, 2017 at 01:14:33PM +, Tvrtko Ursulin wrote:
>
> On 10/03/2017 12:21, Chris Wilson wrote:
> >Provide some serialisation between user operations by waiting for the
> >reset initiated by setting i915_wedged to complete.
> >
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
>
On Fri, Mar 10, 2017 at 02:41:16PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > We only need to clflush those cachelines that we have validated to be
> > read by the GPU. Userspace typically fills the batch length in
> > correctly, the exceptions tend to be explicit tests within igt.
== Series Details ==
Series: drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
URL : https://patchwork.freedesktop.org/series/21049/
State : success
== Summary ==
Series 21049v1 drm/i915/glk: Improve rounding caused by pre-CSC gamma tables
https://patchwork.freedesktop.org/api/1.0/
On Fri, Mar 10, 2017 at 12:59:47PM +, Tvrtko Ursulin wrote:
>
> On 09/03/2017 10:22, Chris Wilson wrote:
> >+void i915_gem_unset_wedged(struct drm_i915_private *dev_priv)
> >+{
> >+struct i915_gem_timeline *tl;
> >+int i;
> >+
> >+lockdep_assert_held(&dev_priv->drm.struct_mutex);
>
On 10/03/2017 12:21, Chris Wilson wrote:
Provide some serialisation between user operations by waiting for the
reset initiated by setting i915_wedged to complete.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file change
On 08/03/2017 14:46, Chris Wilson wrote:
Sometimes we want to explicitly page out all available objects from igt,
i.e. call i915_gem_shrink_all() and check that subsequent operations
succeed. This adds DROP_SHRINK_ALL [0x8] to the set of flags for
Not 0x20 ?
debugfs/i915_drop_caches.
Signed
Chris Wilson writes:
> On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> If we avoid initializing forcewake domains when running as
>> a guest, and also use gen2 mmio accessors in that case, we
>> can avoid the timer traffic and any looping through th
On 09/03/2017 10:22, Chris Wilson wrote:
When we wedge the device, we override engine->submit_request with a nop
to ensure that all in-flight requests are marked in error. However, igt
would like to unwedge the device to test -EIO handling. This requires us
to flush those in-flight requests and
On Fri, Mar 10, 2017 at 12:18:34PM +0200, Ander Conselvan de Oliveira wrote:
> The 33rd entry in the pre-CSC gamma table in Geminilake can represent a
> value of 1.0 as 17 bits fixed point with one integer bit. However, the
> table was generated such that the value of 1.0 would be 0. with
> all
== Series Details ==
Series: drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly
URL : https://patchwork.freedesktop.org/series/21047/
State : success
== Summary ==
Series 21047v1 drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly
https://patchwork.freedesktop.org/api/1.0/series
Chris Wilson writes:
> We only need to clflush those cachelines that we have validated to be
> read by the GPU. Userspace typically fills the batch length in
> correctly, the exceptions tend to be explicit tests within igt.
>
> v2: Use ptr_mask_bits() to make Mika happy
> v3: cmd is not advanced
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ander Conselvan de Oliveira
commit c34f078675f505c4437919bb1897b1351f16a050 upstream.
In the path where intel_crt_detect_ddc() detects a CRT, if would return
true without freeing the edid.
Fi
Provide some serialisation between user operations by waiting for the
reset initiated by setting i915_wedged to complete.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu
On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote:
> Current version of intel_guc_init_hw() does a lot:
> - cares about submission
> - loads huc
> - implement WA
>
> This change offloads some of the logic to intel_uc_init_hw(), which now
> cares about the above.
>
> v2: rename gu
We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.
v2: Use ptr_mask_bits() to make Mika happy
v3: cmd is not advanced on MI_BBE, so make sure to include
On 10/03/2017 10:54, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 09:32:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_init_hw(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
v4: rem
On Fri, Mar 10, 2017 at 01:19:01PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > We only need to clflush those cachelines that we have validated to be
> > read by the GPU. Userspace typically fills the batch length in
> > correctly, the exceptions tend to be explicit tests within igt.
Chris Wilson writes:
> We only need to clflush those cachelines that we have validated to be
> read by the GPU. Userspace typically fills the batch length in
> correctly, the exceptions tend to be explicit tests within igt.
>
> v2: Use ptr_mask_bits() to make Mika happy
>
> Signed-off-by: Chris W
On Fri, Mar 10, 2017 at 09:32:49AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In commit 003342a50021 ("drm/i915: Keep track of active
> forcewake domains in a bitmask") I forgot to adjust the
> newly introduce fw_domains_active state across reset.
>
> This caused the assert_forcewak
On Fri, Mar 10, 2017 at 12:42:34PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote:
> >> >> On Fri, Mar 10, 2017 at 11:58:44
We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.
v2: Use ptr_mask_bits() to make Mika happy
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
driv
== Series Details ==
Series: drm/i915: Fix forcewake active domain tracking (rev4)
URL : https://patchwork.freedesktop.org/series/21004/
State : success
== Summary ==
Series 21004v4 drm/i915: Fix forcewake active domain tracking
https://patchwork.freedesktop.org/api/1.0/series/21004/revisions/
Chris Wilson writes:
> On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote:
>> >> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote:
>> >> > Chris Wilson writes:
>> >> >
>> >> >
On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote:
> >> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote:
> >> > Chris Wilson writes:
> >> >
> >> > > We only need to clflush those
On Thu, 2017-03-09 at 17:17 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c
> URL : https://patchwork.freedesktop.org/series/20992/
> State : success
Pushed to drm-intel-next-queued. Thanks for the patch.
Ander
>
On Fri, 2017-03-10 at 12:18 +0200, Ander Conselvan de Oliveira wrote:
> Some of the kms_cursor_crc subtests where failing on Geminilake. The
> root cause was an error on programming the pre-CSC gamma tables, which
> led to small rounding errors that, although not sufficient to change the
> image as
Chris Wilson writes:
> On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote:
>> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote:
>> > Chris Wilson writes:
>> >
>> > > We only need to clflush those cachelines that we have validated to be
>> > > read by the GPU. Userspace ty
On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote:
> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> > > We only need to clflush those cachelines that we have validated to be
> > > read by the GPU. Userspace typically fills the batch length
Some of the kms_cursor_crc subtests where failing on Geminilake. The
root cause was an error on programming the pre-CSC gamma tables, which
led to small rounding errors that, although not sufficient to change the
image as captured at 8bpc with the Chamelium, were enough to generate a
different CRC.
The 33rd entry in the pre-CSC gamma table in Geminilake can represent a
value of 1.0 as 17 bits fixed point with one integer bit. However, the
table was generated such that the value of 1.0 would be 0. with
all the intervals scaled accordingly. For instance, 0.5 mapped to
0.7fff instead of 0.80
On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> If we avoid initializing forcewake domains when running as
> a guest, and also use gen2 mmio accessors in that case, we
> can avoid the timer traffic and any looping through the
> forcewake code which is cu
On Thu, Mar 09, 2017 at 09:26:36PM +, Chris Wilson wrote:
> On Thu, Mar 09, 2017 at 05:44:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Use I915_{READ,WRITE}_FW() for updating the DSPARB registers on
> > VLV/CHV. This is less expesive as we can grab the unco
On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > We only need to clflush those cachelines that we have validated to be
> > read by the GPU. Userspace typically fills the batch length in
> > correctly, the exceptions tend to be explicit tests within igt.
Chris Wilson writes:
> We only need to clflush those cachelines that we have validated to be
> read by the GPU. Userspace typically fills the batch length in
> correctly, the exceptions tend to be explicit tests within igt.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_cmd_p
From: Tvrtko Ursulin
If we avoid initializing forcewake domains when running as
a guest, and also use gen2 mmio accessors in that case, we
can avoid the timer traffic and any looping through the
forcewake code which is currently just so it can end up in
the no-op forcewake implementation.
Signed
We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 3 ++-
1 file changed, 2 i
From: Tvrtko Ursulin
In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.
This caused the assert_forcewakes_inactive to trigger
during suspend and resume if there were user held
force
== Series Details ==
Series: drm/i915: Fix forcewake active domain tracking (rev2)
URL : https://patchwork.freedesktop.org/series/21004/
State : success
== Summary ==
Series 21004v2 drm/i915: Fix forcewake active domain tracking
https://patchwork.freedesktop.org/api/1.0/series/21004/revisions/
On 10/03/2017 08:50, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 07:32:51AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In commit 003342a50021 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.
== Series Details ==
Series: drm/i915: Wait for reset to complete before returning from
debugfs/i915_wedged
URL : https://patchwork.freedesktop.org/series/21030/
State : success
== Summary ==
Series 21030v1 drm/i915: Wait for reset to complete before returning from
debugfs/i915_wedged
https:
== Series Details ==
Series: drm/i915: Fix vGPU balloon for ggtt guard page (rev2)
URL : https://patchwork.freedesktop.org/series/20983/
State : success
== Summary ==
Series 20983v2 drm/i915: Fix vGPU balloon for ggtt guard page
https://patchwork.freedesktop.org/api/1.0/series/20983/revisions/
== Series Details ==
Series: drm/i915: Move whole object to CPU domain for coherent shmem access
URL : https://patchwork.freedesktop.org/series/21020/
State : failure
== Summary ==
Series 21020v1 drm/i915: Move whole object to CPU domain for coherent shmem
access
https://patchwork.freedesktop
== Series Details ==
Series: drm: Forward declare struct platform_device
URL : https://patchwork.freedesktop.org/series/21017/
State : success
== Summary ==
Series 21017v1 drm: Forward declare struct platform_device
https://patchwork.freedesktop.org/api/1.0/series/21017/revisions/1/mbox/
fi-b
== Series Details ==
Series: series starting with [v3,1/3] drm/i915: Stop using RP_DOWN_EI on
Baytrail
URL : https://patchwork.freedesktop.org/series/21014/
State : success
== Summary ==
Series 21014v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21014/revision
== Series Details ==
Series: series starting with [v3] drm/i915: Stop using RP_DOWN_EI on Baytrail
(rev2)
URL : https://patchwork.freedesktop.org/series/20314/
State : success
== Summary ==
Series 20314v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20314/revis
From: Andrew Morton
gcc-4.4.4 has issues with anonymous union initializers.
In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68:
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error: unknown field
'mock' specified in initializer
drivers/gpu/drm/i915/selftests/i915_
On Fri, Mar 10, 2017 at 07:32:51AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In commit 003342a50021 ("drm/i915: Keep track of active
> forcewake domains in a bitmask") I forgot to adjust the
> newly introduce fw_domains_active state across reset.
>
> This caused the assert_forcewak
From: Andrew Morton
Subject: drivers/gpu/drm/i915/selftests/i915_selftest.c: fix build with
gcc-4.4.4
gcc-4.4.4 has issues with anonymous union initializers.
In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68:
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error:
94 matches
Mail list logo