== Series Details ==
Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in
drm_gem_private_object_init
URL : https://patchwork.freedesktop.org/series/113318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113318v1_full
== Series Details ==
Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start
and size from pages to bytes
URL : https://patchwork.freedesktop.org/series/113313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113313v1_full
=
== Series Details ==
Series: Allow error capture without a request & fix locking issues (rev3)
URL : https://patchwork.freedesktop.org/series/113078/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113078v3
== Series Details ==
Series: drm/i915/mtl/selftests: Flush all tiles on test exit
URL : https://patchwork.freedesktop.org/series/113312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113312v1_full
Su
== Series Details ==
Series: Allow error capture without a request & fix locking issues (rev3)
URL : https://patchwork.freedesktop.org/series/113078/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need
to be re-applied on engine resets
URL : https://patchwork.freedesktop.org/series/113370/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113370v1
==
== Series Details ==
Series: drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
URL : https://patchwork.freedesktop.org/series/113083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638_full -> Patchwork_113083v3_full
===
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/xehp: GAM registers don't need
to be re-applied on engine resets
URL : https://patchwork.freedesktop.org/series/113370/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit
== Series Details ==
Series: drm/i915/gt: Add selftests for TLB invalidation (rev3)
URL : https://patchwork.freedesktop.org/series/112894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_112894v3
Summary
--
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/113363/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113363v1
Summary
---
**SUCCESS
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/113363/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Error/underrun interrupt fixes
URL : https://patchwork.freedesktop.org/series/113353/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113353v1
Summary
---
**SUC
== Series Details ==
Series: drm/fb-helper: Various cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/113220/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113220/revisions/3/mbox/ not
applied
Applying: drm/client: Test for connector
== Series Details ==
Series: Add _PICK_EVEN_2RANGES (rev3)
URL : https://patchwork.freedesktop.org/series/113177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113177v3
Summary
---
**SUCCESS**
N
== Series Details ==
Series: Add _PICK_EVEN_2RANGES (rev3)
URL : https://patchwork.freedesktop.org/series/113177/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [1/2] drm/ttm: revert "stop allocating a dummy
resource for pipelined gutting"
URL : https://patchwork.freedesktop.org/series/113345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113345v1
==
== Series Details ==
Series: series starting with [1/2] drm/ttm: revert "stop allocating a dummy
resource for pipelined gutting"
URL : https://patchwork.freedesktop.org/series/113345/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC intentionally dies on such a situation,
it is no
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/d
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that t
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span
From: John Harrison
The GuC specific register state entry in the error capture object was
just called 'capture'. Although the companion 'node' entry was called
'guc_capture_node'. Rename the base entry to be 'guc_capture' instead
so that it is a) more consistent and b) more obvious what it is.
S
From: John Harrison
intel_guc_find_hung_context() was not acquiring the correct spinlock
before searching the request list. So fix that up. While at it, add
some extra whitespace padding for readability.
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
C
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of an engine reset failure the GuC is not
== Series Details ==
Series: series starting with [v4,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113341/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113341v1
=
== Series Details ==
Series: series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113336/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12640 -> Patchwork_113336v1
=
== Series Details ==
Series: series starting with [v3,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113336/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be check
On Wed, Jan 25, 2023 at 03:41:58PM -0800, Matt Roper wrote:
> Workaround Wa_18018781329 has applied to several recent Xe_HP-based
> platforms. However there are some extra gotchas to implementing this
> properly for MTL that we need to take into account:
>
> * Due to the separation of media and
GAMSTLB_CTRL and GAMCNTRL_CTRL became multicast/replicated registers on
Xe_HP. They should be defined accordingly and use MCR-aware operations.
These registers have only been used for some dg2/xehpsdv workarounds, so
this fix is mostly just for consistency/future-proofing; even lacking
the MCR an
Register reset characteristics (i.e., whether the register maintains or
loses its value on engine reset) is an important factor that determines
which wa_list we want to add workarounds to. We recently found out that
the bspec documentation for the Xe_HP's "GAM" registers in the 0xC800 -
0xCFFF ran
Workaround Wa_18018781329 has applied to several recent Xe_HP-based
platforms. However there are some extra gotchas to implementing this
properly for MTL that we need to take into account:
* Due to the separation of media and render/compute into separate GTs,
this workaround needs to be imple
== Series Details ==
Series: drm/i915/dp_mst: Fix MST payload removal during output disabling
URL : https://patchwork.freedesktop.org/series/113329/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
LD [M] drivers/gpu/drm/i915/i915.o
LD
== Series Details ==
Series: drm/i915: switch to drm_edid and enable HF-EEODB support
URL : https://patchwork.freedesktop.org/series/113327/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113327v1
Summary
== Series Details ==
Series: series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113322v1
=
== Series Details ==
Series: drm/i915: switch to drm_edid and enable HF-EEODB support
URL : https://patchwork.freedesktop.org/series/113327/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
From: Chris Wilson
Check that we invalidate the TLB cache, the updated physical addresses
are immediately visible to the HW, and there is no retention of the old
physical address for concurrent HW access.
Signed-off-by: Chris Wilson
[ahajda: adjust to upstream driver, v2]
Signed-off-by: Andrzej
== Series Details ==
Series: series starting with [v2,1/4] drm/amdgpu: Use cursor start instead of
ttm resource start
URL : https://patchwork.freedesktop.org/series/113322/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be check
On 1/23/2023 09:51, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
-struct i915_request *intel_context_find_active_request(struct
intel_context *ce)
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce)
TB
== Series Details ==
Series: drm/i915/psr: Split sel fetch plane configuration into arm and noarm
URL : https://patchwork.freedesktop.org/series/113321/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12639 -> Patchwork_113321v1
==
On Wed, Jan 25, 2023 at 04:43:29PM -0300, Gustavo Sousa wrote:
> On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> > Register reset characteristics (i.e., whether the register maintains or
> > loses its value on engine reset) is an important factor that determines
> > which wa_list we w
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thom
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
>
== Series Details ==
Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in
drm_gem_private_object_init
URL : https://patchwork.freedesktop.org/series/113318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113318v1
==
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected; it makes no allowances for the well-formed
but incorrect "toggled" state. This patch changes panic-on-toggled
into a warning, allowing to reduce the problem to a repeatable script.
note: this patch is arch
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.
With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected a
lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko
Define DEBUG only in the main module, not in the submod. Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing that
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
The dyndbg-to-trace feature is WIP, and not in mainline, so the
presence of the interface to use/test it is unhelpful/confusing.
So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or
blank, depending upon ifdef DYDBG_TRACE, and update 4 params
controlling the T-flag to use it.
Signed-
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.
Original name was a punt; but the macro is maybe general enough to put
in the API later. Rename and improve the macro towards that end.
Also tweak internal name constructed in the macro, to add a '_'
between the name components. This changes the .i file only.
no functional change.
Signed-off-b
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
no function
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classname args to CLASSMAP macros we
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need t
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authori
Change function's 1st arg-type, by derefing in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic
Inner fn adds mod_name param, allowing caller to guarantee that only
one module is affected by a prdbgs update. Outer fn preserves
kernel_param interface, passing NULL to inner fn.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 36 +---
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the m
currently, for verbose=3, this is logged:
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_C
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly mu
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in mod
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/t
Hi everyone,
In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
drivers at modprobe.
It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set. When
drm_debug_enabled() tested __drm_debug at runtime, this just w
== Series Details ==
Series: series starting with [v4,1/4] drm/gem: Remove BUG_ON in
drm_gem_private_object_init
URL : https://patchwork.freedesktop.org/series/113318/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked se
== Series Details ==
Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start
and size from pages to bytes
URL : https://patchwork.freedesktop.org/series/113313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113313v1
===
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canill
Store the console's preferred BPP value in struct drm_fb_helper
and remove the respective function parameters from the internal
fbdev code.
The BPP value is only required as a fallback and will now always
be available in the fb-helper instance.
No functional changes.
Signed-off-by: Thomas Zimmer
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 17 ++---
1
Call drm_fb_helper_fini() in the generic-fbdev hotplug helper
to revert the effects of drm_fb_helper_init(). No full cleanup
is required.
v3:
* fix error in commit message (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_gene
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_gene
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
v2:
* declare as static inline (kernel test robot)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 14 +-
include/drm/drm_fb_
Add various cleanups and changes to DRM's fbdev helpers and the
generic fbdev emulation. There's no clear theme here, just lots
of small things that need to be updated.
In the end, the code will better reflect which parts are in the
DRM client, which is fbdev emulation, and which are shared fbde
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
v3:
* build with CONFIG_DRM_FBDEV_
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper, which prevents us from initializing these pointers
early after allo
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
== Series Details ==
Series: series starting with [1/4] drm/amdgpu: Movie the amdgpu_gtt_mgr start
and size from pages to bytes
URL : https://patchwork.freedesktop.org/series/113313/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won'
On Tue, Jan 24, 2023 at 05:14:07PM -0800, Matt Roper wrote:
> GAMSTLB_CTRL and GAMCNTRL_CTRL became multicast/replicated registers on
> Xe_HP. They should be defined accordingly and use MCR-aware operations.
>
> These registers have only been used for some dg2/xehpsdv workarounds, so
> this fix i
On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> Register reset characteristics (i.e., whether the register maintains or
> loses its value on engine reset) is an important factor that determines
> which wa_list we want to add workarounds to. We recently found out that
> the bspec docu
On Wed, Jan 25, 2023 at 10:51:53AM +, Tvrtko Ursulin wrote:
>
> On 24/01/2023 20:54, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > Uncore is really part of the GT. So use the GT specific debug/error
That's not really true; uncore should be outside the GT since it's used
f
From: Ville Syrjälä
FBC on gen2/3 seems to trigger page table errors. No visual
artifacts are visible, and essentially the same FBC
code works on gen4 so these seem entirely spurious. There
are also hints in gen3 bspec indicating that certain bits
in PGTBL_ER are just not wired up correctly in th
From: Ville Syrjälä
PGTBL_ER contains the individual reasons for the page table
error interrupt. Dump it out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_i
From: Ville Syrjälä
Pull the EMR calculation into small helpers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++---
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_
From: Ville Syrjälä
The gen2/gen3 irq code is supposed to be identical apart
from the 32bit vs. 16bit access width. The recent change
to intel_de_rmw() ruined that symmetry. Restore it to avoid
needless mental gymnastics when comparing the two codepaths.
And while at it remove the extra eir!=0 c
From: Ville Syrjälä
At least on some platforms (tested on ctg) the way
vgacon does screen blanking seems to flag constant
FIFO underruns, which means we have to be prepared
for them while the driver is loading. Currently
there is a time window between drm_crtc_init() and
intel_sanitize_fifo_under
From: Ville Syrjälä
Fix up some error interrupt/underrun reporting issues
on old platforms.
Ville Syrjälä (5):
drm/i915: Mark FIFO underrun disabled earlier
drm/i915: Undo rmw damage to gen3 error interrupt handler
drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt
drm/i915: Extract {i9
== Series Details ==
Series: drm/i915/mtl/selftests: Flush all tiles on test exit
URL : https://patchwork.freedesktop.org/series/113312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113312v1
Summary
== Series Details ==
Series: drm/i915/display: Pass drm_i915_private as param to i915 funcs (rev3)
URL : https://patchwork.freedesktop.org/series/113083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12638 -> Patchwork_113083v3
=
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
1) It increases the code size since the array is declared
in e
On 1/25/2023 10:12, Tvrtko Ursulin wrote:
On 25/01/2023 18:00, John Harrison wrote:
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus
On 25/01/2023 18:00, John Harrison wrote:
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
Hi,
On 23/01/2023 15:42, Michal Koutný wrote:
Hello Tvrtko.
Interesting work.
Thanks!
On Thu, Jan 12, 2023 at 04:55:57PM +, Tvrtko Ursulin
wrote:
Because of the heterogenous hardware and driver DRM capabilities, soft limits
are implemented as a loose co-operative (bi-directional) i
Why are you top posting?
On Wed, Jan 25, 2023 at 12:28:29PM -0500, Rodrigo Vivi wrote:
>
> Greg, ack on getting these 3 mei patches merged through intel-gfx?
$ mdfrm -c ~/mail/todo/
756 messages in /home/gregkh/mail/todo/
Give me a chance, what is the sudden rush?
greg k-h
On 1/24/2023 06:40, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the erro
Greg, ack on getting these 3 mei patches merged through intel-gfx?
On Wed, Jan 25, 2023 at 12:26:34AM -0800, Alan Previn wrote:
> From: Alexander Usyskin
>
> Client on bus have only one vtag map slot and should disregard the vtag
> value when cleaning pending read flag.
> Fixes read flow contr
On Wed, 25 Jan 2023 at 16:15, Christian König wrote:
>
> Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 15:50, Christian König
> > wrote:
> >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
> >>
> >> It seems to still breka i915.
> > We also need to revert th
Am 25.01.23 um 17:13 schrieb Matthew Auld:
On Wed, 25 Jan 2023 at 15:50, Christian König
wrote:
This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
It seems to still breka i915.
We also need to revert the third patch:
b49323aa35d5 drm/ttm: prevent moving of pinned BOs
It introduce
1 - 100 of 210 matches
Mail list logo
