== Series Details ==
Series: Polish DRAM information readout code (rev5)
URL : https://patchwork.freedesktop.org/series/57213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5663_full -> Patchwork_12312_full
Summary
---
> > At the end of the day, I don't really care that much. I get it, we
> > all have large projects with scarce resources. I just think a few
> > years down the road we'll all regret it as a community.
>
> AMD and others have also spent years tuning TTM for both UMA and VRAM,
> but especially
Hi Greg
topic/mei-hdcp-2019-02-26:
mei-hdcp driver
mei driver for the me hdcp client, for use by drm/i915.
Including the following prep work:
- whitelist hdcp client in mei bus
- merge to include char-misc-next because of another mei bus prep patch to
export a helper macro to drivers
-
Quoting Rodrigo Vivi (2019-02-26 19:53:47)
> On Wed, Feb 06, 2019 at 01:03:12PM +, Chris Wilson wrote:
> > Previously, we were able to rely on the recursive properties of
> > struct_mutex to allow us to serialise revoking mmaps and reacquiring the
> > FENCE registers with them being clobbered
On Wed, Feb 06, 2019 at 01:03:12PM +, Chris Wilson wrote:
> Previously, we were able to rely on the recursive properties of
> struct_mutex to allow us to serialise revoking mmaps and reacquiring the
> FENCE registers with them being clobbered over a global device reset.
> I then proceeded to
== Series Details ==
Series: Polish DRAM information readout code (rev5)
URL : https://patchwork.freedesktop.org/series/57213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5663 -> Patchwork_12312
Summary
---
On Tue, Feb 26, 2019 at 12:10:29PM +0200, Jani Nikula wrote:
On Mon, 25 Feb 2019, Lucas De Marchi wrote:
On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
No change in behavior. Just removing the unused bits since
== Series Details ==
Series: Polish DRAM information readout code (rev5)
URL : https://patchwork.freedesktop.org/series/57213/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Store DIMM rank information as a number
On Tue, Feb 26, 2019 at 04:21:01PM +0200, Ville Syrjälä wrote:
On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
>On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
>> Let the MG plls have their own
On Tue, Feb 26, 2019 at 12:20 PM Alex Deucher wrote:
>
> On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen
> wrote:
> >
> > Quoting Alex Deucher (2019-02-25 21:31:43)
> > > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> > > wrote:
> > > >
> > > > Quoting Dave Airlie (2019-02-25 12:24:48)
> > >
== Series Details ==
Series: Polish DRAM information readout code (rev5)
URL : https://patchwork.freedesktop.org/series/57213/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
011c8a3291c3 drm/i915: Store DIMM rank information as a number
00c9d4441d97 drm/i915: Extract functions
On Tue, Feb 26, 2019 at 04:48:23PM +0200, Ville Syrjälä wrote:
>This seems a rather roundabout way of doing things when we already have
>the vfuncs.
>
>How about just:
>
>mg_pll_enable()
>{
>icl_pll_enable(MG_REG);
>}
>
>combo_pll_enable()
>{
>icl_pll_enable(COMBO_REG);
>}
>
>or
Quoting Matthew Auld (2019-02-26 18:53:17)
> On Thu, 14 Feb 2019 at 15:48, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-02-14 14:57:16)
> > > We need to support doing relocations from the CPU when dealing with LMEM
> > > objects.
> >
> > Why not just use the GPU reloc? Please do explain
On Thu, 14 Feb 2019 at 15:48, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-14 14:57:16)
> > We need to support doing relocations from the CPU when dealing with LMEM
> > objects.
>
> Why not just use the GPU reloc? Please do explain the relative merits.
Are you suggesting just default to
Am 26.02.19 um 18:20 schrieb Alex Deucher:
On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen
wrote:
Quoting Alex Deucher (2019-02-25 21:31:43)
On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
wrote:
Quoting Dave Airlie (2019-02-25 12:24:48)
On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660_full -> Patchwork_12310_full
Summary
From: Ville Syrjälä
We'll need to know the memory type in the system for some
bandwidth limitations and whatnot. Let's read that out on
gen9+.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 84 +++--
drivers/gpu/drm/i915/i915_drv.h |
On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen
wrote:
>
> Quoting Alex Deucher (2019-02-25 21:31:43)
> > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> > wrote:
> > >
> > > Quoting Dave Airlie (2019-02-25 12:24:48)
> > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
> > > > wrote:
> > > >
Quoting Matthew Auld (2019-02-26 14:58:31)
> On Thu, 14 Feb 2019 at 15:25, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-02-14 14:57:03)
> > > + list_for_each_entry(obj, >purgeable, region_link) {
> > > + if (!i915_gem_object_has_pages(obj))
> > > +
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 21-02-2019 om 01:28 schreef Matt Roper:
> > Some display controllers can be programmed to present non-black colors
> > for pixels not covered by any plane (or pixels covered by the
> > transparent regions of higher
Quoting Caz Yokoyama (2019-02-26 16:14:18)
> Reviewed-by: Caz Yokoyama
And pushed, thanks for raising the issue and review.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Caz Yokoyama
-caz
On Mon, 2019-02-25 at 18:29 +, Chris Wilson wrote:
> Quoting Caz Yokoyama (2019-02-25 18:28:34)
> > Chris,
> > By your patch, measure_qlen() reports how many gem_execbuf() can be
> > executed(queue length) within timeout of the slowest engine,
> > correct?
>
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190226]
[cannot apply to v5.0-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> timer callback requires this flag at all. Its sole purpose is to ensure
> synchronisation in the workqueue code.
>
> Remove TIMER_IRQSAFE flag because
== Series Details ==
Series: Polish DRAM information readout code (rev4)
URL : https://patchwork.freedesktop.org/series/57213/
State : failure
== Summary ==
Applying: drm/i915: Store DIMM rank information as a number
Applying: drm/i915: Extract functions to derive SKL+ DIMM info
Applying:
On Tue, 26 Feb 2019, Imre Deak wrote:
> On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza wrote:
>> Unpowered type-c dongles can take some time to boot and be
>> responsible, causing the probe to fail and sink never be detected
>> without further actions from userspace.
>>
>> It
From: Ville Syrjälä
The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.
v2: Deobfuscate the math (Chris)
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Polish the bxt DIMM parsing by extracting a few small helpers.
v2: Use struct dram_dimm_info
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 93 ++---
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git
From: Ville Syrjälä
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.
Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.
v2:
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660 -> Patchwork_12310
Summary
---
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev2)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660_full -> Patchwork_12309_full
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: rework aging tail workaround
Okay!
Commit: drm/i915/perf:
On Thu, 14 Feb 2019 at 15:25, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-14 14:57:03)
> > Support basic eviction for regions.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Abdiel Janulgue
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> >
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev4)
URL : https://patchwork.freedesktop.org/series/54280/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1cdda900a014 drm/i915/perf: rework aging tail workaround
-:241: CHECK:SPACING: No space is necessary
On Mon, Feb 25, 2019 at 01:28:23PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 10:45:34PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 03:23:24PM -0800, Lucas De Marchi wrote:
> >> Use the first 3 bits of dpll_info.platform_flags to mark the type of the
> >> PLL instead of
With the currently available parameters for the i915-perf stream,
there are still situations that are not well covered :
If an application opens the stream with polling disable or at very low
frequency and OA interrupt enabled, no data will be available even
though somewhere between nothing and
This makes the following opening parameters available to
applications :
- DRM_I915_PERF_PROP_POLL_OA_DELAY
- DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT
As well as this new ioctl on the i915-perf file descriptor :
- I915_PERF_IOCTL_FLUSH_DATA
Signed-off-by: Lionel Landwerlin
---
This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.
v2: Allow disabling polling completely with
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 20
2 files changed, 23 insertions(+)
diff --git
We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to poll
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel polling
This let's the application choose to be driven by the interrupt
mechanism of the HW. In conjuction with long periods for checks for
the availability of data on the CPU, this can reduce the CPU load when
doing capture of OA data.
v2: Version the new parameter (Joonas)
Signed-off-by: Lionel
Hi all,
This third iteration adds an i915 perf revision number through
getparam so that application can more easily find out what feature of
i915-perf are available.
The patches containing uAPI updates have been updated to indicate what
version is required to those changes to be available.
The only bit of the status register we currently report in the
i915-perf stream is the "report loss" bit. Only report this when we
have some data to report with it. There was a kind of inconsistency
here in that we could report report loss without appending the reports
associated with the loss.
This isn't really gen specific stuff, so just move it to the common
code.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
The OA unit can notify that its circular buffer is half full through
an interrupt and we would like to give the application the ability to
make use of this interrupt to get rid of CPU checks on the OA buffer.
This change wires up the interrupt to the i915-perf stream and leaves
it ignored for
On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 03:23:22PM -0800, Lucas De Marchi wrote:
> >> Let the MG plls have their own hooks since it shares very little with
> >> other PLL types.
On Tue, 26 Feb 2019 at 13:00, Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> Just some quick comments, not a full review. Possibly a repeat of some
> same comments from way back, not sure.
>
> On 14/02/2019 14:57, Matthew Auld wrote:
> > Support memory regions, as defined by a given (start, end), and allow
Quoting Matthew Auld (2019-02-26 14:03:10)
> On Thu, 14 Feb 2019 at 15:16, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2019-02-14 14:57:02)
> > > +int
> > > +i915_memory_region_get_pages_buddy(struct drm_i915_gem_object *obj)
> > > +{
> > > + struct intel_memory_region *mem =
On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza wrote:
> Unpowered type-c dongles can take some time to boot and be
> responsible, causing the probe to fail and sink never be detected
> without further actions from userspace.
>
> It was not a issue for older platforms because
On Thu, 14 Feb 2019 at 15:16, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-14 14:57:02)
> > +int
> > +i915_memory_region_get_pages_buddy(struct drm_i915_gem_object *obj)
> > +{
> > + struct intel_memory_region *mem = obj->memory_region;
> > + resource_size_t size =
On Mon, Feb 25, 2019 at 01:54:16PM -0800, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
> >On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
> >> No change in behavior. Just removing the unused bits since it makes it
> >> easier to compare
Quoting Tvrtko Ursulin (2019-02-26 13:34:51)
>
> On 14/02/2019 14:57, Matthew Auld wrote:
> > From: Abdiel Janulgue
> >
> > CPU mmap implementation depending on the object's backing pages.
>
> depends?
>
> > At the moment we introduce shmem and local-memory BAR fault handlers
> > Note that
On 14/02/2019 14:57, Matthew Auld wrote:
From: Abdiel Janulgue
CPU mmap implementation depending on the object's backing pages.
depends?
At the moment we introduce shmem and local-memory BAR fault handlers
Note that the mmap type is done one at a time to circumvent the DRM
offset manager
== Series Details ==
Series: series starting with [v2] drm/i915: Replace global_seqno with a
hangcheck heartbeat seqno (rev2)
URL : https://patchwork.freedesktop.org/series/57203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12304_full
Hi,
Just some quick comments, not a full review. Possibly a repeat of some
same comments from way back, not sure.
On 14/02/2019 14:57, Matthew Auld wrote:
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region.
Quoting Alex Deucher (2019-02-25 21:31:43)
> On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> wrote:
> >
> > Quoting Dave Airlie (2019-02-25 12:24:48)
> > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
> > > wrote:
> > > >
> > > > + dri-devel mailing list, especially for the buddy allocator
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev2)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5660 -> Patchwork_12309
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev2)
URL : https://patchwork.freedesktop.org/series/57244/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Skip
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev2)
URL : https://patchwork.freedesktop.org/series/57244/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2fb1e47f69e3 drm/i915: Skip scanning for
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12303_full
Summary
---
**SUCCESS**
No
In order to correctly serialise the order of execution between rings, we
need to flag the scratch address as being written. Make it so.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_nop.c | 152 +-
1 file changed, 133 insertions(+), 19 deletions(-)
Show the total power consumed across all the whispers.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index 0b15fe431..6c3b53756 100644
Read the RAPL power metrics courtesy of perf. Or your local HW
equivalent?
v2: uselocale()
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_gpu_power.c | 114 +++
lib/igt_gpu_power.h | 59 ++
lib/meson.build
To make the demonstration of the cheeky preemption more impactful, make
the second context a nop to contrast the first being 1024
MI_STORE_DWORD_IMM. Then if we execute and wait on the second context
before executing the first, the client latency is even more drastically
reduced.
To more clearly
Include whether the scheduler is using HW semaphore assistance in our
pretty debug strings, and make the caps known for requires.
Signed-off-by: Chris Wilson
---
lib/i915/gem_scheduler.c | 22 +++---
lib/i915/gem_scheduler.h | 2 ++
2 files changed, 21 insertions(+), 3
How much energy does spinning on a semaphore consume relative to plain
old spinning?
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 72 +-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
Signed-off-by: Chris Wilson
---
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight
URL : https://patchwork.freedesktop.org/series/57244/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Replace global_seqno with a
hangcheck heartbeat seqno
URL : https://patchwork.freedesktop.org/series/57242/
State : failure
== Summary ==
Applying: drm/i915: Replace global_seqno with a hangcheck heartbeat seqno
Using index
So I'm not going to go into technical detail here, which I'll happily
leave to Joonas et al, but I think a couple of general points deserve to
be addressed.
On Tue, 26 Feb 2019, Alex Deucher wrote:
> On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> wrote:
>> Adding the suggested smaller
Quoting Tvrtko Ursulin (2019-02-11 17:49:11)
>
> On 11/02/2019 17:32, Abdiel Janulgue wrote:
> > This simplifies adding new query item objects.
> >
> > v2: Use query_hdr (Tvrtko, Chris).
> > int instead of u32 in return (Tvrtko)
> > v3: More naming fixes (Tvrtko)
> >
> > Signed-off-by:
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signaled and we do not need to process
our list of
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 39 +
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and
Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:
__execlists_submission_tasklet 28672847 -20
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.h | 6 --
1 file changed, 4 insertions(+), 2
A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a request into the timeline
(important as the
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately. We then also have to be careful that we don't give earlier
semaphores
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely granted the right to be at the
front of the
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity
If we resubmitting the active context, simply skip the submission as
performing the submission from the interrupt handler has higher
throughput than continually provoking lite-restores. If however, we find
ourselves with a new client, we check whether or not we can dequeue into
the second port or
On Mon, 25 Feb 2019, Lucas De Marchi wrote:
> On Mon, Feb 25, 2019 at 09:28:06PM +0200, Ville Syrjälä wrote:
>>On Fri, Feb 22, 2019 at 04:34:48PM -0800, Lucas De Marchi wrote:
>>> No change in behavior. Just removing the unused bits since it makes it
>>> easier to compare them on new platforms
In selftests/live_hangcheck, we have a lot of tests for resetting simple
spinners, but nothing quite prepared us for how the GPU reacted to
triggering a reset outside of the safe spinner. These two subtests fill
the ring with plain old empty, non-spinning requests, and then triggers
a reset.
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!
Signed-off-by: Chris Wilson
Reviewed-by:
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 4 --
drivers/gpu/drm/i915/i915_gpu_error.h |
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests
== Series Details ==
Series: series starting with [v2] drm/i915: Replace global_seqno with a
hangcheck heartbeat seqno (rev2)
URL : https://patchwork.freedesktop.org/series/57203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12304
== Series Details ==
Series: series starting with [v2] drm/i915: Replace global_seqno with a
hangcheck heartbeat seqno (rev2)
URL : https://patchwork.freedesktop.org/series/57203/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
212a5ef02a79 drm/i915: Replace global_seqno with a
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659 -> Patchwork_12303
Summary
---
**SUCCESS**
No regressions
== Series Details ==
Series: drm/i915: extract AUX mask assignment to separate function (rev2)
URL : https://patchwork.freedesktop.org/series/57119/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5659_full -> Patchwork_12302_full
On Tue, Feb 26, 2019 at 8:42 AM Ramalingam C wrote:
>
> HDCP2.2 phase-II mojorly adds below features:
> Addition of three connector properties
> CP_Content_Type
> CP_SRM
Not really clear why this is a connector property. Do we need
different SRM for
== Series Details ==
Series: HDCP2.2 Phase II
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d436a49061d8 drm: Add CP content type property
-:123: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#123: FILE:
93 matches
Mail list logo
