== Series Details ==
Series: series starting with [CI,1/2] drm/i915/guc: enable guc interrupts
unconditionally in uc_resume
URL : https://patchwork.freedesktop.org/series/40832/
State : failure
== Summary ==
Possible new issues:
Test gem_eio:
Subgroup execbuf:
pa
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, March 28, 2018 3:36 AM
> To: Maarten Lankhorst
> Cc: Sripada, Radhakrishna ; igt-
> d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
> ; Vetter, Daniel ; Vivi
snd_hdac driver would use the component interface from i915 driver.
if i915 driver do the audio component intialization too late, snd_hdac
driver will meet ipanic.
Signed-off-by: Bo He
Signed-off-by: Yang Shi
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i915/intel_display.c
== Series Details ==
Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
URL : https://patchwork.freedesktop.org/series/40851/
State : success
== Summary ==
Series 40851v1 drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
https://patchwork.freedesktop.org/ap
== Series Details ==
Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2)
URL : https://patchwork.freedesktop.org/series/40825/
State : failure
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-dpms:
fail ->
Four drm_mm_node are used to reserve guest ggtt space, but some of them
may aren't initialized and used in intel_vgt_balloon(), so these unused
drm_mm_node couldn't be removed through drm_mm_remove_node().
Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under
gvt environmen
>Среда, 28 марта 2018, 21:30 +03:00 от Tvrtko Ursulin :
>
>+static struct engines *discover_engines(void)
> {
>-uint32_t devid = pci_dev->device_id;
>-uint16_t gcfgc;
>+const char *sysfs_root = "/sys/devices/i915/events";
Just a question.
I think, I have Linux 4.15.11 (from Debian testing) now.
== Series Details ==
Series: drm/i915: Only warn for might_sleep() before a slow wait_for_register
URL : https://patchwork.freedesktop.org/series/40823/
State : failure
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-dpms:
fail
Quoting Chris Wilson (2018-03-29 02:01:37)
> Quoting Francisco Jerez (2018-03-29 01:32:07)
> > Chris Wilson writes:
> > > + else
> > > + execlists_end(execlists);
> > > } else {
> > >
Quoting Francisco Jerez (2018-03-29 01:32:07)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2018-03-28 20:20:19)
> >> Quoting Francisco Jerez (2018-03-28 19:55:12)
> >> > Hi Chris,
> >> >
> >> [snip]
> >> > That said, it wouldn't hurt to call each of them once per sequence of
> >> > overlap
Chris Wilson writes:
> Quoting Chris Wilson (2018-03-28 20:20:19)
>> Quoting Francisco Jerez (2018-03-28 19:55:12)
>> > Hi Chris,
>> >
>> [snip]
>> > That said, it wouldn't hurt to call each of them once per sequence of
>> > overlapping requests. Do you want me to call them from
>> > execlists_
== Series Details ==
Series: drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
URL : https://patchwork.freedesktop.org/series/40821/
State : failure
== Summary ==
Possible new issues:
Test drv_selftest:
Subgroup live_hangcheck:
pass -> DMESG-FAIL (
== Series Details ==
Series: series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit
URL : https://patchwork.freedesktop.org/series/40839/
State : warning
== Summary ==
Series 40839v1 series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit
https://patchwork.freedesktop.org/ap
== Series Details ==
Series: series starting with [v3,01/10] drm: Add DP PSR2 sink enable bit
URL : https://patchwork.freedesktop.org/series/40839/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
83dbb7136992 drm: Add DP PSR2 sink enable bit
36672bef768d drm: Add DP last received
== Series Details ==
Series: drm/i915: Avoid sleeping inside per-engine reset
URL : https://patchwork.freedesktop.org/series/40838/
State : success
== Summary ==
Series 40838v1 drm/i915: Avoid sleeping inside per-engine reset
https://patchwork.freedesktop.org/api/1.0/series/40838/revisions/1/m
On Wed, 2018-03-28 at 17:37 +, Pandiyan, Dhinakaran wrote:
>
>
> On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote:
> > On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote:
> > > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > > > On Mon, Mar 26, 2018 at 0
Quoting Patchwork (2018-03-29 00:01:23)
> == Series Details ==
>
> Series: series starting with [01/15] drm/i915/execlists: Refactor out
> complete_preempt_context()
> URL : https://patchwork.freedesktop.org/series/40834/
> State : failure
>
> == Summary ==
>
> Series 40834v1 series starting
== Series Details ==
Series: ICL PLLs, DP/HDMI and misc display (rev5)
URL : https://patchwork.freedesktop.org/series/38737/
State : success
== Summary ==
Series 38737v5 ICL PLLs, DP/HDMI and misc display
https://patchwork.freedesktop.org/api/1.0/series/38737/revisions/5/mbox/
Possible n
Quoting Chris Wilson (2018-03-28 20:20:19)
> Quoting Francisco Jerez (2018-03-28 19:55:12)
> > Hi Chris,
> >
> [snip]
> > That said, it wouldn't hurt to call each of them once per sequence of
> > overlapping requests. Do you want me to call them from
> > execlists_set/clear_active() themselves wh
== Series Details ==
Series: ICL PLLs, DP/HDMI and misc display (rev5)
URL : https://patchwork.freedesktop.org/series/38737/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
faa292edccbc drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL
890b377784c4 drm/i915/icl: add defin
== Series Details ==
Series: series starting with [01/15] drm/i915/execlists: Refactor out
complete_preempt_context()
URL : https://patchwork.freedesktop.org/series/40834/
State : failure
== Summary ==
Series 40834v1 series starting with [01/15] drm/i915/execlists: Refactor out
complete_pree
== Series Details ==
Series: series starting with [01/15] drm/i915/execlists: Refactor out
complete_preempt_context()
URL : https://patchwork.freedesktop.org/series/40834/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a016c0c4e8a6 drm/i915/execlists: Refactor out complete_pree
== Series Details ==
Series: drm/i915: warn only once about ddi translation table missing
URL : https://patchwork.freedesktop.org/series/40833/
State : success
== Summary ==
Series 40833v1 drm/i915: warn only once about ddi translation table missing
https://patchwork.freedesktop.org/api/1.0/se
Although i915 don't implement aux sync frame through tests was
findout that pannels can do selective update when the y-coordinate
is also included in SDP, that is why it is required to run PSR2 in
i915.
So moving to only one place the sink requirements that the actual
driver needs to enable PSR2.
In the 2 eDP1.4a pannels tested set or not set bit have no effect
but is better set it and comply with specification.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
---
v3: rebased
drivers/gpu/drm/i915/intel_psr.c | 11 ++-
1 file changed, 6 in
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v3: rebased
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
1 file changed, 29 ins
This value do not change overtime so better cache it than
fetch it every PSR enable.
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v3: rebased
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 28 -
Sink can support our PSR2 requirements but userspace can request
a resolution that PSR2 hardware do not support, in this case it
was overwritten the PSR2 sink support.
Adding another flag here, this way if requested resolution changed
to a value that PSR2 hardware can handle, PSR2 can be enabled.
eDP spec states that aux frame is required to do PSR2 selective
update but i915 don't fully implement it. It sends the aux frame
sync messages but the value is always zero as the GTC is not enabled
in driver.
Through tests was findout that pannels can do selective update when
the y-coordinate is a
To comply with eDP1.4a this bit should be set when enabling PSR2.
Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
---
v3: rebased
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 6290
Cosmetic change.
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v3: rebased
drivers/gpu/drm/i915/i915_reg.h | 3 ++-
drivers/gpu/drm/i915/intel_psr.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i
For Geminilake and Cannonlake+ the Y-coordinate support must be
enabled in PSR2_CTL too.
Spec: 7713 and 7720
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v3: rebased
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_psr.c | 1
This is a register to help debug what is in the last SDP VSC
packet revived by sink.
Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
---
v3: rebased
include/drm/drm_dp_helper.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/dr
Quoting Chris Wilson (2018-03-28 23:30:56)
> Only sleep and repeat when asked for a full device reset (ALL_ENGINES)
> and avoid using sleeping waits when asked for a per-engine reset. The
> goal is to be able to use a per-engine reset from hardirq/softirq/timer
> context. A consequence is that our
Only sleep and repeat when asked for a full device reset (ALL_ENGINES)
and avoid using sleeping waits when asked for a per-engine reset. The
goal is to be able to use a per-engine reset from hardirq/softirq/timer
context. A consequence is that our individual wait timeouts are a
thousand times short
Quoting Lis, Tomasz (2018-03-28 17:06:58)
>
>
> On 2018-03-28 01:27, Chris Wilson wrote:
> > Quoting Tomasz Lis (2018-03-27 16:17:59)
> >> The patch adds support of preempt-to-idle requesting by setting a proper
> >> bit within Execlist Control Register, and receiving preemption result from
> >>
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/guc: enable guc interrupts
unconditionally in uc_resume
URL : https://patchwork.freedesktop.org/series/40832/
State : success
== Summary ==
Series 40832v1 series starting with [CI,1/2] drm/i915/guc: enable guc
interrupts unc
From: Manasi Navare
On clock recovery this function is called to find out
the max voltage swing level that we could go.
However gen 9 functions use the old buffer translation tables
to figure that out. ICL uses different set of tables for eDP
and DP for both Combo and MG PHY ports. This patch ad
Just use the hardcoded tables provided by our spec.
v2: Rebase.
v3: Clarify that 38.4 uses the 19.2 table (James).
Reviewed-by: James Ausmus
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 87 ++-
1 file changed, 86 insertions(+), 1 delet
From: James Ausmus
These fields have been deprecated and moved in ICL+. Stop setting the
bits.
They have moved to GAMMA_MODE and CSC_MODE, respectively. This patch
is just to stop incorrectly setting bits in PLANE_COLOR_CTL while
we're waiting for the new replacement functionality to be done.
v
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be intro
From: Manasi Navare
This is an important part of the DDI initalization as well as
for changing the voltage during DisplayPort link training.
The Voltage swing seqeuence is similar to Cannonlake.
However it has different register definitions and hence
it makes sense to create a separate vswing se
HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
the CNL code.
v2:
- Properly detect HDMI crtcs.
- Rebase after changes to the cnl function (clock * 1000).
v3:
- Add a comment to clarify why we treat 38.4 as 19.2 (James).
Reviewed-by: James Ausmus
Signed-off-by: Paulo Zanon
This implements the "MG PLL Programming" sequence from our spec. The
biggest problem was that the spec assumes real numbers, so we had to
adjust some numbers and alculations due to the fact that the Kernel
prefers to deal with integers.
I recommend grabbing some coffee, a pen and paper before revi
There's a lot of code for the PLL enabling, so let's first only
introduce the register definitions in order to make patch reviewing a
little easier.
v2: Coding style (Jani).
v3: Preparation for upstreaming.
v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James).
Cc: James Ausmus
Signed-
We already merged some patches from this series, so this new version is smaller.
Some of the patches here already have R-B tags but they depend on non-reviewed
patches.
Only patches 2, 3 and 7 need reviews. I don't think I can qualify as a reviewer
for patch 7 anymore due to how much I changed it.
On 28/03/18 14:52, Chris Wilson wrote:
Quoting Michel Thierry (2018-03-28 22:47:55)
On 28/03/18 14:18, Chris Wilson wrote:
@@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
unsigned engine_mask)
int retry;
int ret;
- might_sleep();
+ might_
Quoting Michel Thierry (2018-03-28 22:47:55)
> On 28/03/18 14:18, Chris Wilson wrote:
> > @@ -2094,7 +2095,7 @@ int intel_gpu_reset(struct drm_i915_private
> > *dev_priv, unsigned engine_mask)
> > int retry;
> > int ret;
> >
> > - might_sleep();
> > + might_sleep_if(engine_m
On 3/28/2018 2:39 AM, Tvrtko Ursulin wrote:
On 27/03/2018 23:14, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank
pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
On 28/03/18 14:18, Chris Wilson wrote:
Only sleep and repeat when asked for a full device reset (ALL_ENGINES)
and avoid using sleeping waits when asked for a per-engine reset. The
goal is to be able to use a per-engine reset from hardirq/softirq/timer
context. A consequence is that our individual
Quoting Chris Wilson (2018-03-28 22:18:53)
> @@ -1221,7 +1287,7 @@ static void execlists_schedule(struct i915_request
> *request, int prio)
>
> if (prio > engine->execlists.queue_priority &&
> i915_sw_fence_done(&pt_to_request(pt)->submit))
> -
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
v2: Install the timer on scheduling the preempt request; long bef
Only sleep and repeat when asked for a full device reset (ALL_ENGINES)
and avoid using sleeping waits when asked for a per-engine reset. The
goal is to be able to use a per-engine reset from hardirq/softirq/timer
context. A consequence is that our individual wait timeouts are a
thousand times short
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i91
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC:
EGL_NV_realtime_priority?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22
drivers/gpu/drm/i915/i915_gem_context.h| 13 +
drivers/gpu/drm/i915/i915_request.c| 8 ++-
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being ba
As intel_wait_for_register_fw() may use, and if successful only use, a
busy-wait loop, the might_sleep() warning is a little over-zealous.
Restrict it to a might_sleep_if() a slow timeout is specified (and so
the caller authorises use of a usleep).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
When circumstances allow, trying resetting the engine directly from the
preemption timeout handler. As this is softirq context, we have to be
careful both not to sleep and not to spin on anything we may be
interrupting (e.g. the submission tasklet).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the ta
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
trigg
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
dr
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Reviewed-by: Jeff McGee
---
drivers/
The original goal for per-engine reset was to allow them from irq
context for the purpose of implementing a fast watchdog. However, since
we haven't been using them from even softirq context, we have
accumulated a number of sleeps and synchronous waits. With the desire
for a fast reset to unblock p
Quoting Michel Thierry (2018-03-28 22:03:04)
> It's not like it will magically appear or disappear ;)
You know the quote,
"With an infinite amount of spam, we get Shakespeare."
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lis
It's not like it will magically appear or disappear ;)
Signed-off-by: Michel Thierry
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85.
Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC
interrupts enabled when using GuC").
Not really needed since i915_gem_init_hw is called before uc_resume, but
it brings symmetry to uc_suspend.
Signed-off-by: Michel Thierry
Cc: Michał Winiarski
Reviewed-by: Michał Winiar
From: Michal Wajdeczko
Stolen from...
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c96360398072..53037b5eff22 100644
---
== Series Details ==
Series: drm/i915/selftests: Add basic sanitychecks for execlists
URL : https://patchwork.freedesktop.org/series/40805/
State : success
== Summary ==
Possible new issues:
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-onoff:
Quoting Patchwork (2018-03-28 09:22:48)
> == Series Details ==
>
> Series: drm/i915/guc: Support for Guc responses and requests (rev5)
> URL : https://patchwork.freedesktop.org/series/28393/
> State : failure
>
> == Summary ==
>
> Possible new issues:
>
> Test debugfs_test:
> Sub
On Wed, 2018-03-28 at 20:13 +0100, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40)
> >
> > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> > > As intel_wait_for_register_fw() may use, and if successful only use, a
> > > busy-wait loop, the might_sleep() warning
Quoting Patchwork (2018-03-28 08:07:45)
> == Series Details ==
>
> Series: drm/i915/execlists: Reset ring registers on rebinding contexts
> URL : https://patchwork.freedesktop.org/series/40763/
> State : failure
>
> == Summary ==
>
> Possible new issues:
>
> Test kms_flip:
> Subg
== Series Details ==
Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev2)
URL : https://patchwork.freedesktop.org/series/40825/
State : success
== Summary ==
Series 40825v2 drm/i915/breadcrumbs: Keep the fake irq armed across reset
https://patchwork.freedesktop.org/api/1.0
Quoting Francisco Jerez (2018-03-28 19:55:12)
> Hi Chris,
>
[snip]
> That said, it wouldn't hurt to call each of them once per sequence of
> overlapping requests. Do you want me to call them from
> execlists_set/clear_active() themselves when bit == EXECLISTS_ACTIVE_USER,
> or at each callsite of
Hi Dave,
Here's a lonely fix for -next, please pull at your convenience.
drm-misc-next-fixes-2018-03-28:
UABI:
- Mask mode type garbage from userspace (Ville)
Cc: Ville Syrjälä
Cheers, Sean
The following changes since commit b4eec0fa537165efc3265cdbb4bac06e6bdaf596:
Merge tag 'drm-intel-
Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40)
>
> On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> > As intel_wait_for_register_fw() may use, and if successful only use, a
> > busy-wait loop, the might_sleep() warning is a little over-zealous.
> > Restrict it to a might_sleep_if() a s
== Series Details ==
Series: drm/i915: Only warn for might_sleep() before a slow wait_for_register
URL : https://patchwork.freedesktop.org/series/40823/
State : success
== Summary ==
Series 40823v1 drm/i915: Only warn for might_sleep() before a slow
wait_for_register
https://patchwork.freedes
Hi Chris,
Chris Wilson writes:
> Quoting Francisco Jerez (2018-03-28 07:38:45)
>> This allows cpufreq governors to realize when the system becomes
>> non-CPU-bound due to GPU rendering activity, which will cause the
>> intel_pstate LP controller to behave more conservatively: CPU energy
>> usage
On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> As intel_wait_for_register_fw() may use, and if successful only use, a
> busy-wait loop, the might_sleep() warning is a little over-zealous.
> Restrict it to a might_sleep_if() a slow timeout is specified (and so
> the caller authorises use
On 28/03/18 19:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
register access. This patch rewrites it to use only PMU.
Only overall command streamer busyness and GPU global data such as power
and frequencies are included
Quoting Tvrtko Ursulin (2018-03-28 19:29:48)
> From: Tvrtko Ursulin
>
> intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
> register access. This patch rewrites it to use only PMU.
>
> Only overall command streamer busyness and GPU global data such as power
> and frequenc
From: Tvrtko Ursulin
intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
register access. This patch rewrites it to use only PMU.
Only overall command streamer busyness and GPU global data such as power
and frequencies are included in this new version.
For access to more G
== Series Details ==
Series: drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
URL : https://patchwork.freedesktop.org/series/40821/
State : success
== Summary ==
Series 40821v1 drm/i915/execlists: Consistent seqno reporting in GEM_TRACE
https://patchwork.freedesktop.org/api/1.0/seri
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
As intel_wait_for_register_fw() may use, and if successful only use, a
busy-wait loop, the might_sleep() warning is a little over-zealous.
Restrict it to a might_sleep_if() a slow timeout is specified (and so
the caller authorises use of a usleep).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
Quoting Tvrtko Ursulin (2018-03-28 18:39:59)
> From: Tvrtko Ursulin
>
> Some messages are using %d and some %x which creates confusion while
> reading the traces.
>
> I also added:
>
> 1. Fence context/seqno to elsp traces - so it is easier to correlate
> events.
>
> 2. New GEM_TRACE log
From: Tvrtko Ursulin
Some messages are using %d and some %x which creates confusion while
reading the traces.
I also added:
1. Fence context/seqno to elsp traces - so it is easier to correlate
events.
2. New GEM_TRACE logging to port and request cancellation sites.
Signed-off-by: Tvrtko
On Wed, 2018-03-28 at 13:28 +0300, Ville Syrjälä wrote:
> On Tue, Mar 27, 2018 at 06:33:11PM +, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> > > On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > > > Interrupts other than the
The rework looks good to me.
Thanks Mika for testing this.
>-Original Message-
>From: Kahola, Mika
>Sent: Wednesday, March 28, 2018 1:26 AM
>To: Sripada, Radhakrishna ; igt-
>d...@lists.freedesktop.org
>Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
>; Ville Syrjälä ;
>Vetter,
>Da
On Wed, Mar 28, 2018 at 04:51:55PM +0300, Joonas Lahtinen wrote:
> Quoting Daniele Ceraolo Spurio (2018-03-23 19:17:49)
> >
> >
> > On 23/03/18 05:34, Michał Winiarski wrote:
> > > We're seeing "RPM wakelock ref not held during HW access" warning
> > > otherwise. And since IRQ are synced for runt
Quoting Tvrtko Ursulin (2018-03-28 17:26:37)
>
> On 27/03/2018 22:01, Chris Wilson wrote:
> > Tvrtko uncovered a fun issue with recovering from a wedge device. In his
> > tests, he wedged the driver by injecting an unrecoverable hang whilst a
> > batch was spinning. As we reset the gpu in the midd
On 27/03/2018 22:01, Chris Wilson wrote:
Tvrtko uncovered a fun issue with recovering from a wedge device. In his
tests, he wedged the driver by injecting an unrecoverable hang whilst a
batch was spinning. As we reset the gpu in the middle of the spinner,
when resumed it would continue on from t
On Fri, Mar 23, 2018 at 05:28:03PM +0100, Noralf Trønnes wrote:
>
> Den 23.03.2018 16.35, skrev Ville Syrjala:
> > From: Ville Syrjälä
> >
> > mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
> > bowels of the .atomic_enable() hook. That prevents us from taking the
> > plane mu
Op 28-03-18 om 12:21 schreef Jani Nikula:
> On Wed, 28 Mar 2018, Maarten Lankhorst
> wrote:
>> Adding a i915_fifo_underrun_reset debugfs file will make it possible
>> for IGT tests to clear FIFO underrun fallout at the start of each
>> subtest, and make re-enable FBC so tests always have maximum
On 3/28/2018 9:03 AM, Chris Wilson wrote:
Quoting Zhang, Yunwei (2018-03-28 16:54:26)
On 3/27/2018 4:13 PM, Chris Wilson wrote:
Quoting Zhang, Yunwei (2018-03-27 23:49:27)
On 3/27/2018 3:27 PM, Chris Wilson wrote:
Quoting Yunwei Zhang (2018-03-27 23:14:16)
WaProgramMgsrForCorrectSliceSpeci
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a s
1 - 100 of 169 matches
Mail list logo
