Hi Dave, Daniel,
Here's this week drm-misc-fixes PR.
Note that dim pull-request was stalling when generating the email, so I
had to send this with git request-pull, hence the odd tag name and the
format slightly different.
Maxime
The following changes since commit b19926d4f3a660a8b76e5d989ffd11
On 15/12/2021 22:45, john.c.harri...@intel.com wrote:
From: John Harrison
A fault injection probe test hit a BUG_ON in a GuC error path. It
showed that the GuC code could potentially attempt to do many things
when the device is actually wedged. So, add a check in to prevent that.
Signed-off
== Series Details ==
Series: drm/i915/dg1: Read OPROM via SPI controller (rev3)
URL : https://patchwork.freedesktop.org/series/94826/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11006_full -> Patchwork_21857_full
Summary
On 09/12/2021 12:01, Tejas Upadhyay wrote:
Most code paths does full reset with preparing all
engines for reset except below two :
1. Single engine reset needs to prepare engines for
reset based on its reset domain. In __intel_engine
_reset_bh is a place needs loop over to do engine
prepare f
On 15/12/2021 20:46, Arunpravin wrote:
On 14/12/21 12:29 am, Matthew Auld wrote:
On 09/12/2021 15:47, Paneer Selvam, Arunpravin wrote:
[AMD Official Use Only]
Hi Matthew,
Ping on this?
No new comments from me :) I guess just a question of what we should do
with the selftests, and then ofc
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:634:5: warning: symbol 'prev_deps'
was not declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
i915_gem_ttm_move.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
From: Ville Syrjälä
We mustn't forget to update our FBC state even if we don't have
to reallocate the CFB. Otherwise we won't refresh our notion
of what eg. the new fence or the new override CFB stride
should be. Using the wrong CFB stride in particular can cause
underruns and could even corrupt
inding/20211215-183859
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-rhel-8.3-kselftests
(https://download.01.org/0day-ci/archive/20211216/202112161943.cppzejzk-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
> -Original Message-
> From: Jani Nikula
> Sent: Friday, December 10, 2021 4:17 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC] drm/i915/display: Move cdclk checks to atomic
> check
>
> On Thu, 09 Dec 2021, Anusha Srivatsa wrote:
> > i9
Hi
Am 01.12.21 um 17:39 schrieb Arunpravin:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computa
> -Original Message-
> From: Surendrakumar Upadhyay, TejaskumarX
> Sent: 10 December 2021 16:21
> To: Jani Nikula ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH V3] drm/i915/adl-n: Enable ADL-N platform
>
>
>
> > -Original Message-
> > From: Jani Nikula
>
On Fri, 10 Dec 2021, Tejas Upadhyay
wrote:
> Adding PCI device ids and enabling ADL-N platform.
> ADL-N from i915 point of view is subplatform of ADL-P.
>
> BSpec: 68397
>
> Changes since V2:
> - Added version log history
> Changes since V1:
> - replace IS_ALDERLAKE_N with IS_ADLP_N -
On Wed, 15 Dec 2021, Lucas De Marchi wrote:
> From: Clint Taylor
>
> Read OPROM SPI through MMIO and find VBT entry since we can't use
> OpRegion and PCI mapping may not work on some systems due to most BIOSes
> not leaving the Option ROM mapped.
>
> v2: Remove message with allocation failure
>
>
The last user of macros from that include was removed in 2018 by the
commit below.
Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc
interface")
Signed-off-by: Jiri Slaby
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel
On Thu, 16 Dec 2021, Jiri Slaby wrote:
> The last user of macros from that include was removed in 2018 by the
> commit below.
>
> Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc
> interface")
> Signed-off-by: Jiri Slaby
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrig
Hi, Rafael,
On 11/4/21 18:26, Rafael J. Wysocki wrote:
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.
Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.
Call drop_pages with the gem object lock held, instead of the other
way around. This will allow us to drop the vma bindings with the
gem object lock held.
We plan to require the object lock for unpinning in the future,
and this is an easy target.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Nir
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 al
We will need the lock to unbind the vma, and wait for bind to complete.
Remove the special casing for the !ww path, and force ww locking for all.
Changes since v1:
- Pass err to for_i915_gem_ww handling for -EDEADLK handling.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
[mlankhorst: Remove ne
Big delta, but boils down to moving set_pages to i915_vma.c, and removing
the special handling, all callers use the defaults anyway. We only remap
in ggtt, so default case will fall through.
Because we still don't require locking in i915_vma_unpin(), handle this by
using xchg in get_pages(), as it
i915_vma_wait_for_bind needs the vma lock held, fix the caller.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 40 +++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915
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 sev
This is required for i915_gem_evict_vm, to be able to evict the entire VM,
including objects that are already locked to the current ww ctx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 ++--
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 4 ++--
drive
This duck tape workaround is no longer required, unbind and destroy are
fixed to take the obj->resv mutex before destroying and obj->mm.lock has
been removed, always requiring obj->resv as well.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_obj
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
---
drivers/gpu/drm/i915/i915_vma.c | 55 +--
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker 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 several patches, b
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
In the next commits, we may not evict when refcount = 0.
igt_vm_isolation() continuously tries to pin/unpin at same address,
but also calls put() on the object, which means the object may not
be unpinned in time.
Instead of this, re-use the same object over and over, so they can
be unbound as req
We're working on requiring the obj->resv lock during unbind, fix
the shrinker to take the objectl ock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drive
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 th
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.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18
Now that we require locking to evict, multiple vmas from the same object
might not be evicted. This is expected and required, because execbuf will
move to short-term pinning by using the lock only. This will cause these
tests to fail, because they create a ton of vma's for the same object.
Unbind
Hi Dave and Daniel,
here's this week's PR for drm-misc-next for what will become Linux
5.17.
Every single patchset in this PR is awesome: vmwgfx now supports
GL 4.3 userspace and GEM (yeah!), simpledrm added support for Apple M1
firmware framebuffers, the SPRD drivers finally got merged, vc4 adde
Sincere apologies for the delay. Pulled and pushed out.
josh
On Wed, Dec 15, 2021 at 6:41 PM Tolakanahalli Pradeep, Madhumitha
wrote:
>
> Bump! :)
>
> Thanks,
> - Madhumitha
>
> On Wed, 2021-12-08 at 18:11 +, Srivatsa, Anusha wrote:
> > Ping :)
> > Can these updates be merged to linux-firmw
On 2021-12-14 at 12:32:57 +, Matthew Auld wrote:
> On 14/12/2021 10:56, Ramalingam C wrote:
> > On 2021-12-06 at 13:31:39 +, Matthew Auld wrote:
> > > This is all kinds of awkward since we now have to contend with using 64K
> > > GTT pages when mapping anything in LMEM(including the page-ta
Hi,
On 11/21/21 12:00, Hans de Goede wrote:
> After the recent refactoring of the backlight code the contents of
> intel_panel_actually_set_backlight() is exactly the same (minus a
> small wording difference in the drm_dbg_kms() as the contents if the
> more widely used intel_backlight_set_pwm_lev
Enable accelerated moves and clearing on DG2. On such HW we have minimum page
size restrictions when accessing LMEM from the GTT, where we now have to use 64K
GTT pages or larger. With the ppGTT the page-table also has a slightly different
layout from past generations when using the 64K GTT mode(wh
On some platforms we have alignment restrictions when accessing LMEM
from the GTT. In the next few patches we need to be able to modify the
page-tables directly via the GTT itself.
Suggested-by: Ramalingam C
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalin
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
--
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
v2(Ram)
- Document the ppGTT layout and add a better description for the
different windows.
Signed-off-by: Matthew Auld
Cc: Thomas Hellstr
== Series Details ==
Series: drm/i915/fbc: Remember to update FBC state even when not reallocating
CFB
URL : https://patchwork.freedesktop.org/series/98126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11006 -> Patchwork_21858
On 12/16/2021 2:27 PM, Thomas Hellström wrote:
Hi, Rafael,
On 11/4/21 18:26, Rafael J. Wysocki wrote:
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify
== Series Details ==
Series: drm/i915: remove circ_buf.h includes
URL : https://patchwork.freedesktop.org/series/98130/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
24a5cb6b532c drm/i915: remove circ_buf.h includes
-:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: ema
== Series Details ==
Series: drm/i915/fbc: Remember to update FBC state even when not reallocating
CFB
URL : https://patchwork.freedesktop.org/series/98126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11006_full -> Patchwork_21858_full
==
== Series Details ==
Series: drm/i915: remove circ_buf.h includes
URL : https://patchwork.freedesktop.org/series/98130/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11008 -> Patchwork_21859
Summary
---
**SUCCESS**
On 12/12/2021 3:25 PM, Rikard Falkeborn worte:
> On Fri, Dec 10, 2021 at 09:00:56AM +, Wang, Zhi A wrote:
>> On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
>>> Constify a number of static structs that are never modified to allow the
>>> compiler to put them in read-only memory. In order to do t
== Series Details ==
Series: drm/i915/mst: update slot information for 128b/132b
URL : https://patchwork.freedesktop.org/series/98134/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11008 -> Patchwork_21860
Summary
---
On 12/16/2021 00:47, Tvrtko Ursulin wrote:
On 15/12/2021 22:45, john.c.harri...@intel.com wrote:
From: John Harrison
A fault injection probe test hit a BUG_ON in a GuC error path. It
showed that the GuC code could potentially attempt to do many things
when the device is actually wedged. So, ad
== Series Details ==
Series: drm/i915: remove circ_buf.h includes
URL : https://patchwork.freedesktop.org/series/98130/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11008_full -> Patchwork_21859_full
Summary
---
**F
On 12/15/2021 23:23, Zbigniew Kempczyński wrote:
On Mon, Dec 13, 2021 at 03:29:10PM -0800, john.c.harri...@intel.com wrote:
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 ea
On 12/14/2021 11:33 AM, Andi Shyti wrote:
The reference to the GGTT from the private date is not used
anymore. Remove it.
-Quick spellcheck for "data".
Suggested-by: Matt Roper
Signed-off-by: Andi Shyti
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/gt/intel_gt.c| 7 +--
== Series Details ==
Series: drm/i915/mst: update slot information for 128b/132b
URL : https://patchwork.freedesktop.org/series/98134/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11008_full -> Patchwork_21860_full
Summary
On Thu, 2021-12-16 at 09:39 -0500, Josh Boyer wrote:
> Sincere apologies for the delay. Pulled and pushed out.
>
> josh
Thank you, Josh!
>
> On Wed, Dec 15, 2021 at 6:41 PM Tolakanahalli Pradeep, Madhumitha
> wrote:
> >
> > Bump! :)
> >
> > Thanks,
> > - Madhumitha
> >
> > On Wed, 2021-12-
On 12/15/2021 23:46, Zbigniew Kempczyński wrote:
On Mon, Dec 13, 2021 at 03:29:11PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory. This patch collects two such
instances into
On 12/14/2021 11:33 AM, Andi Shyti wrote:
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winia
On 12/14/2021 11:33 AM, Andi Shyti wrote:
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winia
On 12/14/2021 11:33 AM, Andi Shyti wrote:
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
Signed-off-by: Michał Winia
Check return pointer from intel_crtc_for_plane() before dereferencing
it, as it can be NULL.
Cc: Jani Nikula
Cc: Caz Yokoyama
Cc: Radhakrishna Sripada
Signed-off-by: Harish Chegondi
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
SLPC will restore the frequency back to RPn after initialization,
-Original Message-
From: dri-devel On Behalf Of Andi
Shyti
Sent: Tuesday, December 14, 2021 11:34 AM
To: Intel GFX ; DRI Devel
Cc: Winiarski, Michal ; Andi Shyti
; De Marchi, Lucas ; Chris Wilson
; Andi Shyti
Subject: [PATCH v8 11/16] drm/i915/gem: Use to_gt() helper for GGTT acces
Replace GEN with DISPLAY_VER, in line with the naming convention
followed in the i915 driver code.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
---
drivers/gpu/drm/i915/display/intel_dmc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915
The following series of patches add writeback support for i915. This has been
validated on TGL using IGT.
Note:Only a single instance of WD transcoder is being considered for now, using
multiple WD transcoder may not work. The support for the same will be added in
next
set of patches.
suraj kan
From: suraj kandpal
Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector
Adding drm_connector and drm_encoder pointers in drm_writeback_connector
Signed-off-by: suraj kandpal
---
drivers/gpu/drm/drm_writeback.c | 19 ++-
From: suraj kandpal
Changing driver to use drm_writeback_connector.base pointer
Signed-off-by: suraj kandpal
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 3 ++-
drivers/gpu/drm/arm/display/komeda/komeda_wb_conne
From: suraj kandpal
Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
Signed-off-by: suraj kandpal
---
drivers/gpu/drm/i915/display/intel_display.h | 6 ++
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/i915_reg.h
From: suraj kandpal
Adding support for writeback transcoder to start capturing frames using
interrupt mechanism
Signed-off-by: suraj kandpal
---
drivers/gpu/drm/i915/Makefile |2 +
drivers/gpu/drm/i915/display/intel_acpi.c |1 +
drivers/gpu/drm/i915/display/intel_di
69 matches
Mail list logo
