The following changes since commit b0e898fbaf377c99a36aac6fdeb7250003648ca4:
linux-firmware: Update firmware file for Intel Bluetooth 9462 (2021-11-23
12:31:45 -0500)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_v69.0.3
for you to fetch
On Fri, Jan 14, 2022 at 11:41:31AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> BSPEC: 46123
> Cc: Matt Roper
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
> drivers/gpu/drm/i915/i915_reg.h | 4
> 2 files
== Series Details ==
Series: drm/i915/dg2: add Wa_14015023722
URL : https://patchwork.freedesktop.org/series/98911/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11088 -> Patchwork_22005
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/dg2: add Wa_14015023722
URL : https://patchwork.freedesktop.org/series/98911/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers
URL : https://patchwork.freedesktop.org/series/98910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11088 -> Patchwork_22004
Summary
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers
URL : https://patchwork.freedesktop.org/series/98910/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers
URL : https://patchwork.freedesktop.org/series/98910/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
03db6d6cfb02 drm/i915/wopcm: Handle pre-programmed WOPCM registers
-:14:
From: Clint Taylor
BSPEC: 46123
Cc: Matt Roper
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
Starting from DG2, some of the programming previously done by i915 and
the GuC has been moved to the GSC and the relevant registers are no
longer writable by either CPU or GuC. This is also referred to as GuC
deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer
Hi Matt,
> > The GT has its own properties and in sysfs they should be grouped
> > in the 'gt/' directory.
> >
> > Create a 'gt/' directory in sysfs which will contain gt0...gtN
> > directories related to each tile configured in the GPU. Move the
> > power management files inside those
From: John Harrison
Various tests want to configure engine properties such as pre-emption
timeout and heartbeat interval. Some don't bother to restore the
original values again afterwards. So, add a helper to make it easier
to do this.
v2: Fix for platforms with no pre-emption capability.
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
v2: Use _device_coherent instead of _wc for
From: John Harrison
As opposed to only on the non-target engines. This means that there is
some other workload present for the scheduler to switch between and so
detet the hang immediately.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10 ++
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b ("tests/i915/gem_exec_fence: Convert to intel_ctx_t (v2)")
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/gem_exec_fence.c | 2 +-
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by:
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
v2: Don't restore too
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
Reviewed-by:
From: John Harrison
Added descriptions of the various sub-tests and the test as a whole.
v2: Added missing linefeed (spotted by Petri)
Signed-off-by: John Harrison
Reviewed-by: Petri Latvala
---
tests/i915/i915_hangman.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
From: John Harrison
Some of the IGT framework relies on receving a uevent when a hang
occurs. So add a test that this actually works.
While testing this, noticed that hangs could sometimes be missed
because the uevent was (presumably) still in flight by the time the
handler was de-registered.
From: John Harrison
Fix a bunch of issues with i915_hangman and gem_exec_capture with the
ultimate aim of making them pass on GuC enabled platforms.
v2: Fixes to the store code. Add engine properties management.
v3: Fix for platforms without pre-emption.
v4: Simplify anti-ban code, support
From: John Harrison
The above function was checking for valid rings via the old interface.
The new scheme is to check for engines on contexts as there are now
more engines than could be supported.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
lib/igt_gt.c | 6
Hi Matt,
[...]
> > -int intel_uncore_setup_mmio(struct intel_uncore *uncore)
> > +int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t
> > phys_addr)
> > {
> > struct drm_i915_private *i915 = uncore->i915;
> > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > -
On Thu, Jan 13, 2022 at 12:20:31AM +0200, Andi Shyti wrote:
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create a 'gt/' directory in sysfs which will contain gt0...gtN
> directories related to each tile configured in the GPU. Move the
> power
On Thu, Jan 13, 2022 at 12:20:30AM +0200, Andi Shyti wrote:
> From: Tvrtko Ursulin
>
> On a multi-tile platform, each tile has its own registers + GGTT
> space, and BAR 0 is extended to cover all of them.
>
> Up to four gts are supported in i915->gt[], with slot zero
> shadowing the existing
On Thu, Jan 13, 2022 at 03:51:07PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Although the hangman test was ensuring that *some* reset functionality
> was enabled, it did not differentiate what kind. The infrastructure
> required to choose between per engine reset or full
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. to polish the cursor plane registers.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 25 ---
>
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. to polish the g4x+ sprite plane registers.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++--
>
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. to polish the vlv/chv sprite plane registers.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 9 +-
> drivers/gpu/drm/i915/i915_reg.h |
On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_BIT() & co. to polish the ivb+ sprite plane registers.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 20 +++--
>
On Thu, Jan 13, 2022 at 03:51:05PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The above function was checking for valid rings via the old interface.
> The new scheme is to check for engines on contexts as there are now
> more engines than could be supported.
>
>
On Thu, Jan 13, 2022 at 03:51:08PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some of the IGT framework relies on receving a uevent when a hang
> occurs. So add a test that this actually works.
>
> While testing this, noticed that hangs could sometimes be missed
> because
On 13/01/2022 09:21, Jani Nikula wrote:
On Wed, 12 Jan 2022, Colin Ian King wrote:
Don't populate the read-only array flex_regs on the stack but
instead it static const. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King
---
RESEND: Use correct e-mail address for
On Fri, Jan 14, 2022 at 03:24:59PM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> here are two more fixes for this week. I cherry-picked both from
> drm-misc-next.
>
> Best regards
> Thomas
>
> drm-misc-next-fixes-2022-01-14:
> * atomic helpers: Fix error messages
> * mipi-dbi:
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98895/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11086 -> Patchwork_22003
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98895/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_gem_evict.c:144: warning:
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98895/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98895/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
db8c9a3db0b3 drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent
Hi Dave and Daniel,
here are two more fixes for this week. I cherry-picked both from
drm-misc-next.
Best regards
Thomas
drm-misc-next-fixes-2022-01-14:
* atomic helpers: Fix error messages
* mipi-dbi: Fix buffer mapping
The following changes since commit
On 1/14/22 14:23, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some
On Thu, Jan 13, 2022 at 09:29:51AM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> here's this week's PR for drm-misc-next-fixes.
>
> Best regards
> Thomas
>
> drm-misc-next-fixes-2022-01-13:
> * Fix use of CRTC state's active vs enable in atomic helper
> The following changes since
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
Reviewed-by: Thomas Hellström
---
Because we will start to require the obj->resv lock for unbinding,
ensure these vma eviction utility functions also take the lock.
This requires some function signature changes, to ensure that the
ww context is passed around, but is mostly straightforward.
Previously this was split up into
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still happen with concurrent mmaps
where we can't
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will
We want to remove more members of i915_vma, which requires the locking to
be held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to
the object may be held by
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over
On Thu, Jan 13, 2022 at 09:33:03AM +, Tvrtko Ursulin wrote:
>
> Hi Dave and Daniel,
>
> A few fixes for the merge window.
>
> One dealing with runtime PM handling on the PXP unbind path and a few
> regarding the newly added TTM backend support.
>
> Regards,
>
> Tvrtko
>
> ---
>
>
Hi Dave, Daniel,
Here's a few patches stuck in drm-misc-fixes for some time.
Maxime
drm-misc-fixes-2022-01-14:
Two DT bindings fixes for meson, a device refcounting fix for sun4i, a
probe fix for vga16fb, a locking fix for the CMA dma-buf heap and a
compilation fix for ttm.
The following
On Fri, Jan 07, 2022 at 06:29:26AM +0100, Jim Cromie wrote:
> adds: dynamic_trace()
> uses trace_console() temporarily to issue printk:console event
> uses internal-ish __ftrace_trace_stack code:
> 4-context buffer stack, barriers per Steve
>
> call it from new funcs:
> dynamic_printk()
On Fri, Jan 07, 2022 at 06:29:24AM +0100, Jim Cromie wrote:
> #ifdef CONFIG_JUMP_LABEL
> - if (dp->flags & _DPRINTK_FLAGS_PRINT) {
> - if (!(modifiers->flags & _DPRINTK_FLAGS_PRINT))
> + if (dp->flags & _DPRINTK_FLAGS_ENABLED) {
On Wed, 12 Jan 2022, Manasi Navare wrote:
> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> settings.
> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> MSA bit
> in the DPCD. Currently the driver parses that onevery HPD but fails to reset
Hi Eric,
Hope you are back from new year holiday.:-) Have you got chane to consider
this patch?
Regards,
Yi Liu
On 2021/11/30 19:32, Liu, Yi L wrote:
From: Eric Farman
Sent: Tuesday, November 30, 2021 1:18 AM
On Wed, 2021-11-24 at 12:25 +, Liu, Yi L wrote:
From: Jason Gunthorpe
Sent:
== Series Details ==
Series: drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem
allocation
URL : https://patchwork.freedesktop.org/series/98878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11081_full -> Patchwork_22002_full
== Series Details ==
Series: drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem
allocation
URL : https://patchwork.freedesktop.org/series/98878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11081 -> Patchwork_22002
== Series Details ==
Series: drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem
allocation
URL : https://patchwork.freedesktop.org/series/98878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
578053b3b809 drm/i915: Use i915_gem_object_pin_map_unlocked function
Using i915_gem_object_pin_map_unlocked instead of
i915_gem_object_lmem_io_map, would eliminate the need
of using I915_BO_ALLOC_CONTIGUOUS, when calling
i915_vma_pin_iomap, because it supports non-contiguous
allocation as well.
Signed-off-by: Stanislav Lisovskiy
---
61 matches
Mail list logo
