On 5/13/2022 8:11 PM, Matt Roper wrote:
On Fri, May 13, 2022 at 10:47:54AM +0200, Nirmoy Das wrote:
From: Bommu Krishnaiah
Enable Tile4 tiling mode on platform that supports
Tile4 but no TileY like DG2.
Drive-by comment: the patch description doesn't match what the code is
actually doing.
On 14/05/2022 00:06, Jordan Justen wrote:
On 2022-05-13 05:31:00, Lionel Landwerlin wrote:
On 02/05/2022 17:15, Ramalingam C wrote:
Capture the impact of memory region preference list of the objects, on
their memory residency and Flat-CCS capability.
v2:
Fix the Flat-CCS capability of an o
On Sat, 14 May 2022, Vinay Belgaumkar wrote:
> SLPC min/max frequency updates require H2G calls. We are seeing
> timeouts when GuC channel is backed up and it is unable to respond
> in a timely fashion causing warnings and affecting CI.
>
> This is seen when waitboosting happens during a stress te
On Mon, 16 May 2022, Jani Nikula wrote:
> On Sat, 14 May 2022, Vinay Belgaumkar wrote:
>> SLPC min/max frequency updates require H2G calls. We are seeing
>> timeouts when GuC channel is backed up and it is unable to respond
>> in a timely fashion causing warnings and affecting CI.
>>
>> This is s
On 14.05.2022 19:03, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915/display: disable HPD workers before display driver
unregister (rev7)
*URL:* https://patchwork.freedesktop.org/series/103811/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tre
On 2022-05-16 00:47:43, Lionel Landwerlin wrote:
> On 14/05/2022 00:06, Jordan Justen wrote:
>>
>> Acked-by: Jordan Justen
>>
>> I think Nanley has accounted for this on iris with:
>>
>>
>> https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8
>
On Fri, 13 May 2022, "Teres Alexis, Alan Previn"
wrote:
> Nit: not sure why we use ERR_PTR for int when calling func was also returning
> an int.
> Anyway, that was how the original code was, so:
%pe on an error pointer prints the symbolic error name if
CONFIG_SYMBOLIC_ERRNAME=y and the errno i
There's an early return for !engine->kernel_context.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index ee46561b5ae8..7
On Tue, 10 May 2022, "Nautiyal, Ankit K" wrote:
> LGTM.
>
> Reviewed-by: Ankit Nautiyal
Thanks for the review, pushed the lot already on Friday.
BR,
Jani.
>
> Regards,
>
> Ankit
>
> On 5/9/2022 5:33 PM, Jani Nikula wrote:
>> Introduce new opaque type struct drm_edid to encapsulate the EDID dat
From: Bommu Krishnaiah
Update the selftest to include Tile 4 mode and switch to Tile 4 on
platforms that supports Tile 4 but no Tile Y and vice versa.
Also switch to XY_FAST_COPY_BLT on platforms that supports it.
v4: update commit message to reflect the code changes properly.
v3: add a function
On Mon, 02 May 2022, Harry Wentland wrote:
> Both the kernel and IGT series look good to me.
>
> I recommend you merge the entire kernel set as one into drm-next. We
> can pull it into amd-staging-drm-next so as not to break our CI once
> the IGT patches land.
Can we read that as an ack to merge
On Tue, 12 Apr 2022, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of
>> Bhanuprakash Modem
>> Sent: Monday, April 11, 2022 3:21 PM
>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; jani.nik...@linux.i
== Series Details ==
Series: drm/i915/overlay: remove redundant GEM_BUG_ON()
URL : https://patchwork.freedesktop.org/series/104015/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11656 -> Patchwork_104015v1
Summary
---
Commit 30e114ef4b16 ("drm/i915/tc: Check for DP-alt, legacy sinks before
taking PHY ownership") defaults any disconnected Type-C ports to TBT-alt
mode which presents a problem (which could most likely result in a system
hang) when userspace forces a modeset on a Type-C port that is wired for
legacy
Although, doing a modeset on any disconnected connector might be futile,
it can be particularly problematic if the connector is a Type-C port
without a sink. And, the spec only says "Display software must not use
a disconnected port" while referring to the Type-C DDI seqeuence, it does
not spell ou
The following two patches try to prevent a system hang when a modeset
is forced by userspace (Weston) on legacy Type-C ports that are
disconnected. This issue was accidentally discovered while trying
to modeset one of the HDMI ports on the TGL based Gigabyte system
(https://www.gigabyte.com/Mini-Pc
== Series Details ==
Series: drm/i915: Update tiled blits selftest
URL : https://patchwork.freedesktop.org/series/104016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11656 -> Patchwork_104016v1
Summary
---
**WARNIN
Hi Nirmoy.
On Fri, 2022-05-13 at 13:37 +0200, Nirmoy Das wrote:
> _i915_vma_move_to_active() can receive > 1 fence for
> multiple batch buffer submission so make sure to
> individualize fences before adding to dma_resv obj
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
> Sign
On Mon, 16 May 2022, Vivek Kasireddy wrote:
> Although, doing a modeset on any disconnected connector might be futile,
> it can be particularly problematic if the connector is a Type-C port
> without a sink. And, the spec only says "Display software must not use
> a disconnected port" while referr
On Mon, May 16, 2022 at 01:54:02AM -0700, Vivek Kasireddy wrote:
> Although, doing a modeset on any disconnected connector might be futile,
> it can be particularly problematic if the connector is a Type-C port
> without a sink. And, the spec only says "Display software must not use
> a disconnecte
== Series Details ==
Series: drm/i915/overlay: remove redundant GEM_BUG_ON()
URL : https://patchwork.freedesktop.org/series/104015/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11656_full -> Patchwork_104015v1_full
Summary
On 5/13/2022 4:54 PM, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915: individualize fences before adding
*URL:* https://patchwork.freedesktop.org/series/103981/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103981v1/in
== Series Details ==
Series: drm/i915: Update tiled blits selftest
URL : https://patchwork.freedesktop.org/series/104016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11656_full -> Patchwork_104016v1_full
Summary
---
+Hans
Hans, do you have any comments?
On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
> In some implementations, such as the Qualcomm platforms, the display
> driver has no way to query the current HPD state and as such it's
> impossible to distinguish between disconnect and atte
== Series Details ==
Series: drm/i915/tc: Prevent system hang when modesetting disconnected Type-C
ports
URL : https://patchwork.freedesktop.org/series/104019/
State : warning
== Summary ==
Error: dim checkpatch failed
578eba87cd3b drm/i915/tc: Don't default disconnected legacy Type-C ports t
> -Original Message-
> From: Dixit, Ashutosh
> Sent: Thursday, May 12, 2022 9:47 AM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use drm_dbg for rpm logging
>
> On Wed, 11 May 2022 06:04:54 -0700, Anshuman Gupta wrote:
> >
>
== Series Details ==
Series: drm/i915/tc: Prevent system hang when modesetting disconnected Type-C
ports
URL : https://patchwork.freedesktop.org/series/104019/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11656 -> Patchwork_104019v1
==
Hi,
On 5/16/22 13:25, Heikki Krogerus wrote:
> +Hans
>
> Hans, do you have any comments?
Thanks for the ping, this looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
>
> On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
>> In some implementations, such as the Qualco
On Mon, May 16, 2022 at 01:54:01AM -0700, Vivek Kasireddy wrote:
> Commit 30e114ef4b16 ("drm/i915/tc: Check for DP-alt, legacy sinks before
> taking PHY ownership") defaults any disconnected Type-C ports to TBT-alt
> mode which presents a problem (which could most likely result in a system
> hang)
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split the DPLL state computation into a separate function
> from the current .get_dplls() which currently serves a dual duty
> by also reserving the shared DPLLs.
>
> v2: s/false/-EINVAL/ (Jani)
>
> Cc: Jani Nikula
> Signed-off-
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we calculate a lot of things (pixel rate, watermarks,
> cdclk) trusting that the DPLL can generate the exact frequency
> we ask it. In practice that is not true and there can be
> certain amount of rounding involved.
>
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The debugs in lower level DPLL code don't really provide any
> useful extra information AFAICS. Better just streamline the
> code and just put the necessary debugs (to identify at which
> step the modeset failed) into the higher
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deduplicate the crtc_ timigns comparisons.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 45
> 1 file changed, 18 insertions(+), 27 dele
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deduplicate the crtc_ timigns comparisons.
*timings
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 45
> 1 file changed, 18 insertions(+), 27 deletions(-)
>
> diff
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deduplicate the drm_rect comparisons.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the state+crtc calling convention for intel_modeset_pipe_config()
> and othere related functions. Many of these need the full atomic state
> anyway so passing it all the way through is just nicer than having to
> worry about
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename some of the 'pipe_config's to the more modern
> 'crtc_state'.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 62 ++--
> 1 file changed,
Hi
The merge window for 5.19 will probably be opening next week, has
there been any progress with this bug?
Thanks
Mike
On Mon, 2 May 2022 at 17:31, Mike Lothian wrote:
>
> On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam
> wrote:
> >
> >
> >
> > On 5/2/2022 8:41 PM, Mike Lothian wrote:
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the "[CRTC:%d:%s]'/etc. format for some of the modeset debugs
> so we know more about what has happened during the modeset state
> computation.
>
> Also tweak the connector bpp debug message a bit to make it less
> confusing.
On Wed, 04 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse
> this during state computation in order to determine the actual final
> dotclcok after the DPLL computation has been done (which may not give
> us the exact same
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull the various iCLKIP parameters into a struct. Later on
> we'll reuse this during the state computation to determine
> the exact dotclock the hardware will be generating for us.
>
> Signed-off-by: Ville Syrjälä
> ---
> drive
On Thu, 05 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull the various iCLKIP parameters into a struct. Later on
> we'll reuse this during the state computation to determine
> the exact dotclock the hardware will be generating for us.
>
> v2: Don't lost the phaseinc calculation
Oh
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Only reassign the pipe's DPLL if it's going through a full
> .compute_config() cycle. If OTOH it's just getting modeset
> eg. in order to change cdclk there doesn't seem much point in
> picking a new DPLL for it.
>
> This should
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later
On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote:
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu99, which allows using var
On 5/16/22 06:31, Greg KH wrote:
On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote:
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, whi
On Mon, May 16, 2022 at 8:40 AM Mike Lothian wrote:
>
> Hi
>
> The merge window for 5.19 will probably be opening next week, has
> there been any progress with this bug?
It took a while to find a combination of GPUs that would repro the
issue, but now that we can, it is still being investigated.
_i915_vma_move_to_active() can receive > 1 fence for
multiple batch buffer submission so make sure to
individualize fences before adding to dma_resv obj
v2: make sure to reserve fence slots before adding.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
Signed-off-by: Nirmoy Das
--
Please ignore this revision. I will send another one tomorrow.
Nirmoy
On 5/16/2022 5:51 PM, Nirmoy Das wrote:
_i915_vma_move_to_active() can receive > 1 fence for
multiple batch buffer submission so make sure to
individualize fences before adding to dma_resv obj
v2: make sure to reserve fence
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
== Series Details ==
Series: drm/i915: individualize fences before adding (rev2)
URL : https://patchwork.freedesktop.org/series/103981/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11660 -> Patchwork_103981v2
Summary
-
== Series Details ==
Series: drm/doc: add rfc section for small BAR uapi (rev2)
URL : https://patchwork.freedesktop.org/series/102875/
State : warning
== Summary ==
Error: dim checkpatch failed
bade7406bc64 drm/doc: add rfc section for small BAR uapi
-:29: WARNING:BAD_SIGN_OFF: Duplicate signa
== Series Details ==
Series: drm/doc: add rfc section for small BAR uapi (rev2)
URL : https://patchwork.freedesktop.org/series/102875/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11660 -> Patchwork_102875v2
Summary
--
On 5/16/22 03:57, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20220513:
>
on i386:
CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘act_freq_mhz_show’:
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:20: error: impli
On 5/6/2022 21:58, Alan Previn wrote:
GuC error capture blurts some debug messages about empty
register lists for certain register types on engines during
firmware initialization.
These are not errors or warnings, so get rid of them.
Signed-off-by: Alan Previn
Reviewed-by: John Harrison
--
DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
messages. By rough count, they are used 5140 times in the kernel.
These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(),
which checks bits in global __drm_debug. Some of these are page-flips
and vblanks, and get c
In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/
Vincent's patch commented on, and worked around, a bug toggling
static_branch's, when a 2nd PRINTK-ish flag was added. The bug
results in a premature static_branch_disable when the 1st of 2 flags
was disabled.
The cited commit comp
print "old -> new" flag values in the info("change") message.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a56c1286ffa4..ca2a28f1d51c 100644
This exported fn is unused, and is effectively obsoleted by a
forthcoming commit, so remove it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But following patches
implement the drm.debug interface, and adapt drm to just use it, so
For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb()
stub-fn is too permissive:
bash-5.1# modprobe drm JUNKdyndbg
bash-5.1# modprobe drm dyndbgJUNK
[ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds
[ 42.937484] ACPI: bus type drm_connector registered
This c
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
We only need 4 bits for drm, and with that reserved, we have 2 to
spare on 32 bit builds; lets take one extra (5 bits total), and keep a
spare bit. 32 classes-p
Add module-to-class validation, in
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", ddebug_validate_classname (called from
ddebug_change) requires that FOO is known to module X, otherwize X is
skipped entirely.
The choice of FOO is highly selective, giving
Add dynamic_debug_register_classes() to API, allowing user modules
(builtin and loadable) to register class_names for the .class_id's
they are using. Knowing classes is 1st step to validating with them.
Add dynamic_debug_unregister_classes() also.
Add struct ddebug_known_classes_map: maps known c
Extend the sysfs-node bitmap support to accept class-names
registered by the module, allowing:
#> echo DRM_UT_CORE,-DRM_UT_ATOMIC,+DRM_UT_KMS \
> /sys/module/drm/parameters/debug
Do this in param_set_dyndbg_class_strings(), which is called from
param_set_dyndbg_classes() when the inpu
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are not used 2x in a query; a thing
cannot be named both foo and bar (not even wildcards, no OR is
contemplated).
Amend the treatment of module; while still enforcing the 2x rule on
it, set the d
The added paragraph is slightly process oriented, rather than in
language of guarantees; I thought the implications were clear enough.
It does perhaps undersell the selectivity gained with string
class_names; only drm/* would sanely register DRM_UT_CORE etc, so
doing multiple "module {drm*,amdgpu,
Add kernel_param_ops and callbacks to implement a bitmap in a
sysfs-node. IE, add these:
- int param_set_dyndbg_classes()
- int param_get_dyndbg_classes()
- struct kernel_param_ops param_ops_dyndbg_classes
Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
non-static and ex
Upgrade single classes-map to list of them:
This allows multiple DYNAMIC_DEBUG_CLASSES(class-map)s per module,
using _base to segment the 0..30 classid space.
alter struct ddebug table:
replace .classes (a &map) with maps (list-head)
dynamic_debug_register_classes(map) - adds new map to maps li
Demonstrate dyndbg's "class FOO" and bitmap-to-classes support. This
support is meant to plug into drm.debug system, and largely replace
the use of drm_debug_enabled(category) with JUMP_LABELs.
Recap:
#> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control
This is made "safe" because dyndbg
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already. But test_dynamic_debug needs it in order to demonstrate all
the moving parts.
Note the __ prefix; its not intended for general use, and doesn't
include any bu
enum drm_debug_category has 10 categories, but is initialized with
bitmasks which require 10 bits of underlying storage. By using
natural enumeration, and moving the BIT(cat) into drm_debug_enabled(),
the enum fits in 4 bits, allowing the category to be represented
directly in pr_debug callsites,
Invoke DYNAMIC_DEBUG_CLASSES from drm_drv.h. This declares a
maybe-unused struct ddebug_known_classes_map var, initialized with:
. var: passed to dynamic_debug_register_classes()
. class-names: "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", etc.
These names map to .class_id's by their index, ie:
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg()
in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
Next, those functions are adapted to accept a descriptor arg, and we
drop the _no_desc suffix, then the (~4000) drm.debug callsites will be
controllable by their
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics, w
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
POC: adapt drm_print to use/test the bitmap callback support.
with dynamic_debug.verbose=1:
bash-5.1# echo 1 > /sys/module/drm/parameters/debug
[ 33.697039] dyndbg: set_dyndbg_classes: new 0x1 current 0x0
[ 33.697571] dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
[ 33.698072] dyndbg: no mat
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT (and define former as latter), in preparation to
add another bit next: _DPRINTK_FLAGS_TRACE
And change JUMP_LABEL code block to use the more general
_DPRINTK_FLAGS_ENABLED symbol. Also add a 'K' to get new symbol
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via dyndbg
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 0a
Add a struct _ddebug ptr to drm_dbg() and drm_dev_dbg() protos, and
upgrade their callers - the interposed macros added recently, to use
_dynamic_func_call_no_desc(); ie drop the '_no_desc', since the
factory macro's callees (these 2 functions) are now expecting the arg.
This makes those functions
clone DRM.debug interface to DRM.tracebits: ie map bits to
drm-debug-categories, except this interface enables messages to
tracefs, not to syslog.
This reuses dyndbg's register-classes API to add the new sysfs-knob:
drm_drv.h:
[A] 2nd use of DYNAMIC_DEBUG_CLASSES(drm_trace_classes), which
declar
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new funcs:
ddebug_printk() - print to both syslog/tracefs
ddebug_dev_printk() - dev-print to
I'm confident that the below regression is not a regression that resulted from
the code change of this series.
The changes i made removes debug messages that are only executed at the GuC-ADS
preparation time
and is never being executed at runtime. Also, the code changes had nothing to
do with po
== Series Details ==
Series: drm/i915: individualize fences before adding (rev2)
URL : https://patchwork.freedesktop.org/series/103981/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11660_full -> Patchwork_103981v2_full
Sum
== Series Details ==
Series: Remove unnecessary GuC err capture noise (rev2)
URL : https://patchwork.freedesktop.org/series/103709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11661 -> Patchwork_103709v2
Summary
---
== Series Details ==
Series: DRM.debug on DYNAMIC_DEBUG, add trace events
URL : https://patchwork.freedesktop.org/series/104052/
State : warning
== Summary ==
Error: dim checkpatch failed
9b925049d3f8 dyndbg: fix static_branch manipulation
7a33c56c8d24 dyndbg: show both old and new in change-i
== Series Details ==
Series: DRM.debug on DYNAMIC_DEBUG, add trace events
URL : https://patchwork.freedesktop.org/series/104052/
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.debug on DYNAMIC_DEBUG, add trace events
URL : https://patchwork.freedesktop.org/series/104052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11661 -> Patchwork_104052v1
Summary
---
*
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb Add linux-next specific
files for 20220516
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com
https
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
54395a33718a ("drm/i915/dmc: Add MMIO range restrictions")
from the drm-intel-fixes tree and commit:
9c67d9e84c7d ("drm/i915/dmc: split out dmc registers to a separate fil
== Series Details ==
Series: linux-next: manual merge of the drm tree with the drm-intel-fixes tree
(rev3)
URL : https://patchwork.freedesktop.org/series/71725/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/71725/revisions/3/mbox/ not
applied
Ap
This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
One key idea of this series is that although we have a fixed ABI to
convey SSEU dat
Xe_HP has enough fundamental differences from previous platforms that it
makes sense to use a separate SSEU init function to keep things
straightforward and easy to understand. We'll also add a has_xehp_dss
flag to the SSEU structure that will be used by other upcoming changes.
v2:
- Add has_xeh
Slice/subslice/EU information should be obtained via the topology
queries provided by the I915_QUERY interface; let's turn off support for
the old GETPARAM lookups on Xe_HP and beyond where we can't return
meaningful values.
The slice mask lookup is meaningless since Xe_HP doesn't support
traditio
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose be
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation that's more natural:
Xe_HP platforms will be
PVC splits the mask of enabled DSS over two registers. It also changes
the meaning of the EU fuse register such that each bit represents a
single EU rather than a pair of EUs.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can simplify the code slightly by
dropping the
== Series Details ==
Series: i915: SSEU handling updates (rev3)
URL : https://patchwork.freedesktop.org/series/103244/
State : warning
== Summary ==
Error: dim checkpatch failed
908d6ce4c18e drm/i915/xehp: Use separate sseu init function
358b3a7e510b drm/i915/xehp: Drop GETPARAM lookups of I91
1 - 100 of 105 matches
Mail list logo
