All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: quic_saipraka@quicinc.com, catalin.marinas@arm.com,
	dri-devel@lists.freedesktop.org, will@kernel.org, maz@kernel.org,
	amd-gfx@lists.freedesktop.org, mingo@redhat.com,
	daniel.vetter@ffwll.ch, arnd@arndb.de,
	linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	rostedt@goodmis.org, jbaron@akamai.com, seanpaul@chromium.org,
	intel-gvt-dev@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org, sean@poorly.run,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	robdclark@gmail.com, quic_psodagud@quicinc.com,
	mathieu.desnoyers@efficios.com
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC
Date: Fri, 12 Nov 2021 12:49:54 +0100	[thread overview]
Message-ID: <20211112114953.GA1381@axis.com> (raw)
In-Reply-To: <20211111220206.121610-9-jim.cromie@gmail.com>

On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> Sean Paul proposed, in:
> https://patchwork.freedesktop.org/series/78133/
> drm/trace: Mirror DRM debug logs to tracefs
> 
> His patchset's objective is to be able to independently steer some of
> the drm.debug stream to an alternate tracing destination, by splitting
> drm_debug_enabled() into syslog & trace flavors, and enabling them
> separately.  2 advantages were identified:
> 
> 1- syslog is heavyweight, tracefs is much lighter
> 2- separate selection of enabled categories means less traffic
> 
> Dynamic-Debug can do 2nd exceedingly well:
> 
> A- all work is behind jump-label's NOOP, zero off cost.
> B- exact site selectivity, precisely the useful traffic.
>    can tailor enabled set interactively, at shell.
> 
> Since the tracefs interface is effective for drm (the threads suggest
> so), adding that interface to dynamic-debug has real potential for
> everyone including drm.
> 
> if CONFIG_TRACING:
> 
> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> available by default to all pr_debugs.  This will likely need some
> further per-module treatment; perhaps something reflecting hierarchy
> of module,file,function,line, maybe with a tuned flattening.
> 
> endif CONFIG_TRACING
> 
> Add a new +T flag to enable tracing, independent of +p, and add and
> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> the flag checks.  Existing code treats T like other flags.

I posted a patchset a while ago to do something very similar, but that
got stalled for some reason and I unfortunately didn't follow it up:

 https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/

A key difference between that patchset and this patch (besides that
small fact that I used +x instead of +T) was that my patchset allowed
the dyndbg trace to be emitted to the main buffer and did not force them
to be in an instance-specific buffer.

That feature is quite important at least for my use case since I often
use dyndbg combined with function tracing, and the latter doesn't work
on non-main instances according to Documentation/trace/ftrace.rst.

For example, here's a random example of a bootargs from one of my recent
debugging sessions:

 trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
 ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"


WARNING: multiple messages have this Message-ID (diff)
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: quic_saipraka@quicinc.com, catalin.marinas@arm.com,
	dri-devel@lists.freedesktop.org, will@kernel.org, maz@kernel.org,
	amd-gfx@lists.freedesktop.org, mingo@redhat.com,
	daniel.vetter@ffwll.ch, arnd@arndb.de,
	linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	rostedt@goodmis.org, jbaron@akamai.com, seanpaul@chromium.org,
	intel-gvt-dev@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, quic_psodagud@quicinc.com,
	mathieu.desnoyers@efficios.com
Subject: Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC
Date: Fri, 12 Nov 2021 12:49:54 +0100	[thread overview]
Message-ID: <20211112114953.GA1381@axis.com> (raw)
In-Reply-To: <20211111220206.121610-9-jim.cromie@gmail.com>

On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> Sean Paul proposed, in:
> https://patchwork.freedesktop.org/series/78133/
> drm/trace: Mirror DRM debug logs to tracefs
> 
> His patchset's objective is to be able to independently steer some of
> the drm.debug stream to an alternate tracing destination, by splitting
> drm_debug_enabled() into syslog & trace flavors, and enabling them
> separately.  2 advantages were identified:
> 
> 1- syslog is heavyweight, tracefs is much lighter
> 2- separate selection of enabled categories means less traffic
> 
> Dynamic-Debug can do 2nd exceedingly well:
> 
> A- all work is behind jump-label's NOOP, zero off cost.
> B- exact site selectivity, precisely the useful traffic.
>    can tailor enabled set interactively, at shell.
> 
> Since the tracefs interface is effective for drm (the threads suggest
> so), adding that interface to dynamic-debug has real potential for
> everyone including drm.
> 
> if CONFIG_TRACING:
> 
> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> available by default to all pr_debugs.  This will likely need some
> further per-module treatment; perhaps something reflecting hierarchy
> of module,file,function,line, maybe with a tuned flattening.
> 
> endif CONFIG_TRACING
> 
> Add a new +T flag to enable tracing, independent of +p, and add and
> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> the flag checks.  Existing code treats T like other flags.

I posted a patchset a while ago to do something very similar, but that
got stalled for some reason and I unfortunately didn't follow it up:

 https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/

A key difference between that patchset and this patch (besides that
small fact that I used +x instead of +T) was that my patchset allowed
the dyndbg trace to be emitted to the main buffer and did not force them
to be in an instance-specific buffer.

That feature is quite important at least for my use case since I often
use dyndbg combined with function tracing, and the latter doesn't work
on non-main instances according to Documentation/trace/ftrace.rst.

For example, here's a random example of a bootargs from one of my recent
debugging sessions:

 trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
 ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"


WARNING: multiple messages have this Message-ID (diff)
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: <jbaron@akamai.com>, <gregkh@linuxfoundation.org>,
	<robdclark@gmail.com>, <sean@poorly.run>,
	<daniel.vetter@ffwll.ch>, <seanpaul@chromium.org>,
	<lyude@redhat.com>, <linux-kernel@vger.kernel.org>,
	<rostedt@goodmis.org>, <mathieu.desnoyers@efficios.com>,
	<dri-devel@lists.freedesktop.org>,
	<amd-gfx@lists.freedesktop.org>,
	<intel-gvt-dev@lists.freedesktop.org>,
	<intel-gfx@lists.freedesktop.org>, <quic_saipraka@quicinc.com>,
	<will@kernel.org>, <catalin.marinas@arm.com>,
	<quic_psodagud@quicinc.com>, <maz@kernel.org>, <arnd@arndb.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>, <mingo@redhat.com>
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC
Date: Fri, 12 Nov 2021 12:49:54 +0100	[thread overview]
Message-ID: <20211112114953.GA1381@axis.com> (raw)
In-Reply-To: <20211111220206.121610-9-jim.cromie@gmail.com>

On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> Sean Paul proposed, in:
> https://patchwork.freedesktop.org/series/78133/
> drm/trace: Mirror DRM debug logs to tracefs
> 
> His patchset's objective is to be able to independently steer some of
> the drm.debug stream to an alternate tracing destination, by splitting
> drm_debug_enabled() into syslog & trace flavors, and enabling them
> separately.  2 advantages were identified:
> 
> 1- syslog is heavyweight, tracefs is much lighter
> 2- separate selection of enabled categories means less traffic
> 
> Dynamic-Debug can do 2nd exceedingly well:
> 
> A- all work is behind jump-label's NOOP, zero off cost.
> B- exact site selectivity, precisely the useful traffic.
>    can tailor enabled set interactively, at shell.
> 
> Since the tracefs interface is effective for drm (the threads suggest
> so), adding that interface to dynamic-debug has real potential for
> everyone including drm.
> 
> if CONFIG_TRACING:
> 
> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> available by default to all pr_debugs.  This will likely need some
> further per-module treatment; perhaps something reflecting hierarchy
> of module,file,function,line, maybe with a tuned flattening.
> 
> endif CONFIG_TRACING
> 
> Add a new +T flag to enable tracing, independent of +p, and add and
> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> the flag checks.  Existing code treats T like other flags.

I posted a patchset a while ago to do something very similar, but that
got stalled for some reason and I unfortunately didn't follow it up:

 https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/

A key difference between that patchset and this patch (besides that
small fact that I used +x instead of +T) was that my patchset allowed
the dyndbg trace to be emitted to the main buffer and did not force them
to be in an instance-specific buffer.

That feature is quite important at least for my use case since I often
use dyndbg combined with function tracing, and the latter doesn't work
on non-main instances according to Documentation/trace/ftrace.rst.

For example, here's a random example of a bootargs from one of my recent
debugging sessions:

 trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
 ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"


WARNING: multiple messages have this Message-ID (diff)
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: <jbaron@akamai.com>, <gregkh@linuxfoundation.org>,
	<robdclark@gmail.com>,  <sean@poorly.run>,
	<daniel.vetter@ffwll.ch>, <seanpaul@chromium.org>,
	<lyude@redhat.com>, <linux-kernel@vger.kernel.org>,
	<rostedt@goodmis.org>, <mathieu.desnoyers@efficios.com>,
	<dri-devel@lists.freedesktop.org>,
	<amd-gfx@lists.freedesktop.org>,
	<intel-gvt-dev@lists.freedesktop.org>,
	<intel-gfx@lists.freedesktop.org>, <quic_saipraka@quicinc.com>,
	<will@kernel.org>, <catalin.marinas@arm.com>,
	<quic_psodagud@quicinc.com>, <maz@kernel.org>, <arnd@arndb.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>, <mingo@redhat.com>
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC
Date: Fri, 12 Nov 2021 12:49:54 +0100	[thread overview]
Message-ID: <20211112114953.GA1381@axis.com> (raw)
In-Reply-To: <20211111220206.121610-9-jim.cromie@gmail.com>

On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> Sean Paul proposed, in:
> https://patchwork.freedesktop.org/series/78133/
> drm/trace: Mirror DRM debug logs to tracefs
> 
> His patchset's objective is to be able to independently steer some of
> the drm.debug stream to an alternate tracing destination, by splitting
> drm_debug_enabled() into syslog & trace flavors, and enabling them
> separately.  2 advantages were identified:
> 
> 1- syslog is heavyweight, tracefs is much lighter
> 2- separate selection of enabled categories means less traffic
> 
> Dynamic-Debug can do 2nd exceedingly well:
> 
> A- all work is behind jump-label's NOOP, zero off cost.
> B- exact site selectivity, precisely the useful traffic.
>    can tailor enabled set interactively, at shell.
> 
> Since the tracefs interface is effective for drm (the threads suggest
> so), adding that interface to dynamic-debug has real potential for
> everyone including drm.
> 
> if CONFIG_TRACING:
> 
> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> available by default to all pr_debugs.  This will likely need some
> further per-module treatment; perhaps something reflecting hierarchy
> of module,file,function,line, maybe with a tuned flattening.
> 
> endif CONFIG_TRACING
> 
> Add a new +T flag to enable tracing, independent of +p, and add and
> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> the flag checks.  Existing code treats T like other flags.

I posted a patchset a while ago to do something very similar, but that
got stalled for some reason and I unfortunately didn't follow it up:

 https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/

A key difference between that patchset and this patch (besides that
small fact that I used +x instead of +T) was that my patchset allowed
the dyndbg trace to be emitted to the main buffer and did not force them
to be in an instance-specific buffer.

That feature is quite important at least for my use case since I often
use dyndbg combined with function tracing, and the latter doesn't work
on non-main instances according to Documentation/trace/ftrace.rst.

For example, here's a random example of a bootargs from one of my recent
debugging sessions:

 trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
 ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: quic_saipraka@quicinc.com, catalin.marinas@arm.com,
	dri-devel@lists.freedesktop.org, will@kernel.org, maz@kernel.org,
	amd-gfx@lists.freedesktop.org, mingo@redhat.com,
	daniel.vetter@ffwll.ch, arnd@arndb.de,
	linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	rostedt@goodmis.org, jbaron@akamai.com, seanpaul@chromium.org,
	intel-gvt-dev@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org, sean@poorly.run,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC
Date: Fri, 12 Nov 2021 12:49:54 +0100	[thread overview]
Message-ID: <20211112114953.GA1381@axis.com> (raw)
In-Reply-To: <20211111220206.121610-9-jim.cromie@gmail.com>

On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> Sean Paul proposed, in:
> https://patchwork.freedesktop.org/series/78133/
> drm/trace: Mirror DRM debug logs to tracefs
> 
> His patchset's objective is to be able to independently steer some of
> the drm.debug stream to an alternate tracing destination, by splitting
> drm_debug_enabled() into syslog & trace flavors, and enabling them
> separately.  2 advantages were identified:
> 
> 1- syslog is heavyweight, tracefs is much lighter
> 2- separate selection of enabled categories means less traffic
> 
> Dynamic-Debug can do 2nd exceedingly well:
> 
> A- all work is behind jump-label's NOOP, zero off cost.
> B- exact site selectivity, precisely the useful traffic.
>    can tailor enabled set interactively, at shell.
> 
> Since the tracefs interface is effective for drm (the threads suggest
> so), adding that interface to dynamic-debug has real potential for
> everyone including drm.
> 
> if CONFIG_TRACING:
> 
> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> available by default to all pr_debugs.  This will likely need some
> further per-module treatment; perhaps something reflecting hierarchy
> of module,file,function,line, maybe with a tuned flattening.
> 
> endif CONFIG_TRACING
> 
> Add a new +T flag to enable tracing, independent of +p, and add and
> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> the flag checks.  Existing code treats T like other flags.

I posted a patchset a while ago to do something very similar, but that
got stalled for some reason and I unfortunately didn't follow it up:

 https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/

A key difference between that patchset and this patch (besides that
small fact that I used +x instead of +T) was that my patchset allowed
the dyndbg trace to be emitted to the main buffer and did not force them
to be in an instance-specific buffer.

That feature is quite important at least for my use case since I often
use dyndbg combined with function tracing, and the latter doesn't work
on non-main instances according to Documentation/trace/ftrace.rst.

For example, here's a random example of a bootargs from one of my recent
debugging sessions:

 trace_event=printk:* ftrace_filter=_mmc*,mmc*,sd*,dw_mci*,mci*
 ftrace=function trace_buf_size=20M dyndbg="file drivers/mmc/* +x"


  reply	other threads:[~2021-11-12 14:21 UTC|newest]

Thread overview: 129+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 22:01 [PATCH v10 00/10 RESEND] use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace Jim Cromie
2021-11-11 22:01 ` Jim Cromie
2021-11-11 22:01 ` Jim Cromie
2021-11-11 22:01 ` [Intel-gfx] " Jim Cromie
2021-11-11 22:01 ` [PATCH v10 01/10] dyndbg: add DEFINE_DYNAMIC_DEBUG_BITGRPS macro and callbacks Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:01 ` [PATCH v10 02/10] drm: fix doc grammar Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:01 ` [PATCH v10 03/10] amdgpu: use dyndbg.BITGRPS to control existing pr_debugs Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` Jim Cromie
2021-11-11 22:01   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 04/10] i915/gvt: trim spaces from pr_debug "gvt: core:" prefixes Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 05/10] i915/gvt: use dyndbg.BITGRPS for existing pr_debugs Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 06/10] drm_print: add choice to use dynamic debug in drm-debug Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 07/10] drm_print: instrument drm_debug_enabled Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-12 11:49   ` Vincent Whitchurch [this message]
2021-11-12 11:49     ` Vincent Whitchurch
2021-11-12 11:49     ` Vincent Whitchurch
2021-11-12 11:49     ` Vincent Whitchurch
2021-11-12 11:49     ` [Intel-gfx] " Vincent Whitchurch
2021-11-12 15:08     ` Jason Baron
2021-11-12 15:08       ` Jason Baron
2021-11-12 15:08       ` Jason Baron
2021-11-12 15:08       ` Jason Baron
2021-11-12 15:08       ` [Intel-gfx] " Jason Baron
2021-11-12 17:07       ` Steven Rostedt
2021-11-12 17:07         ` Steven Rostedt
2021-11-12 17:07         ` Steven Rostedt
2021-11-12 17:07         ` Steven Rostedt
2021-11-12 17:07         ` [Intel-gfx] " Steven Rostedt
2021-11-12 17:32         ` Jason Baron
2021-11-12 17:32           ` Jason Baron
2021-11-12 17:32           ` Jason Baron
2021-11-12 17:32           ` Jason Baron
2021-11-12 17:32           ` [Intel-gfx] " Jason Baron
2021-11-12 17:54           ` Steven Rostedt
2021-11-12 17:54             ` Steven Rostedt
2021-11-12 17:54             ` Steven Rostedt
2021-11-12 17:54             ` Steven Rostedt
2021-11-12 17:54             ` [Intel-gfx] " Steven Rostedt
2021-11-16  8:46       ` Pekka Paalanen
2021-11-16  8:46         ` Pekka Paalanen
2021-11-16  8:46         ` Pekka Paalanen
2021-11-16  8:46         ` [Intel-gfx] " Pekka Paalanen
2021-11-18 14:29         ` Jason Baron
2021-11-18 14:29           ` Jason Baron
2021-11-18 14:29           ` Jason Baron
2021-11-18 14:29           ` [Intel-gfx] " Jason Baron
2021-11-18 15:24           ` Pekka Paalanen
2021-11-18 15:24             ` Pekka Paalanen
2021-11-18 15:24             ` Pekka Paalanen
2021-11-18 15:24             ` [Intel-gfx] " Pekka Paalanen
2021-11-19 16:21             ` Jason Baron
2021-11-19 16:21               ` Jason Baron
2021-11-19 16:21               ` Jason Baron
2021-11-19 16:21               ` [Intel-gfx] " Jason Baron
2021-11-19 22:46               ` jim.cromie
2021-11-19 22:46                 ` jim.cromie
2021-11-19 22:46                 ` jim.cromie
2021-11-19 22:46                 ` jim.cromie
2021-11-19 22:46                 ` [Intel-gfx] " jim.cromie
2021-11-19 22:54                 ` Steven Rostedt
2021-11-19 22:54                   ` Steven Rostedt
2021-11-19 22:54                   ` Steven Rostedt
2021-11-19 22:54                   ` Steven Rostedt
2021-11-19 22:54                   ` [Intel-gfx] " Steven Rostedt
2021-11-25 13:51                 ` Vincent Whitchurch
2021-11-25 13:51                   ` Vincent Whitchurch
2021-11-25 13:51                   ` Vincent Whitchurch
2021-11-25 13:51                   ` Vincent Whitchurch
2021-11-25 13:51                   ` [Intel-gfx] " Vincent Whitchurch
2021-11-22  9:02               ` Pekka Paalanen
2021-11-22  9:02                 ` Pekka Paalanen
2021-11-22  9:02                 ` Pekka Paalanen
2021-11-22  9:02                 ` [Intel-gfx] " Pekka Paalanen
2021-11-22 22:42                 ` jim.cromie
2021-11-22 22:42                   ` jim.cromie
2021-11-22 22:42                   ` jim.cromie
2021-11-22 22:42                   ` [Intel-gfx] " jim.cromie
2021-11-23  8:45                   ` Pekka Paalanen
2021-11-23  8:45                     ` Pekka Paalanen
2021-11-23  8:45                     ` Pekka Paalanen
2021-11-23  8:45                     ` [Intel-gfx] " Pekka Paalanen
2021-11-23  9:32                     ` Simon Ser
2021-11-23  9:32                       ` Simon Ser
2021-11-23  9:32                       ` Simon Ser
2021-11-23  9:32                       ` [Intel-gfx] " Simon Ser
2021-12-08  5:16     ` jim.cromie
2021-12-08  5:16       ` jim.cromie
2021-12-08  5:16       ` jim.cromie
2021-12-08  5:16       ` jim.cromie
2021-12-08  5:16       ` [Intel-gfx] " jim.cromie
2021-12-09 15:09       ` Vincent Whitchurch
2021-12-09 15:09         ` Vincent Whitchurch
2021-12-09 15:09         ` Vincent Whitchurch
2021-12-09 15:09         ` Vincent Whitchurch
2021-12-09 15:09         ` [Intel-gfx] " Vincent Whitchurch
2021-11-11 22:02 ` [PATCH v10 09/10] dyndbg: create DEFINE_DYNAMIC_DEBUG_LOG|TRACE_GROUPS Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:02 ` [PATCH v10 10/10] drm: use DEFINE_DYNAMIC_DEBUG_TRACE_GROUPS in 3 places Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` Jim Cromie
2021-11-11 22:02   ` [Intel-gfx] " Jim Cromie
2021-11-11 22:40 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace (rev3) Patchwork
2021-12-10  7:22 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace (rev4) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-11-05 19:26 [PATCH v10 00/10] use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace Jim Cromie
2021-11-05 19:26 ` [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Jim Cromie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211112114953.GA1381@axis.com \
    --to=vincent.whitchurch@axis.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jbaron@akamai.com \
    --cc=jim.cromie@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=quic_psodagud@quicinc.com \
    --cc=quic_saipraka@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=sean@poorly.run \
    --cc=seanpaul@chromium.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.