From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_gem_drop_caches
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- drop_caches
|
+-- forc
Hi Chris,
On Wed, Mar 18, 2020 at 02:06:07PM +, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-18 13:58:37)
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
>
> Ok.
>
> > i915_ge
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt
Hi Chris,
On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-20 03:49:01)
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> > i915_gem_interrupt
> > i
h.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Lyude Paul
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/in
hes
> and doesn't justify full power.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
> Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Lyude
Hi Chris,
> struct intel_uncore *uncore = rc6_to_uncore(rc6);
> + unsigned int target;
>
> if (!rc6->enabled)
> return;
> @@ -622,7 +623,14 @@ void intel_rc6_park(struct intel_rc6 *rc6)
>
> /* Turn off the HW timers and go directly to rc6 */
> set(unco
l rc6 */
>
> can we put names to these values?
actually, you are using these only here and there is a comment to
them... givinb those values a meaningful define is a bit of a
formality, I'd say. It's up to you.
Reviewed-by: Andi Shyti
Thanks,
Andi
__
/gitlab.freedesktop.org/drm/intel/issues/1516
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
bugs:
> - keep printing HUC_STATUS register
> - correcly set permissions for writable debugfs files
>
> Cc: Andi Shyti
> Cc: Michal Wajdeczko
> Cc: John Harrison
> Cc: Matthew Brost
>
> Andi Shyti (1):
> drm/i915/gt: allow setting generic data pointer
&g
y
> means we failed to enter RC0 correctly.
>
> If we can't measure the energy draw with the MSR, then it will report 0
> for both measurements. Since the measurement works on all gen6+, this seems
> worth flagging as an error.
>
> Signed-off-by: Chris Wilson
> Cc: M
Hi Chris,
On Thu, Mar 26, 2020 at 02:27:27PM +, Chris Wilson wrote:
> Userptr causes lockdep to complain when we are using the aliasing-ppgtt
> (and ggtt, but for that it is rightfully so to complain about) in that
> when we revoke the userptr we take a mutex which we also use to revoke
> the
Hi Chris,
> > On Thu, Mar 26, 2020 at 02:27:27PM +, Chris Wilson wrote:
> > > Userptr causes lockdep to complain when we are using the aliasing-ppgtt
> > > (and ggtt, but for that it is rightfully so to complain about) in that
> > > when we revoke the userptr we take a mutex which we also us
Hi Chris,
On Tue, Mar 31, 2020 at 05:53:32PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-31 17:45:08)
> > +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > + int slice, u8 *to_mask)
> > +{
> >
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- inte
> error")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Joonas Lahtinen
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- inte
On Tue, Mar 31, 2020 at 11:10:55PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-31 23:04:32)
> > From: Andi Shyti
> >
> > The following interfaces:
> >
> > i915_wedged
> > i915_forcewake_user
> > i915_gem_interrupt
> > i915_sseu_s
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forc
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forc
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forc
Hi Chris,
On Mon, Apr 06, 2020 at 12:00:26PM +0100, Chris Wilson wrote:
> All the information for hangcheck is pulled into i915_engine_info so the
> separate dump is redundant.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
now we can get rid of i915
ture problem -- and leave it to whoever has to debug it next time.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Andi Shyti
The i915_sseu_status is broken and the tests on this interface
are disabled. There is no reason to drag it along.
Remove it!
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs.c | 257
1 file changed, 257 deletions(-)
diff --git a
Please ignore... wrong patch! :/
Andi
On Wed, Apr 08, 2020 at 12:43:50AM +0300, Andi Shyti wrote:
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_user
> i915_gem_interrupt
> i915_rcs_topology
> i915_sseu_status
>
>
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forc
From: Andi Shyti
Hi,
In this 7th version I removed in a separate patch the sseu
interface which is broken and therefore useless.
Thanks Tvrtko and Chris for the review,
Andi
Changelog
=
v7:
- add a preliminary patch that removes completely the
i915_sseu_status interface.
v6
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forc
Hi Tvrtko,
I start by saying that this patch was mainly sent to kickstart a
discussion about cleanups required in debugfs and how debugfs can
be inconsistent and how much it looks to me that we are relying
on its current state.
> > The i915_sseu_status is broken and the tests on this interface
>
ris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
forcing the
> uncached read, and adding the missing barrier for the singular
> insert_page (relocation paths), the sporadic failures go away.
>
> Fixes: 983d308cb8f6 ("agp/intel: Serialise after GTT updates")
> Signed-off-by: Chris Wilson
> Cc: sta...@vger.kernel.
s) &&
> + execlists_active(&engine->execlists) == rq &&
> !i915_request_completed(rq)) {
> struct drm_printer p =
> drm_info_printer(gt->i915->drm.dev);
Reviewed-b
TEST_PAN | TEST_HANG,
> "flip-vs-panning-vs-hang" },
> + { 1, TEST_FLIP | TEST_MODESET | TEST_HANG | TEST_NOEVENT,
> "flip-vs-modeset-vs-hang" },
> + { 1, TEST_FLIP | TEST_PAN | TEST_HANG,
> "flip-vs-panning-vs-hang"
is true and we
> compare the interrupt with the EI that caused it.]
looks reasonable to me. Wouldn't it make also sense to evaluate
the difference between the current and the previous pm_iir?
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mail
wart jitter on bursty workloads by
> making it easier to increase than it is to decrease frequencies, and
> reduce the number of interrupts we would need to process.
>
> Fixes: 21abf0bf168d ("drm/i915/gt: Treat idling as a RPS downclock event")
> Closes: https://gitlab.f
for long
> periods of time.
>
> Reported-by: Francisco Jerez
> Suggested-by: Francisco Jerez
> Fixes: 35cc7f32c298 ("drm/i915/gt: Use non-forcewake writes for RPS")
> Signed-off-by: Chris Wilson
> Cc: Francisco Jerez
> Cc: Mika Kuoppala
> Cc: Andi Shyti
see
> an interrupt if we keep the GPU busy for an entire EI.
>
> Signed-off-by: Chris Wilson
Looks correct to me,
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gned-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 27 +
> drivers/gpu/drm/i915/gt/intel_gt_clk.c | 76 +
> drivers/gpu/drm/i915/gt/inte
Hi Chris,
On Thu, Apr 16, 2020 at 09:33:52PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-04-16 21:31:10)
> > Hi Chris,
> >
> > > For many configuration details within RC6 and RPS we are programming
> > > intervals for the internal clo
Hi Chris,
> +static u64 __measure_power(int duration_ms)
> +{
> + u64 nrg, dt;
> +
> + dt = -ktime_get();
> + nrg = -st_energy_uJ();
> + msleep(5);
usleep_range?
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-g
3589] drm_mode_page_flip_ioctl+0x587/0x5d0
>
> This completes the symmetry lost in commit 8b1c78e06e61 ("drm/i915: Avoid
> calling i915_gem_object_unbind holding object lock").
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1743
> Fixes: 8b1c78e06e61 ("drm/i915: Avoid calling i915_gem_object_unbind holding
> object lock")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Andi Shyti
> Cc: # v5.6+
Acked-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
[...]
> +static int s_many(void *arg)
> +{
> + struct perf_series *ps = arg;
why do we need to go through void... all functions are taking a
perf_series structure.
> + IGT_TIMEOUT(end_time);
> + unsigned int idx = 0;
> +
[...]
> + for (idx = 0; idx < nengines
request_put as well?
>
> No. Nasty API, add consumes the reference. It's on the list to update
> now that we have a ~majority of cases that want to keep a reference to
> their request.
arrghh!
> > > + for_each_uabi_engine(engine, i915) {
> > >
\n");
> err = -EINVAL;
> - goto out_close;
> + goto out_put;
> }
>
> err = i915_subtests(tests, ppgtt);
>
> -out_close:
> +out_put:
> i915_vm_put(&ppgtt->vm);
Did anything change here
On Fri, Apr 24, 2020 at 11:22:13AM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-04-24 11:16:17)
> > Hi Chris,
> >
> > On Wed, Apr 22, 2020 at 08:05:58PM +0100, Chris Wilson wrote:
> > > The history of i915_vma_close() is confusing, as is its use. As the
>
Hi Chris,
On Wed, Apr 22, 2020 at 01:17:01AM +0100, Chris Wilson wrote:
> 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,
lson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
t;
> > > - mask &= READ_ONCE(rps->pm_events);
> > > + mask &= rps->pm_events;
> >
> > we are giving up the read/write ordering here because we thing
> > that removing the down interval we won't have anymore
> >
> static void engine_record_execlists(struct intel_engine_coredump *ee)
> @@ -1231,8 +1235,10 @@ static void engine_record_execlists(struct
> intel_engine_coredump *ee)
> struct i915_request * const *port = el->active;
> unsigned int n = 0;
>
> - while (*port)
> - re
Hi Chris,
On Sat, Apr 25, 2020 at 06:57:48PM +0100, Chris Wilson wrote:
> Use the new intel_rps.flags field to store whether or not interrupts are
> being used with RPS.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
_
Hi Chris,
On Sat, Apr 25, 2020 at 07:54:00PM +0100, Chris Wilson wrote:
> As with the realisation for soft-rc6, we respond to idling the engines
> within microseconds, far faster than the response times for HW RC6 and
> RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> running f
Hi Chris,
> intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
> if (IS_CHERRYVIEW(i915))
> - rps->enabled = chv_rps_enable(rps);
> + enabled = chv_rps_enable(rps);
> else if (IS_VALLEYVIEW(i915))
> - rps->enabled = vlv_rps_enable(rps);
> +
more responsive for better performance and powersaving
> for both spiky workloads and steady-state.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1698
> Fixes: 98479ada421a ("drm/i915/gt: Treat idling as a RPS downclock event")
> Signed-off-by: Chris Wilson
and instead
> try and derive the pointer from a supplied intel_gt.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
Thank you,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesk
read back from the CPU cache and
> so we must clflush our control over that page. In doing so, push the
> sanitisation to the start of the GT sequence so that our poisoning is
> assuredly before we start talking to the HW.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
An
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:01AM +0100, Chris Wilson wrote:
> The bspec lists both the clock frequency and the effective interval. The
> interval corresponds to observed behaviour, so adjust the frequency to
> match.
what is the observed behavior?
Andi
___
s
> whose only interaction is through the manual parking events, carry over
> the aggressive downclocking to the fake RPS events.
>
> References: 21abf0bf168d ("drm/i915/gt: Treat idling as a RPS downclock
> event")
> Signed-off-by: Chris Wilson
Reviewed-by: And
190751537693,100.00,,
> 1447.89,Joules,power/energy-cores/,190751542360,100.00,,
> 394.93,Joules,power/energy-gpu/,190751543518,100.00,,
> 67956,M,i915/actual-frequency/,190751526709,100.00,,
> 40240837120,ns,i915/rc6-residency/,190751523820,100.00,,
> 147090761985,ns,i915/rcs0-busy/,190751525291,100.0
Hi Chris,
On Mon, Apr 27, 2020 at 09:54:04AM +0100, Chris Wilson wrote:
> Pull the boolean intel_rps.enabled and intel_rps.active into a single
> flags field, in preparation for more.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
for indirect ctx
> batchbuffers")
> Signed-off-by: Dan Carpenter
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
up again
> unexepectedly.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1811
> Fixes: 8e99299a04bc ("drm/i915/gt: Track use of RPS interrupts in flags")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
Thanks,
Andi
sometimes^W
> - * often trashed across a GPU reset! Instead we have to rely on
> - * guessing the missed context-switch events by looking at what
> - * requests were completed.
> - */
> - execlists_cancel_port_requests(execlists);
> -
why did this end up
Hi Chris,
> static void i915_switcheroo_set_state(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> {
> - struct drm_device *dev = pci_get_drvdata(pdev);
> + struct drm_i915_private *i915 = pdev_to_i915(pdev);
> pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
>
> +
Hi Chris,
On Tue, Jul 30, 2019 at 02:30:30PM +0100, Chris Wilson wrote:
> Use the same mechanism to determine if a backend engine exists for a
> uabi mapping as used internally.
Looks OK,
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Hi Chris,
> /**
> - * i915_gem_shrinker_register - Register the i915 shrinker
> + * i915_gem_driver_register__shrinker - Register the i915 shrinker
> * @i915: i915 device
> *
> * This function registers and sets up the i915 shrinker and OOM handler.
> */
> -void i915_gem_shrinker_register
n
the fly :)
Would be nice to have _any_ change documented in the log. In any
case:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
On Tue, Jul 30, 2019 at 02:30:27PM +0100, Chris Wilson wrote:
> Push the ring creation flags from the outer GEM context to the inner
> intel_cotnext to avoid an unsightly back-reference from inside the
> backend.
>
> Signed-off-by: Chris Wilson
looks nice!
Reviewed
Hi Chris,
On Tue, Jul 30, 2019 at 10:24:53PM +0100, Chris Wilson wrote:
> Check for viability of store-dword before use.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
use i915 inside drv_get_drvdata()
> v3: Only expect i915 inside drv_get_drvdata() so drop the assumed
> i915/drm equivalence.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
Thanks,
Andi
___
In
em_context_is_banned(ctx))
> + return;
just a question, if a context is "banned", don't we want to check
on the requests anyway?
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
heartbeat? I like it :)
Reviewed-by: Andi Shyti
Thanks,
Andi
___
checking.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Acked-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
On Sat, Aug 10, 2019 at 10:03:29AM +0100, Chris Wilson wrote:
> Check that the engine w/a persist after we performed a context switch
> and record those w/a into the default context state.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Acked-by: Andi Shyti
9
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
, it
> is in order submission (and so the batch is after the main setup
> anyway!).
>
> Signed-off-by: Chris Wilson
looks straight forward to me.
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:11AM +0100, Chris Wilson wrote:
> Trying to hit a deadlock for invalidating dirty userptr pages (via
> kcompactd).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailin
be run in fence order and fall back to submission
> order, we will time out waiting for our incremental results and trigger
> a few GPU hangs.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110987
> Signed-off-by: Chris Wils
Hi Chris,
On Tue, Aug 13, 2019 at 07:20:12AM +0100, Chris Wilson wrote:
> Still trying to hit a deadlock with userptr from kcompatcd.
>
> Signed-off-by: Chris Wilson
This looks all right, as well.
Reveiwed-by: Andi Shyti
Andi
___
Intel-gf
ing up the GPU error capture")
> Fixes: 748317386afb ("drm/i915/execlists: Offline error capture")
> Signed-off-by: Chris Wilson
> Cc: Mike Lothian
> Cc: Andi Shyti
right!
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mai
y case,
Reviewed-by: Andi Shyti
Thanks,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
reedesktop.org/drm/intel/issues/1114
> Testcase: igt/i915_pm_rc6_residency/rc6-idle #ivb
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/dr
e system.
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1114
> > > Testcase: igt/i915_pm_rc6_residency/rc6-idle #ivb
> > > Signed-off-by: Chris Wilson
> > > Cc: Andi Shyti
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +-
From: Andi Shyti
Add three basic tests for rc6 power status:
1. live_rc6_basic - simply checks if rc6 works when it's enabled
or stops when it's disabled.
2. live_rc6_threshold - rc6 should not work when the evaluation
interval is less than the threshold and should work oth
Hi Mika,
> > +static bool test_rc6(struct intel_rc6 *rc6, bool enabled)
> > +{
> > + struct intel_uncore *uncore = rc6_to_uncore(rc6);
> > + intel_wakeref_t wakeref;
> > + u32 ec1, ec2;
> > + u32 interval;
> > +
> > + wakeref = intel_runtime_pm_get(uncore->rpm);
> > +
> > + interval =
From: Andi Shyti
Add three basic tests for rc6 power status:
1. live_rc6_basic - simply checks if rc6 works when it's enabled
or stops when it's disabled.
2. live_rc6_threshold - rc6 should not work when the evaluation
interval is less than the threshold and should work oth
From: Andi Shyti
Add three basic tests for rc6 power status:
1. live_rc6_basic - simply checks if rc6 works when it's enabled
or stops when it's disabled.
2. live_rc6_threshold - rc6 should not work when the evaluation
interval is less than the threshold and should work oth
From: Andi Shyti
live_rc6_busy keeps the gpu busy and then goes in idle;
checks that we don't fall in rc6 when busy and that we do fall
in rc6 when idling.
The test is added as subtest of the bigger live_late_gt_pm
selftest.
The basic rc6 functionality is tested by checking the refe
From: Andi Shyti
rc6 should not work when the evaluation interval is less than the
threshold and should work otherwise.
live_rc6_threshold tests such behavior
The test is added as subtest of the bigger live_late_gt_pm
selftest.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm
From: Andi Shyti
live_rc6_basic simply checks if rc6 works when it's enabled
or stops when it's disabled.
The test is added as subtest of the bigger live_late_gt_pm
selftest.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 1 +
drivers/gp
From: Andi Shyti
Hi,
unfortunately rc6 is still a mysterious system and not all tests
provide the expected results.
I split the three tests in three different patches in order to
have more flexibility in picking them.
Thanks Chris and Mika for the reviews,
Andi
Changelog:
* v5 ->
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile| 4 +-
dri
On Sat, Feb 08, 2020 at 04:26:18PM +, Chris Wilson wrote:
> Quoting Andi Shyti (2020-02-08 12:27:59)
> > From: Andi Shyti
> >
> > The GT has its own properties and in sysfs they should be grouped
> > in the 'gt/' directory.
> >
> > Creat
Hi Chris,
> > > > The GT has its own properties and in sysfs they should be grouped
> > > > in the 'gt/' directory.
> > > >
> > > > Create the 'gt/' directory in sysfs and move the power management
> > > > related files.
> > >
> > > As shown by BAT, we have a conundrum; do we have to preserve th
> > > > > > The GT has its own properties and in sysfs they should be grouped
> > > > > > in the 'gt/' directory.
> > > > > >
> > > > > > Create the 'gt/' directory in sysfs and move the power management
> > > > > > related files.
> > > > >
> > > > > As shown by BAT, we have a conundrum; do we ha
Hi Jani,
> > void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private
> > *i915)
> > {
> > @@ -321,6 +322,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
> > intel_rps_driver_register(>->rps);
> >
> > debugfs_gt_register(gt);
>
> Yikes, when did this happen? Not
"We don't own the debugfs 'namespace' prefix." (Jani Nikula [*])
I agree, change the functions name from "debugfs_*" to
"intel_gt_*" prefix.
[*] https://patchwork.freedesktop.org/patch/352553/#comment_651183
Signed-off-by: Andi Shyti
Hi Chris,
> > "We don't own the debugfs 'namespace' prefix." (Jani Nikula [*])
> >
> > I agree, change the functions name from "debugfs_*" to
> > "intel_gt_*" prefix.
>
> An alternate way of looking at it is that these are all dependent on
> CONFIG_DEBUGFS. So are they not the debugfs interface?
Hi Chris,
On Tue, Feb 11, 2020 at 12:37:42AM +, Chris Wilson wrote:
> The engine names are now stored inside the iterator and not as static
> strings. If we wish to use them later, we need to make a copy.
But we are not using them later. Your patch just copies and frees
an array.
Is there a
t;drm/i915/execlists: Leave resetting ring to
> intel_ring")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
looks OK to me:
Reviewed-by: Andi Shyti
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Feb 11, 2020 at 08:10:27PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> rela
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Signed-off-by: Andi Shyti
---
Hi,
this second version takes into account the co
501 - 600 of 2148 matches
Mail list logo
