== Series Details ==
Series: Allow privileged user to map the OA buffer (rev6)
URL : https://patchwork.freedesktop.org/series/79460/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8814_full -> Patchwork_18269_full
Summary
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev6)
URL : https://patchwork.freedesktop.org/series/79460/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8814 -> Patchwork_18269
Summary
---
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev6)
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Allow privileged user to map the OA buffer (rev6)
URL : https://patchwork.freedesktop.org/series/79460/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f47a2dc77f17 drm/i915: Allow removal of whitelist register and refactor
0b9b3f22f602
From: Piotr Maciejewski
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach
From: Piotr Maciejewski
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
Fixes: 00a7f0d7155c
From: Piotr Maciejewski
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is
The flags field of the wa->reg has whitelist settings as opposed to the
value returned from i915_mmio_reg_offset(reg). Clear the flags before
compare.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
This cover letter is included to trigger "Test-with" an IGT patch.
Tests - https://patchwork.freedesktop.org/series/80059/
Signed-off-by: Umesh Nerlige Ramappa
Test-with: 20200730004603.8171-1-umesh.nerlige.rama...@intel.com
Piotr Maciejewski (4):
drm/i915/perf: Ensure observation logic is
- Add a helper to remove whitelisted register from the list.
- Refactor _wa_add to use _wa_index to find an existing whitelisted
register.
- Free the old list when growing the whitelist.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 82
Applied. Thanks!
Alex
On Tue, Jul 28, 2020 at 2:56 AM Christian König
wrote:
>
> Am 27.07.20 um 23:30 schrieb Daniel Vetter:
> > Trying to grab dma_resv_lock while in commit_tail before we've done
> > all the code that leads to the eventual signalling of the vblank event
> > (which can be a
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/80045/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8814_full -> Patchwork_18268_full
On Wed, Jul 29, 2020 at 10:51:23AM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 5:24 AM Daniel Vetter wrote:
> >
> > Do we have a access_ok_array or so? Instead of duplicating overflow checks
> > everywhere and getting it all wrong ...
>
> I really really think you should get away from
On Wed, Jul 29, 2020 at 5:24 AM Daniel Vetter wrote:
>
> Do we have a access_ok_array or so? Instead of duplicating overflow checks
> everywhere and getting it all wrong ...
I really really think you should get away from access_ok() entirely.
Please just get rid of it, and use
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/80045/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8814 -> Patchwork_18268
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/80045/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
kmalloc uses power-of-two slab buckets for small allocations (up to a
few pages). Since i915_page_directory is a page of pointers, plus a
couple more, this is rounded up to 8K, and we waste nearly 50% of that
allocation. Long terms this leads to poor memory utilisation, bloating
the kernel
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and that we need to break
away from simple system
We need to make the DMA allocations used for page directories to be
performed up front so that we can include those allocations in our
memory reservation pass. The downside is that we have to assume the
worst case, even before we know the final layout, and always allocate
enough page directories
On 29/07/2020 15:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-29 15:22:26)
On 29/07/2020 14:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-29 13:40:38)
On 28/07/2020 15:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
On 15/07/2020 12:50, Chris
== Series Details ==
Series: drm/i915/display: Check for an LPSP encoder before dereferencing
URL : https://patchwork.freedesktop.org/series/80036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8814_full -> Patchwork_18267_full
> -Original Message-
> From: Chris Wilson
> Sent: Tuesday, July 28, 2020 9:28 AM
> To: Daniel Vetter ; Dave Airlie
> Cc: intel-gfx ; stable
> ; Gustavo Padovan
> ; Tang, CQ ; dri-
> devel ; Vetter, Daniel
>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
>
Quoting Tvrtko Ursulin (2020-07-29 15:22:26)
>
> On 29/07/2020 14:42, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-07-29 13:40:38)
> >>
> >> On 28/07/2020 15:28, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
>
Quoting Tvrtko Ursulin (2020-07-29 15:22:26)
>
> On 29/07/2020 14:42, Chris Wilson wrote:
> >> parent = NULL;
> >> p = >tree.rb_node;
> >> while (*p) {
> >> parent = *p;
> >>
> >> node = rb_entry(parent, struct active_node, node);
> >>
On 29/07/2020 14:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-29 13:40:38)
On 28/07/2020 15:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
On 15/07/2020 12:50, Chris Wilson wrote:
Rather than require the next timeline after idling to match the MRU
before
Quoting Chris Wilson (2020-07-29 14:42:06)
> Quoting Tvrtko Ursulin (2020-07-29 13:40:38)
> >
> > On 28/07/2020 15:28, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
> > >>
> > >> On 15/07/2020 12:50, Chris Wilson wrote:
> > >>> Rather than require the next timeline after
== Series Details ==
Series: drm/i915/display: Check for an LPSP encoder before dereferencing
URL : https://patchwork.freedesktop.org/series/80036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8814 -> Patchwork_18267
On 7/29/20 2:17 PM, Tvrtko Ursulin wrote:
On 28/07/2020 12:17, Thomas Hellström (Intel) wrote:
On 7/16/20 5:53 PM, Tvrtko Ursulin wrote:
On 15/07/2020 16:43, Maarten Lankhorst wrote:
Op 15-07-2020 om 13:51 schreef Chris Wilson:
Our goal is to pull all memory reservations (next iteration
Quoting Tvrtko Ursulin (2020-07-29 13:40:38)
>
> On 28/07/2020 15:28, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
> >>
> >> On 15/07/2020 12:50, Chris Wilson wrote:
> >>> Rather than require the next timeline after idling to match the MRU
> >>> before idling, reset the
== Series Details ==
Series: drm/i915/display: Check for an LPSP encoder before dereferencing
URL : https://patchwork.freedesktop.org/series/80036/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/display: Check for an LPSP encoder before dereferencing
URL : https://patchwork.freedesktop.org/series/80036/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
775703fc534e drm/i915/display: Check for an LPSP encoder before dereferencing
-:12:
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev5)
URL : https://patchwork.freedesktop.org/series/78012/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8814 -> Patchwork_18266
Avoid a GPF at
<1>[ 20.177320] BUG: kernel NULL pointer dereference, address:
007c
<1>[ 20.177322] #PF: supervisor read access in kernel mode
<1>[ 20.177323] #PF: error_code(0x) - not-present page
<6>[ 20.177324] PGD 0 P4D 0
<4>[ 20.177327] Oops: [#1] PREEMPT SMP
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev5)
URL : https://patchwork.freedesktop.org/series/78012/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
On 28/07/2020 15:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 14:23:22)
On 15/07/2020 12:50, Chris Wilson wrote:
Before we can execute a request, we must wait for all of its vma to be
bound. This is a frequent operation for which we can optimise away a
few atomic operations
On 28/07/2020 15:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
On 15/07/2020 12:50, Chris Wilson wrote:
Rather than require the next timeline after idling to match the MRU
before idling, reset the index on the node and allow it to match the
first request. However,
On Wed, Jul 08, 2020 at 04:17:51PM +0300, Lionel Landwerlin wrote:
> To allow faster engine to engine synchronization, peel the layer of
> dma-fence-chain to expose potential i915 fences so that the
> i915-request code can emit HW semaphore wait/signal operations in the
> ring which is faster than
On Wed, Jul 08, 2020 at 04:17:50PM +0300, Lionel Landwerlin wrote:
> Introduces a new parameters to execbuf so that we can specify syncobj
> handles as well as timeline points.
>
> v2: Reuse i915_user_extension_fn
>
> v3: Check that the chained extension is only present once (Chris)
>
> v4:
Hi Kees,
Not sure you're the right person, but figured I start with you with an
idea I had while looking at this patch. Cut out everything except the
relevant part:
On Wed, Jul 8, 2020 at 3:18 PM Lionel Landwerlin
wrote:
> + /* Check multiplication overflow for access_ok() and
On 28/07/2020 12:17, Thomas Hellström (Intel) wrote:
On 7/16/20 5:53 PM, Tvrtko Ursulin wrote:
On 15/07/2020 16:43, Maarten Lankhorst wrote:
Op 15-07-2020 om 13:51 schreef Chris Wilson:
Our goal is to pull all memory reservations (next iteration
obj->ops->get_pages()) under a ww_mutex, and
== Series Details ==
Series: drm/i915/gt: Fix termination condition for freeing all buffer objects
(rev2)
URL : https://patchwork.freedesktop.org/series/80031/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8813 -> Patchwork_18265
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev6)
URL : https://patchwork.freedesktop.org/series/79855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8810_full -> Patchwork_18261_full
== Series Details ==
Series: drm/i915/gt: Fix termination condition for freeing all buffer objects
(rev2)
URL : https://patchwork.freedesktop.org/series/80031/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915/gt: Fix termination condition for freeing all buffer objects
URL : https://patchwork.freedesktop.org/series/80031/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8813 -> Patchwork_18263
A last minute change, that unfortunately broke CI so badly it declared
SUCCESS, was to refactor the debug free all buffer pool code to reuse
the normal worker, inverted the termination condition so that it instead
of discarding the nodes, they were all declared young enough and
eligible for reuse.
== Series Details ==
Series: drm/i915/gt: Fix termination condition for freeing all buffer objects
URL : https://patchwork.freedesktop.org/series/80031/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v5 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
>
> This series consists
On Fri, Jul 17, 2020 at 03:37:48PM +0200, Hans de Goede wrote:
> Replace the enable, disable and config pwm_ops with an apply op,
> to support the new atomic PWM API.
I didn't notice any visible issue, so
Reviewed-by: Andy Shevchenko
Perhaps you may consider reusing existing _enable() /
A last minute change, that unfortunately broke CI so badly it declared
SUCCESS, was to refactor the debug free all buffer pool code to reuse
the normal worker, inverted the termination condition so that it instead
of discarding the nodes, they were all declared young enough and
eligible for reuse.
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev4)
URL : https://patchwork.freedesktop.org/series/78012/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
On Fri, Jul 17, 2020 at 03:37:47PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this commit
On Fri, Jul 17, 2020 at 03:37:46PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
> controls a
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less
On Fri, Jul 17, 2020 at 03:37:45PM +0200, Hans de Goede wrote:
> The CRC PWM controller has a clock-divider which divides the clock with
> a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
> defines, this range maps to a register value of 0-127.
>
> So after calculating the
On 7/28/20 5:33 PM, Chris Wilson wrote:
Before we peek at the barrier status for an assert, first serialise with
its callbacks so that we see a stable value.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
cHi,
On 7/29/20 10:23 AM, Andy Shevchenko wrote:
On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote:
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
I've applied patches 3 through 12 to the PWM tree. I thought it was a
bit odd that only a handful of these patches
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev6)
URL : https://patchwork.freedesktop.org/series/79855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8810 -> Patchwork_18261
On Mon, Jul 27, 2020 at 09:41:20AM +0200, Thierry Reding wrote:
> On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> I've applied patches 3 through 12 to the PWM tree. I thought it was a
> bit odd that only a handful of these patches had been reviewed and there
> were no Tested-bys,
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
> While looking into adding atomic-pwm support to the pwm-crc driver I
> noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
> there is a clock-divider which divides this with a value between 1-128,
> and there are 256
On Tue, Jul 28, 2020 at 09:55:22PM +0200, Hans de Goede wrote:
> On 7/28/20 8:57 PM, Andy Shevchenko wrote:
> > On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
...
> > Maybe I'm too picky, but I would go even further and split apply to two
> > versions
> >
> > static int
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev6)
URL : https://patchwork.freedesktop.org/series/79855/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
Some very low hanging fruit, but contention on the pool->lock is
noticeable between intel_gt_get_buffer_pool() and pool_retire(), with
the majority of the hold time due to the locked list iteration. If we
make the node itself RCU protected, we can perform the search for an
suitable node just under
On 7/28/20 1:17 PM, Thomas Hellström (Intel) wrote:
On 7/16/20 5:53 PM, Tvrtko Ursulin wrote:
On 15/07/2020 16:43, Maarten Lankhorst wrote:
Op 15-07-2020 om 13:51 schreef Chris Wilson:
Our goal is to pull all memory reservations (next iteration
obj->ops->get_pages()) under a ww_mutex, and
On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
>
> On async flips, there needs to be some clarity/guideline on the behaviour and
> event expectation from the
> driver by user space.
> Here are few assumptions that we have,
> 1. Our understanding is that the user space doesn’t expect the
> -Original Message-
> From: Zanoni, Paulo R
> Sent: Saturday, July 25, 2020 4:56 AM
> To: B S, Karthik ; intel-gfx@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Vetter, Daniel ;
> Kulkarni, Vandita ;
> nicholas.kazlaus...@amd.com; harry.wentl...@amd.com; Shankar, Uma
> ;
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev5)
URL : https://patchwork.freedesktop.org/series/79855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18260_full
== Series Details ==
Series: drm/i915/selftests: Flush the active barriers before asserting
URL : https://patchwork.freedesktop.org/series/79995/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18259_full
Hi,
A CRTC can be associated with one or more Connectors.
Suppose if a CRTC is associated with two connectors in which case, can modeset
on one connector
Fail?
1. How it is handled in i915?
2. Whether modeset on one of the (two) connectors can fail /not as per DRM
documentation?
Kindly
70 matches
Mail list logo
