Hi Gustavo
Am 03.03.20 um 19:20 schrieb Gustavo A. R. Silva:
>
>
> On 2/25/20 08:17, Jani Nikula wrote:
>> On Tue, 25 Feb 2020, "Gustavo A. R. Silva" wrote:
>>> The current codebase makes use of the zero-length array language
>>> extension to the C90 standard, but the preferred mechanism to dec
On Fri, 06 Mar 2020, Manasi Navare wrote:
> On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
>> On Thu, 05 Mar 2020, Manasi Navare wrote:
>> > This patch adds defines for the detailed monitor
>> > range flags as per the EDID specification.
>> >
>> > Suggested-by: Ville Syrjälä
>> > C
On 2020-03-05 at 08:47:42 +0530, Anshuman Gupta wrote:
> On 2020-03-04 at 20:45:20 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 03:33:03PM +0200, Jani Nikula wrote:
> > > On Wed, 04 Mar 2020, Anshuman Gupta wrote:
> > > > Few edp panels like Sharp is triggering short and long
> > > > hp
During i915_request_retire() we decouple the i915_request.hwsp_seqno
from the intel_timeline so that it may be freed before the request is
released. However, we need to warn the compiler that the pointer may
update under its nose.
[ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fenc
On Thu, Mar 05, 2020 at 01:44:20AM +0200, Souza, Jose wrote:
> On Wed, 2020-03-04 at 17:09 +0200, Imre Deak wrote:
> > Fix the following kerneldoc warning and while at it also the doc for
> > the
> > corresponding vfunc hook.
> >
> > $ make htmldocs 2>&1 > /dev/null | grep i915
> > ./drivers/gpu/d
Chris Wilson writes:
> Be sure to wait for the vma to be in place before we tell the GPU to
> execute from the wa batch. Since initialisation is mostly synchronous
> (or rather at some point during start up we will need to sync anyway),
> we can affort to do an explicit i915_vma_sync() during wa
On Fri, 06 Mar 2020 17:45:44 +0100,
Kai Vehmanen wrote:
>
> Hi folks,
>
> [+Takashi from ALSA]
>
> On Mon, 6 Jan 2020, Matt Roper wrote:
> >>> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> CDCLK>=2*
During i915_request_retire() we decouple the i915_request.hwsp_seqno
from the intel_timeline so that it may be freed before the request is
released. However, we need to warn the compiler that the pointer may
update under its nose.
[ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fenc
[ 145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work
[i915]
[ 145.927980]
[ 145.927992] write (marked) to 0x8881e513fab0 of 8 bytes by interrupt on
cpu 2:
[ 145.928250] signal_irq_work+0x134/0x640 [i915]
[ 145.928268] irq_work_run_list+0xd7/0x120
[ 145.928283]
[ 120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] / effective_prio
[i915]
[ 120.176566]
[ 120.176577] write to 0x8881e35e6540 of 4 bytes by task 730 on cpu 3:
[ 120.176792] __i915_schedule+0x63e/0x920 [i915]
[ 120.177007] __bump_priority+0x63/0x80 [i915]
[ 120.177220] __i9
[ 25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] /
process_csb [i915]
[ 25.025561]
[ 25.025573] write (marked) to 0x8881e85c1620 of 8 bytes by task 696 on
cpu 1:
[ 25.025789] __i915_request_create+0x54b/0x5d0 [i915]
[ 25.026001] i915_request_create+0xcc/0x150 [i9
Record the initial active element we use when building the next ELSP
submission, so that we can compare against it latter to see if there's
no change.
Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 17
[ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[ 206.875654]
[ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
bytes by task 703 on cpu 3:
[ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
[ 206.876130] __bump_priority+0x63/0x80 [i915]
[ 2
We read the current state of intel_rps.active outside of the lock, so
mark up the racy access.
[ 525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park
[i915]
[ 525.037091]
[ 525.037103] write to 0x8881f145efa1 of 1 bytes by task 192 on cpu 2:
[ 525.037331] intel_rp
== Series Details ==
Series: drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
URL : https://patchwork.freedesktop.org/series/74442/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16876
Summary
-
[ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail /
drm_gem_object_handle_put_unlocked
[ 1715.899838]
[ 1715.899861] write to 0x8881830f3604 of 4 bytes by task 7834 on cpu 1:
[ 1715.899896] drm_gem_handle_create_tail+0x62/0x250
[ 1715.899927] drm_gem_open_ioctl+0xc1/0x160
[
Mark up the potential racy read in drm_mm_initialized(), as we want a
cheap and cheerful check:
[ 121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915] /
rm_hole
[ 121.098766]
[ 121.098789] write (marked) to 0x8881f01ed330 of 8 bytes by task 3568 on
cpu 3:
[ 121.0988
== Series Details ==
Series: series starting with [1/5] drm/i915: Mark up unlocked update of
i915_request.hwsp_seqno
URL : https://patchwork.freedesktop.org/series/74445/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16877
===
Chris Wilson writes:
> We read the current state of intel_rps.active outside of the lock, so
> mark up the racy access.
>
> [ 525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] /
> intel_rps_park [i915]
> [ 525.037091]
> [ 525.037103] write to 0x8881f145efa1 of 1 bytes by task 19
== Series Details ==
Series: drm/i915/gt: Defend against concurrent updates to execlists->active
URL : https://patchwork.freedesktop.org/series/74447/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16878
Su
== Series Details ==
Series: drm/i915/gt: Mark up intel_rps.active for racy reads
URL : https://patchwork.freedesktop.org/series/74448/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16879
Summary
---
[ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] /
i915_request_await_dma_fence [i915]
[ 3783.276766]
[ 3783.276787] write to 0x8881f1bc60a0 of 1 bytes by interrupt on cpu 2:
[ 3783.277187] __i915_request_submit+0x47e/0x4a0 [i915]
[ 3783.277580] __execlists_submission_tas
== Series Details ==
Series: drm/i915: Gamma cleanups (rev4)
URL : https://patchwork.freedesktop.org/series/69136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8087 -> Patchwork_16866
Summary
---
**SUCCESS**
No r
== Series Details ==
Series: drm: Mark up racy check of drm_gem_object.handle_count
URL : https://patchwork.freedesktop.org/series/74450/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16880
Summary
---
Chris Wilson writes:
> During i915_request_retire() we decouple the i915_request.hwsp_seqno
> from the intel_timeline so that it may be freed before the request is
> released. However, we need to warn the compiler that the pointer may
> update under its nose.
>
> [ 171.438899] BUG: KCSAN: data-r
Quoting Mika Kuoppala (2020-03-09 14:03:01)
> Chris Wilson writes:
>
> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
> > from the intel_timeline so that it may be freed before the request is
> > released. However, we need to warn the compiler that the pointer may
> > upda
On Sat, Mar 07, 2020 at 10:13:10PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-12-13 17:17:39)
> > On Fri, Dec 13, 2019 at 07:06:01PM +0200, Ville Syrjälä wrote:
> > > On Fri, Dec 13, 2019 at 03:54:33PM +, Chris Wilson wrote:
> > > > Quoting Ville Syrjala (2019-12-13 15:28:23)
> >
Quoting Ville Syrjälä (2020-03-09 14:21:20)
> On Sat, Mar 07, 2020 at 10:13:10PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2019-12-13 17:17:39)
> > > On Fri, Dec 13, 2019 at 07:06:01PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Dec 13, 2019 at 03:54:33PM +, Chris Wilson wrote:
> >
== Series Details ==
Series: drm/mm: Allow drm_mm_initialized() to be used outside of the locks
URL : https://patchwork.freedesktop.org/series/74451/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16881
Sum
[ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] /
process_csb [i915]
[ 7534.150706]
[ 7534.150717] write to 0x8881f1bc24b4 of 4 bytes by task 24404 on cpu 3:
[ 7534.150925] __execlists_submission_tasklet+0x1158/0x2780 [i915]
[ 7534.151133] execlists_submit_reque
== Series Details ==
Series: drm/i915: Mark racy read of intel_engine_cs.saturated
URL : https://patchwork.freedesktop.org/series/74455/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16882
Summary
---
== Series Details ==
Series: drm/i915: Mark up unlocked update of i915_request.hwsp_seqno
URL : https://patchwork.freedesktop.org/series/74442/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16876_full
Chris Wilson writes:
> [ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] /
> i915_request_await_dma_fence [i915]
> [ 3783.276766]
> [ 3783.276787] write to 0x8881f1bc60a0 of 1 bytes by interrupt on cpu 2:
> [ 3783.277187] __i915_request_submit+0x47e/0x4a0 [i915]
> [ 3783.
From: Wambui Karuga
This converts uses of the printk based drm logging macros to the struct
drm_device logging macros in i915/display/intel_dsb.c. This was done
using the following coccinelle script:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T
Rebase of Wambui's series [1] to drm-tip, with a couple of manual
conversions included.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/72760/
Wambui Karuga (10):
drm/i915/dsb: convert to drm_device based logging macros.
drm/i915/fbc: convert to drm_device based logging macros.
drm
Please ignore this, I seem to have some smtp trouble which fails some of
tha patches. This will be incomplete.
Wambui, I'll resend this later.
BR,
Jani.
On Mon, 09 Mar 2020, Jani Nikula wrote:
> Rebase of Wambui's series [1] to drm-tip, with a couple of manual
> conversions included.
>
> BR,
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-03-09 14:03:01)
>> Chris Wilson writes:
>>
>> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
>> > from the intel_timeline so that it may be freed before the request is
>> > released. However, we need to warn the compiler
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++-
drivers/gpu/drm/i915/selftests/i915_request.c | 18 -
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
Chris Wilson writes:
> [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> [ 206.875654]
> [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> bytes by task 703 on cpu 3:
> [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> [ 206.876130] __
Quoting Mika Kuoppala (2020-03-09 15:05:45)
> Chris Wilson writes:
>
> > [ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] /
> > i915_request_await_dma_fence [i915]
> > [ 3783.276766]
> > [ 3783.276787] write to 0x8881f1bc60a0 of 1 bytes by interrupt on cpu 2:
> > [ 3783.2
== Series Details ==
Series: series starting with [1/5] drm/i915: Mark up unlocked update of
i915_request.hwsp_seqno
URL : https://patchwork.freedesktop.org/series/74445/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16877_full
=
== Series Details ==
Series: drm/i915/execlists: Mark up the racy access to switch_priority_hint
URL : https://patchwork.freedesktop.org/series/74457/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16883
Su
Quoting Mika Kuoppala (2020-03-09 15:21:31)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-03-09 14:03:01)
> >> Chris Wilson writes:
> >>
> >> > During i915_request_retire() we decouple the i915_request.hwsp_seqno
> >> > from the intel_timeline so that it may be freed before the reque
== Series Details ==
Series: series starting with [01/17] drm/i915: Add an implementation for
i915_gem_ww_ctx locking, v2. (rev2)
URL : https://patchwork.freedesktop.org/series/74387/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a07375e972da drm/i915: Add an implementation fo
Chris Wilson writes:
> [ 25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] /
> process_csb [i915]
> [ 25.025561]
> [ 25.025573] write (marked) to 0x8881e85c1620 of 8 bytes by task 696 on
> cpu 1:
> [ 25.025789] __i915_request_create+0x54b/0x5d0 [i915]
> [ 25.026001
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
Reviewed-by: Ville Syrjälä
Signed-off-by: Stanislav Lisovskiy
---
driv
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with ad
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
That is a preparation patch before next one where we
introduce old_bw_state and a bunch of other changes
as well.
In a review comment it was suggested to split out
at least that renaming into a separate patch, what
is done here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4ec4dbba022f..a8a01a980b8f 100644
--- a/dr
Quoting Mika Kuoppala (2020-03-09 15:34:40)
> Chris Wilson writes:
>
> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> > [ 206.875654]
> > [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> > bytes by task 703 on cpu 3:
> > [ 206.875901
On Sun, Mar 08, 2020 at 03:32:32AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl: Don't treat unslice registers as masked (rev3)
> URL : https://patchwork.freedesktop.org/series/74351/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8090_full
== Series Details ==
Series: series starting with [01/17] drm/i915: Add an implementation for
i915_gem_ww_ctx locking, v2. (rev2)
URL : https://patchwork.freedesktop.org/series/74387/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8097 -> Patchwork_16884
==
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-03-09 15:34:40)
>> Chris Wilson writes:
>>
>> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
>> > [ 206.875654]
>> > [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of
>> > 8 bytes by task
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/74461/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5a587535617 drm/i915: Start passing latency as parameter
33f087f7ad33 drm/i915: Introduce skl_plane_wm_level accessor.
Chris Wilson writes:
> [ 145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work
> [i915]
> [ 145.927980]
> [ 145.927992] write (marked) to 0x8881e513fab0 of 8 bytes by interrupt
> on cpu 2:
> [ 145.928250] signal_irq_work+0x134/0x640 [i915]
> [ 145.928268] irq_wor
Quoting Mika Kuoppala (2020-03-09 16:38:49)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-03-09 15:34:40)
> >> Chris Wilson writes:
> >>
> >> > [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930
> >> > [i915]
> >> > [ 206.875654]
> >> > [ 206.875666] race at unkno
>>But he asked whether it's possible for Media and OpenCL drivers to also
>>disable mid-thread preemption through the INTERFACE_DESCRIPTOR_DATA, instead
>>of from the >>kernel side, so we could try to experiment with it in the
>>future.
Interface Descriptor setting only switches the preemption
Chris Wilson writes:
> [ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915]
> / process_csb [i915]
> [ 7534.150706]
> [ 7534.150717] write to 0x8881f1bc24b4 of 4 bytes by task 24404 on cpu 3:
> [ 7534.150925] __execlists_submission_tasklet+0x1158/0x2780 [i915]
> [ 7
Chris Wilson writes:
> [ 120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] /
> effective_prio [i915]
> [ 120.176566]
> [ 120.176577] write to 0x8881e35e6540 of 4 bytes by task 730 on cpu 3:
> [ 120.176792] __i915_schedule+0x63e/0x920 [i915]
> [ 120.177007] __bump_priority+0x
[ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[ 206.875654]
[ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
bytes by task 703 on cpu 3:
[ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
[ 206.876130] __bump_priority+0x63/0x80 [i915]
[ 2
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/display: Deactive FBC in
fastsets when disabled by parameter (rev2)
URL : https://patchwork.freedesktop.org/series/74401/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
80e3e1bd274b drm/i915/display: Deactive F
Chris Wilson writes:
> [ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
> [ 206.875654]
> [ 206.875666] race at unknown origin, with read to 0x8881f7644480 of 8
> bytes by task 703 on cpu 3:
> [ 206.875901] __i915_schedule+0x7fc/0x930 [i915]
> [ 206.876130] __
On Wed, Mar 4, 2020 at 4:36 PM Daniele Ceraolo Spurio
wrote:
>
> Hi,
>
> Kindly add the below i915 changes to linux-firmware.git
>
> The following changes since commit 0148cfefcbf98898ca65bb26d9d7d638b30e211d:
>
> Merge https://github.com/rjliao-qca/qca-btfw (2020-03-02 08:08:15 -0500)
>
> are a
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix
From: Tvrtko Ursulin
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 +
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For in
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 23 +
From: Tvrtko Ursulin
Accumulate software tracked runtime from abandoned engines and destroyed
contexts (same as we previously did for pphwsp runtimes).
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_contex
From: Tvrtko Ursulin
When available prefer context tracked context busyness because it provides
visibility into currently executing contexts as well.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drm_client.c | 83 +-
drivers/gpu/drm/i915/i915_drm_client.h
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
pat
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/ge
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing o
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_con
From: Tvrtko Ursulin
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
drivers/gpu/drm/i915/i9
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series. Highlights from this
version:
* Different way of tracking runtime of exited/unreachable context. This time
round I accumulate those per context/client and engine class, but active
contexts are kept in a list an
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index abf8c777041d..
From: Tvrtko Ursulin
Just a demo to follow the the i915 feature.
Tvrtko Ursulin (1):
intel-gpu-top: Support for client stats
tools/intel_gpu_top.c | 539 +-
1 file changed, 528 insertions(+), 11 deletions(-)
--
2.20.1
___
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads:
== Series Details ==
Series: Per client engine busyness (rev5)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a60fd0a6e3d1 drm/i915: Expose list of clients in sysfs
-:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted fil
== Series Details ==
Series: Per client engine busyness (rev5)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Expose list of clients in sysfs
Okay!
Commit: drm/i915: Update client name on
== Series Details ==
Series: drm/i915: Gamma cleanups (rev4)
URL : https://patchwork.freedesktop.org/series/69136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8087_full -> Patchwork_16866_full
Summary
---
**WARNING
== Series Details ==
Series: drm/i915/gt: Defend against concurrent updates to execlists->active
URL : https://patchwork.freedesktop.org/series/74447/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16878_full
==
== Series Details ==
Series: drm/i915/gt: Mark up intel_rps.active for racy reads
URL : https://patchwork.freedesktop.org/series/74448/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16879_full
Summary
== Series Details ==
Series: drm/i915: Gamma cleanups (rev4)
URL : https://patchwork.freedesktop.org/series/69136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8087_full -> Patchwork_16866_full
Summary
---
**WARNING
On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
On 04/03/2020 07:48, Dixit, Ashutosh wrote:
> On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
>> From: Lionel Landwerlin
>>
>> With the currently avail
On Fri, Mar 06, 2020 at 09:10:56PM +0530, Sharma, Swati2 wrote:
>
>
> On 03-Mar-20 11:03 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Remainder of my earlier gamma cleanups, rebased due to
> > hw vs. uapi split and intel_de_{read,write}().
>
> I didn't get patch#8. Everything looks
On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> amongst every driver and don't do anything other than calling
> drm_connector_register().
> drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
> a
== Series Details ==
Series: drm: Mark up racy check of drm_gem_object.handle_count
URL : https://patchwork.freedesktop.org/series/74450/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16880_full
Summa
On Mon, Mar 09, 2020 at 10:35:52AM +0200, Jani Nikula wrote:
> On Fri, 06 Mar 2020, Manasi Navare wrote:
> > On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
> >> On Thu, 05 Mar 2020, Manasi Navare wrote:
> >> > This patch adds defines for the detailed monitor
> >> > range flags as pe
On Mon, Mar 9, 2020 at 4:27 PM Lyude Paul wrote:
>
> On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> > amongst every driver and don't do anything other than calling
> > drm_connector_register().
> > drm_dp_mst_
On running several back to back perf capture sessions involving closing
and opening the perf stream, invalid OA reports are seen in the
beginning of the OA buffer in some sessions. Fix this by invalidating OA
TLB when the perf stream is closed or disabled on gen12.
Signed-off-by: Umesh Nerlige Ram
On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
On 04/03/2020 07:48, Dixit, Ashutosh wrote:
> On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
>> From: Lionel Landwerlin
>>
>> With the currently avail
== Series Details ==
Series: drm/mm: Allow drm_mm_initialized() to be used outside of the locks
URL : https://patchwork.freedesktop.org/series/74451/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8097_full -> Patchwork_16881_full
===
Quoting Tvrtko Ursulin (2020-03-09 18:31:18)
> +struct i915_drm_client *
> +i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct
> *task)
> +{
> + struct i915_drm_client *client;
> + int ret;
> +
> + client = kzalloc(sizeof(*client), GFP_KERNEL);
> + if
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_f
1 - 100 of 131 matches
Mail list logo
