From: Pallavi Mishra
It's a noop on all new platforms starting from MTL.
Refer: (e7737b67ab46) drm/i915/uapi: reject caching ioctls for discrete
v2:
1. block get caching ioctl
2. return ENODEV similar to DGFX
3. update the doc in i915_drm.h
Cc: Lucas De Marchi
Cc: Matt Roper
Cc: Joonas Lahtin
Add a separate PTE encode function for MTL. The number of PAT registers
have increased to 16 on MTL. All 16 PAT registers are available for
PPGTT mapped pages, but only the lower 4 are available for GGTT mapped
pages.
BSPEC: 63884
Cc: Lucas De Marchi
Cc: Matt Roper
Co-developed-by: Fei Yang
Si
New platforms will use different encode functions.
Cc: Lucas De Marchi
Cc: Matt Roper
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++--
3 files ch
From: Madhumitha Tolakanahalli Pradeep
On MTL due to the introduction of L4 cache, coherency and cacheability
selections are different and also GT can no longer allocate on LLC. The
MOCS/PAT tables needs an update.
BSpec: 44509, 45101, 44235
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by:
== Series Details ==
Series: drm/i915: Add support for GSC FW loading (rev3)
URL : https://patchwork.freedesktop.org/series/70/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_70v3_full
Summary
On Mon, 2022-12-05 at 18:04 -0800, Alan Previn Teres Alexis wrote:
> On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> > On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> > >
> > > All other GuC Relay Logging debugfs handles including recent
> > > additions are under the 'i915/g
== Series Details ==
Series: drm/i915: Add support for GSC FW loading (rev3)
URL : https://patchwork.freedesktop.org/series/70/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12471 -> Patchwork_70v3
Summary
---
== Series Details ==
Series: drm/i915: Add support for GSC FW loading (rev3)
URL : https://patchwork.freedesktop.org/series/70/
State : warning
== Summary ==
Error: dim checkpatch failed
ed465c9fce3c drm/i915/uc: Introduce GSC FW
Traceback (most recent call last):
File "scripts/spdxcheck
== Series Details ==
Series: drm/i915: Add support for GSC FW loading (rev3)
URL : https://patchwork.freedesktop.org/series/70/
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_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/111651/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_111651v1_full
Summary
---
**F
GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.
The GSC is not reset as part
On 12/5/2022 4:03 PM, Alan Previn wrote:
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only
== Series Details ==
Series: series starting with [v9,1/1] drm/i915/pxp: Promote pxp subsystem to
top-level of i915
URL : https://patchwork.freedesktop.org/series/111650/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12471_full -> Patchwork_111650v1_full
=
Hi,
Issue re-reported, https://patchwork.freedesktop.org/series/111373/
Bug filed for this issue, https://gitlab.freedesktop.org/drm/intel/-/issues/7647
Thanks,
Y Sai Nandan
From: Nautiyal, Ankit K
Sent: Monday, December 5, 2022 5:49 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminaraya
== Series Details ==
Series: Align DDI_BUF_CTL Active timeouts with Bspec updates (rev4)
URL : https://patchwork.freedesktop.org/series/111373/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12465_full -> Patchwork_111373v4_full
=
== Series Details ==
Series: DRM_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/111651/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12471 -> Patchwork_111651v1
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: Add support for GSC FW loading (rev2)
URL : https://patchwork.freedesktop.org/series/70/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M] drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.o
drivers/
== Series Details ==
Series: DRM_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/111651/
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_USE_DYNAMIC_DEBUG regression
URL : https://patchwork.freedesktop.org/series/111651/
State : warning
== Summary ==
Error: dim checkpatch failed
8d78d81edb74 test-dyndbg: fixup CLASSMAP usage error
a526555f2fee test-dyndbg: show that DEBUG enables prdbgs at compi
== Series Details ==
Series: series starting with [v9,1/1] drm/i915/pxp: Promote pxp subsystem to
top-level of i915
URL : https://patchwork.freedesktop.org/series/111650/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12471 -> Patchwork_111650v1
===
On Wed, 2022-07-20 at 12:08 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:51 -0700, Alan Previn wrote:
> >
> > All other GuC Relay Logging debugfs handles including recent
> > additions are under the 'i915/gt/uc/path' so let's also move
> > 'guc_log_relay_chan' to its proper home
Alan
>
Alan:snip
>
> > void intel_guc_log_debugfs_register(struct intel_guc_log *log,
> > @@ -204,7 +204,7 @@ void intel_guc_log_debugfs_register(struct
> > intel_guc_log *log,
> > { "guc_log_dump", &guc_log_dump_fops, NULL },
> > { "guc_load_err_log_dump", &guc_load_err_log
On Tue, 2022-07-19 at 19:49 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:48 -0700, Alan Previn wrote:
> >
Alan: [snip]
Alan: This patch is not needed any longer because it was also part of another
re-factor related to error-capture and
debug-log-sizing management changes that got m
It's been a while - trying to resurrect this now.
On Tue, 2022-07-19 at 20:40 -0700, Dixit, Ashutosh wrote:
> On Mon, 09 May 2022 14:01:49 -0700, Alan Previn wrote:
> >
> >
Alan: [snip]
> > +#define GUC_LOG_RELAY_SUBBUF_COUNT 8
> > +u32 intel_guc_log_relay_subbuf_count(struct intel_guc_log *l
== Series Details ==
Series: series starting with [v9,1/1] drm/i915/pxp: Promote pxp subsystem to
top-level of i915
URL : https://patchwork.freedesktop.org/series/111650/
State : warning
== Summary ==
Error: dim checkpatch failed
c366ae879c50 drm/i915/pxp: Promote pxp subsystem to top-level o
Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
From: Jonathan Cavitt
The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.
IMPORTANT: lack of GSC FW breaks media C6 due to o
If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-initiated FLR is not the same as PCI config space FLR in
that it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs
On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.
Similarly to the other FWs, the GSC FW path can be overriden via
modparam. The modparam can also be used to disable the GSC
GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.
The GSC is not reset as part
The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the cod
Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).
The loading happens via a submission to the GSC engine. All subseque
dont break the loop, to see multiple clients. the 3 client records
are differently wrong.
---
lib/dynamic_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 3ef1c0a1f0cd..a26eaa348731 100644
--- a/lib/dynamic_debug.c
++
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
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- classnames were formerly specified a
DECLARE_DYNDBG_CLASSMAPs 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 to
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.
It appears that, at least for builtin drm,i915 loadable amdgpu, data
in the class_refs section is not properly linked, this works partway
towards isolating the problem.
The "NO CLI" name test is failing.
This version of the report fails with a non-canonical address:
// v2pr_info("NO CLI name on:
The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn. Its one-time purpose was subsumed
into the ddebug_info record, which is used in dynamic_debug_init() as
a cursor to load the builtin _ddebug[] table.
TODO: cited commit gives another reason for b
currently, for verbose=3, this is logged:
[ 3832.333424] dyndbg: parsed: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[ 3832.333888] dyndbg: no matches for query
[ 3832.334093] dyndbg: no-match: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[
for loadable drm, helpers, and drivers, dependent-load is failing to
apply changes, needs more investigation.
---
lib/dynamic_debug.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 46684aa7284d..3ef1c0a1f0cd 100644
--- a/
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE variants, 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)
ARRAY_SIZE works here, since array decl is complete.
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..81b643ab7f6e 100644
--- a/incl
dynamic_debug_init() currently uses strcmp to find the module
boundaries in the builtin _ddebug[] table.
The table is filled by the linker; for its content, pointer inequality
works, is faster, and communicates the data properties more tightly.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, make it more selective, by adding query_module param.
The fn now calls ddebug_exec_queries(query, NULL), where NULL is
query_modname wildcard ("*" does the same). So just expose the
parameter, and alter users to expl
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
Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:
echo L3 > p_level_names
cat p_level_names
4
Fix this with a -1 offset in LEVEL_NAMES readback.
NOTE:
Calling this a BU
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
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,
DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
Regression is due to a chicken-egg problem loading modules; on
`modprobe i915`, drm is loaded 1st, and drm.debug is set. When
drm_debug_enabled() tested __drm_debug at runtime, that just worked.
But with DRM_USE_DYNAMIC_DEBUG=y, the
On Mon, 2022-11-28 at 16:48 -0800, Alan Previn wrote:
> A driver bug was recently discovered where the security firmware was
> receiving internal HW signals indicating that session key expirations
> had occurred. Architecturally, the firmware was expecting a response
> from the GuC to acknowledge t
On Mon, Dec 5, 2022 at 9:18 AM Patchwork
wrote:
>
> == Series Details ==
>
> Series: DRM - avoid regression in -rc, fix comment
> URL : https://patchwork.freedesktop.org/series/111631/
> State : failure
>
> == Summary ==
>
> Error: patch
> https://patchwork.freedesktop.org/api/1.0/series/111631
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pe
On Mon, Dec 05, 2022 at 04:33:29PM -0300, Gustavo Sousa wrote:
> On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> > The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> > literal value of 0x2FC0100F for this register. The register's hardware
> > default value is 0x2FC
On Fri, Dec 02, 2022 at 03:44:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On mtl (at least) clearing the guardband bits in the same write
> as the enable bit gets cleared seems to cause an immediate FIFO
> underrun. Thus is seems that we need to first clear just the
> enable bit, t
On Mon, 2022-12-05 at 11:53 -0800, Ceraolo Spurio, Daniele wrote:
>
Alan:[snip]
> >
> > ext_data->flags |= I915_BO_PROTECTED;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 29e9e8d5b6fe..ed74d173a092 100644
>
On Fri, Dec 02, 2022 at 03:44:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On mtl it looks like disabling VRR after the transcoder has
> been disabled can cause the pipe/transcoder to get stuck
> when re-enabled in non-vrr mode. Reversing the order seems to
> help.
>
> Bspec is ext
On Fri, Dec 02, 2022 at 03:44:10PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We are miscalculating both the guardband value, and the resulting
> vblank exit length on adl+. This means that our start of vblank
> (double buffered register latch point) is incorrect, and we also
> think t
On Fri, Dec 02, 2022 at 03:44:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Account for the framestart delay when calculating the "pipeline full"
> value for icl/tgl vrr. This puts the start of vblank (ie. where the
> double bufferd registers get latched) to a consistent place regard
Am 30.11.22 um 15:06 schrieb Daniel Vetter:
On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
wrote:
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here,
On 12/2/2022 3:28 PM, Alan Previn wrote:
Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only
On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> literal value of 0x2FC0100F for this register. The register's hardware
> default value is 0x2FC0108F, so this translates to just clearing one
> bit.
>
> Take this op
== Series Details ==
Series: drm/i915/hwmon: Silence "mailbox access failed" warning in
snb_pcode_read (rev2)
URL : https://patchwork.freedesktop.org/series/111599/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12467_full -> Patchwork_111599v2_full
===
On 12/5/2022 11:04 AM, Teres Alexis, Alan Previn wrote:
On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
Alan: [snip]
@@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
{
struct drm_i91
On Mon, 2022-12-05 at 12:57 -0500, Vivi, Rodrigo wrote:
> On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> >
> >
> >
Alan: [snip]
> > @@ -1168,6 +1176,8 @@ static int i915_drm_prepare(struct drm_device *dev)
> > {
> > struct drm_i915_private *i915 = to_i915(dev);
> >
> >
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
>
> On 02/12/2022 20:14, John Harrison wrote:
>
and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end user) so let maintainers decide
On 05/12/2022 16:27, Matt Roper wrote:
On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
On 02/12/2022 22:49, Rodrigo Vivi wrote:
On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
When determining whether the platform has a hardware-level steering
semaphore (i.e., MT
Debian packaging apparently just decided not to include i915g in the
transition? Not our fault.
On Mon, Dec 5, 2022 at 9:59 AM Rodrigo Vivi wrote:
> Cc: mesa-dev ml
>
> On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> > From libgl1-mesa-dri:amd64 changelog:
> > mesa (22.0.0~rc2-1)
On 05/12/2022 15:52, Matt Roper wrote:
On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
On 28/11/2022 23:30, Matt Roper wrote:
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against ra
Cc: mesa-dev ml
On Sat, Dec 03, 2022 at 03:00:44AM -0500, Felix Miata wrote:
> From libgl1-mesa-dri:amd64 changelog:
> mesa (22.0.0~rc2-1) experimental; urgency=medium
>
> * New upstream release candidate.
> * path_max.diff: Refreshed.
> * rules: Drop classic drivers (r100, r200, nouveau_vi
On Fri, Dec 02, 2022 at 03:28:21PM -0800, Alan Previn wrote:
> Starting with MTL, there will be two GT-tiles, a render and media
> tile. PXP as a service for supporting workloads with protected
> contexts and protected buffers can be subscribed by process
> workloads on any tile. However, depending
Below failure is not related to PXP (PXP is not supported on SKL).
Additionally, towards the end of dmesg seems like gt got wedged when attempting
a completely different igt selftest which bailed on a timeout causing locking
issues.
...alan
On Sat, 2022-12-03 at 10:18 +, Patchwork wrote:
Pat
On Mon, Dec 05, 2022 at 04:17:16PM +0200, Jani Nikula wrote:
> On Mon, 05 Dec 2022, Jani Nikula wrote:
> > Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
> > no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
> > VLV_DISPLAY_BASE. Use it statically, reducing
== Series Details ==
Series: drm/i915/hwmon: Silence "mailbox access failed" warning in
snb_pcode_read (rev2)
URL : https://patchwork.freedesktop.org/series/111599/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12467 -> Patchwork_111599v2
=
On 05/12/2022 16:31, Kamil Konieczny wrote:
Hi Matt,
after re-reading I have few more nits.
On 2022-12-02 at 12:02:41 +, Matthew Auld wrote:
So we can use this across different tests.
v2
- Add docs for everything (Petri)
- Add missing copyright and fix headers slightly (Kamil)
Sign
On Sat, Dec 03, 2022 at 08:38:41AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/mtl: Check full IP version when applying hw steering
> semaphore
> URL : https://patchwork.freedesktop.org/series/111595/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI
== Series Details ==
Series: drm/i915/hwmon: Silence "mailbox access failed" warning in
snb_pcode_read (rev2)
URL : https://patchwork.freedesktop.org/series/111599/
State : warning
== Summary ==
Error: dim checkpatch failed
686d5a838376 drm/i915/hwmon: Silence "mailbox access failed" warning
Hi Matt,
after re-reading I have few more nits.
On 2022-12-02 at 12:02:41 +, Matthew Auld wrote:
> So we can use this across different tests.
>
> v2
> - Add docs for everything (Petri)
> - Add missing copyright and fix headers slightly (Kamil)
>
> Signed-off-by: Matthew Auld
> Cc: Kami
On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
>
> On 02/12/2022 22:49, Rodrigo Vivi wrote:
> > On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
> > > When determining whether the platform has a hardware-level steering
> > > semaphore (i.e., MTL and beyond), we need to
== Series Details ==
Series: DRM - avoid regression in -rc, fix comment
URL : https://patchwork.freedesktop.org/series/111631/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/111631/revisions/1/mbox/ not
applied
Applying: drm: mark CONFIG_DRM_USE_D
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression, due to a chicken-egg
initialization problem:
1- modprobe i915
i915 needs drm.ko, which is loaded 1st
2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
drm.debug is set post-initialization, from boot-args etc
3- `modprobe i915` finishes
W/
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
hi DRM-folks,
DRM_USE_DYNAMIC_DEBUG has regression, mark as BROKEN for now.
Also correct a comment.
Jim Cromie (2):
drm: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now
drm_print: fix stale macro-name in comment
drivers/gpu/drm/Kconfig | 3 ++-
include/drm/drm_print.h | 5 -
2 files
== Series Details ==
Series: drm/i915/backlight: drop implict dev_priv etc.
URL : https://patchwork.freedesktop.org/series/111628/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12467 -> Patchwork_111628v1
Summary
---
On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
>
> On 28/11/2022 23:30, Matt Roper wrote:
> > Starting with MTL, the driver needs to not only protect the steering
> > control register from simultaneous software accesses, but also protect
> > against races with hardware/firmware ag
== Series Details ==
Series: drm/i915/fbc: drop uncore locking around i8xx/i965 fbc nuke
URL : https://patchwork.freedesktop.org/series/111626/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12466_full -> Patchwork_111626v1_full
=
== Series Details ==
Series: drm/i915/backlight: drop implict dev_priv etc.
URL : https://patchwork.freedesktop.org/series/111628/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bito
On Sat, Dec 03, 2022 at 02:27:44AM -, Patchwork wrote:
> Patch Details
>
> Series: add guard padding around i915_vma (rev7)
> URL: https://patchwork.freedesktop.org/series/110720/
> State: failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v7/index.html
>
>
== Series Details ==
Series: drm/i915/gt: remove some limited use register access wrappers (rev2)
URL : https://patchwork.freedesktop.org/series/111265/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12466_full -> Patchwork_111265v2_full
On Mon, 05 Dec 2022, Jani Nikula wrote:
> Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
> no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
> VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv
> references.
Hmm, I spotted this, but looks l
Dump a local branch I've had laying around for a while.
Jani Nikula (5):
drm/i915/backlight: use VLV_DISPLAY_BASE for VLV/CHV backlight
registers
drm/i915/backlight: get rid of the implicit dev_priv
drm/i915/backlight: mass rename dev_priv to i915
drm/i915/backlight: drop drm_device lo
Fix the final straggler.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_backlight.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 3599c7c8c007..8d8f
Prefer only having struct drm_i915_private *i915 around. Drop the
drm_device *dev locals.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_backlight.c| 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_back
With the implicit dev_priv usage gone, we can rename dev_priv to i915
throughout. Do some drive-by whitespace cleanups while at it.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_backlight.c| 517 +-
1 file changed, 248 insertions(+), 269 deletions(-)
diff --g
Pass the i915 pointer to the macros where needed.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_backlight.c| 38 +--
.../drm/i915/display/intel_backlight_regs.h | 6 +--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/d
Since the VLV/CHV backlight registers are only used on VLV/CHV, there's
no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's
VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv
references.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_backlight_regs.h |
Am 25.11.22 um 19:18 schrieb Alex Deucher:
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well.
Am 29.11.22 um 22:14 schrieb Felix Kuehling:
On 2022-11-25 05:21, Christian König wrote:
Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.
This not only simplifies the handling massively,
On 02/12/2022 20:14, John Harrison wrote:
and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end user) so let maintainers decide here what is
expectation here
Could we have some examples pa
== Series Details ==
Series: drm/i915/fbc: drop uncore locking around i8xx/i965 fbc nuke
URL : https://patchwork.freedesktop.org/series/111626/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12466 -> Patchwork_111626v1
Summa
1 - 100 of 109 matches
Mail list logo
