== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/79534/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8752_full -> Patchwork_18184_full
On Wed, Jul 15, 2020 at 09:27:42PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
> 'ret' is uninitialized when used here [-Wuninitialized]
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
>
== Series Details ==
Series: drm/i915/display: Ensure that ret is always initialized in
icl_combo_phy_verify_state
URL : https://patchwork.freedesktop.org/series/79536/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8753 -> Patchwork_18185
== Series Details ==
Series: drm/i915/display: Ensure that ret is always initialized in
icl_combo_phy_verify_state
URL : https://patchwork.freedesktop.org/series/79536/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b0efac00fd8c drm/i915/display: Ensure that ret is always
Clang warns:
drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
'ret' is uninitialized when used here [-Wuninitialized]
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
^~~
drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10:
On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote:
>
> On 13/07/2020 06:09, Dave Airlie wrote:
> > On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
> >>
> >> We need to add support for pwrite'ing an LMEM object.
> >
> > why? DG1 is a discrete GPU, these interfaces we already gross and
> > overly
== Series Details ==
Series: drm/i915/display: Implement HOBL
URL : https://patchwork.freedesktop.org/series/79525/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18183_full
Summary
---
On Wed, Jul 15, 2020 at 04:16:09PM -0700, Matt Atwood wrote:
> On Wed, Jul 15, 2020 at 11:27:15PM +0300, Imre Deak wrote:
> > On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> > > On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > > > The problem the reverted patch
== Series Details ==
Series: drm/i915/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18182_full
On Wed, Jul 15, 2020 at 11:27:15PM +0300, Imre Deak wrote:
> On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> > On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > > The problem the reverted patch revealed could've been fixed by commit
> > > 619ad4874585 ("drm/i915/ddi:
On Tue, Jul 07, 2020 at 05:39:14PM -0700, Souza, Jose wrote:
> On Tue, 2020-06-16 at 20:30 -0700, Matt Roper wrote:
> > If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> > using some of the PHYs and DPLLs making them unavailable for general
> > usage. Let's read out the
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/79534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8752 -> Patchwork_18184
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97213337456c HAX to make DSC work on the icelake test system
From: Maarten Lankhorst
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 61 ---
From: Maarten Lankhorst
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
From: Maarten Lankhorst
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used,
so use the vblank evasion to cover both pipes.
This way ideally everything will be tear free, and updates are
really atomic as userspace
From: Maarten Lankhorst
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied
From: Maarten Lankhorst
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough
From: Maarten Lankhorst
The members in hw.mode can be used from adjusted_mode as well,
use that when available.
Some places that use hw.mode can be converted to use adjusted_mode
as well.
v2:
* Manual rebase (Manasi)
* remove the use of pipe_mode defined in patch 3 (Manasi)
v3:
* Rebase on
From: Maarten Lankhorst
Unfortunately I have no way to test this, but it should be correct
if the bios sets up bigjoiner in a sane way.
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the
From: Maarten Lankhorst
Dump debugfs and planar links as well, this will make it easier to debug
when things go wrong.
v4:
* Rebase
Changes since v1:
- Report planar slaves as such, now that we have the plane_state switch.
Changes since v2:
- Rebase on top of the new plane format dumping
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
eDP does not support bigjoiner, so do not expose bigjoiner only
modes on the eDP port.
v5:
* Increase max plane width to
From: Maarten Lankhorst
Make sure that when a plane is set in a bigjoiner mode, we will add
their counterpart to the atomic state as well. This will allow us to
make sure all state is available when planes are checked.
Because of the funny interactions with bigjoiner and planar YUV
formats,
From: Maarten Lankhorst
DSC is available on the display emulator, but not set in DPCD.
Override the entries to allow bigjoiner testing.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
include/drm/drm_dp_helper.h | 1 +
2 files changed, 3 insertions(+), 2
== Series Details ==
Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
URL : https://patchwork.freedesktop.org/series/79522/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751_full -> Patchwork_18181_full
On Wed, Jul 15, 2020 at 12:15:35PM -0700, Manasi Navare wrote:
> On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> > The problem the reverted patch revealed could've been fixed by commit
> > 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling
> > flag")
> > in
== Series Details ==
Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context
URL : https://patchwork.freedesktop.org/series/79521/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18180_full
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait (rev2)
URL : https://patchwork.freedesktop.org/series/79517/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18179_full
Quoting Chris Wilson (2020-07-10 18:10:01)
> [ 1413.563200] BUG: KCSAN: data-race in __await_execution+0x217/0x370 [i915]
> [ 1413.563221]
> [ 1413.563236] race at unknown origin, with read to 0x5bb6c478 of 8
> bytes by task 9654 on cpu 1:
> [ 1413.563548] __await_execution+0x217/0x370
On Wed, Jul 15, 2020 at 07:29:31PM +0300, Imre Deak wrote:
> The problem the reverted patch revealed could've been fixed by commit
> 619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling flag")
> in particular because the revealed problem (at least in one case) happened
> when
== Series Details ==
Series: series starting with [v2] drm/i915: Remove i915_request.lock
requirement for execution callbacks (rev2)
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750_full -> Patchwork_18178_full
Hi Sam and Daniel,
Thank you very much for reviewing the code. I will squish all the commits and
send version 3, so it will be easier for you to review.
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 15, 2020 10:07 AM
> To: Daniel Vetter
> Cc: Chrisanthus,
== Series Details ==
Series: drm/i915/display: Implement HOBL
URL : https://patchwork.freedesktop.org/series/79525/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18183
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/display: Implement HOBL
URL : https://patchwork.freedesktop.org/series/79525/
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/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18182
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails
== Series Details ==
Series: drm/i915/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f736e550c1ab drm/i915/gt: Only transfer the virtual context to the new
== Series Details ==
Series: drm/i915/gt: Only transfer the virtual context to the new engine if
active
URL : https://patchwork.freedesktop.org/series/79524/
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: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
URL : https://patchwork.freedesktop.org/series/79522/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8751 -> Patchwork_18181
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the
== Series Details ==
Series: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
URL : https://patchwork.freedesktop.org/series/79522/
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: Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
URL : https://patchwork.freedesktop.org/series/79522/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
16afab03b437 Revert "Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+""
Hi Dave and Daniel,
here is the PR for the current drm-misc-fixes. The aspeed fix is only
about dmesg noise. The dmabuf locking appears to be a real bug.
Best regards
Thomas
drm-misc-fixes-2020-07-15:
* aspeed: setup fbdev console after registering device; avoids warning
and stacktrace in
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver
Hi Anitha.
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay
The problem the reverted patch revealed could've been fixed by commit
619ad4874585 ("drm/i915/ddi: Don't frob the DP link scramble disabling flag")
in particular because the revealed problem (at least in one case) happened
when switching to the TPS4 training pattern, which needs scrambling.
Let's
== Series Details ==
Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context
URL : https://patchwork.freedesktop.org/series/79521/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18180
On 07/15, Arkadiusz Hiler wrote:
> On Mon, Jun 22, 2020 at 01:38:26PM -0300, Melissa Wen wrote:
> > When running subtests in sequence using vkms, the beginning of CRC capture
> > process does not match the simulated vblank timing. This mismatch leads to
> > an endless busy wait and, consequently,
== Series Details ==
Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79514/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8749_full -> Patchwork_18176_full
== Series Details ==
Series: drm/i915/selftests: Mock the status_page.vma for the kernel_context
URL : https://patchwork.freedesktop.org/series/79521/
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: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait (rev2)
URL : https://patchwork.freedesktop.org/series/79517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18179
Since we assert that the kernel_context is using the perma-pinned HWSP,
make it so.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
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 to align those reservations
> with other drivers, i.e. control all such allocations with the
> reservation_ww_class. Currently, this is under
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait (rev2)
URL : https://patchwork.freedesktop.org/series/79517/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
130497fc98af drm/i915: Reduce
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait (rev2)
URL : https://patchwork.freedesktop.org/series/79517/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used,
The first "scheduler" was a topographical sorting of requests into
priority order. The execution order was deterministic, the earliest
submitted, highest priority request would be executed first. Priority
inherited ensured that inversions were kept at bay, and allowed us to
dynamically boost
Quoting Ville Syrjälä (2020-07-15 15:22:24)
> On Tue, Jul 14, 2020 at 09:32:54PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-07-14 21:19:45)
> > > From: Ville Syrjälä
> > >
> > > Since g4x the CFB base only takes a 28bit offset into stolen.
> > > Not sure if the CFB is allowed to
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver
Hi Anitha
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC.
Quoting Chris Wilson (2020-07-15 15:47:15)
> Quoting Tvrtko Ursulin (2020-07-15 13:26:23)
> >
> > On 15/07/2020 13:06, Tvrtko Ursulin wrote:
> > >
> > > On 15/07/2020 11:50, Chris Wilson wrote:
> > >> Currently, we use i915_request_completed() directly in
> > >> i915_request_wait() and follow up
Quoting Tvrtko Ursulin (2020-07-15 13:26:23)
>
> On 15/07/2020 13:06, Tvrtko Ursulin wrote:
> >
> > On 15/07/2020 11:50, Chris Wilson wrote:
> >> Currently, we use i915_request_completed() directly in
> >> i915_request_wait() and follow up with a manual invocation of
> >> dma_fence_signal().
On Wed, Jul 15, 2020 at 4:37 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-07-15 15:03:34)
> > On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson
> > wrote:
> > > There's a further problem in that we call INIT_LIST_HEAD on the
> > > dma_fence_cb before the signal callback. So even if
Quoting Daniel Vetter (2020-07-15 15:03:34)
> On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> > There's a further problem in that we call INIT_LIST_HEAD on the
> > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > confirms the dma_fence_cb to be completely
== Series Details ==
Series: series starting with [v2] drm/i915: Remove i915_request.lock
requirement for execution callbacks (rev2)
URL : https://patchwork.freedesktop.org/series/79467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18178
On Tue, Jul 14, 2020 at 09:32:54PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-07-14 21:19:45)
> > From: Ville Syrjälä
> >
> > Since g4x the CFB base only takes a 28bit offset into stolen.
> > Not sure if the CFB is allowed to start below that limit but
> > then extend beyond it.
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79517/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8750 -> Patchwork_18177
== Series Details ==
Series: series starting with [v2] drm/i915: Remove i915_request.lock
requirement for execution callbacks (rev2)
URL : https://patchwork.freedesktop.org/series/79467/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used,
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Async GPU
relocations only" (rev3)
URL : https://patchwork.freedesktop.org/series/79470/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18175_full
On Wed, Jul 15, 2020 at 3:34 PM Jani Nikula wrote:
>
>
> Argh, failed to mention:
>
> On Wed, 15 Jul 2020, Jani Nikula wrote:
> > Lee Shawn C (1):
> > drm/i915/mst: filter out the display mode exceed sink's capability
>
> The above depends on:
>
> > Lyude Paul (1):
> >
On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> Quoting Chris Wilson (2020-07-15 13:21:43)
> > Quoting Daniel Vetter (2020-07-15 13:10:22)
> > > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > > When waiting with a callback on the stack, we must remove the callback
> > >
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the irq-spinlock.
v2: Avoid using the irq_work
On Wed, Jul 15, 2020 at 2:53 PM Liviu Dudau wrote:
>
> On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> > Again needs to be put right after the call to
> > drm_atomic_helper_commit_hw_done(), since that's the last thing which
> > can hold up a subsequent atomic commit.
> >
> > No
== Series Details ==
Series: series starting with [1/2] dma-buf/dma-fence: Trim
dma_fence_add_callback()
URL : https://patchwork.freedesktop.org/series/79513/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18174_full
On Mon, Jul 13, 2020 at 04:53:33PM -0700, José Roberto de Souza wrote:
> Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> supported motherboards to use a special voltage swing table for eDP
> panels that uses less power.
>
> So here if supported by HW, OEM will set it in
On 15/07/2020 13:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-15 13:39:56)
On 14/07/2020 10:47, Chris Wilson wrote:
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise
Argh, failed to mention:
On Wed, 15 Jul 2020, Jani Nikula wrote:
> Lee Shawn C (1):
> drm/i915/mst: filter out the display mode exceed sink's capability
The above depends on:
> Lyude Paul (1):
> drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx
Which has changes
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79517/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each
== Series Details ==
Series: series starting with [01/66] drm/i915: Reduce i915_request.lock
contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79517/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
91bde1c5e935 drm/i915: Reduce i915_request.lock
etch changes up to e57bd05ec0d2d82d63725dedf9f5a063f879de25:
drm/i915: Update DRIVER_DATE to 20200715 (2020-07-15 14:18:02 +0300)
drm/i915 features for v5.9, batch #2
Highlights:
- Very early DG1 enabling (Abdiel, Lucas, Anusha)
Hi all -
The following commits have been marked as Cc: stable or fixing something
in v5.8-rc5 or earlier, but failed to cherry-pick to
drm-intel-fixes. Please see if they are worth backporting, and please do
so if they are.
Failed to cherry-pick:
e5ec1f954869 ("drm/i915/fbc: Use the correct
On Wed, Jun 24, 2020 at 06:54:00AM -0300, Melissa Wen wrote:
> Hi,
>
> I was studying the code of kms_cursor_crc test, and I just adjusted some
> comments
> and added descriptions for subtests.
>
> Melissa Wen (2):
> lib/igt_fb: change comments with fd description
> test/kms_cursor_crc:
Hi Dave & Daniel -
drm-intel-fixes-2020-07-15:
drm/i915 fixes for v5.8-rc6:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
BR,
Jani.
The
On Mon, Jun 22, 2020 at 01:38:26PM -0300, Melissa Wen wrote:
> When running subtests in sequence using vkms, the beginning of CRC capture
> process does not match the simulated vblank timing. This mismatch leads to
> an endless busy wait and, consequently, timeout failures for the remaining
>
On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> Again needs to be put right after the call to
> drm_atomic_helper_commit_hw_done(), since that's the last thing which
> can hold up a subsequent atomic commit.
>
> No surprises here.
I was (still am) hoping to do a testing for this
Quoting Tvrtko Ursulin (2020-07-15 13:39:56)
>
> On 14/07/2020 10:47, Chris Wilson wrote:
> > We are using the i915_request.lock to serialise adding an execution
> > callback with __i915_request_submit. However, if we use an atomic
> > llist_add to serialise multiple waiters and then check to see
On Mon, Jun 22, 2020 at 01:37:55PM -0300, Melissa Wen wrote:
> When a subtest fails, it skips the cleanup, and its pipe_crc remains
> allocated.
> As a consequence, the following subtest also fails (timeout) when trying to
> create a new one. This patch releases any remaining pipe_crc to enable
Quoting Chris Wilson (2020-07-15 13:21:43)
> Quoting Daniel Vetter (2020-07-15 13:10:22)
> > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > When waiting with a callback on the stack, we must remove the callback
> > > upon wait completion. Since this will be notified by the
On 14/07/2020 10:47, Chris Wilson wrote:
We are using the i915_request.lock to serialise adding an execution
callback with __i915_request_submit. However, if we use an atomic
llist_add to serialise multiple waiters and then check to see if the
request is already executing, we can remove the
== Series Details ==
Series: series starting with [1/2] dma-buf/sw_sync: Avoid recursive lock during
fence signal
URL : https://patchwork.freedesktop.org/series/79510/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8748_full -> Patchwork_18173_full
== Series Details ==
Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79514/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8749 -> Patchwork_18176
On 15/07/2020 13:06, Tvrtko Ursulin wrote:
On 15/07/2020 11:50, Chris Wilson wrote:
Currently, we use i915_request_completed() directly in
i915_request_wait() and follow up with a manual invocation of
dma_fence_signal(). This appears to cause a large number of contentions
on i915_request.lock
Quoting Daniel Vetter (2020-07-15 13:10:22)
> On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > When waiting with a callback on the stack, we must remove the callback
> > upon wait completion. Since this will be notified by the fence signal
> > callback, the removal often contends
== Series Details ==
Series: drm/i915: Reduce i915_request.lock contention for i915_request_wait
URL : https://patchwork.freedesktop.org/series/79514/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> When waiting with a callback on the stack, we must remove the callback
> upon wait completion. Since this will be notified by the fence signal
> callback, the removal often contends with the fence->lock being held by
> the signaler.
On 15/07/2020 11:50, Chris Wilson wrote:
Currently, we use i915_request_completed() directly in
i915_request_wait() and follow up with a manual invocation of
dma_fence_signal(). This appears to cause a large number of contentions
on i915_request.lock as when the process is woken up after the
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
>
> Hi,
>
> On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> wrote:
> > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> > wrote:
> > > Maybe now is the time to ask: are you using sw_sync outside of
> > > validation?
> >
> > Yes, this is
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 25
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 (notably a cmpxchg) in lieu of the RCU protection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.h | 15
Currently, we construct and teardown the i915_dependency chains using a
global spinlock. As the lists are entirely local, it should be possible
to use an double-lock with an explicit nesting [signaler -> waiter,
always] and so avoid the costly convenience of a global spinlock.
Signed-off-by:
1 - 100 of 190 matches
Mail list logo
