== Series Details ==
Series: drm/i915/tgl: Wa_14011059788 (rev4)
URL : https://patchwork.freedesktop.org/series/75990/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8335_full -> Patchwork_17393_full
Summary
---
**SUC
On Wed, Apr 15, 2020 at 09:40:12AM +0200, Daniel Vetter wrote:
> Because it is.
Indeed.
Acked-by: Gerd Hoffmann
take care,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Apr 15, 2020 at 09:40:34AM +0200, Daniel Vetter wrote:
> This is leftovers from the old drm_driver->load callback
> upside-down issues. It doesn't do anything for not-hotplugged
> connectors since drm_dev_register takes care of that.
>
> Signed-off-by: Daniel Vetter
> Cc: Gerd Hoffmann
>
Pankaj, the subject line is identical to patch 4, please update.
Imre, one question inline for you.
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 433e5a81dd4d..5475
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev11)
URL : https://patchwork.freedesktop.org/series/72853/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
33516c7eda02 video/hdmi: Add Unpack only function for DRM infoframe
5eae0ec2d8
Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > I think the the patch should be dropped for now before the issue is
> > properly addressed. Either by backporting the mainline fixes or if
> > those are too big and there indeed is a
== Series Details ==
Series: In order to readout DP SDPs, refactors the handling of DP SDPs (rev11)
URL : https://patchwork.freedesktop.org/series/72853/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8339 -> Patchwork_17395
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN_ON over WARN_ON.
>
> Signed-off-by: Pankaj Bharadiya
> ---
> drivers/gpu/drm/i915/i91
The RPS DOWN_TIMEOUT interrupt is signaled after a period of rc6, and
upon receipt of that interrupt we reprogram the GPU clocks down to the
next idle notch [to help convserve power during rc6]. However, on
execlists, we benefit from soft-rc6 immediately parking the GPU and
setting idle frequencies
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN_ON over WARN_ON.
>
> Conversion is done with below sementic patch:
>
> @@
> identifier
Imre, please check the one question inline.
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN* over WARN*.
>
> Conversion is done with
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN* over WARN* at places where struct drm_device pointer
> can be extracted.
I'd like to
Chris Wilson writes:
> We want to see the pstate limits whenever we fail to set the minimum
> frequency as that may help for debugging.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_rps.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> Now we have struct drm_device specific drm_WARN* macros which include
> device information in the backtrace, so we know what device the
> warnings originate from.
>
> This series converts WARN* with drm_WARN* where struct drm_device
> pointer can be
Quoting Mika Kuoppala (2020-04-21 09:28:41)
> Chris Wilson writes:
>
> > We want to see the pstate limits whenever we fail to set the minimum
> > frequency as that may help for debugging.
> >
> > Signed-off-by: Chris Wilson
>
> Reviewed-by: Mika Kuoppala
It was a nice idea but for soraka, it
Import the kernel's i915_pciids.h, up to:
commit 8717c6b7414ffb890672276dccc284c23078ac0e
Author: Lee Shawn C
Date: Tue Dec 10 23:04:15 2019 +0800
drm/i915/cml: Separate U series pci id from origianl list.
Signed-off-by: Liwei Song
---
V3 -> V4:
Add missed PINEVIEW
V2 -> V3:
Add 4
Since we may lose the content of any buffer when we relinquish control
of the system (e.g. suspend/resume), we have to be careful not to rely
on regaining control. A good method to detect when we might be using
garbage is by always injecting that garbage prior to first use on
load/resume/etc.
v2:
Add tracek to the RPS events (interrupts, worker, enabling, threshold
selection, frequency setting), so that if we have to debug reticent HW
we have some traces to start from.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_rps.c | 48 ++---
1 file changed,
For many configuration details within RC6 and RPS we are programming
intervals for the internal clocks. From gen11, these clocks are
configuration via the RPM_CONFIG and so for convenience, we would like
to convert to/from more natural units (ns).
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: M
On Tue, Apr 21, 2020 at 03:49:19AM +0100, Al Viro wrote:
> The only source I'd been able to find speeks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in q
On Tue, Apr 21, 2020 at 10:53:12AM +0300, Jani Nikula wrote:
>
> Pankaj, the subject line is identical to patch 4, please update.
>
> Imre, one question inline for you.
>
> On Mon, 06 Apr 2020, Pankaj Bharadiya
> wrote:
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b
Since we may lose the content of any buffer when we relinquish control
of the system (e.g. suspend/resume), we have to be careful not to rely
on regaining control. A good method to detect when we might be using
garbage is by always injecting that garbage prior to first use on
load/resume/etc.
v2:
Quoting Liwei Song (2020-04-21 09:41:28)
> +static const struct intel_device_info intel_cannonlake_info = {
> + .gen = 0115,
.gen = 0120 /* 10 */
> +};
> +
> +static const struct intel_device_info intel_icelake_info = {
> + .gen = 0116,
.gen = 0130 /* 11 */
> +};
> +
> +static const s
On 2020-04-15 at 13:01:21 +0300, Jani Nikula wrote:
> On Tue, 07 Apr 2020, Jeevan B wrote:
> > From: Oleg Vasilev
> >
> > Currently, downstream port type is only reported in debugfs. This
> > information should be considered important since it reflects the actual
> > physical connector type. Some
On 2020-04-15 at 13:01:59 +0300, Jani Nikula wrote:
> On Tue, 07 Apr 2020, Jeevan B wrote:
> > From: Oleg Vasilev
> >
> > Since DP-specific information is stored in driver's structures, every
> > driver needs to implement subconnector property by itself.
> >
> > v2: updates to match previous comm
On Tue, Apr 21, 2020 at 11:28:24AM +0300, Jani Nikula wrote:
>
> Imre, please check the one question inline.
>
> On Mon, 06 Apr 2020, Pankaj Bharadiya
> wrote:
> > struct drm_device specific drm_WARN* macros include device information
> > in the backtrace, so we know what device the warnings or
On 4/21/20 17:29, Chris Wilson wrote:
> Quoting Liwei Song (2020-04-21 09:41:28)
>> +static const struct intel_device_info intel_cannonlake_info = {
>> + .gen = 0115,
> .gen = 0120 /* 10 */
>
>> +};
>> +
>> +static const struct intel_device_info intel_icelake_info = {
>> + .gen = 01
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-04-17 15:44:27)
>> Restoration of a previous timestamp can collide
>> with updating the timestamp, causing a value corruption.
>>
>> Combat this issue by using indirect ctx bb to
>> modify the context image during restoring process.
>>
>> For r
Quoting Liwei Song (2020-04-21 10:59:04)
>
>
> On 4/21/20 17:29, Chris Wilson wrote:
> > Quoting Liwei Song (2020-04-21 09:41:28)
> >> +static const struct intel_device_info intel_cannonlake_info = {
> >> + .gen = 0115,
> > .gen = 0120 /* 10 */
> >
> >> +};
> >> +
> >> +static const struct
== Series Details ==
Series: Sync i915_pciids upto 8717c6b7414f (rev4)
URL : https://patchwork.freedesktop.org/series/76080/
State : failure
== Summary ==
Applying: Sync i915_pciids upto 8717c6b7414f
error: sha1 information is lacking or useless (src/intel_module.c).
error: could not build fak
On Tue, Apr 21, 2020 at 11:24:39AM +0300, Jani Nikula wrote:
> On Mon, 06 Apr 2020, Pankaj Bharadiya
> wrote:
> > struct drm_device specific drm_WARN* macros include device information
> > in the backtrace, so we know what device the warnings originate from.
> >
> > Prefer drm_WARN_ON over WARN_O
On Tue, Apr 21, 2020 at 11:35:08AM +0300, Jani Nikula wrote:
> On Mon, 06 Apr 2020, Pankaj Bharadiya
> wrote:
> > Now we have struct drm_device specific drm_WARN* macros which include
> > device information in the backtrace, so we know what device the
> > warnings originate from.
> >
> > This ser
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Trace RPS events
URL : https://patchwork.freedesktop.org/series/76251/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated
The RPS DOWN_TIMEOUT interrupt is signaled after a period of rc6, and
upon receipt of that interrupt we reprogram the GPU clocks down to the
next idle notch [to help convserve power during rc6]. However, on
execlists, we benefit from soft-rc6 immediately parking the GPU and
setting idle frequencies
== Series Details ==
Series: drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT (rev2)
URL : https://patchwork.freedesktop.org/series/76216/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17396
Summary
Due to the latency from impedance mismatch on memory access, as the GPU
gets faster we need to increase the frequency of the ring to offset.
In effect, we are fixing the topmost frequency selection, and scaling
down faster, so that at low frequencies we will be using lower ring
frequencies and con
== Series Details ==
Series: drm/i915/gt: Poison residual state [HWSP] across resume. (rev5)
URL : https://patchwork.freedesktop.org/series/76100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17399
Summar
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
> > Add a new macro helper to combine the usual init sequence in drivers,
> > consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> > triplet. This allows us to remove the
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
From: Chris Wilson
Since the introduction of 'soft-rc6', we aim to park the device quickly
and that results in frequent idling of the whole device. Currently upon
idling we free the batch buffer pool, and so this renders the cache
ineffective for many workloads. If we want to have an effective ca
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
== Series Details ==
Series: drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT (rev3)
URL : https://patchwork.freedesktop.org/series/76216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17400
Summary
Import the kernel's i915_pciids.h, up to:
commit 8717c6b7414ffb890672276dccc284c23078ac0e
Author: Lee Shawn C
Date: Tue Dec 10 23:04:15 2019 +0800
drm/i915/cml: Separate U series pci id from origianl list.
Signed-off-by: Liwei Song
---
V4 -> V5:
adjust gen number
V3 -> V4:
Add mis
On 15/04/2020 10:39, Daniel Vetter wrote:
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_crtc
On 15/04/2020 10:39, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 15 ---
1 file changed, 4
Quoting Liwei Song (2020-04-21 11:19:55)
> Import the kernel's i915_pciids.h, up to:
>
> commit 8717c6b7414ffb890672276dccc284c23078ac0e
> Author: Lee Shawn C
> Date: Tue Dec 10 23:04:15 2019 +0800
>
> drm/i915/cml: Separate U series pci id from origianl list.
>
> Signed-off-by: Liwei Son
== Series Details ==
Series: drm/i915/gt: Apply a small scalefactor for the gpu:ring ratio
URL : https://patchwork.freedesktop.org/series/76254/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17401
Summary
Quoting Patchwork (2020-04-21 12:37:30)
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_selftest@live@gt_timelines:
> - fi-snb-2520m: [PASS][1] -> [FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8342/fi-snb-2520m/igt@i915_selftest@live@gt
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8184ca928432 perf/core: Only copy-to-user after
== Series Details ==
Series: Sync i915_pciids upto 8717c6b7414f (rev5)
URL : https://patchwork.freedesktop.org/series/76080/
State : failure
== Summary ==
Applying: Sync i915_pciids upto 8717c6b7414f
error: sha1 information is lacking or useless (src/intel_module.c).
error: could not build fak
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17402
===
If we detect that the RPS end points do not scale perfectly, take the
time to measure all the in between values as well. We are aborting the
test, so we might as well spend the available time gathering critical
debug information instead.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers
Hi Dave, Daniel,
just a friendly reminder to merge these changes. They don't seem to be
in the upstream tree yet.
Best regards
Thomas
Am 14.04.20 um 11:07 schrieb Thomas Zimmermann:
> Hi Dave, Daniel,
>
> with 5.7-rc1 being tagged, here's the first PR for drm-next-misc for what
> will become L
If we detect that the RPS end points do not scale perfectly, take the
time to measure all the in between values as well. We are aborting the
test, so we might as well spend the available time gathering critical
debug information instead.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers
On 15/04/2020 10:40, Daniel Vetter wrote:
Not used anymore since the switch to suspend/resume helpers.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.h | 2 --
1 file changed, 2 deletions(-)
More often than not, we need a byte offset into lrc
register state from the start of the hw state. Make it so.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 3 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 8
drivers/gpu/drm/i915/gt/intel_lrc.h
Use indirect ctx bb to load cmd buffer control value
from context image to avoid corruption.
v2: add to lrc layout (Chris)
Testcase: igt/i915_selftest/gt_lrc
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 73 +++--
drivers/gpu/drm/i915/gt/intel_lr
Indirect ctx batchbuffers are a hw feature of which
batch can be run, by hardware, during context restoration stage.
Driver can setup a batchbuffer and also an offset into the
context image. When context image is marshalled from
memory to registers, and when the offset from the start of
context reg
Restoration of a previous timestamp can collide
with updating the timestamp, causing a value corruption.
Combat this issue by using indirect ctx bb to
modify the context image during restoring process.
For render engine, we can preload value into
scratch register. From which we then do the actual
We use different workarounds for render engine than
for other engines. Split the selftest according to these
types so that we get error rates per workaround.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 26 +++---
1 file changed, 23 insertions(+),
Mika Kuoppala writes:
> Indirect ctx batchbuffers are a hw feature of which
> batch can be run, by hardware, during context restoration stage.
> Driver can setup a batchbuffer and also an offset into the
> context image. When context image is marshalled from
> memory to registers, and when the of
Quoting Mika Kuoppala (2020-04-21 14:16:32)
> - END(80)
> + END(185)
Round up to the next cacheline(192) for safety paranoia.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/int
Quoting Mika Kuoppala (2020-04-21 14:16:33)
> @@ -4774,6 +4773,12 @@ static int live_lrc_timestamp(void *arg)
> unsigned long heartbeat;
> int i, err = 0;
>
> + if (rcs && data.engine->class != RENDER_CLASS)
> + continue;
> +
> +
On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>
> Hi Dave, Daniel,
>
> just a friendly reminder to merge these changes. They don't seem to be
> in the upstream tree yet.
Dave noticed and pinged me on irc that there's some changes in core mm
in this one. That patch is correctly acked by
In RPS, we have the option to only specify the unslice [ring] clock
ratio and for the pcu to derive the slice [gpu] clock ratio from its
magic table. We also have the option to tell the pcu to use our
requested gpu clock ratio, and for it to try and throttle the unslice
and slice ratios separately.
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-04-21 14:16:33)
>> @@ -4774,6 +4773,12 @@ static int live_lrc_timestamp(void *arg)
>> unsigned long heartbeat;
>> int i, err = 0;
>>
>> + if (rcs && data.engine->class != RENDER_CLASS)
>> +
Quoting Chris Wilson (2020-04-21 14:45:12)
> In RPS, we have the option to only specify the unslice [ring] clock
> ratio and for the pcu to derive the slice [gpu] clock ratio from its
> magic table. We also have the option to tell the pcu to use our
> requested gpu clock ratio, and for it to try an
== Series Details ==
Series: drm/i915/selftests: Show the full scaling curve on failure (rev2)
URL : https://patchwork.freedesktop.org/series/76260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17404
Summ
Quoting Chris Wilson (2020-04-21 14:50:51)
> Quoting Chris Wilson (2020-04-21 14:45:12)
> > In RPS, we have the option to only specify the unslice [ring] clock
> > ratio and for the pcu to derive the slice [gpu] clock ratio from its
> > magic table. We also have the option to tell the pcu to use ou
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
URL : https://patchwork.freedesktop.org/series/76262/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
52efd944a36d drm/i915: Make define for lrc state offset
c968fc0ee7cf drm/i915:
Chris Wilson writes:
> Quoting Chris Wilson (2020-04-21 14:45:12)
>> In RPS, we have the option to only specify the unslice [ring] clock
>> ratio and for the pcu to derive the slice [gpu] clock ratio from its
>> magic table. We also have the option to tell the pcu to use our
>> requested gpu cloc
Chris Wilson writes:
> If we detect that the RPS end points do not scale perfectly, take the
> time to measure all the in between values as well. We are aborting the
> test, so we might as well spend the available time gathering critical
> debug information instead.
>
> Signed-off-by: Chris Wilso
Hi
Am 21.04.20 um 12:45 schrieb Daniel Vetter:
> On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
>>> Add a new macro helper to combine the usual init sequence in drivers,
>>> consisting of a kzalloc + devm_drm_dev_init + drmm_add
Hi
Am 21.04.20 um 15:41 schrieb Daniel Vetter:
> On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>>
>> Hi Dave, Daniel,
>>
>> just a friendly reminder to merge these changes. They don't seem to be
>> in the upstream tree yet.
>
> Dave noticed and pinged me on irc that there's some chang
Quoting Mika Kuoppala (2020-04-21 15:00:08)
> Chris Wilson writes:
>
> > If we detect that the RPS end points do not scale perfectly, take the
> > time to measure all the in between values as well. We are aborting the
> > test, so we might as well spend the available time gathering critical
> > d
Quoting Mika Kuoppala (2020-04-21 14:56:46)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2020-04-21 14:45:12)
> >> In RPS, we have the option to only specify the unslice [ring] clock
> >> ratio and for the pcu to derive the slice [gpu] clock ratio from its
> >> magic table. We also have the
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
URL : https://patchwork.freedesktop.org/series/76262/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17405
Let's isolate the impact of cpu frequency selection on determing the GPU
throughput in response to selection of RPS frequencies.
For real systems, we do have to be concerned with the impact of
integrating c-states, p-states and rp-states, but for the sake of
proving whether or not RPS works, one b
We use different workarounds for render engine than
for other engines. Split the selftest according to these
types so that we get error rates per workaround.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3
1 - 100 of 147 matches
Mail list logo
