On Thu, Mar 15, 2018 at 02:08:51PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new fe
== Series Details ==
Series: series starting with [1/3] drm/i915: Trim error mask to known engines
URL : https://patchwork.freedesktop.org/series/40130/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass
== Series Details ==
Series: drm/i915: Some plane init cleanups
URL : https://patchwork.freedesktop.org/series/39390/
State : failure
== Summary ==
Possible new issues:
Test kms_fbcon_fbt:
Subgroup fbc:
pass -> FAIL (shard-apl)
Subgroup fbc-sus
On Fri, 2018-03-16 at 17:38 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Fri, 2018-03-16 at 16:30 -0700, Rodrigo Vivi wrote:
> > On Fri, Mar 16, 2018 at 04:05:01PM -0700, José Roberto de Souza
> > wrote:
> > > Having has_psr and has_psr2 can be ambiguous and also uses one
> > > more
> > > byte tha
== Series Details ==
Series: tests: Introduce drv_cgroup (v2)
URL : https://patchwork.freedesktop.org/series/40143/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
98f7614bd725afaae48f7b70d18329149075661b lib: Parse plane IN_FORMATS blobifiers
into a nicer
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum()
URL : https://patchwork.freedesktop.org/series/40122/
State : success
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip -> PASS
== Series Details ==
Series: drm/i915: Disable some extra clang warnings
URL : https://patchwork.freedesktop.org/series/40145/
State : failure
== Summary ==
Applying: drm/i915: Disable some extra clang warnings
error: Failed to merge in the changes.
Using index info to reconstruct a base tree.
== Series Details ==
Series: cgroup private data and DRM/i915 integration
URL : https://patchwork.freedesktop.org/series/40142/
State : success
== Summary ==
Series 40142v1 cgroup private data and DRM/i915 integration
https://patchwork.freedesktop.org/api/1.0/series/40142/revisions/1/mbox/
--
On Fri, 2018-03-16 at 16:30 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 16, 2018 at 04:05:01PM -0700, José Roberto de Souza wrote:
> > Having has_psr and has_psr2 can be ambiguous and also uses one more
> > byte than needed(not taking in care struct alignment).
> >
> > Cc: Dhinakaran Pandiyan
> >
Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enab
On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> From: "Souza, Jose"
>
> For Geminilake and Cannonlake+ the Y-coordinate support must be
> enabled in PSR2_CTL too.
>
> Spec: 7713
>
> Cc: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
== Series Details ==
Series: cgroup private data and DRM/i915 integration
URL : https://patchwork.freedesktop.org/series/40142/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ed1f8853712d cgroup: Allow registration and lookup of cgroup private data (v2)
-:52: CHECK:UNCOMMENTED_D
On Fri, 2018-03-16 at 16:25 -0700, Rodrigo Vivi wrote:
> On Fri, Mar 16, 2018 at 04:04:58PM -0700, José Roberto de Souza wrote:
> > Move to only one place the sink requirements that the actual driver
> > needs to enable PSR2.
> >
> > Also intel_psr2_config_valid() is called every time the crtc
On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> Move to only one place the sink requirements that the actual driver
> needs to enable PSR2.
>
> Also intel_psr2_config_valid() is called every time the crtc config
> is computed, wasting some time every time it was checking for
>
drv_cgroup exercises both valid and invalid usage of the i915 cgroup
parameter ioctl.
v2:
- Add support for display boost
- Drop cgroup permissions test (the kernel no longer bases access
control on fs permissions)
Signed-off-by: Matt Roper
---
tests/Makefile.sources | 1 +
tests/drv_cgr
Update i915_context_status to include priority information.
v2:
- Clarify that the offset is based on cgroup (Chris)
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/i
Usually display-boosted contexts get treated as
I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular
GPU contexts. Now that we allow a much larger range of effective
priority values via per-cgroup priority offsets, a system administrator
may want more detailed control over how mu
In preparation for adding cgroup-based priority adjustments, let's
define the driver's priority values a little more clearly.
Cc: Chris Wilson
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/i9
Wraps task_dfl_cgroup() to also take a reference to the cgroup.
v2:
- Eliminate cgroup_mutex and make lighter-weight (Tejun)
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 29 +
1 file changed, 29 insertions(+)
dif
Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups. i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.
v2:
- Large rebase/rewrite for new cgroup_priv interface
v3:
- A
Getting cgroup private data for the current process' cgroup is such a
common pattern that we should add a convenience wrapper for it.
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 1 +
kernel/cgroup/cgroup.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to
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
This is the fourth iteration of the work previously posted here:
(v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
(v2)
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
(v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/15
== Series Details ==
Series: series starting with [v2,1/5] drm/i915/psr: Nuke aux_frame_sync
URL : https://patchwork.freedesktop.org/series/40138/
State : failure
== Summary ==
Series 40138v1 series starting with [v2,1/5] drm/i915/psr: Nuke aux_frame_sync
https://patchwork.freedesktop.org/api/
== Series Details ==
Series: series starting with [v2,1/5] drm/i915/psr: Nuke aux_frame_sync
URL : https://patchwork.freedesktop.org/series/40138/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ed472e09578b drm/i915/psr: Nuke aux_frame_sync
7106739a3800 drm/i915/psr: Tie PSR2 su
== Series Details ==
Series: force-preempt-reset
URL : https://patchwork.freedesktop.org/series/40136/
State : failure
== Summary ==
Applying: force-preempt-reset
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/intel_lrc.c).
error: could not build fake ancestor
Patch faile
== Series Details ==
Series: drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
URL : https://patchwork.freedesktop.org/series/40118/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip -> P
On Fri, 2018-03-16 at 16:04 -0700, José Roberto de Souza wrote:
> PSR2 selective update requires aux frame sync(even though we don't
> support it in i915)
Any chance I could get you to fix this line?
i915 does not support aux frame sync ^
PSR2 panel needs to support aux frame sync (see below)
On Fri, Mar 16, 2018 at 04:05:01PM -0700, José Roberto de Souza wrote:
> Having has_psr and has_psr2 can be ambiguous and also uses one more
> byte than needed(not taking in care struct alignment).
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
>
>
On Fri, Mar 16, 2018 at 04:05:00PM -0700, José Roberto de Souza wrote:
> 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 reso
On Fri, Mar 16, 2018 at 04:04:58PM -0700, José Roberto de Souza wrote:
> Move to only one place the sink requirements that the actual driver
> needs to enable PSR2.
>
> Also intel_psr2_config_valid() is called every time the crtc config
> is computed, wasting some time every time it was checking f
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/matthew
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.
PSR2 selective update requires aux frame sync(even though we don't
support it in i915) and do not makes sense active PSR2 to only do
full screen updates aka PSR1.
Having aux_frame_sync flag could cause it be set to true even when
the PSR1 is being used, see intel_psr2_config_valid().
Cc: Dhinakara
Having has_psr and has_psr2 can be ambiguous and also uses one more
byte than needed(not taking in care struct alignment).
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v2: Grouped the 2 bools into one u8 as suggested by Dhinakaran Pandiyan.
drivers/gpu/dr
From: "Souza, Jose"
For Geminilake and Cannonlake+ the Y-coordinate support must be
enabled in PSR2_CTL too.
Spec: 7713
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
v2: This is specific to Geminilake and Cannonlake+
drivers/gpu/drm/i915/i915_r
Move to only one place the sink requirements that the actual driver
needs to enable PSR2.
Also intel_psr2_config_valid() is called every time the crtc config
is computed, wasting some time every time it was checking for
Y coordinate requirement.
This allow us to nuke y_cord_support and some of VS
A more concrete idea of what I think the serialisation should be between
reset timer and tasklet.
---
drivers/gpu/drm/i915/intel_lrc.c| 43 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i
== Series Details ==
Series: igt/gem_ctx_switch: Measure qlen for timing loops
URL : https://patchwork.freedesktop.org/series/40105/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
skip -> PASS (
== Series Details ==
Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
(rev2)
URL : https://patchwork.freedesktop.org/series/39473/
State : warning
== Summary ==
Possible new issues:
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
Quoting jeff.mc...@intel.com (2018-03-16 18:30:57)
> From: Jeff McGee
>
> Force preemption uses engine reset to enforce a limit on the time
> that a request targeted for preemption can block. This feature is
> a requirement in automotive systems where the GPU may be shared by
> clients of critica
On 16/03/18 15:14, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-16 22:11:11)
On 13/03/18 05:31, Chris Wilson wrote:
Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.
Signed-off
On Thu, 2018-03-15 at 19:09 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Wed, 2018-03-14 at 15:36 -0700, José Roberto de Souza wrote:
> > This value is a match of hardware and sink has PSR + if it can be
> > enabled by the requested state, see intel_psr_compute_config().
> >
> > Cc: Dhinakaran Pa
== Series Details ==
Series: series starting with [1/3] drm/i915: Trim error mask to known engines
URL : https://patchwork.freedesktop.org/series/40130/
State : success
== Summary ==
Series 40130v1 series starting with [1/3] drm/i915: Trim error mask to known
engines
https://patchwork.freedes
Quoting Antonio Argenziano (2018-03-16 22:11:11)
>
>
> On 13/03/18 05:31, Chris Wilson wrote:
> > Execute the same batch on each engine and check that the composite fence
> > across all engines completes only after the batch is completed on every
> > engine.
> >
> > Signed-off-by: Chris Wilson
On 13/03/18 05:31, Chris Wilson wrote:
Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.
Signed-off-by: Chris Wilson
---
tests/gem_exec_fence.c | 127 ++
Ville Syrjälä writes:
> On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
>> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
>> > > Ville Syrjala writes:
>> > >
>> > > > From: Ville Syrjälä
>> > > >
>
Build up a large stockpile of requests, ~500,000, and feed them into the
system at 20KHz whilst simultaneously triggering set-wedged in order to
try and race i915_gem_set_wedged() against the engine->submit_request()
callback.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Acked-by: Antonio Argen
Quoting Daniele Ceraolo Spurio (2018-03-16 20:28:25)
>
>
> On 16/03/18 05:14, Mika Kuoppala wrote:
> > From: Michel Thierry
> >
> > The bits used to reset the different engines/domains have changed in
> > GEN11, this patch maps the reset engine mask bits with the new bits
> > in the reset contr
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
---
drivers/gpu/drm/i915/intel_lrc.c
For the convenience of userspace passing in an arbitrary reset mask,
remove unknown engines from the set of engines that are to be reset.
This means that we always follow a per-engine reset with a full-device
reset when userspace writes -1 into debugfs/i915_wedged.
Reported-by: Michał Winiarski
S
Not all callers want the GPU error to handled in the same way, so expose
a control parameter. In the first instance, some callers do not want the
heavyweight error capture so add a bit to request the state to be
captured and saved.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Mika Kuoppala
--
On 13/03/18 05:31, Chris Wilson wrote:
Build up a large stockpile of requests, ~500,000, and feed them into the
system at 20KHz whilst simultaneously triggering set-wedged in order to
try and race i915_gem_set_wedged() against the engine->submit_request()
callback.
Signed-off-by: Chris Wilson
Quoting Chris Wilson (2018-03-16 20:53:01)
> +static void preempt_reset(struct work_struct *work)
> +{
> + struct intel_engine_cs *engine =
> + container_of(work, typeof(*engine), execlists.preempt_reset);
> +
So thinking about the races you had in the reset, you need
tasklet_
Quoting jeff.mc...@intel.com (2018-03-16 18:30:57)
> From: Jeff McGee
>
> Force preemption uses engine reset to enforce a limit on the time
> that a request targeted for preemption can block. This feature is
> a requirement in automotive systems where the GPU may be shared by
> clients of critica
Quoting jeff.mc...@intel.com (2018-03-16 18:31:05)
> +bool intel_engine_cancel_fpreempt(struct intel_engine_cs *engine)
> +{
> + hrtimer_cancel(&engine->fpreempt_timer);
Can not be used inside the tasklet as the hrtimer may also be a tasklet
on the same CPU; so busy spin deadlock.
-Chris
___
== Series Details ==
Series: drm/i915: Some plane init cleanups
URL : https://patchwork.freedesktop.org/series/39390/
State : success
== Summary ==
Series 39390v1 drm/i915: Some plane init cleanups
https://patchwork.freedesktop.org/api/1.0/series/39390/revisions/1/mbox/
Known issues:
Te
Quoting jeff.mc...@intel.com (2018-03-16 18:31:05)
> From: Jeff McGee
>
> The hardware can complete the requested preemption at only certain points
> in execution. Thus an uncooperative request that avoids those points can
> block a preemption indefinitely. Our only option to bound the preemption
Quoting jeff.mc...@intel.com (2018-03-16 18:31:04)
> From: Jeff McGee
>
> Pull the reset handling out of i915_handle_error() so that it can be
> called by that function and directly by the upcoming force preemption
> handler. This allows the force preemption handler to bypass the error
> capture
Quoting jeff.mc...@intel.com (2018-03-16 18:30:58)
> From: Jeff McGee
>
> It is possible for the hardware to be reset just as a context is
> completing. The reset post-processing may see the seqno update and
> assume that the context escaped corruption, but the context may
> have been disrupted i
Quoting jeff.mc...@intel.com (2018-03-16 18:30:59)
> From: Jeff McGee
>
> Engine reset is fast. A context switch interrupt may be generated just
> prior to the reset such that the top half handler is racing with reset
> post-processing. The handler may set the irq_posted bit again after
> the res
On 16/03/18 05:14, Mika Kuoppala wrote:
From: Michel Thierry
The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.
v2: Use shift-left instead of BIT macro to match the file style
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Daniel Vetter
>Sent: Friday, March 16, 2018 1:43 AM
>To: Xiong, James
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Subject: Re: [PATCH libdrm 0/5] improve reuse
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum()
URL : https://patchwork.freedesktop.org/series/40122/
State : success
== Summary ==
Series 40122v1 drm: Don't pass the index to drm_property_add_enum()
https://patchwork.freedesktop.org/api/1.0/series/40122/revis
On 16/03/18 11:28, Michel Thierry wrote:
On 3/16/2018 5:14 AM, Mika Kuoppala wrote:
Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.
v3: rebase on top of rps intr
use
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum()
URL : https://patchwork.freedesktop.org/series/40122/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f153106cd56b drm: Don't pass the index to drm_property_add_enum()
-:135: CHECK:SPACING: spaces p
From: Ville Syrjälä
drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.
Cc: Patrik Jakobsson
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 6 +++---
dri
== Series Details ==
Series: Force preemption
URL : https://patchwork.freedesktop.org/series/40120/
State : failure
== Summary ==
Applying: drm/i915: Downgrade tasklet GEM_BUG_ON for request not completed
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/intel_lrc.c).
error:
== Series Details ==
Series: drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
URL : https://patchwork.freedesktop.org/series/40118/
State : success
== Summary ==
Series 40118v1 drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
https://patchwork.freedesktop.org/api/1.0/se
From: Jeff McGee
The current non-atomic wait_for routines convert the provided usec
timeout into jiffies with upward rounding. This can increase the
actual timeout several msecs which is fine in most cases. In the next
patch we need the timeout to conform more exactly to what is
requested.
This
From: Jeff McGee
Pull the reset handling out of i915_handle_error() so that it can be
called by that function and directly by the upcoming force preemption
handler. This allows the force preemption handler to bypass the error
capture that i915_handle_error() does before getting on with the
reset.
From: Jeff McGee
Force preemption uses engine reset to enforce a limit on the time
that a request targeted for preemption can block. This feature is
a requirement in automotive systems where the GPU may be shared by
clients of critically high priority and clients of low priority that
may not have
From: Jeff McGee
Engine reset is fast. A context switch interrupt may be generated just
prior to the reset such that the top half handler is racing with reset
post-processing. The handler may set the irq_posted bit again after
the reset code has cleared it to start fresh. Then the re-enabled
task
From: Jeff McGee
It is possible for the hardware to be reset just as a context is
completing. The reset post-processing may see the seqno update and
assume that the context escaped corruption, but the context may
have been disrupted in the save out process. The corruption may
screw up the HEAD an
From: Jeff McGee
The active request is found by scanning the engine timeline for the
request that follows the last completed request. That method is accurate
if there is no preemption in progress, because the engine will certainly
have started that request. If there is a preemption in progress, i
From: Jeff McGee
The hardware can complete the requested preemption at only certain points
in execution. Thus an uncooperative request that avoids those points can
block a preemption indefinitely. Our only option to bound the preemption
latency is to trigger reset and recovery just as we would if
From: Jeff McGee
In the next patch we are improving how we find the active request
on an engine with a pending preemption. We need to know if the
preemption has completed or not. This determination can be made
most robustly by having the preemption context write a preemption
finished indicator to
From: Jeff McGee
It is possible for the preemption context to be active on an engine
when the engine is reset. The preemption context is not tracked via
the request mechanism, so the normal reset handling will not detect
this scenario and will not be able to fixup possible context
corruption. So
the system]
url:
https://github.com/0day-ci/linux/commits/Nautiyal-Ankit-K/Aspect-ratio-support-in-DRM-layer/20180316-204825
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by
== Series Details ==
Series: drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
URL : https://patchwork.freedesktop.org/series/40118/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f40fddd1cd8c drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
-:24: CHECK:MA
From: Ville Syrjälä
Make the PIPE_CONF_CHECK macros a bit more robust by wrapping them
in do {} while(0). Avoids funky sirprises when you try put an 'else'
after a PIPE_CONF_CHECK invocation...
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 45 +
On 3/16/2018 5:14 AM, Mika Kuoppala wrote:
Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.
v3: rebase on top of rps intr
use correct class / instance limits (Michel)
S
== Series Details ==
Series: igt/gem_ctx_switch: Measure qlen for timing loops
URL : https://patchwork.freedesktop.org/series/40105/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
98f7614bd725afaae48f7b70d18329149075661b lib: Parse plane IN_FORMATS blobifie
== Series Details ==
Series: drm/i915: Rework FBC schedule locking
URL : https://patchwork.freedesktop.org/series/40102/
State : success
== Summary ==
Possible new issues:
Test gem_eio:
Subgroup suspend:
fail -> PASS (shard-snb)
Known issues:
Te
== Series Details ==
Series: drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
(rev2)
URL : https://patchwork.freedesktop.org/series/39473/
State : success
== Summary ==
Series 39473v2 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP
1.4
https://patchwork.f
== Series Details ==
Series: drm/i915: make edp optimize config (rev2)
URL : https://patchwork.freedesktop.org/series/39652/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK i
On 16 March 2018 at 08:43, Daniel Vetter wrote:
> On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
>> From: "Xiong, James"
>>
>> With gem_reuse enabled, when a buffer size is different than
>> the sizes of buckets, it is aligned to the next bucket's size,
>> which means about 25% more
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavio
From: Matt Atwood
Previously it was assumed that eDP panels would advertise the lowest link
rate required for their singular mode to function. With the introduction
of more advanced features there are advantages to a panel advertising a
higher rate then it needs for a its given mode. For panels t
== Series Details ==
Series: series starting with [1/8] drm/i915/icl: Check for fused-off VDBOX and
VEBOX instances (rev2)
URL : https://patchwork.freedesktop.org/series/40093/
State : success
== Summary ==
Possible new issues:
Test gem_fenced_exec_thrash:
Subgroup 2-spare-fence
On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Do the refresh rate calculation with a single division. This gives
> > us slightly more accurate results, especially for interlaced since
Some platforms may execute the heavy workload very slowly, such that
using a batch of 1024 takes tens of seconds and immediately overrunning
the 5s timeout on a pass. Added up over a few dozen passes, this turns a
120 second test into 10 minutes. Counter this by doing a warmup loop to
estimate the
Quoting Andy Shevchenko (2018-03-16 14:12:13)
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Andy Shevchenko
And pushed, thanks very much for the patch.
-Chris
___
On Fri, 16 Mar 2018, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Rework FBC schedule locking
> URL : https://patchwork.freedesktop.org/series/40102/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
So I'll try to look at these reports a bit now that we'v
== Series Details ==
Series: drm/i915: Rework FBC schedule locking
URL : https://patchwork.freedesktop.org/series/40102/
State : success
== Summary ==
Series 40102v1 drm/i915: Rework FBC schedule locking
https://patchwork.freedesktop.org/api/1.0/series/40102/revisions/1/mbox/
Known issue
== Series Details ==
Series: drm/i915: Rework FBC schedule locking
URL : https://patchwork.freedesktop.org/series/40102/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3bacd111d921 drm/i915: Rework FBC schedule locking
-:93: WARNING:LONG_LINE: line over 100 characters
#93: FILE:
== Series Details ==
Series: i915: Re-use DEFINE_SHOW_ATTRIBUTE() macro (rev2)
URL : https://patchwork.freedesktop.org/series/38263/
State : failure
== Summary ==
Series 38263v2 i915: Re-use DEFINE_SHOW_ATTRIBUTE() macro
https://patchwork.freedesktop.org/api/1.0/series/38263/revisions/2/mbox/
Instead of taking fbc->lock inside the worker, don't take any lock
and cancel the work synchronously to prevent races. Since the worker
waits for a vblank before activating, wake up all vblank waiters after
signalling the cancel through unsetting work->scheduled_vblank. This
will make sure that we
On 3/14/2018 3:07 PM, Chris Wilson wrote:
As we know that whenever the GT is awake, rc6 and rps are enabled (if
available), then we can remove the individual tracking and enabling to
the gen6_rps_busy/gen6_rps_idle() (now called intel_gt_pm_busy and
intel_gt_pm_idle) entry points.
Signed-off-b
1 - 100 of 155 matches
Mail list logo
