Execlists is now enabled by default and included in the list of
capabilities printed out to dmesg and beyond. We do not need to mention
it again, every time we restart the engine, so kill the spam.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 1 -
1 file changed, 1 deletion
Pull the physical status page cleanup into a common
cleanup_status_page() for caller simplicity.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_c
On 1/19/2018 6:59 AM, Jackie Li wrote:
Hardware may have specific restrictions on GuC WOPCM size
It would be good if you can tell about Gen9/CNL restriction briefly here.
versus HuC firmware size. With static GuC WOPCM size,
there's no way to adjust the GuC WOPCM partition size based on
the a
Quoting Chris Wilson (2018-02-01 08:36:34)
> Pull the physical status page cleanup into a common
> cleanup_status_page() for caller simplicity.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 23 +++
> 1 file changed, 7 insertions(+), 16 delet
On 1/19/2018 6:59 AM, Jackie Li wrote:
CNL has different WOPCM size and hardware restriction on GuC
WOPCM size.
You are also updating gen9 path so update subject and commit message.
This patch returns the correct WOPCM reserved size on CNL and
adds the GuC WOPCM size check for CNL.
v6:
- E
On 1/19/2018 6:59 AM, Jackie Li wrote:
Signed-off-by: Jackie Li
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 4 ++--
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++
4 files changed, 10 insert
== Series Details ==
Series: drm/i915/execlists: Remove the startup spam
URL : https://patchwork.freedesktop.org/series/37467/
State : success
== Summary ==
Series 37467v1 drm/i915/execlists: Remove the startup spam
https://patchwork.freedesktop.org/api/1.0/series/37467/revisions/1/mbox/
Test
== Series Details ==
Series: drm/i915: Combine cleanup_status_page()
URL : https://patchwork.freedesktop.org/series/37468/
State : success
== Summary ==
Series 37468v1 drm/i915: Combine cleanup_status_page()
https://patchwork.freedesktop.org/api/1.0/series/37468/revisions/1/mbox/
Test debugfs
During testing, we trigger a lot of resets on an unbannable context
leading to massive amounts of irrelevant debug spam. Remove the
ban_score accounting and message for the unbannable context so that we
improve the signal:noise in the log messages for when the unexpected
occurs.
Signed-off-by: Chr
Quoting Oscar Mateo (2017-11-08 23:59:43)
> Until we agree on a design, I have removed all new code to save the actual
> list
> of WAs and dump it in debugfs. For the moment, only shuffle things arounds
> until
> most WAs are in the same file (and classified correctly according to the type
> of W
On 01/02/2018 08:36, Chris Wilson wrote:
Pull the physical status page cleanup into a common
cleanup_status_page() for caller simplicity.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
di
Quoting Tvrtko Ursulin (2018-02-01 09:42:02)
>
> On 01/02/2018 08:36, Chris Wilson wrote:
> > Pull the physical status page cleanup into a common
> > cleanup_status_page() for caller simplicity.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 23 +++
== Series Details ==
Series: drm/i915: Remove unbannable context spam from reset
URL : https://patchwork.freedesktop.org/series/37470/
State : success
== Summary ==
Series 37470v1 drm/i915: Remove unbannable context spam from reset
https://patchwork.freedesktop.org/api/1.0/series/37470/revisio
On 01/02/2018 08:29, Chris Wilson wrote:
Execlists is now enabled by default and included in the list of
capabilities printed out to dmesg and beyond. We do not need to mention
it again, every time we restart the engine, so kill the spam.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
Quoting Tvrtko Ursulin (2018-02-01 10:02:22)
>
> On 01/02/2018 08:29, Chris Wilson wrote:
> > Execlists is now enabled by default and included in the list of
> > capabilities printed out to dmesg and beyond. We do not need to mention
> > it again, every time we restart the engine, so kill the spam
On 01/02/2018 00:52, Michel Thierry wrote:
From: Daniele Ceraolo Spurio
The main difference with previous GENs is that starting from Gen11
each VCS and VECS engine has its own power well, which only exist
if the related engine exists in the HW.
The fallback forcewake request workaround is only
Op 31-01-18 om 20:57 schreef Harry Wentland:
> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
>> Op 29-01-18 om 16:41 schreef Leo Li:
>>> Updated IGT results seem sane:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>>>
>>> Would someone be able to apply this patch?
>>>
>
Execlists is now enabled by default and included in the list of
capabilities printed out to dmesg and beyond. We do not need to mention
it again, every time we restart the engine, so kill the spam.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 1 -
1 file changed, 1 deletion
Avoid injecting hangs in to the i915->kernel_context in case the GPU
reset leaves corruption in the context image in its wake (leading to
continual failures and system hangs after the selftests are ostensibly
complete). Use a sacrificial kernel_context instead.
Signed-off-by: Chris Wilson
Cc: Mik
---
drivers/gpu/drm/i915/i915_gem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index e920dab7f1b8..1a03b3432cc0 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -48,7 +48
During testing, we trigger a lot of resets on an unbannable context
leading to massive amounts of irrelevant debug spam. Remove the
ban_score accounting and message for the unbannable context so that we
improve the signal:noise in the log messages for when the unexpected
occurs.
Signed-off-by: Chr
In preparation for the next patch, we want the engine to appear idle
after a reset (if there are no requests in flight). For execlists, this
entails clearing the active status on reset, it will be regenerated on
restarting the engine after the reset. In the process, note that a
couple of other stat
Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a
GPU reset on an idle engine") we submit a request following the engine
reset. The intent is that we don't submit a request if the engine is
busy (as it will restart active by itself) but we only checked to see if
there were re
== Series Details ==
Series: drm/i915/execlists: Remove the startup spam
URL : https://patchwork.freedesktop.org/series/37467/
State : success
== Summary ==
Test perf:
Subgroup polling:
pass -> FAIL (shard-hsw) fdo#102252
Test drv_selftest:
Subgroup
We have the max DP link rate info available in VBT since BDB version
216, included in child device config since commit c4fb60b9aba9
("drm/i915/bios: add DP max link rate to VBT child device
struct"). Parse it and use it.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by:
Hi Rodrigo, this is what I had in mind for the DP CNL and VBT rate limiting, I
hope you don't mind me writing the patches. It was easier to express myself in C
than English.
BR,
Jani.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Jani Nikula (3):
drm/i915/dp: abstract rate arra
Make the limiting rate based instead of messing with the array size.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/dr
This will be useful later on. Also move the functions around to not need
forward declarations in subsequent patches. No functional changes.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 38 ++
From: Tvrtko Ursulin
To decrease log spam on GPU reset in case of execlists we move the engine
init messages from the init vfunc to intel_engines_init.
This way on startup we still get information on all available engines in
debug logs, and we replace the reset/resume side of things with a singl
On Wed, 31 Jan 2018, Rodrigo Vivi wrote:
> Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link
> rate to VBT child device struct")' we have the new entry
> defined for max dp rate that is in use for CNL.
>
> Let's start using it for all VBT 216+ and
> also organize the cnl adjusted rates i
== Series Details ==
Series: series starting with [1/6] disable-gem-trace
URL : https://patchwork.freedesktop.org/series/37473/
State : success
== Summary ==
Series 37473v1 series starting with [1/6] disable-gem-trace
https://patchwork.freedesktop.org/api/1.0/series/37473/revisions/1/mbox/
Te
== Series Details ==
Series: drm/i915/dp: refactoring + respect vbt max dp rate
URL : https://patchwork.freedesktop.org/series/37475/
State : success
== Summary ==
Series 37475v1 drm/i915/dp: refactoring + respect vbt max dp rate
https://patchwork.freedesktop.org/api/1.0/series/37475/revisions
== Series Details ==
Series: drm/i915: Combine cleanup_status_page()
URL : https://patchwork.freedesktop.org/series/37468/
State : success
== Summary ==
Test perf:
Subgroup oa-exponents:
pass -> FAIL (shard-apl) fdo#102254
Test drv_selftest:
Subgroup
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
Additional load failure checkpoints added into uC initialization
sequence should help us verify correctness of error handling.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 11 +++
1 file chang
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EI
== Series Details ==
Series: drm/i915: Less verbose engine startup
URL : https://patchwork.freedesktop.org/series/37476/
State : success
== Summary ==
Series 37476v1 drm/i915: Less verbose engine startup
https://patchwork.freedesktop.org/api/1.0/series/37476/revisions/1/mbox/
Test debugfs_tes
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
In case of GuC initialization failure we may continue with driver
load, but we wrongly assume that GuC is fully functional. This
leads to the BUG as we attempt to access non-existing log vma.
[26386.121085] BUG: unable to handle kernel NULL pointe
== Series Details ==
Series: drm/i915: Remove unbannable context spam from reset
URL : https://patchwork.freedesktop.org/series/37470/
State : failure
== Summary ==
Test perf:
Subgroup oa-exponents:
pass -> FAIL (shard-apl) fdo#102254
Subgroup enable
Quoting Tvrtko Ursulin (2018-02-01 11:08:08)
> From: Tvrtko Ursulin
>
> To decrease log spam on GPU reset in case of execlists we move the engine
> init messages from the init vfunc to intel_engines_init.
This still has exactly the same issue, the 10,000 irrelevant debug
messages during selftest
Hi All,
As you may have heard I've recently been working on improving
Linux laptop battery life, specifically the OOTB experience
without tweaking any options such as e.g. powertop --auto-tune
would do, see:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
So far this is going q
Quoting Sagar Arun Kamble (2018-02-01 11:48:54)
>
>
> On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
> > Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure")
> > we believed that we correctly handle all errors encountered during
> > GuC initialization, including special one that i
Quoting Michal Wajdeczko (2018-01-31 17:32:39)
> In case of GuC initialization failure we may continue with driver
> load, but we wrongly assume that GuC is fully functional. This
> leads to the BUG as we attempt to access non-existing log vma.
>
> [26386.121085] BUG: unable to handle kernel NULL
On Thu, Feb 01, 2018 at 01:03:43PM +0200, Jani Nikula wrote:
> We have the max DP link rate info available in VBT since BDB version
> 216, included in child device config since commit c4fb60b9aba9
> ("drm/i915/bios: add DP max link rate to VBT child device
> struct"). Parse it and use it.
>
> Cc:
On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> G4x cursor control registers still allow us to write to the pipe
> select
> bits even though cursors are supposed to be fixed to a specific pipe.
> Bspec tells us that we should only ever write 0 to these bits. Let'
== Series Details ==
Series: series starting with [1/6] disable-gem-trace
URL : https://patchwork.freedesktop.org/series/37473/
State : warning
== Summary ==
Test gem_eio:
Subgroup in-flight-contexts:
fail -> PASS (shard-hsw) fdo#104676
Subgroup in-f
On 31/01/2018 16:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-01-31 16:02:38)
From: Tvrtko Ursulin
By carefully chosing slightly unsynchronized values for timer frequency
and period, we can remove the multiplications from the sampling loop and
replace them with shifts only.
Downside
Avoid injecting hangs in to the i915->kernel_context in case the GPU
reset leaves corruption in the context image in its wake (leading to
continual failures and system hangs after the selftests are ostensibly
complete). Use a sacrificial kernel_context instead.
v2: Closing a context is tricky; exp
== Series Details ==
Series: drm/i915/dp: refactoring + respect vbt max dp rate
URL : https://patchwork.freedesktop.org/series/37475/
State : success
== Summary ==
Test gem_exec_schedule:
Subgroup preempt-other-vebox:
pass -> FAIL (shard-apl) fdo#102848
Test
On Thu, 01 Feb 2018 13:35:15 +0100, Chris Wilson
wrote:
Quoting Sagar Arun Kamble (2018-02-01 11:48:54)
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
> Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure")
> we believed that we correctly handle all errors encountered during
On Thu, 01 Feb 2018 12:43:29 +0100, Sagar Arun Kamble
wrote:
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
Additional load failure checkpoints added into uC initialization
sequence should help us verify correctness of error handling.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
== Series Details ==
Series: series starting with [1/6] disable-gem-trace (rev2)
URL : https://patchwork.freedesktop.org/series/37473/
State : success
== Summary ==
Series 37473v2 series starting with [1/6] disable-gem-trace
https://patchwork.freedesktop.org/api/1.0/series/37473/revisions/2/mb
On 2018-02-01 05:30 AM, Maarten Lankhorst wrote:
> Op 31-01-18 om 20:57 schreef Harry Wentland:
>> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
>>> Op 29-01-18 om 16:41 schreef Leo Li:
Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>
== Series Details ==
Series: drm/i915: Less verbose engine startup
URL : https://patchwork.freedesktop.org/series/37476/
State : success
== Summary ==
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-atomic:
pass -> FAIL (shard-apl) fdo#102670
Test perf:
On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-01-31 18:23:47)
Our inject_load_failure functionality allows to insert one
failure during driver load, but it is hard to guess which
number should passed as modparam to select specific checkpoint.
Use neg
Thanks for clarification.
On 2/1/2018 7:57 PM, Michal Wajdeczko wrote:
On Thu, 01 Feb 2018 12:43:29 +0100, Sagar Arun Kamble
wrote:
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
Additional load failure checkpoints added into uC initialization
sequence should help us verify correctness o
On 2/1/2018 7:53 PM, Michal Wajdeczko wrote:
On Thu, 01 Feb 2018 13:35:15 +0100, Chris Wilson
wrote:
Quoting Sagar Arun Kamble (2018-02-01 11:48:54)
On 1/31/2018 11:02 PM, Michal Wajdeczko wrote:
> Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure")
> we believed that we
On Thu, Feb 01, 2018 at 11:03:41AM +, Jani Nikula wrote:
> This will be useful later on. Also move the functions around to not need
> forward declarations in subsequent patches. No functional changes.
>
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Jani N
On Thu, Feb 01, 2018 at 11:03:42AM +, Jani Nikula wrote:
> Make the limiting rate based instead of messing with the array size.
>
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_d
On Thu, Feb 01, 2018 at 11:03:43AM +, Jani Nikula wrote:
> We have the max DP link rate info available in VBT since BDB version
> 216, included in child device config since commit c4fb60b9aba9
> ("drm/i915/bios: add DP max link rate to VBT child device
> struct"). Parse it and use it.
>
> Cc:
On Thu, Feb 01, 2018 at 11:03:40AM +, Jani Nikula wrote:
> Hi Rodrigo, this is what I had in mind for the DP CNL and VBT rate limiting, I
> hope you don't mind me writing the patches. It was easier to express myself
> in C
> than English.
of course I don't mind. Thanks for the clean version.
Quoting Michal Wajdeczko (2018-02-01 14:47:05)
> On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2018-01-31 18:23:47)
> >> Our inject_load_failure functionality allows to insert one
> >> failure during driver load, but it is hard to guess which
> >> num
On Thu, 01 Feb 2018 16:28:31 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-02-01 14:47:05)
On Wed, 31 Jan 2018 21:48:42 +0100, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2018-01-31 18:23:47)
>> Our inject_load_failure functionality allows to insert one
>> failure during dr
On 2/1/2018 2:25 AM, Tvrtko Ursulin wrote:
On 01/02/2018 00:52, Michel Thierry wrote:
From: Daniele Ceraolo Spurio
The main difference with previous GENs is that starting from Gen11
each VCS and VECS engine has its own power well, which only exist
if the related engine exists in the HW.
The f
From: Daniele Ceraolo Spurio
The main difference with previous GENs is that starting from Gen11
each VCS and VECS engine has its own power well, which only exist
if the related engine exists in the HW.
The fallback forcewake request workaround is only needed on gen9
according to the HSDES WA entr
Quoting Michal Wajdeczko (2018-02-01 15:51:58)
> I was assuming these steps:
>
> 1. add new failure checkpoint(s) to the code
> 2. boot driver with inject modparam=-1 to list active checkpoints
> 3. note the number of checkpoint that we want to trigger
> 4. boot driver with inject modparam=n to tr
From: Ville Syrjälä
Add a .get_hw_state() method for planes, returning true or false
depending on whether the plane is enabled. Use it to rewrite the
plane enabled/disabled asserts in platform agnostic fashion.
We do lose the pre-gen4 plane<->pipe mapping checks, but since we're
supposed sanitiz
From: Ville Syrjälä
Unify the plane disabling during state readout by pulling the code into
a new helper intel_plane_disable_noatomic(). We'll also read out the
state of all planes, so that we know which planes really need to be
diabled.
Additonally we change the plane<->pipe mapping sanitation
From: Ville Syrjälä
i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.
Replace the assert_plane() calls (which calls ->g
From: Ville Syrjälä
These backports fix a plane related regression causing a corrupted
screen and bunch of WARNs from the kernel on some pre-i965 era
hardware.
Cc: # 4.14
Ville Syrjälä (3):
drm/i915: Add .get_hw_state() method for planes
drm/i915: Redo plane sanitation during readout
drm
== Series Details ==
Series: drm/i915: Fix plane regression
URL : https://patchwork.freedesktop.org/series/37492/
State : failure
== Summary ==
Applying: drm/i915: Add .get_hw_state() method for planes
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/intel_display.c).
error
We're using i915_inject_load_failure() to inject dummy
faults during driver load, but since this is debug utility
we shouldn't expose it in default config as it consumes
both code and data.
add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302)
Function old
Hi-
As requested in your blog post, I tested PSR. I see something like
2.69W with PSR off and 2.17W with PSR on. Screen blanking,
suspend/resume, and the contents of the screen all seem okay. This is
a Dell XPS 13 9350, i.e.:
System Information
Manufacturer: Dell Inc.
Product N
Quoting Michal Wajdeczko (2018-02-01 17:32:48)
> We're using i915_inject_load_failure() to inject dummy
> faults during driver load, but since this is debug utility
> we shouldn't expose it in default config as it consumes
> both code and data.
>
> add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302
On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote:
> Hi-
>
> As requested in your blog post, I tested PSR. I see something like
> 2.69W with PSR off and 2.17W with PSR on. Screen blanking,
> suspend/resume, and the contents of the screen all seem okay. This is
> a Dell XPS 13 9350, i.e.:
>
On Thu, 01 Feb 2018 18:42:00 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-02-01 17:32:48)
We're using i915_inject_load_failure() to inject dummy
faults during driver load, but since this is debug utility
we shouldn't expose it in default config as it consumes
both code and data.
Quoting Michal Wajdeczko (2018-02-01 17:45:52)
> On Thu, 01 Feb 2018 18:42:00 +0100, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2018-02-01 17:32:48)
> >> We're using i915_inject_load_failure() to inject dummy
> >> faults during driver load, but since this is debug utility
> >> we sho
== Series Details ==
Series: series starting with [1/6] disable-gem-trace (rev2)
URL : https://patchwork.freedesktop.org/series/37473/
State : success
== Summary ==
Test kms_sysfs_edid_timing:
warn -> PASS (shard-apl) fdo#100047
Test gem_eio:
Subgroup in-fli
Quoting Andy Lutomirski (2018-02-01 17:40:22)
> *However*, I do see one unfortunate side effect of turning on PSR. It
> seems that, when I move my cursor a little bit after a few seconds of
> doing nothing, there seems to be a little bit of lag, as if either a
> few frames are dropped at the begin
On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
> Dear Rodrigo Vivi, Ville Syrjälä,
>
> My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We
> intend to use static analysis tools on the kernel source to identify,
> analyze and report issues. As a very first step, w
Quoting Patchwork (2018-02-01 17:52:06)
> shard-apltotal:2838 pass:1750 dwarn:1 dfail:0 fail:23 skip:1064
> time:12757s
> shard-hswtotal:2838 pass:1735 dwarn:1 dfail:0 fail:11 skip:1090
> time:12008s
> shard-snbtotal:2838 pass:1328 dwarn:2 dfail:0 fail:10 sk
On Tue, Jan 30, 2018 at 04:29:38PM +0200, Imre Deak wrote:
> Currently we see sporadic timeouts during CDCLK changing both on BXT and
> GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
> changing the frequency in a tight loop after blanking the display. The
> upper bound for
== Series Details ==
Series: drm/i915: Enable inject_load_failure only in DEBUG config
URL : https://patchwork.freedesktop.org/series/37495/
State : success
== Summary ==
Series 37495v1 drm/i915: Enable inject_load_failure only in DEBUG config
https://patchwork.freedesktop.org/api/1.0/series/3
Quoting Mika Kuoppala (2018-01-31 13:58:17)
> Chris Wilson writes:
>
> > Rather than having the high level ioctl interface guess the underlying
> > implementation details, having the implementation declare what
> > capabilities it exports. We define an intel_driver_caps, similar to the
> > intel_
Rather than having the high level ioctl interface guess the underlying
implementation details, having the implementation declare what
capabilities it exports. We define an intel_driver_caps, similar to the
intel_device_info, which instead of trying to describe the HW gives
details on what the drive
On Tue, Jan 30, 2018 at 03:06:03PM +0530, Shashank Sharma wrote:
> From: "Sharma, Shashank"
>
> LSPCON chips can generate YCBCR outputs, if asked nicely :).
>
> In order to generate YCBCR 4:2:0 outputs, a source must:
> - send YCBCR 4:4:4 signals to LSPCON
> - program color space as 4:2:0 in AVI
On Tue, Jan 30, 2018 at 03:05:57PM +0530, Shashank Sharma wrote:
> From: "Sharma, Shashank"
>
> Currently, we are using a bool in CRTC state (state->ycbcr420),
> to indicate modeset, that the output format is YCBCR 4:2:0. Now in
> order to support other YCBCR formats, we will need more such flags
On Tue, Jan 30, 2018 at 10:11:49PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915/bxt, glk: Increase PCODE
> timeouts during CDCLK freq changing
> URL : https://patchwork.freedesktop.org/series/37344/
> State : failure
>
> == Summary ==
>
> T
== Series Details ==
Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL
(rev3)
URL : https://patchwork.freedesktop.org/series/37395/
State : failure
== Summary ==
Series 37395v3 series starting with [v2] drm/i915/guc: Allow preempt-client to
be NULL
https://patch
diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c
b/drivers/gpu/drm/i915/intel_guc_ads.c
index ac62753..7215594 100644
--- a/drivers/gpu/drm/i915/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc)
blob->reg_s
On 01/31/2018 11:37 PM, Chris Wilson wrote:
Quoting Jackie Li (2018-01-19 01:29:27)
intel_guc_reg.h should only include definition for GuC registers
and related register bits. GuC WOPCM related values should not
be defined in intel_guc_reg.h
GuC registers does not include GuC WOPCM? The code do
On 01/31/2018 11:38 PM, Chris Wilson wrote:
Quoting Jackie Li (2018-01-19 01:29:28)
GuC related exported functions should start with "intel_guc_"
prefix and pass intel_guc as the first parameter since its guc
related. Current guc_ggtt_offset() failed to follow this code
convention.
But it was
This is a second iteration of the patches originally posted here:
https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
Please see the original cover letter to understand the general goal and
justification for this work.
This series makes the following important chang
There are cases where drivers need to adjust behavior or control
device-specific resources according to the type of clients (processes)
submitting requests. Linux cgroups are a natural fit for this type of
resource control and policy management, so we need a way for drivers to
associate their own
Drivers will need to save/restore the appropriate cgroup data for the process
submitting a driver request. Add an interface for drivers to determine the
cgroup for the userspace process submitting a driver request.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include
Drivers may wish to access a cgroup's inode to perform permission checks on
driver-specific operations.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
fs/kernfs/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index a3430
Register i915 as a consumer of the cgroup_driver framework and add an ioctl to
allow userspace to set i915-specific parameters associated with cgroups.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_
There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-lev
Signed-off-by: Matt Roper
---
include/drm/drm_file.h| 20
kernel/cgroup/cgroup_driver.c | 12 ++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868451a5..72ac40530ad3 100644
--- a/inc
Update i915_context_status to include priority information.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..e9d8e20155b1 100644
1 - 100 of 140 matches
Mail list logo
