== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98137/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc08f58eeb3f drm/i915: Remove unused bits of i915_vma/active api
91bcecf2
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98137/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked se
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98137/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_gem_evict.c:110: warning: Functi
On 11/30/2021 6:46 PM, Christoph Hellwig wrote:
> I still think this goes into the wrong direction.
>
> Something closer to your first version that also saves away the
> gvt->mmio.mmio_attribute flags in the core i915 module, and which
> splits the MMIO table into one that contains just the offset,
== Series Details ==
Series: DG2 accelerated migration/clearing support (rev3)
URL : https://patchwork.freedesktop.org/series/97544/
State : failure
== Summary ==
Applying: drm/i915/gtt: allow overriding the pt alignment
Applying: drm/i915/gtt: add xehpsdv_ppgtt_insert_entry
Applying: drm/i915
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21861
===
On 16/12/2021 20:30, John Harrison wrote:
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 thin
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us movin
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but s
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
== Series Details ==
Series: drm/i915/guc: Request RP0 before loading firmware (rev3)
URL : https://patchwork.freedesktop.org/series/97682/
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: Fix possible NULL pointer dereferences in i9xx_update_wm()
URL : https://patchwork.freedesktop.org/series/98154/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21863
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding support for writeback transcoder to start capturing frames using
> interrupt mechanism
I stopped reviewing this after a while, because there's just way too
much unrelated noise in the patch to even be able to focus on
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding drm_writeback_connector to drm_connector so that
> writeback_connector can be fetched from drm_connector
This needs some explaining, since drm_connector_to_writeback() does
exactly that.
> Adding drm_connector and drm
This change is to avoid over-specification of the TEOT timing
parameter, which is derived from software in current design.
Supposed that THS-TRAIL and THS-EXIT have the minimum values,
i.e., 60 and 100 in ns. If SW is overriding the HW default,
the TEOT value becomes 150 ns, approximately calculat
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Changing driver to use drm_writeback_connector.base pointer
Every commit should build and work on its own, so this makes me believe
the previous patch breaks the build.
Also, why?
You see that (in our clunky object hierarch
== Series Details ==
Series: More preparation for multi gt patches (rev2)
URL : https://patchwork.freedesktop.org/series/98032/
State : failure
== Summary ==
Applying: drm/i915: Store backpointer to GT in uncore
Applying: drm/i915: Introduce to_gt() helper
Applying: drm/i915/display: Use to_gt
On Fri, 17 Dec 2021, "Kandpal, Suraj" wrote:
> From: suraj kandpal
>
> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
This should be part of the patch that uses them.
BR,
Jani.
>
> Signed-off-by: suraj kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h
== Series Details ==
Series: drm/i915/guc: Request RP0 before loading firmware (rev3)
URL : https://patchwork.freedesktop.org/series/97682/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21864
Summary
On Thu, 16 Dec 2021, Harish Chegondi wrote:
> Check return pointer from intel_crtc_for_plane() before dereferencing
> it, as it can be NULL.
If you're doing this to satisfy some static analyzer, in these cases the
code would read *much* better if you added the NULL check inside
intel_crtc_active(
On Thu, 16 Dec 2021, Patchwork wrote:
> == 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
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, December 16, 2021 5:28 PM
> To: Surendrakumar Upadhyay, TejaskumarX
> ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V3] drm/i915/adl-n: Enable ADL-N platform
>
> On Fri, 10 Dec
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> i915_vma_wait_for_bind needs the vma lock held, fix the caller.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> 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.
>
> S
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf by requiring lock to
unbind.
URL : https://patchwork.freedesktop.org/series/98137/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11009_full -> Patchwork_21861_full
=
== Series Details ==
Series: drm/i915/dmc: Eliminate remnant GEN references
URL : https://patchwork.freedesktop.org/series/98166/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11009 -> Patchwork_21866
Summary
---
**F
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking w
On 17/12/2021 11:06, Tvrtko Ursulin wrote:
On 14/12/2021 17:04, Matthew Brost wrote:
From: John Harrison
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were b
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> 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
== Series Details ==
Series: drm/i915/guc: Request RP0 before loading firmware (rev3)
URL : https://patchwork.freedesktop.org/series/97682/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11009_full -> Patchwork_21864_full
Su
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
"unbind kill"
> 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: Maa
6-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unb
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the GuC firmware in the similar way it is done
by the execlists backend.
This way we have notion of where the hangs are before the GuC gains
support for proper error capture.
Ping - any interest to lo
== Series Details ==
Series: Adding writeback support for i915
URL : https://patchwork.freedesktop.org/series/98168/
State : failure
== Summary ==
Applying: drm: add writeback pointers to drm_connector
Using index info to reconstruct a base tree...
M include/drm/drm_connector.h
Falling b
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev2)
URL : https://patchwork.freedesktop.org/series/98055/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
04617ab4c517 drm/i915: Avoid using the i915_fence_array when collecting
dependencies
c9d9298d1a0b drm/i9
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev2)
URL : https://patchwork.freedesktop.org/series/98055/
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: Asynchronous vma unbinding (rev2)
URL : https://patchwork.freedesktop.org/series/98055/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/dr
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev2)
URL : https://patchwork.freedesktop.org/series/98055/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21868
Summary
---
**FAIL
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> We're working on requiring the obj->resv lock during unbind, fix
> the shrinker to take the objectl ock.
lock
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> 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
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, 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 alrea
== Series Details ==
Series: drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3)
URL : https://patchwork.freedesktop.org/series/96750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21869
Summary
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 Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> 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 str
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us movin
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 176 +
drivers/
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but s
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by: Thom
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a s
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the ins
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to a
On 17-12-2021 14:55, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> 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
>
== Series Details ==
Series: drm/i915/dsi: let HW maintain the HS-TRAIL timing (rev3)
URL : https://patchwork.freedesktop.org/series/96750/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11012_full -> Patchwork_21869_full
Su
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev3)
URL : https://patchwork.freedesktop.org/series/98055/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
af22ef498eaa drm/i915: Avoid using the i915_fence_array when collecting
dependencies
664fd217a101 drm/i9
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev3)
URL : https://patchwork.freedesktop.org/series/98055/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> 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 i
On 17-12-2021 12:58, Matthew Auld wrote:
> On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
> wrote:
>> Now that we cannot unbind kill the currently locked object directly
> "unbind kill"
>
>> because we're removing short term pinning, we may have to unbind the
>> object from gtt manually, using a
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev3)
URL : https://patchwork.freedesktop.org/series/98055/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11012 -> Patchwork_21870
Summary
---
**SUCC
From: Ville Syrjälä
Pull the "do we want to use i915->vbt.ports[]?" check into
a central place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
From: Ville Syrjälä
Quick attempt at unifying the VBT DDI parsing to all g4x+
platforms.
Note that we'll still use the hardware straps as the primary
source of port presence information on old platforms since the
device type bits in VBT tend to be often a bit wrong (for DP++
ports at least). Ho
From: Ville Syrjälä
CHV is currently straddling the divide by using parse_ddi_ports() stuff
for aux_ch/ddc_pin but going through all old codepaths for the rest
(intel_bios_is_port_present(), intel_bios_is_port_edp(),
intel_bios_is_port_dp_dual_mode()). Let's switch over full and use
i915->vbt.por
From: Ville Syrjälä
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need
to drop the version check as some elk/ctg machines may have VBTs
older than that. The oldest I know is an elk with version 142.
But the child device stuff has had the correct size since at
least version 125 (obser
From: Ville Syrjälä
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just
a DP+HDMI check. The rest of the bits shouldn't really
matter anyway.
The slight change in behaviour here is that now we do look at
the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via
intel_bios_encoder_supports_hdmi()) when we p
From: Ville Syrjälä
Now that we parse the DDI port info from the VBT on all g4x+ platforms
we can throw out all the old codepaths in intel_bios_is_port_present(),
intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None
of these should be called on pre-g4x platforms.
For good measure
From: Ville Syrjälä
Lots of machines these days seem to have a crappy type1 DP dual
mode adaptor chip slapped onto the motherboard. Based on the
DP dual mode spec we currently limit those to 165MHz max TMDS
clock.
Windows OTOH ignores DP dual mode adaptors when the VBT
indicates that the port is
Check return pointer from intel_crtc_for_plane() before dereferencing
it, as it can be NULL.
v2: Moved the NULL check into intel_crtc_active().
Cc: Jani Nikula
Cc: Caz Yokoyama
Cc: Radhakrishna Sripada
Signed-off-by: Harish Chegondi
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed,
On Fri, Dec 17, 2021 at 08:02:55AM -0800, Harish Chegondi wrote:
> Check return pointer from intel_crtc_for_plane() before dereferencing
> it, as it can be NULL.
Can't actually bu NULL. But I guess no real harm in having the
check if it shuts up some static analysis thing.
>
> v2: Moved the NULL
The screen resolution on my laptop is not reported accurately. Here's
an extract from the output of xdpyinfo:
screen #0:
dimensions:3200x1800 pixels (847x476 millimeters)
resolution:96x96 dots per inch
The number of pixels is correct, but the size and resolution values
smack of a b
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
>
> On 14/12/2021 15:07, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Log engine resets done by the GuC firmware in the similar way it is done
> > by the execlists backend.
> >
> > This way we have notion of where the han
On Thu, Dec 16, 2021 at 04:05:48PM +0200, Jani Nikula wrote:
> 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
== Series Details ==
Series: drm/i915: Extend parse_ddi_port() to all g4x+ platforms
URL : https://patchwork.freedesktop.org/series/98183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21871
Summary
-
== Series Details ==
Series: drm/i915: Fix possible NULL pointer dereferences in i9xx_update_wm()
(rev2)
URL : https://patchwork.freedesktop.org/series/98154/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21872
==
== Series Details ==
Series: drm/i915: Asynchronous vma unbinding (rev3)
URL : https://patchwork.freedesktop.org/series/98055/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11012_full -> Patchwork_21870_full
Summary
---
== Series Details ==
Series: drm/i915: Extend parse_ddi_port() to all g4x+ platforms
URL : https://patchwork.freedesktop.org/series/98183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11013_full -> Patchwork_21871_full
Sum
Checking cdclk conditions during atomic check and preparing
for commit phase so we can have atomic commit as simple
as possible. Add the specific steps to be taken during
cdclk changes, prepare for squashing, crawling and modeset
scenarios.
Rename functions intel_cdclk_can_squash() and
intel_cdclk_
== Series Details ==
Series: drm/i915/display: Move cdclk checks to atomic check (rev2)
URL : https://patchwork.freedesktop.org/series/97850/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a83c610f1486 drm/i915/display: Move cdclk checks to atomic check
-:120: CHECK:PARENTHESIS_
== Series Details ==
Series: drm/i915/display: Move cdclk checks to atomic check (rev2)
URL : https://patchwork.freedesktop.org/series/97850/
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/display: Move cdclk checks to atomic check (rev2)
URL : https://patchwork.freedesktop.org/series/97850/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_cdclk.c:2025: warning: Function paramete
== Series Details ==
Series: drm/i915/display: Move cdclk checks to atomic check (rev2)
URL : https://patchwork.freedesktop.org/series/97850/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11013 -> Patchwork_21873
Summary
--
On Thu, 2021-12-16 at 19:41 -0800, Madhumitha Tolakanahalli Pradeep
wrote:
> Replace GEN with DISPLAY_VER, in line with the naming
> convention
> followed in the i915 driver code.
>
> Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> madhumitha.tolakanahalli.prad...@intel.com>
> ---
> drivers/g
== Series Details ==
Series: drm/i915/display: Move cdclk checks to atomic check (rev2)
URL : https://patchwork.freedesktop.org/series/97850/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11013_full -> Patchwork_21873_full
On Tue, Dec 14, 2021 at 09:33:41PM +0200, 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.
>
On Tue, Dec 14, 2021 at 09:33:42PM +0200, 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.
>
On Tue, Dec 14, 2021 at 09:33:43PM +0200, 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.
>
On Tue, Dec 14, 2021 at 09:33:44PM +0200, 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.
>
On Tue, Dec 14, 2021 at 09:33:45PM +0200, 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.
>
On Tue, Dec 14, 2021 at 09:33:46PM +0200, Andi Shyti wrote:
> The reference to the GGTT from the private date is not used
> anymore. Remove it.
You may want to also mention here that tile0's ggtt will now be
dynamically allocated (and auto-deallocated on driver unload by the
drmm_* infrastructure)
On Wed, Dec 15, 2021 at 07:25:17AM +, Patchwork wrote:
> == Series Details ==
>
> Series: More preparation for multi gt patches
> URL : https://patchwork.freedesktop.org/series/98032/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11002_full -> Patchwork_21849_ful
When using QFLAG_APPLY_ONCE we make sure the quirk is applied only once.
This is useful when it's enough one device to trigger a certain
condition or when the resource in each that applies is global to the
system rather than local to the device.
However we call the quirk handler based on vendor, c
== Series Details ==
Series: x86/quirks: Fix logic to apply quirk once
URL : https://patchwork.freedesktop.org/series/98200/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11014 -> Patchwork_21874
Summary
---
**SUCCES
96 matches
Mail list logo
