On Wed, Feb 07, 2018 at 09:32:35PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
> > On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> > > > 570e86963a5
See bug: https://bugs.freedesktop.org/show_bug.cgi?id=105069
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Saarinen, Jani
> Sent: Tuesday, February 13, 2018 9:35 AM
> To: Kumar, Abhijeet ; Takashi Iwai
> ; Chris Wilson
> Cc: intel-g
These patches failed to cherry-pick on drm-intel-fixes
Please provide a backport or advise how to proceed.
fd10e2ce9905 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers")
1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Thanks,
Rodrigo.
__
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Kumar, Abhijeet
> Sent: tiistai 13. helmikuuta 2018 7.18
> To: Takashi Iwai ; Chris Wilson
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "AL
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Takashi Iwai
> Sent: tiistai 13. helmikuuta 2018 7.11
> To: Chris Wilson
> Cc: intel-gfx@lists.freedesktop.org; Kumar, Abhijeet
>
> Subject: Re: [Intel-gfx] [PATCH] AWOOGA: Revert "
On Fri, Feb 09, 2018 at 11:32:59PM +, James Ausmus wrote:
> On Fri, Feb 09, 2018 at 03:07:55PM +0200, David Weinehall wrote:
> > While the comment singles out Port A or B, the code says Port A or *D*.
> > Looking at the history it seems that the comment was added after the code,
> > so it seems
On 2/13/2018 10:41 AM, Takashi Iwai wrote:
On Mon, 12 Feb 2018 18:29:53 +0100,
Chris Wilson wrote:
This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync power
state")
Cc: Abhijeet Kumar
Cc: Takashi Iwai
Did
On Mon, 12 Feb 2018 18:29:53 +0100,
Chris Wilson wrote:
>
> This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
>
> Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync
> power state")
> Cc: Abhijeet Kumar
> Cc: Takashi Iwai
Did the patch break anything?
I don't
== Series Details ==
Series: tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()
URL : https://patchwork.freedesktop.org/series/38108/
State : failure
== Summary ==
Test pm_rpm:
Subgroup sysfs-read:
fail -> PASS (shard-hsw)
Subgro
== Series Details ==
Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL : https://patchwork.freedesktop.org/series/38107/
State : failure
== Summary ==
Test kms_mmio_vs_cs_flip:
Subgroup setcrtc_vs_cs_flip:
skip -> PASS (shard-
== Series Details ==
Series: series starting with [v10,1/7] drm/i915/guc: Move GuC WOPCM related
code into separate files
URL : https://patchwork.freedesktop.org/series/38119/
State : failure
== Summary ==
Series 38119v1 series starting with [v10,1/7] drm/i915/guc: Move GuC WOPCM
related cod
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 and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offse
GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers which
will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).
This patch moves the GuC
On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware size.
This patch adds new verfication code to ensure the available GuC WOPCM size
to be larger than or equal to HuC firmware size on both Gen9 and CNL A0.
v6:
intel_guc_reg.h should only include definition for GuC registers and
related register bits. Non-register related GuC WOPCM macro definitions
should not be defined in intel_guc_reg.h.
This patch cleans up intel_guc_reg.h and moves GuC WOPCM related code into
new created separate files as future pat
Signed-off-by: Jackie Li
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_params.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gp
Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will l
CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.
This patch updates the code to return CNL specific reserved GuC WOPCM size
for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.
v9:
- Created a new patch for these cha
== Series Details ==
Series: Queued/runnable/running engine stats (rev2)
URL : https://patchwork.freedesktop.org/series/36926/
State : failure
== Summary ==
Test kms_plane_scaling:
Subgroup pipe-a-scaler-with-rotation:
skip -> PASS (shard-apl)
Test kms_vblan
== Series Details ==
Series: RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade
(rev2)
URL : https://patchwork.freedesktop.org/series/38109/
State : failure
== Summary ==
Series 38109v2 RFC drm/i915: Only acquire vblank-irq when waiting for vblank
evade
https://patchwork.fre
== Series Details ==
Series: tests/kms_rotation_crc: Remove hardcoding of platforms in igt_require()
URL : https://patchwork.freedesktop.org/series/38108/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
f8d6fa4fa04103b027430f960f2c55d24c4a9600 igt/gem_exec_c
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 65 ++---
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..ad707c97a9d9
== Series Details ==
Series: AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync
power state"
URL : https://patchwork.freedesktop.org/series/38097/
State : success
== Summary ==
Test pm_rpm:
Subgroup gem-execbuf:
fail -> PASS (shard-hsw)
== Series Details ==
Series: RFC drm/i915: Only acquire vblank-irq when waiting for vblank evade
URL : https://patchwork.freedesktop.org/series/38109/
State : warning
== Summary ==
Series 38109v1 RFC drm/i915: Only acquire vblank-irq when waiting for vblank
evade
https://patchwork.freedesktop
== Series Details ==
Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL : https://patchwork.freedesktop.org/series/38107/
State : success
== Summary ==
Series 38107v1 drm/i915: Release the atomic kmap relocation cache around snb
GTT w/a
https://patchwork.freedes
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 65 ++---
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..dd8c1f24980f
Rework the rotate and reflect subtests by checking the
crtc supported properties against the ones that the
test is testing. Remove the hardcoded platform names in
igt_require()
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Maarten Lankhorst
Cc: Mika Kahola
Signed-off-by: Anusha Srivatsa
---
tests/k
On 09/02/18 03:46, Chris Wilson wrote:
Try to reset the GPU from within igt_require_gem() if we notice we are
starting with a wedged device. If it remains wedged, the test definitely
cannot run. We leave a warning in place to highlight the potentially
suspect result, which will keep the flip-fl
When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding a kmap_atomic() and
we may need to sleep for i915_vma_bind(). In practice, this is not an
issue as we already hold an rpm reference for the execbuffer, but with
tighter error ch
== Series Details ==
Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL : https://patchwork.freedesktop.org/series/38074/
State : failure
== Summary ==
Test pm_rpm:
Subgroup i2c:
fail -> PASS (shard-hsw)
Test kms_plane:
Subgro
Quoting Ville Syrjälä (2018-02-12 18:06:58)
> On Mon, Feb 12, 2018 at 05:24:54PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-02-12 16:55:28)
> > > On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > > > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > > > Quoting M
Quoting Belgaumkar, Vinay (2018-02-12 18:20:31)
>
>
> On 2/10/2018 1:00 AM, Chris Wilson wrote:
> > We run the per-engine scheduling smoketests across all engines, the
> > opposite of what was intended!
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_exec_schedule.c | 12 ---
On Tue, Feb 06, 2018 at 03:12:38PM +0100, Hans de Goede wrote:
> Make intel_bios_cleanup function free the DSI VBT data structures which
> are memdup-ed by parse_mipi_config() and parse_mipi_sequence().
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i
On Tue, Feb 06, 2018 at 03:12:37PM +0100, Hans de Goede wrote:
> Add an intel_bios_cleanup() function to act as counterpart of
> intel_bios_init() and move the cleanup of vbt related resources there,
> putting it in the same file as the allocation.
>
> Signed-off-by: Hans de Goede
> ---
> driver
== Series Details ==
Series: Queued/runnable/running engine stats (rev2)
URL : https://patchwork.freedesktop.org/series/36926/
State : success
== Summary ==
Series 36926v2 Queued/runnable/running engine stats
https://patchwork.freedesktop.org/api/1.0/series/36926/revisions/2/mbox/
Test gem_ri
On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem
From: Tvrtko Ursulin
Enable count array is supposed to have one counter for each possible
engine sampler. As such array sizing and bounds checking is not
correct when more engine samplers are added.
At the same time tidy the assert for readability and robustness.
Signed-off-by: Tvrtko Ursulin
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests currently executing
on the GPU.
This is useful to analyze the overall load of the system.
v2:
* Rebase.
* Drop floating point constant. (Chris Wilson)
v3:
* Change scale to 1024 for faster arithmetics. (Chris Wilson)
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests which have been
submitted from userspace but are not yet runnable due dependencies and
unsignaled fences.
This is useful to analyze the overall load of the system.
v2:
* Rebase for name change and re-order.
* Drop floa
From: Tvrtko Ursulin
Keep a per-engine number of runnable (waiting for GPU time) requests.
v2:
* Move queued increment from insert_request to execlist_submit_request to
avoid bumping when re-ordering for priority.
* Support the counter on the ringbuffer submission path as well, albeit
ju
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests with resolved
dependencies waiting for a slot on the GPU to run.
This is useful to analyze the overall load of the system.
v2: Don't limit to gen8+.
v3:
* Rebase for dynamic sysfs.
* Drop currently executing requests.
From: Tvrtko Ursulin
Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencies.
v2: Rename and move under the container struct. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
drivers/gpu/drm/i915/intel
From: Tvrtko Ursulin
Per-engine queue depths are an interesting metric for analyzing the system load
and also for users who wish to use it to load balance their submissions based
on it.
In this version I have split the metrics into three separate counters:
1. QUEUED - From execbuf time to reque
On Mon, Feb 12, 2018 at 05:50:12PM +, Chris Wilson wrote:
> Quoting Lyude Paul (2018-02-12 17:46:11)
> > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > > Introduce a helper to determine if the current task is an output poll
> > > worker.
> > >
> > > This allows us to fix a long-sta
On Mon, Feb 12, 2018 at 05:37:56PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-12 17:30:52)
> > On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> > > On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> > > so we must request a SECURE batch.
> >
== Series Details ==
Series: AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync
power state"
URL : https://patchwork.freedesktop.org/series/38097/
State : success
== Summary ==
Series 38097v1 AWOOGA: Revert "ALSA: hda: Make use of core codec functions to
sync power state"
ht
On 2/10/2018 1:00 AM, Chris Wilson wrote:
We run the per-engine scheduling smoketests across all engines, the
opposite of what was intended!
Signed-off-by: Chris Wilson
---
tests/gem_exec_schedule.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tests/gem_
== Series Details ==
Series: drm: Use idr_init_base(1) when using id==0 for invalid
URL : https://patchwork.freedesktop.org/series/38089/
State : success
== Summary ==
Test gem_softpin:
Subgroup noreloc-s4:
fail -> SKIP (shard-snb) fdo#103375
Test gem_eio:
On Mon, Feb 12, 2018 at 05:24:54PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-12 16:55:28)
> > On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> > > >> Op 12-
Quoting Lyude Paul (2018-02-12 17:46:11)
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> >
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend ca
== Series Details ==
Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL : https://patchwork.freedesktop.org/series/38074/
State : success
== Summary ==
Series 38074v1 drm/i915: Always catch incorrect usage of intel_runtime_pm_get
https://patchwork.freedesktop.org/api/1.
On Sat, Feb 10, 2018 at 08:39:08AM +, Chris Wilson wrote:
> Quoting Oscar Mateo (2018-02-09 23:46:31)
> >
> > On 02/09/2018 02:35 PM, Chris Wilson wrote:
> > > In order to allow the compiler to use a known constant number of
> > > available engines, disable modification of intel_device_static_
On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
>
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish a
This patchset is a no-brainer for me. I'm ashamed to say I think I might have
seen this issue before, but polling gets used so rarely nowadays it slipped
under the rug by accident.
Anyway, for the whole series (except patch #2, which I will respond to with a
short comment in just a moment):
Revi
On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote:
> Hi,
>
> On 12-02-18 07:08, Dhinakaran Pandiyan wrote:
> > PSR currently when enabled results in semi-permanent freezes or noticeable
> > cursor lags.
> >
> > https://patchwork.freedesktop.org/series/37598/ will fix long freezes due
> >
Quoting Ville Syrjälä (2018-02-12 17:30:52)
> On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> > On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> > so we must request a SECURE batch.
>
> IIRC ctg supposedly introduced some form of ppgtt. Isn't that the
> r
Quoting Patchwork (2018-02-12 17:19:01)
> == Series Details ==
>
> Series: drm/i915: Replace open-coded memset_p()
> URL : https://patchwork.freedesktop.org/series/38082/
> State : success
>
> == Summary ==
>
> Test pm_rpm:
> Subgroup gem-idle:
> fail -> PASS
On Sat, Feb 10, 2018 at 09:43:38PM +, Chris Wilson wrote:
> On ctg/ilk, for whatever reason, MI_STORE_DWORD is a privileged operation
> so we must request a SECURE batch.
IIRC ctg supposedly introduced some form of ppgtt. Isn't that the
reason?
Hmm. Now I wonder how anything works on these pl
On Sat, Feb 10, 2018 at 09:43:59AM +, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-09 17:55:38)
> > On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi wrote:
> > > Rodrigo Vivi writes:
> > > So, I move the hacked scheduled to 10s and forced psr_activate 10ms
> > > after that and the resul
This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync power
state")
Cc: Abhijeet Kumar
Cc: Takashi Iwai
---
sound/pci/hda/hda_codec.c | 28 +++-
sound/pci/hda/hda_local.h | 6 +-
2 fi
Quoting Ville Syrjälä (2018-02-12 16:55:28)
> On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> > Op 12-02-18 om 16:31 schreef Chris Wilson:
> > > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> > >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > >>> Quoting Maarten Lankhorst (
== Series Details ==
Series: drm/i915: Replace open-coded memset_p()
URL : https://patchwork.freedesktop.org/series/38082/
State : success
== Summary ==
Test pm_rpm:
Subgroup gem-idle:
fail -> PASS (shard-hsw)
shard-apltotal:3391 pass:1763 dwarn:1
On Mon, Feb 12, 2018 at 02:55:33PM +, Chris Wilson wrote:
> Use the new idr_init_base() function to create an IDR that knows id==0
> is never allocated as it maps to an invalid identifier. By knowing that
> id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
> of having to
Hello,
On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Introduce a helper to retrieve the current task's work struct if it is
> a workqueue worker.
>
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for a specif
On Fri, Feb 09, 2018 at 06:21:08PM +0100, Maarten Lankhorst wrote:
> Op 09-02-18 om 11:04 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:53:59)
> >> Some cleanups to move the uncore.lock around vblank evasion, so run
> >> to completion without racing on uncore.lock. Hopefully th
== Series Details ==
Series: drm/i915: Grab the vblank evasion lock around the entire evasion.
URL : https://patchwork.freedesktop.org/series/37986/
State : warning
== Summary ==
Test gem_eio:
Subgroup in-flight:
pass -> DMESG-WARN (shard-snb) fdo#104058
Test pm_r
On Mon, Feb 12, 2018 at 04:41:05PM +0100, Maarten Lankhorst wrote:
> Op 12-02-18 om 16:31 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> >> Op 12-02-18 om 16:22 schreef Chris Wilson:
> >>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> Op 12-02-18 om 16:10 schre
On Fri, Feb 09, 2018 at 09:16:54PM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 2 ++
> drivers/gpu/drm/i915/intel_fbc.c | 3
On Fri, Feb 09, 2018 at 09:16:52PM +, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 8a570f75d67e..d5f34f124e34 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_in
Op 12-02-18 om 16:44 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:39:16)
>> Op 12-02-18 om 16:19 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-09 09:54:02)
This requires being able to read the vblank counter with the
uncore.lock already held. This is als
== Series Details ==
Series: drm: Use idr_init_base(1) when using id==0 for invalid
URL : https://patchwork.freedesktop.org/series/38089/
State : success
== Summary ==
Series 38089v1 drm: Use idr_init_base(1) when using id==0 for invalid
https://patchwork.freedesktop.org/api/1.0/series/38089/r
Quoting Maarten Lankhorst (2018-02-12 15:39:16)
> Op 12-02-18 om 16:19 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:54:02)
> >> This requires being able to read the vblank counter with the
> >> uncore.lock already held. This is also a preparation for
> >> being able to run the
== Series Details ==
Series: drm/i915: Always catch incorrect usage of intel_runtime_pm_get
URL : https://patchwork.freedesktop.org/series/38074/
State : failure
== Summary ==
Series 38074v1 drm/i915: Always catch incorrect usage of intel_runtime_pm_get
https://patchwork.freedesktop.org/api/1.
On Fri, Feb 09, 2018 at 03:24:28AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it
> URL : https://patchwork.freedesktop.org/series/37936/
> State : success
Pushed it to -dinq with the s/Reference:/References:/ change
Op 12-02-18 om 16:31 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:27:34)
>> Op 12-02-18 om 16:22 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
Op 12-02-18 om 16:10 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
>>
Op 12-02-18 om 16:19 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:02)
>> This requires being able to read the vblank counter with the
>> uncore.lock already held. This is also a preparation for
>> being able to run the entire vblank update sequence with
>> the uncore lock hel
Quoting Maarten Lankhorst (2018-02-12 15:27:34)
> Op 12-02-18 om 16:22 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> >> Op 12-02-18 om 16:10 schreef Chris Wilson:
> >>> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> This is a nice preparation for grabbing the u
Op 12-02-18 om 16:22 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-12 15:16:39)
>> Op 12-02-18 om 16:10 schreef Chris Wilson:
>>> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
This is a nice preparation for grabbing the uncore lock during evasion.
Grabbing the spinlock with
Quoting Maarten Lankhorst (2018-02-12 15:16:39)
> Op 12-02-18 om 16:10 schreef Chris Wilson:
> > Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> >> This is a nice preparation for grabbing the uncore lock during evasion.
> >> Grabbing the spinlock with the lock held messes up the locking,
> >> so
Quoting Maarten Lankhorst (2018-02-09 09:54:02)
> This requires being able to read the vblank counter with the
> uncore.lock already held. This is also a preparation for
> being able to run the entire vblank update sequence with
> the uncore lock held.
>
> Signed-off-by: Maarten Lankhorst
> ---
>
== Series Details ==
Series: drm/i915: Replace open-coded memset_p()
URL : https://patchwork.freedesktop.org/series/38082/
State : success
== Summary ==
Series 38082v1 drm/i915: Replace open-coded memset_p()
https://patchwork.freedesktop.org/api/1.0/series/38082/revisions/1/mbox/
Test kms_cha
Op 12-02-18 om 16:10 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:54:00)
>> This is a nice preparation for grabbing the uncore lock during evasion.
>> Grabbing the spinlock with the lock held messes up the locking,
>> so it's easier to handover the reference to the eve
>>
>> Sig
Quoting Maarten Lankhorst (2018-02-09 09:54:01)
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 10 ++
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff
Quoting Maarten Lankhorst (2018-02-09 09:54:00)
> This is a nice preparation for grabbing the uncore lock during evasion.
> Grabbing the spinlock with the lock held messes up the locking,
> so it's easier to handover the reference to the event.
>
> Signed-off-by: Maarten Lankhorst
> ---
> driver
== Series Details ==
Series: drm/i915: Grab the vblank evasion lock around the entire evasion.
URL : https://patchwork.freedesktop.org/series/37986/
State : success
== Summary ==
Series 37986v1 drm/i915: Grab the vblank evasion lock around the entire evasion.
https://patchwork.freedesktop.org/
Use the new idr_init_base() function to create an IDR that knows id==0
is never allocated as it maps to an invalid identifier. By knowing that
id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
of having to start each lookup from the zeroth leaf as id==0 is always
unused (and
On Wed, 2018-01-24 at 18:20 +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal
>
> This patch adds the support to print the aspect ratio of the modes
> (if provided) along with other mode information.
>
> Signed-off-by: Ankit Nautiyal
> ---
> lib/igt_kms.c | 31
Chris Wilson writes:
> When initialising the page directories, we set the GTT entries and the
> tree to the scratch page. We have already replaced the DMA fill with
> memset64(), but we can similarly use memset_p() to set the pointer array.
>
> References: 4dd504f7d98a ("drm/i915: Use memset64()
On 12 February 2018 at 13:31, Chris Wilson wrote:
> When initialising the page directories, we set the GTT entries and the
> tree to the scratch page. We have already replaced the DMA fill with
> memset64(), but we can similarly use memset_p() to set the pointer array.
>
> References: 4dd504f7d98a
Quoting Mika Kuoppala (2018-02-12 13:28:54)
> Chris Wilson writes:
>
> > When dumping the engine, we print out the current register values. This
> > requires the rpm wakeref. If the device is alseep, we can assume the
> > engine is asleep (and the register state is uninteresting) so skip and
> >
When initialising the page directories, we set the GTT entries and the
tree to the scratch page. We have already replaced the DMA fill with
memset64(), but we can similarly use memset_p() to set the pointer array.
References: 4dd504f7d98a ("drm/i915: Use memset64() to prefill the GTT page")
Signed
Chris Wilson writes:
> When dumping the engine, we print out the current register values. This
> requires the rpm wakeref. If the device is alseep, we can assume the
> engine is asleep (and the register state is uninteresting) so skip and
> only acquire the rpm wakeref if the device is already aw
On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend. But this results in the GPU bouncing back and forth
> between D0 and D3 continuously. That's a total no-go for GPUs which
> runtim
== Series Details ==
Series: drm/i915: Hold rpm wakeref for printing the engine's register state
URL : https://patchwork.freedesktop.org/series/38077/
State : success
== Summary ==
Test perf:
Subgroup oa-exponents:
pass -> FAIL (shard-apl) fdo#102254
Test ge
On Mon, Feb 12, 2018 at 12:33:57PM +0200, Jani Nikula wrote:
> On Thu, 08 Feb 2018, Imre Deak wrote:
> > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > platforms. Do it only on SNB, IVB and HSW, where we use this command
> >
On Mon, Feb 12, 2018 at 11:19:09AM +, Chris Wilson wrote:
> Quoting Imre Deak (2018-02-08 18:44:41)
> > On Thu, Feb 08, 2018 at 06:33:03PM +, Chris Wilson wrote:
> > > Quoting Imre Deak (2018-02-08 17:41:02)
> > > > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > > > MAILBOX_P24C_CC_ILLEG
On 12/02/18 11:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-02-12 11:00:10)
On 12/02/18 10:41, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-02-12 10:37:52)
On 09/02/18 20:53, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-02-09 17:47:44)
Hey Chris,
From the i915/p
== Series Details ==
Series: drm/i915: Don't wake the device up to check if the engine is asleep
URL : https://patchwork.freedesktop.org/series/38075/
State : failure
== Summary ==
Test perf:
Subgroup oa-exponents:
pass -> FAIL (shard-apl) fdo#102254
Quoting Imre Deak (2018-02-08 18:44:41)
> On Thu, Feb 08, 2018 at 06:33:03PM +, Chris Wilson wrote:
> > Quoting Imre Deak (2018-02-08 17:41:02)
> > > On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
> > > MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
> > > platforms. Do it onl
Quoting Lionel Landwerlin (2018-02-12 11:00:10)
> On 12/02/18 10:41, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-02-12 10:37:52)
> >> On 09/02/18 20:53, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2018-02-09 17:47:44)
> Hey Chris,
>
> From the i915/perf point
1 - 100 of 123 matches
Mail list logo
