RE: [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
Now, this change and changes from patch 51 of this series is taken care as part
of the below series
https://patchwork.freedesktop.org/series/92750/
and merged.
Thanks,
Vandita
> -Original Message-
> From: Jani Nikula
> Sent: Friday, July 2, 2021 1:50 PM
> To: Roper, Matthew D ; intel-
> g...@lists.freedesktop.org
> Cc: Patnana, Venkata Sai ; Srivatsa, Anusha
> ; dri-devel@lists.freedesktop.org; Navare,
> Manasi D ; Kulkarni, Vandita
>
> Subject: Re: [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs
> node for DSC BPP enable
>
> On Thu, 01 Jul 2021, Matt Roper wrote:
> > From: Anusha Srivatsa
> >
> > DSC can be supported per DP connector. This patch creates a per
> > connector debugfs node to expose the Input and Compressed BPP.
> >
> > The same node can be used from userspace to force DSC to a certain
> > BPP.
> >
> > force_dsc_bpp is written through this debugfs node to force DSC BPP to
> > all accepted values
>
> I think this patch needs rework, and it's independent of the rest of the
> series. Please just drop this one and the next.
>
> BR,
> Jani.
>
> >
> > Cc: Vandita Kulkarni
> > Cc: Manasi Navare
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Patnana Venkata Sai
> > Signed-off-by: Matt Roper
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 103 +-
> > .../drm/i915/display/intel_display_types.h| 1 +
> > 2 files changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index af9e58619667..1805d70ea817 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -2389,6 +2389,100 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> > .write = i915_dsc_fec_support_write
> > };
> >
> > +static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct drm_device *dev = connector->dev;
> > + struct drm_crtc *crtc;
> > + struct intel_dp *intel_dp;
> > + struct drm_modeset_acquire_ctx ctx;
> > + struct intel_crtc_state *crtc_state = NULL;
> > + int ret = 0;
> > + bool try_again = false;
> > +
> > + drm_modeset_acquire_init(,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > +
> > + do {
> > + try_again = false;
> > + ret = drm_modeset_lock(
> >mode_config.connection_mutex,
> > + );
> > + if (ret) {
> > + ret = -EINTR;
> > + break;
> > + }
> > + crtc = connector->state->crtc;
> > + if (connector->status != connector_status_connected ||
> !crtc) {
> > + ret = -ENODEV;
> > + break;
> > + }
> > + ret = drm_modeset_lock(>mutex, );
> > + if (ret == -EDEADLK) {
> > + ret = drm_modeset_backoff();
> > + if (!ret) {
> > + try_again = true;
> > + continue;
> > + }
> > + break;
> > + } else if (ret) {
> > + break;
> > + }
> > + intel_dp =
> intel_attached_dp(to_intel_connector(connector));
> > + crtc_state = to_intel_crtc_state(crtc->state);
> > + seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
> > + seq_printf(m, "Compressed_BPP: %d\n",
> > + crtc_state->dsc.compressed_bpp);
> > + } while (try_again);
> > +
> > + drm_modeset_drop_locks();
> > + drm_modeset_acquire_fini();
> > +
> > + return ret;
> > +}
> > +
> > +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + int dsc_bpp = 0;
> > + int ret;
> > + struct drm_connector *connector =
> > + ((struct seq_file *)file->private_data)->private;
> > + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + if (len == 0)
> > + return 0;
> > +
> > + drm_dbg(>drm,
> > + "Copied %zu bytes from user to force BPP\n", len);
> > +
> > + ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
> > +
> > + intel_dp->force_dsc_bpp = dsc_bpp;
> > + if (ret < 0)
> > + return ret;
> > +
> > + *offp += len;
> > + return len;
> > +}
> > +
> > +static int i915_dsc_bpp_support_open(struct inode *inode,
> > + struct file *file)
> > +{
> > + return single_open(file, i915_dsc_bpp_support_show,
> > + inode->i_private);
> > +}
> > +
> >
Re: [PATCH] drm/amd/pm: And destination bounds checking to struct copy
Thanks Kees!
Reviewed-by: Lijo Lazar
Thanks,
Lijo
On 8/20/2021 1:44 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
The "Board Parameters" members of the structs:
struct atom_smc_dpm_info_v4_5
struct atom_smc_dpm_info_v4_6
struct atom_smc_dpm_info_v4_7
struct atom_smc_dpm_info_v4_10
are written to the corresponding members of the corresponding PPTable_t
variables, but they lack destination size bounds checking, which means
the compiler cannot verify at compile time that this is an intended and
safe memcpy().
Since the header files are effectively immutable[1] and a struct_group()
cannot be used, nor a common struct referenced by both sides of the
memcpy() arguments, add a new helper, memcpy_trailing(), to perform the
bounds checking at compile time. Replace the open-coded memcpy()s with
memcpy_trailing() which includes enough context for the bounds checking.
"objdump -d" shows no object code changes.
[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2Fe56aad3c-a06f-da07-f491-a894a570d78f%40amd.comdata=04%7C01%7Clijo.lazar%40amd.com%7Cb0567a0252604c8c84cd08d9634dfe39%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637650008892964983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UikQRh9WCwr8H29bBqZu3iLJt095Es9mIG5mVwPJpC0%3Dreserved=0
Cc: Lijo Lazar
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Hawking Zhang
Cc: Feifei Xu
Cc: Likun Gao
Cc: Jiawei Gu
Cc: Evan Quan
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_Npb8uYvd%2BR4UHgf-w8-cQj3JoODjviJR_Y9w9wqJ71mQ%40mail.gmail.comdata=04%7C01%7Clijo.lazar%40amd.com%7Cb0567a0252604c8c84cd08d9634dfe39%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637650008892964983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LVHdf9C1jx6eIB2BQ%2Bm5q4o5KcRzBWJi7PhNviKzKGM%3Dreserved=0
---
Alex, I dropped your prior Acked-by, since the implementation is very
different. If you're still happy with it, I can add it back. :)
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 25 +++
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 6 ++---
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 8 +++---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 5 ++--
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 96e895d6be35..4605934a4fb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1446,4 +1446,29 @@ static inline int amdgpu_in_reset(struct amdgpu_device
*adev)
{
return atomic_read(>in_gpu_reset);
}
+
+/**
+ * memcpy_trailing - Copy the end of one structure into the middle of another
+ *
+ * @dst: Pointer to destination struct
+ * @first_dst_member: The member name in @dst where the overwrite begins
+ * @last_dst_member: The member name in @dst where the overwrite ends after
+ * @src: Pointer to the source struct
+ * @first_src_member: The member name in @src where the copy begins
+ *
+ */
+#define memcpy_trailing(dst, first_dst_member, last_dst_member,
\
+ src, first_src_member) \
+({\
+ size_t __src_offset = offsetof(typeof(*(src)), first_src_member); \
+ size_t __src_size = sizeof(*(src)) - __src_offset; \
+ size_t __dst_offset = offsetof(typeof(*(dst)), first_dst_member); \
+ size_t __dst_size = offsetofend(typeof(*(dst)), last_dst_member) - \
+ __dst_offset; \
+ BUILD_BUG_ON(__src_size != __dst_size);\
+ __builtin_memcpy((u8 *)(dst) + __dst_offset, \
+(u8 *)(src) + __src_offset, \
+__dst_size); \
+})
+
#endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index 8ab58781ae13..1918e6232319 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -465,10 +465,8 @@ static int arcturus_append_powerplay_table(struct
smu_context *smu)
if ((smc_dpm_table->table_header.format_revision == 4) &&
(smc_dpm_table->table_header.content_revision == 6))
- memcpy(_pptable->MaxVoltageStepGfx,
-
Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs
Kees Cook writes:
> On Fri, Aug 20, 2021 at 05:49:35PM +1000, Michael Ellerman wrote:
>> Kees Cook writes:
>> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> > field bounds checking for memset(), avoid intentionally writing across
>> > neighboring fields.
>> >
>> > Add a struct_group() for the spe registers so that memset() can correctly
>> > reason
>> > about the size:
>> >
>> >In function 'fortify_memset_chk',
>> >inlined from 'restore_user_regs.part.0' at
>> > arch/powerpc/kernel/signal_32.c:539:3:
>> >>> include/linux/fortify-string.h:195:4: error: call to
>> >>> '__write_overflow_field' declared with attribute warning: detected write
>> >>> beyond size of field (1st parameter); maybe use struct_group()?
>> >>> [-Werror=attribute-warning]
>> > 195 |__write_overflow_field();
>> > |^~~~
>> >
>> > Cc: Michael Ellerman
>> > Cc: Benjamin Herrenschmidt
>> > Cc: Paul Mackerras
>> > Cc: Christophe Leroy
>> > Cc: Sudeep Holla
>> > Cc: linuxppc-...@lists.ozlabs.org
>> > Reported-by: kernel test robot
>> > Signed-off-by: Kees Cook
>> > ---
>> > arch/powerpc/include/asm/processor.h | 6 --
>> > arch/powerpc/kernel/signal_32.c | 6 +++---
>> > 2 files changed, 7 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/powerpc/include/asm/processor.h
>> > b/arch/powerpc/include/asm/processor.h
>> > index f348e564f7dd..05dc567cb9a8 100644
>> > --- a/arch/powerpc/include/asm/processor.h
>> > +++ b/arch/powerpc/include/asm/processor.h
>> > @@ -191,8 +191,10 @@ struct thread_struct {
>> >int used_vsr; /* set if process has used VSX */
>> > #endif /* CONFIG_VSX */
>> > #ifdef CONFIG_SPE
>> > - unsigned long evr[32];/* upper 32-bits of SPE regs */
>> > - u64 acc;/* Accumulator */
>> > + struct_group(spe,
>> > + unsigned long evr[32];/* upper 32-bits of SPE regs */
>> > + u64 acc;/* Accumulator */
>> > + );
>> >unsigned long spefscr;/* SPE & eFP status */
>> >unsigned long spefscr_last; /* SPEFSCR value on last prctl
>> > call or trap return */
>> > diff --git a/arch/powerpc/kernel/signal_32.c
>> > b/arch/powerpc/kernel/signal_32.c
>> > index 0608581967f0..77b86caf5c51 100644
>> > --- a/arch/powerpc/kernel/signal_32.c
>> > +++ b/arch/powerpc/kernel/signal_32.c
>> > @@ -532,11 +532,11 @@ static long restore_user_regs(struct pt_regs *regs,
>> >regs_set_return_msr(regs, regs->msr & ~MSR_SPE);
>> >if (msr & MSR_SPE) {
>> >/* restore spe registers from the stack */
>> > - unsafe_copy_from_user(current->thread.evr, >mc_vregs,
>> > -ELF_NEVRREG * sizeof(u32), failed);
>> > + unsafe_copy_from_user(>thread.spe, >mc_vregs,
>> > +sizeof(current->thread.spe), failed);
>>
>> This makes me nervous, because the ABI is that we copy ELF_NEVRREG *
>> sizeof(u32) bytes, not whatever sizeof(current->thread.spe) happens to
>> be.
>>
>> ie. if we use sizeof an inadvertent change to the fields in
>> thread_struct could change how many bytes we copy out to userspace,
>> which would be an ABI break.
>>
>> And that's not that hard to do, because it's not at all obvious that the
>> size and layout of fields in thread_struct affects the user ABI.
>>
>> At the same time we don't want to copy the right number of bytes but
>> the wrong content, so from that point of view using sizeof is good :)
>>
>> The way we handle it in ptrace is to have BUILD_BUG_ON()s to verify that
>> things match up, so maybe we should do that here too.
>>
>> ie. add:
>>
>> BUILD_BUG_ON(sizeof(current->thread.spe) == ELF_NEVRREG * sizeof(u32));
>>
>> Not sure if you are happy doing that as part of this patch. I can always
>> do it later if not.
>
> Sounds good to me; I did that in a few other cases in the series where
> the relationships between things seemed tenuous. :) I'll add this (as
> !=) in v3.
Thanks.
cheers
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
between commit:
71ac6f390f6a ("drm/mediatek: Add AAL output size configuration")
from Linus' tree and commit:
78d1783c3243 ("drm/mediatek: Separate aal sub driver")
from the drm tree.
I fixed it up (I added the following merge resolution patch after
using the latter version of the above file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
From: Stephen Rothwell
Date: Mon, 23 Aug 2021 12:37:29 +1000
Subject: [PATCH] drm/mediatek: merge fix for "Add AAL output size
configuration"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 64b45284766a..a6760761088b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -18,7 +18,7 @@
#define DISP_AAL_EN0x
#define AAL_EN BIT(0)
#define DISP_AAL_SIZE 0x0030
-
+#define DISP_AAL_OUTPUT_SIZE 0x04d8
struct mtk_disp_aal_data {
bool has_gamma;
@@ -57,6 +57,7 @@ void mtk_aal_config(struct device *dev, unsigned int w,
struct mtk_disp_aal *aal = dev_get_drvdata(dev);
mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, aal->regs,
DISP_AAL_SIZE);
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, priv->regs,
DISP_AAL_OUTPUT_SIZE);
}
void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
--
2.32.0
--
Cheers,
Stephen Rothwell
pgppMwES77RZQ.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/lima: Remove unused lima_vm_print()
This function is kept for debug usage.
On Fri, Aug 20, 2021 at 10:19 AM Cai Huoqing wrote:
>
> lima_vm_print() isn't used, so remove it
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/lima/lima_vm.c | 29 -
> drivers/gpu/drm/lima/lima_vm.h | 1 -
> 2 files changed, 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_vm.c b/drivers/gpu/drm/lima/lima_vm.c
> index 2b2739adc7f5..b3426c5c987f 100644
> --- a/drivers/gpu/drm/lima/lima_vm.c
> +++ b/drivers/gpu/drm/lima/lima_vm.c
> @@ -251,35 +251,6 @@ void lima_vm_release(struct kref *kref)
> kfree(vm);
> }
>
> -void lima_vm_print(struct lima_vm *vm)
> -{
> - int i, j, k;
> - u32 *pd, *pt;
> -
> - if (!vm->pd.cpu)
> - return;
> -
> - pd = vm->pd.cpu;
> - for (i = 0; i < LIMA_VM_NUM_BT; i++) {
> - if (!vm->bts[i].cpu)
> - continue;
> -
> - pt = vm->bts[i].cpu;
> - for (j = 0; j < LIMA_VM_NUM_PT_PER_BT; j++) {
> - int idx = (i << LIMA_VM_NUM_PT_PER_BT_SHIFT) + j;
> -
> - printk(KERN_INFO "lima vm pd %03x:%08x\n", idx,
> pd[idx]);
> -
> - for (k = 0; k < LIMA_PAGE_ENT_NUM; k++) {
> - u32 pte = *pt++;
> -
> - if (pte)
> - printk(KERN_INFO " pt %03x:%08x\n",
> k, pte);
> - }
> - }
> - }
> -}
> -
> int lima_vm_map_bo(struct lima_vm *vm, struct lima_bo *bo, int pageoff)
> {
> struct lima_bo_va *bo_va;
> diff --git a/drivers/gpu/drm/lima/lima_vm.h b/drivers/gpu/drm/lima/lima_vm.h
> index 3a7c74822d8b..291ec9a0a1c4 100644
> --- a/drivers/gpu/drm/lima/lima_vm.h
> +++ b/drivers/gpu/drm/lima/lima_vm.h
> @@ -58,7 +58,6 @@ static inline void lima_vm_put(struct lima_vm *vm)
> kref_put(>refcount, lima_vm_release);
> }
>
> -void lima_vm_print(struct lima_vm *vm);
> int lima_vm_map_bo(struct lima_vm *vm, struct lima_bo *bo, int pageoff);
>
> #endif
> --
> 2.25.1
>
[PATCH v6 11/11] dyndbg: RFC add print-once and print-ratelimited features. RFC.
Its tautological that having pr_debug()s with optional print-once and
rate-limiting features could be useful. Build it, they will come.
The advantages:
- dynamically configured with flags
- can use them on existing callsites
- printonce is easy, (almost) just new flags
no additional resources
- ratelimiting is pooled, expecting rare use
provisioned only for enabled & ratelimited callsites
- RFC ratelimit grouping
mostly to reduce resources
reduces to choice of hash key: module, function, file, line
Whats done here:
Expand ddebug.flags to 11 bits, and define new flags to support
print-once and ratelimited semantics:
echo file init/main.c +o > control# init/main runs just once anyway
echo module foo +r > control # turn on ratelimiting
echo module foo +g > control # turn on group flag
is_onced_or_ratelimited() tests these conditions, it is called from
__dynamic_pr_debug() and others (which are all behind the '+p'
enablement test).
NB: test_dynamic_debug.ko ratelimiting test triggers reports on
is_onced_or_ratelimited() as the limited source.
PRINT-ONCE: can be done with just +2 bits in flags;
.o _DPRINTK_FLAGS_ONCE enables state test and set
.P _DPRINTK_FLAGS_PRINTED state bit
Just adding the flags lets the existing code operate on them.
We will need new code to enforce constraints on flag combos;
'+ro' is nonsense, but this can wait, or can take a new meaning.
RATE-LIMITING:
.r _DPRINTK_FLAGS_RATELIMITED - track & limit prdbgs callrate
We wait until a prdebug is called, and if RATELIMITED is set, THEN
lookup a RateLimitState (RL) for it. If found, bump its state and
return true/false, otherwise create & initialize one and return false.
RFC: GROUP-FLAG:
.g _DPRINTK_FLAGS_GROUPED
Currently, the hash-key is just the prdebug descriptor, so is unique
per prdebug. With the 'g' flag, we could use a different key, for
example desc->site.function, to get a shared ratelimit for whole
functions.
This gets subtly different behavior at the ratelimit transition, but
it is predictable for a given function (except perhaps recursive, but
thats not done anyway).
Note also that any function can have a single group of prdebugs, plus
any number of prdbgs without 'g', either with or without 'r'. So
grouping should be flexible enough to use advantageously.
Signed-off-by: Jim Cromie
---
v6: new to patchset
---
include/linux/dynamic_debug.h | 19 --
lib/dynamic_debug.c | 125 +-
2 files changed, 137 insertions(+), 7 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8807367c7903..e9871557cff1 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -28,26 +28,33 @@ struct _ddebug {
* writes commands to /dynamic_debug/control
*/
#define _DPRINTK_FLAGS_NONE0
-#define _DPRINTK_FLAGS_PRINT (1<<0) /* printk() a message */
+#define _DPRINTK_FLAGS_PRINT (1<<4) /* printk() a message */
#define _DPRINTK_FLAGS_PRINT_TRACE (1<<5) /* call (*tracer) */
#define _DPRINTK_ENABLED (_DPRINTK_FLAGS_PRINT | _DPRINTK_FLAGS_PRINT_TRACE)
-#define _DPRINTK_FLAGS_INCL_MODNAME(1<<1)
-#define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<2)
-#define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
-#define _DPRINTK_FLAGS_INCL_TID(1<<4)
+#define _DPRINTK_FLAGS_INCL_MODNAME(1<<0)
+#define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<1)
+#define _DPRINTK_FLAGS_INCL_LINENO (1<<2)
+#define _DPRINTK_FLAGS_INCL_TID(1<<3)
#define _DPRINTK_FLAGS_INCL_ANY\
(_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID)
+#define _DPRINTK_FLAGS_ONCE(1<<6) /* print once flag */
+#define _DPRINTK_FLAGS_PRINTED (1<<7) /* print once state */
+#define _DPRINTK_FLAGS_RATELIMITED (1<<8)
+#define _DPRINTK_FLAGS_GROUPED (1<<9) /* manipulate as a group */
+#define _DPRINTK_FLAGS_DELETE_SITE (1<<10) /* drop site info to save ram */
+
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
#define _DPRINTK_FLAGS_DEFAULT 0
#endif
- unsigned int flags:8;
+ unsigned int flags:11;
+
#ifdef CONFIG_JUMP_LABEL
union {
struct static_key_true dd_key_true;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 60bf2c01db1a..16e4db04082b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -83,13 +83,19 @@ static inline const char *trim_prefix(const char *path)
return path + skip;
}
-static struct { unsigned flag:8; char opt_char; } opt_array[] = {
+static struct { unsigned flag:12; char opt_char; } opt_array[] = {
{ _DPRINTK_FLAGS_PRINT, 'p' },
{ _DPRINTK_FLAGS_PRINT_TRACE, 'T' },
{ _DPRINTK_FLAGS_INCL_MODNAME, 'm' },
{ _DPRINTK_FLAGS_INCL_FUNCNAME, 'f' },
{ _DPRINTK_FLAGS_INCL_LINENO, 'l' },
[PATCH v6 09/11] nouveau: fold multiple DRM_DEBUG_DRIVERs together
With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes.
We can combine 12 into one here and save ~620 bytes.
Signed-off-by: Jim Cromie
---
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +--
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index a616cf4573b8..58693e40b447 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1246,19 +1246,29 @@ nouveau_drm_pci_table[] = {
static void nouveau_display_options(void)
{
- DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n");
-
- DRM_DEBUG_DRIVER("... tv_disable : %d\n", nouveau_tv_disable);
- DRM_DEBUG_DRIVER("... ignorelid: %d\n", nouveau_ignorelid);
- DRM_DEBUG_DRIVER("... duallink : %d\n", nouveau_duallink);
- DRM_DEBUG_DRIVER("... nofbaccel: %d\n", nouveau_nofbaccel);
- DRM_DEBUG_DRIVER("... config : %s\n", nouveau_config);
- DRM_DEBUG_DRIVER("... debug: %s\n", nouveau_debug);
- DRM_DEBUG_DRIVER("... noaccel : %d\n", nouveau_noaccel);
- DRM_DEBUG_DRIVER("... modeset : %d\n", nouveau_modeset);
- DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
- DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
- DRM_DEBUG_DRIVER("... hdmimhz : %d\n", nouveau_hdmimhz);
+ DRM_DEBUG_DRIVER("Loading Nouveau with parameters:\n"
+"... tv_disable : %d\n"
+"... ignorelid: %d\n"
+"... duallink : %d\n"
+"... nofbaccel: %d\n"
+"... config : %s\n"
+"... debug: %s\n"
+"... noaccel : %d\n"
+"... modeset : %d\n"
+"... runpm: %d\n"
+"... vram_pushbuf : %d\n"
+"... hdmimhz : %d\n"
+, nouveau_tv_disable
+, nouveau_ignorelid
+, nouveau_duallink
+, nouveau_nofbaccel
+, nouveau_config
+, nouveau_debug
+, nouveau_noaccel
+, nouveau_modeset
+, nouveau_runtime_pm
+, nouveau_vram_pushbuf
+, nouveau_hdmimhz);
}
static const struct dev_pm_ops nouveau_pm_ops = {
--
2.31.1
[PATCH v6 10/11] dyndbg: RFC add debug-trace callback, selftest with it. RFC
Sean Paul seanp...@chromium.org proposed, in https://patchwork.freedesktop.org/series/78133/ drm/trace: Mirror DRM debug logs to tracefs That patchset's objective is to be able to independently steer some of the debug stream to an alternate tracing destination, by splitting drm_debug_enabled() into syslog & trace flavors, and enabling them separately with a drm.debug_trace knob. 2 advantages are identified: - syslog is heavyweight, alternate stream is lighter - steering selected categories separately means less traffic Dynamic-Debug can do this better: 1- all work is behind jump-label's NOOP, Zero overhead when off. 2- perfect site selectivity, no unwanted traffic. drm's debug categories are a general classification system, not one tailored to pick out the exact pool of pr_debugs to watch/trace. With drm.debug built on dyndbg, the given "drm::" system can be used to select a base trace-set, which can then be adjusted +/-, and/or augmented with unrelated pr_debugs that just happen to be useful. And this tweaking can be done at the command-line, and reduced to a script. Then the string-prefix "drm::" system can be extended to suit. The basic elements: - add a new struct _ddebug member: (*tracer)(char *format, ...) - add a new T flag to enable tracer - adjust the static-key-enable/disable condition for (p|T) - if (p) before printk, since T enables too. - if (T) call tracer if its true = int dynamic_debug_register_tracer(query, modname, tracer); = int dynamic_debug_unregister_tracer(query, modname, cookie); This new interface lets clients set/unset a tracer function on each callsite matching the query, for example: "drm:atomic:fail:". Clients must unregister the same callsites they register, allowing protection of each client's dyndbg-state setup against overwrites by others, while allowing maximal sharing of 1 slot/callsite. The internal call-chain gets some rework: it gets new void* tracer param, which dynamic_debug_exec_queries() hides from public. And convert ddebug_exec_queries() to wrap __ddebug_exec_queries(), and move the query copy code to it. public: passing down: dynamic_debug_(un)register_tracer tracer dynamic_debug_exec_queriestracer=NULL calling: ddebug_exec_queries copies ro-query, tracer __ddebug_exec_queries modifies query, tracer ddebug_exec_query modifies query, tracer Then adjust most ddebug_exec_queries users to __ddebug_exec_queries Intended Behavior: (things are in flux, RFC) - register sets empty slot, doesn't overwrite the query selects callsites, and sets +T (grammar requires +-action) - register allows same-tracer over-set wo warn 2nd register can then enable superset, subset, disjoint set - unregister clears slot if it matches cookie/tracer query selects set, -T (as tested) tolerates over-clears - dd-exec-queries(+/-T) can modify the enablements not sure its needed, but it falls out.. The code is currently in-line in ddebug_change(), to be moved to separate fn, rc determines flow, may also veto/alter changes by altering flag-settings - tbd. TBD: Im not sure what happens when exec-queries(+T) hits a site wo a tracer (silence I think. maybe not ideal). SELFTEST: test_dynamic_debug.ko: Uses the tracer facility to implement a selftest: - DUT(x) calls a set of categorized pr_debugs x times - A custom tracer counts the number of calls (of T-enabled pr_debugs), - test registers the tracer on the function, then iteratively: manipulates dyndbg states via query-cmds calls DUT(x) counts enabled callsite executions reports mismatches - modprobe test_dynamic_debug broken_tracer=1 attaches a broken tracer: recursive on pr_debug Bad Things Happen. has thrown me interesting panics. This needs more work. RFC. waste of time due to use_bad_tracer properties ? NOTES: Next step: replace tracer member with a hashtable lookup, done only when T. Registration then becomes populating the hashtable; mod->name would make a good key, which would limit tracer mapping granularity to 1 registrant per module, but not enablement, which is still the per-callsite bit. ERRORS (or WARNINGS): It should be an error to +T a callsite which has no aux_print set (ie already registered with a query that selected that callsite). This tacitly enforces registration. Then +T,-T can toggle those aux_print callsites (or subsets of them) to tailor the debug-stream for the purpose. Controlling flow is the best work limiter. Signed-off-by: Jim Cromie --- v5: (this patch sent after (on top of) v4) . fix "too many arguments to function", and name the args: int (*aux_print)(const char *fmt, char *prefix, char *label, void *); prefix : is a slot for dynamic_emit_prefix, or for custom buffer insert label : for builtin-caller used by drm-trace-print void* : vaf, add type constraint later. . fix printk (to syslog) needs if (+p), since +T
[PATCH v6 07/11] drm_print: instrument drm_debug_enabled
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that its
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabled() itself.
This gives us unique callsite info for the 8 remaining users of
drm_debug_enabled(), and lets us enable them individually to see how
much logging traffic they generate. The oft-visited callsites can
then be reviewed for runtime cost and possible optimizations.
Heres what we get:
bash-5.1# modprobe drm
dyndbg: 384 debug prints in module drm
bash-5.1# grep todo: /proc/dynamic_debug/control
drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid
via dyndbg\012"
drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via
dyndbg\012"
drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via
dyndbg\012"
drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:787
[drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo:
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo:
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via
dyndbg\012"
At quick glance, edid won't qualify, drm_print might, drm_vblank is
strongest chance, maybe atomic-ioctl too.
Signed-off-by: Jim Cromie
---
---
include/drm/drm_print.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 8775b67ecb30..1f8a65eb5d9a 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -378,6 +378,11 @@ enum drm_debug_category {
#define DRM_DBG_CAT_DP DRM_UT_DP
#define DRM_DBG_CAT_DRMRES DRM_UT_DRMRES
+static inline bool drm_debug_enabled(enum drm_debug_category category)
+{
+ return unlikely(__drm_debug & category);
+}
+
#else /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
/* join prefix+format in cpp so dyndbg can see it */
@@ -397,12 +402,13 @@ enum drm_debug_category {
#define DRM_DBG_CAT_DP "drm:dp: "
#define DRM_DBG_CAT_DRMRES "drm:res: " /* not in MODULE_PARM_DESC */
-#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
+#define drm_debug_enabled(category)\
+ ({ \
+ pr_debug("todo: maybe avoid via dyndbg\n"); \
+ unlikely(__drm_debug & category); \
+ })
-static inline bool drm_debug_enabled(enum drm_debug_category category)
-{
- return unlikely(__drm_debug & category);
-}
+#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
/*
* struct device based logging
--
2.31.1
[PATCH v6 08/11] amdgpu_ucode: reduce number of pr_debug calls
There are blocks of DRM_DEBUG calls, consolidate their args into
single calls. With dynamic-debug in use, each callsite consumes 56
bytes of ro callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.
no functional changes.
RFC: this creates multi-line log messages, does that break any syslog
conventions ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 --
1 file changed, 158 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 2834981f8c08..14a9fef1f4c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -30,17 +30,26 @@
static void amdgpu_ucode_print_common_hdr(const struct common_firmware_header
*hdr)
{
- DRM_DEBUG("size_bytes: %u\n", le32_to_cpu(hdr->size_bytes));
- DRM_DEBUG("header_size_bytes: %u\n",
le32_to_cpu(hdr->header_size_bytes));
- DRM_DEBUG("header_version_major: %u\n",
le16_to_cpu(hdr->header_version_major));
- DRM_DEBUG("header_version_minor: %u\n",
le16_to_cpu(hdr->header_version_minor));
- DRM_DEBUG("ip_version_major: %u\n", le16_to_cpu(hdr->ip_version_major));
- DRM_DEBUG("ip_version_minor: %u\n", le16_to_cpu(hdr->ip_version_minor));
- DRM_DEBUG("ucode_version: 0x%08x\n", le32_to_cpu(hdr->ucode_version));
- DRM_DEBUG("ucode_size_bytes: %u\n", le32_to_cpu(hdr->ucode_size_bytes));
- DRM_DEBUG("ucode_array_offset_bytes: %u\n",
- le32_to_cpu(hdr->ucode_array_offset_bytes));
- DRM_DEBUG("crc32: 0x%08x\n", le32_to_cpu(hdr->crc32));
+ DRM_DEBUG("size_bytes: %u\n"
+ "header_size_bytes: %u\n"
+ "header_version_major: %u\n"
+ "header_version_minor: %u\n"
+ "ip_version_major: %u\n"
+ "ip_version_minor: %u\n"
+ "ucode_version: 0x%08x\n"
+ "ucode_size_bytes: %u\n"
+ "ucode_array_offset_bytes: %u\n"
+ "crc32: 0x%08x\n",
+ le32_to_cpu(hdr->size_bytes),
+ le32_to_cpu(hdr->header_size_bytes),
+ le16_to_cpu(hdr->header_version_major),
+ le16_to_cpu(hdr->header_version_minor),
+ le16_to_cpu(hdr->ip_version_major),
+ le16_to_cpu(hdr->ip_version_minor),
+ le32_to_cpu(hdr->ucode_version),
+ le32_to_cpu(hdr->ucode_size_bytes),
+ le32_to_cpu(hdr->ucode_array_offset_bytes),
+ le32_to_cpu(hdr->crc32));
}
void amdgpu_ucode_print_mc_hdr(const struct common_firmware_header *hdr)
@@ -55,9 +64,9 @@ void amdgpu_ucode_print_mc_hdr(const struct
common_firmware_header *hdr)
const struct mc_firmware_header_v1_0 *mc_hdr =
container_of(hdr, struct mc_firmware_header_v1_0,
header);
- DRM_DEBUG("io_debug_size_bytes: %u\n",
- le32_to_cpu(mc_hdr->io_debug_size_bytes));
- DRM_DEBUG("io_debug_array_offset_bytes: %u\n",
+ DRM_DEBUG("io_debug_size_bytes: %u\n"
+ "io_debug_array_offset_bytes: %u\n",
+ le32_to_cpu(mc_hdr->io_debug_size_bytes),
le32_to_cpu(mc_hdr->io_debug_array_offset_bytes));
} else {
DRM_ERROR("Unknown MC ucode version: %u.%u\n", version_major,
version_minor);
@@ -82,13 +91,17 @@ void amdgpu_ucode_print_smc_hdr(const struct
common_firmware_header *hdr)
switch (version_minor) {
case 0:
v2_0_hdr = container_of(hdr, struct
smc_firmware_header_v2_0, v1_0.header);
- DRM_DEBUG("ppt_offset_bytes: %u\n",
le32_to_cpu(v2_0_hdr->ppt_offset_bytes));
- DRM_DEBUG("ppt_size_bytes: %u\n",
le32_to_cpu(v2_0_hdr->ppt_size_bytes));
+ DRM_DEBUG("ppt_offset_bytes: %u\n"
+ "ppt_size_bytes: %u\n",
+ le32_to_cpu(v2_0_hdr->ppt_offset_bytes),
+ le32_to_cpu(v2_0_hdr->ppt_size_bytes));
break;
case 1:
v2_1_hdr = container_of(hdr, struct
smc_firmware_header_v2_1, v1_0.header);
- DRM_DEBUG("pptable_count: %u\n",
le32_to_cpu(v2_1_hdr->pptable_count));
- DRM_DEBUG("pptable_entry_offset: %u\n",
le32_to_cpu(v2_1_hdr->pptable_entry_offset));
+ DRM_DEBUG("pptable_count: %u\n"
+ "pptable_entry_offset: %u\n",
+ le32_to_cpu(v2_1_hdr->pptable_count),
+ le32_to_cpu(v2_1_hdr->pptable_entry_offset));
break;
default:
break;
@@ -111,10 +124,12 @@
[PATCH v6 06/11] drm_print: add choice to use dynamic debug in drm-debug
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEBUG*(8 names),
DRM_DEV_DEBUG*(3 names). There are thousands of these callsites, each
categorized by their authors.
These callsites can be enabled at runtime by their category, each
controlled by a bit in drm.debug (/sys/modules/drm/parameter/debug).
In the current "basic" implementation, drm_debug_enabled() tests these
bits in __drm_debug each time an API[1] call is executed; while cheap
individually, the costs accumulate.
This patch uses dynamic-debug with jump-label to patch enabled calls
onto their respective NOOP slots, avoiding all runtime bit-checks of
__drm_debug.
Dynamic debug has no concept of category, but we can emulate one by
replacing enum categories with a set of prefix-strings; "drm:core:",
"drm:kms:" "drm:driver:" etc, and prepend them (at compile time) to
the given formats.
Then we can use:
`echo module drm format "^drm:core: " +p > control`
to enable the whole category with one query.
This conversion yields ~2100 new callsites on my i7/i915 laptop:
dyndbg: 195 debug prints in module drm_kms_helper
dyndbg: 298 debug prints in module drm
dyndbg: 1630 debug prints in module i915
CONFIG_DRM_USE_DYNAMIC_DEBUG enables this, and is available if
CONFIG_DYNAMIC_DEBUG or CONFIG_DYNAMIC_DEBUG_CORE is chosen, and if
CONFIG_JUMP_LABEL is enabled; this because its required to get the
promised optimizations.
The "basic" -> "dyndbg" switchover is layered into the macro scheme
A. use DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug, __drm_debug,
"DRM debug category-per-bit control",
{ "drm:core:", "enable CORE debug messages" },
{ "drm:kms:", "enable KMS debug messages" }, ...);
B. A "classy" version of DRM_UT_ map, named DRM_DBG_CAT_
DRM_DBG_CLASS_ was proposed, I had agreed, but reconsidered;
CATEGORY is already DRM's term-of-art, and adding a near-synonym
'CLASS' only adds ambiguity.
"basic": DRM_DBG_CAT_ <=== DRM_UT_. Identity map.
"dyndbg":
#define DRM_DBG_CAT_KMS"drm:kms: "
#define DRM_DBG_CAT_PRIME "drm:prime: "
#define DRM_DBG_CAT_ATOMIC "drm:atomic: "
DRM_UT_* are preserved, since theyre used elsewhere.
We can probably reduce its use further, but thats a separate thing.
C. drm_dev_dbg() & drm_debug() are interposed with macros
basic: forward to renamed fn, with args preserved
enabled: redirect to pr_debug, dev_dbg, with CATEGORY # format
this is where drm_debug_enabled() is avoided.
prefix is prepended at compile-time, no category at runtime.
D. API[1] uses DRM_DBG_CAT_s
these already use (C), now they use (B) too,
to get the correct token type for "basic" and "dyndbg" configs.
NOTES:
Because the dyndbg callback is watching __drm_debug, it is coherent
with drm_debug_enabled(), the switchover should be transparent.
Code Review is expected to catch lack of correspondence between
bit=>prefix definitions (the selector) and the prefixes used in the
API[1] layer above pr_debug()
I've coded the search-prefixes/categories with a trailing space, which
excludes any sub-categories added later. This convention protects any
"drm:atomic:fail:" callsites from getting stomped on by `echo 0 > debug`.
Other categories could differ, but we need some default.
Dyndbg requires that the prefix be in the compiled-in format string;
run-time prefixing evades callsite selection by category.
pr_debug("%s: ...", __func__, ...) // not ideal
With "lineno X" in a query, its possible to enable single callsites,
but it is tedious, and useless in a category context.
Unfortunately __func__ is not a macro, and cannot be catenated at
preprocess/compile time.
Signed-off-by: Jim Cromie
---
v6:
. add kernel doc
. fix cpp paste, drop '#'
v5:
. use DEFINE_DYNAMIC_DEBUG_CATEGORIES in drm_print.c
. s/DRM_DBG_CLASS_/DRM_DBG_CAT_/ - dont need another term
. default=y in KBuild entry - per @DanVet
. move some commit-log prose to dyndbg commit
. add-prototyes to (param_get/set)_dyndbg
. more wrinkles found by
. relocate ratelimit chunk from elsewhere
---
drivers/gpu/drm/Kconfig | 13
drivers/gpu/drm/drm_print.c | 49 +
include/drm/drm_print.h | 142
3 files changed, 160 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7ff89690a976..97e38d86fd27 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -57,6 +57,19 @@ config DRM_DEBUG_MM
If in doubt, say "N".
+config DRM_USE_DYNAMIC_DEBUG
+ bool "use dynamic debug to implement drm.debug"
+ default y
+ depends on DRM
+ depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
+ depends on JUMP_LABEL
+ help
+ The "basic" drm.debug facility does a lot of unlikely
+ bit-field tests at runtime; while cheap individually, the
+ cost
[PATCH v6 04/11] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories
The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM. Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
{ "gvt:cmd: ", "command processing" },
{ "gvt:core: ", "core help" },
{ "gvt:dpy: ", "display help" },
{ "gvt:el: ", "help" },
{ "gvt:irq: ", "help" },
{ "gvt:mm: ", "help" },
{ "gvt:mmio: ", "help" },
{ "gvt:render: ", "help" },
{ "gvt:sched: " "help" });
The actual patch has a few details different, cmd_help() macro emits
the initialization construct.
if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
cflags, by gvt/Makefile.
Signed-off-by: Jim Cromie
---
v4+:
. static decl of vector of bit->class descriptors - Emil.V
. relocate gvt-makefile chunk from elsewhere
---
drivers/gpu/drm/i915/gvt/Makefile | 4
drivers/gpu/drm/i915/i915_params.c | 35 ++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..846ba73b8de6 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -7,3 +7,7 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
+
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+ccflags-y += -DDYNAMIC_DEBUG_MODULE
+#endif
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index e07f4cfea63a..683e942a074e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)
I915_PARAMS_FOR_EACH(FREE);
#undef FREE
}
+
+#ifdef DRM_USE_DYNAMIC_DEBUG
+/* todo: needs DYNAMIC_DEBUG_MODULE in some cases */
+
+unsigned long __gvt_debug;
+EXPORT_SYMBOL(__gvt_debug);
+
+#define _help(key) "\t\"" key "\"\t: help for " key "\n"
+
+#define I915_GVT_CATEGORIES(name) \
+ " Enable debug output via /sys/module/i915/parameters/" #name \
+ ", where each bit enables a debug category.\n" \
+ _help("gvt:cmd:") \
+ _help("gvt:core:") \
+ _help("gvt:dpy:") \
+ _help("gvt:el:")\
+ _help("gvt:irq:") \
+ _help("gvt:mm:")\
+ _help("gvt:mmio:") \
+ _help("gvt:render:")\
+ _help("gvt:sched:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
+ I915_GVT_CATEGORIES(debug_gvt),
+ _DD_cat_("gvt:cmd:"),
+ _DD_cat_("gvt:core:"),
+ _DD_cat_("gvt:dpy:"),
+ _DD_cat_("gvt:el:"),
+ _DD_cat_("gvt:irq:"),
+ _DD_cat_("gvt:mm:"),
+ _DD_cat_("gvt:mmio:"),
+ _DD_cat_("gvt:render:"),
+ _DD_cat_("gvt:sched:"));
+
+#endif
--
2.31.1
[PATCH v6 05/11] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to control categorized pr_debugs
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these use DRM debug API, so are controllable using drm.debug,
but others use bare pr_debug("$prefix: .."), each with a different
class-prefix matching "^\[\w+\]:"
Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a /sys debug_dc
parameter, modinfos, and to specify a map from bits -> categorized
pr_debugs to be controlled.
Signed-off-by: Jim Cromie
---
.../gpu/drm/amd/display/dc/core/dc_debug.c| 44 ++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
index 21be2a684393..69e68d721512 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
@@ -36,8 +36,50 @@
#include "resource.h"
-#define DC_LOGGER_INIT(logger)
+#ifdef DRM_USE_DYNAMIC_DEBUG
+/* define a drm.debug style dyndbg pr-debug control point */
+#include
+
+unsigned long __debug_dc;
+EXPORT_SYMBOL(__debug_dc);
+
+#define _help_(key)"\t " key "\t- help for " key "\n"
+
+/* Id like to do these inside DEFINE_DYNAMIC_DEBUG_CATEGORIES, if possible */
+#define DC_DYNDBG_BITMAP_DESC(name)\
+ "Control pr_debugs via /sys/module/amdgpu/parameters/" #name\
+ ", where each bit controls a debug category.\n" \
+ _help_("[SURFACE]:")\
+ _help_("[CURSOR]:") \
+ _help_("[PFLIP]:") \
+ _help_("[VBLANK]:") \
+ _help_("[HW_LINK_TRAINING]:") \
+ _help_("[HW_AUDIO]:") \
+ _help_("[SCALER]:") \
+ _help_("[BIOS]:") \
+ _help_("[BANDWIDTH_CALCS]:")\
+ _help_("[DML]:")\
+ _help_("[IF_TRACE]:") \
+ _help_("[GAMMA]:") \
+ _help_("[SMU_MSG]:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_dc, __debug_dc,
+ DC_DYNDBG_BITMAP_DESC(debug_dc),
+ _DD_cat_("[CURSOR]:"),
+ _DD_cat_("[PFLIP]:"),
+ _DD_cat_("[VBLANK]:"),
+ _DD_cat_("[HW_LINK_TRAINING]:"),
+ _DD_cat_("[HW_AUDIO]:"),
+ _DD_cat_("[SCALER]:"),
+ _DD_cat_("[BIOS]:"),
+ _DD_cat_("[BANDWIDTH_CALCS]:"),
+ _DD_cat_("[DML]:"),
+ _DD_cat_("[IF_TRACE]:"),
+ _DD_cat_("[GAMMA]:"),
+ _DD_cat_("[SMU_MSG]:"));
+#endif
+#define DC_LOGGER_INIT(logger)
#define SURFACE_TRACE(...) do {\
if (dc->debug.surface_trace) \
--
2.31.1
[PATCH v6 03/11] i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes
Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the nested quoting needed otherwise:
$> echo "format '^gvt: core:' +p" >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.
Consider a generic drm-debug example:
# turn off ATOMIC reports
echo format "^drm:atomic: " -p > control
# turn off all ATOMIC:* reports, including any sub-categories
echo format "^drm:atomic:" -p > control
# turn on ATOMIC:FAIL: reports
echo format "^drm:atomic:fail: " +p > control
Removing embedded spaces in the class-prefixes simplifies the
corresponding match-prefix. This means that "quoted" match-prefixes
are only needed when the trailing space is desired, in order to
exclude explicitly sub-categorized pr-debugs; in this example,
"drm:atomic:fail:".
RFC: maybe the prefix catenation should paste in the " " class-prefix
terminator explicitly. A pr_debug_() flavor could exclude the " ",
allowing ad-hoc sub-categorization by appending for example, "fail:"
to "drm:atomic:".
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/i915/gvt/debug.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..b4021f41c546 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -36,30 +36,30 @@ do {
\
} while (0)
#define gvt_dbg_core(fmt, args...) \
- pr_debug("gvt: core: "fmt, ##args)
+ pr_debug("gvt:core: "fmt, ##args)
#define gvt_dbg_irq(fmt, args...) \
- pr_debug("gvt: irq: "fmt, ##args)
+ pr_debug("gvt:irq: "fmt, ##args)
#define gvt_dbg_mm(fmt, args...) \
- pr_debug("gvt: mm: "fmt, ##args)
+ pr_debug("gvt:mm: "fmt, ##args)
#define gvt_dbg_mmio(fmt, args...) \
- pr_debug("gvt: mmio: "fmt, ##args)
+ pr_debug("gvt:mmio: "fmt, ##args)
#define gvt_dbg_dpy(fmt, args...) \
- pr_debug("gvt: dpy: "fmt, ##args)
+ pr_debug("gvt:dpy: "fmt, ##args)
#define gvt_dbg_el(fmt, args...) \
- pr_debug("gvt: el: "fmt, ##args)
+ pr_debug("gvt:el: "fmt, ##args)
#define gvt_dbg_sched(fmt, args...) \
- pr_debug("gvt: sched: "fmt, ##args)
+ pr_debug("gvt:sched: "fmt, ##args)
#define gvt_dbg_render(fmt, args...) \
- pr_debug("gvt: render: "fmt, ##args)
+ pr_debug("gvt:render: "fmt, ##args)
#define gvt_dbg_cmd(fmt, args...) \
- pr_debug("gvt: cmd: "fmt, ##args)
+ pr_debug("gvt:cmd: "fmt, ##args)
#endif
--
2.31.1
[PATCH v6 02/11] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks
DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
allows users to define a drm.debug style (bitmap) sysfs interface, and
to specify the desired mapping from bits[0-N] to the format-prefix'd
pr_debug()s to be controlled.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"i915/gvt bitmap desc",
/**
* search-prefixes, passed to dd-exec_queries
* defines bits 0-N in order.
* leading ^ is tacitly inserted (by callback currently)
* trailing space used here excludes subcats.
* helper macro needs more work
* macro to autogen ++$i, 0x%x$i ?
*/
_DD_cat_("gvt:cmd: "),
_DD_cat_("gvt:core: "),
_DD_cat_("gvt:dpy: "),
_DD_cat_("gvt:el: "),
_DD_cat_("gvt:irq: "),
_DD_cat_("gvt:mm: "),
_DD_cat_("gvt:mmio: "),
_DD_cat_("gvt:render: "),
_DD_cat_("gvt:sched: "));
dynamic_debug.c: add 3 new elements:
- int param_set_dyndbg()
- int param_get_dyndbg()
- struct kernel_param_ops param_ops_dyndbg
Following the model of kernel/params.c STANDARD_PARAM_DEFS, All 3 are
non-static and exported.
dynamic_debug.h:
Add DEFINE_DYNAMIC_DEBUG_CATEGORIES() described above, and a do-nothing stub.
Note that it also calls MODULE_PARM_DESC for the user, but expects the
user to catenate all the bit-descriptions together (as is done in
drm.debug), and in the following uses in amdgpu, i915.
This in the hope that someone can offer an auto-incrementing
label-generating macro, producing "\tbit-4 0x10\t" etc, and can show
how to apply it to __VA_ARGS__.
Also extern the struct kernel_param param_ops_dyndbg symbol, as is
done in moduleparams.h for all the STANDARD params.
USAGE NOTES:
Using dyndbg to query on "format ^$prefix" requires that the prefix be
present in the compiled-in format string; where run-time prefixing is
used, that format would be "%s...", which is not usefully selectable.
Adding structural query terms (func,file,lineno) could help (module is
already done), but DEFINE_DYNAMIC_DEBUG_CATEGORIES can't do that now,
adding it needs a better reason imo.
Dyndbg is completely agnostic wrt the categorization scheme used, to
play well with any prefix convention already in use. Ad-hoc
categories and sub-categories are implicitly allowed, author
discipline and review is expected.
Here are some examples:
"1","2","3" 2 doesn't imply 1.
otherwize, sorta like printk levels
"1:","2:","3:" are better, avoiding [1-9]\d+ ambiguity
"hi:","mid:","low:" are reasonable, and imply independence
"todo:","rfc:","fixme:" might be handy
"A:".."Z:" uhm, yeah
Hierarchical classes/categories are natural:
"drm::"is used in later commit
"drm:::" is a natural extension.
"drm:atomic:fail:" has been proposed, sounds directly useful
Some properties of a hierarchical category deserve explication:
Trailing spaces matter !
With 1..3-space ("drm: ", "drm:atomic: ", "drm:atomic:fail: "), the
":" doesn't terminate the search-space, the trailing space does. So a
"drm:" search spec will match all DRM categories & subcategories, and
will not be useful in an interface where all categories are already
controlled together. That said, "drm:atomic:" & "drm:atomic: " are
different, and both are useful in cases.
Ad-Hoc sub-categories:
These have a caveat wrt wrapper macros adding prefixes like
"drm:atomic: "; the trailing space in the prefix means that
drm_dbg_atomic("fail: ...") pastes as "drm:atomic: fail: ", which
obviously isn't ideal wrt clear and simple bitmaps.
A possible solution is to have a FOO_() version of every FOO() macro
which (anti-mnemonically) elides the trailing space, which is normally
inserted by a modified FOO(). Doing this would enforce a policy
decision that "debug categories will be space terminated", with an
pressure-relief valve.
Summarizing:
- "drm:kms: " & "drm:kms:" are different
- "drm:kms"also different - includes drm:kms2:
- "drm:kms:\t" also different
- "drm:kms:*" doesn't work, no wildcard on format atm.
Order matters in DEFINE_DYNAMIC_DEBUG_CATEGORIES(... @bit_descs)
@bit_descs (array) position determines the bit mapping to the prefix,
so to keep a stable map, new categories or 3rd level categories must
be added to the end.
Since bits are/will-stay applied 0-N, the later bits can countermand
the earlier ones, but its tricky - consider;
DD_CATs(... "drm:atomic:", "drm:atomic:fail:" ) // misleading
The 1st search-term is misleading, because it includes (modifies)
subcategories, but then 2nd overrides it. So don't do that.
For "drm:atomic:fail:" in particular, its best not to add it into an
existing bitmap, because the current setting would be lost at every
(unrelated) write, and a separate bitmap is much more stable.
There is still plenty of bikeshedding to do.
Signed-off-by: Jim Cromie
---
v5:
. rename to
[PATCH v6 01/11] moduleparam: add data member to struct kernel_param
Add a const void* data member to the struct, to allow attaching
private data that will be used soon by a setter method (via kp->data)
to perform more elaborate actions.
To attach the data at compile time, add new macros:
module_param_cb_data() derives from module_param_cb(), adding data
param, and latter is redefined to use former.
It calls __module_param_call_with_data(), which accepts new data param
and inits .data with it. Re-define __module_param_call() to use it.
Use of this new data member will be rare, it might be worth redoing
this as a separate/sub-type to de-bloat the base case.
Signed-off-by: Jim Cromie
---
v6:
. const void* data -
. better macro names s/_cbd/_cb_data/, s/_wdata/_with_data/
. more const, no cast - Willy
---
include/linux/moduleparam.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index eed280fae433..b8871e514de5 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -78,6 +78,7 @@ struct kernel_param {
const struct kparam_string *str;
const struct kparam_array *arr;
};
+ const void *data;
};
extern const struct kernel_param __start___param[], __stop___param[];
@@ -175,6 +176,9 @@ struct kparam_array
#define module_param_cb(name, ops, arg, perm)\
__module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
+#define module_param_cb_data(name, ops, arg, perm, data)
\
+ __module_param_call_with_data(MODULE_PARAM_PREFIX, name, ops, arg,
perm, -1, 0, data)
+
#define module_param_cb_unsafe(name, ops, arg, perm) \
__module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1,\
KERNEL_PARAM_FL_UNSAFE)
@@ -284,14 +288,17 @@ struct kparam_array
/* This is the fundamental function for registering boot/module
parameters. */
-#define __module_param_call(prefix, name, ops, arg, perm, level, flags)
\
+#define __module_param_call(prefix, name, ops, arg, perm, level, flags) \
+ __module_param_call_with_data(prefix, name, ops, arg, perm, level,
flags, NULL)
+
+#define __module_param_call_with_data(prefix, name, ops, arg, perm, level,
flags, data) \
/* Default value instead of permissions? */ \
static const char __param_str_##name[] = prefix #name; \
static struct kernel_param __moduleparam_const __param_##name \
__used __section("__param") \
__aligned(__alignof__(struct kernel_param)) \
= { __param_str_##name, THIS_MODULE, ops, \
- VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
+ VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg }, data }
/* Obsolete - use module_param_cb() */
#define module_param_call(name, _set, _get, arg, perm) \
--
2.31.1
[PATCH v6 00/11] use DYNAMIC_DEBUG to implement DRM.debug
This patchset does 3 main things. Adds DEFINE_DYNAMIC_DEBUG_CATEGORIES to define bitmap => category control of pr_debugs, and to create their sysfs entries. Uses it in amdgpu, i915 to control existing pr_debugs according to their ad-hoc categorizations. Plugs dyndbg into drm-debug framework, in a configurable manner. v6: cleans up per v5 feedback, and adds RFC stuff: - test_dynamic_debug.ko: uses tracer facility added in v5:8/9 - prototype print-once & rate-limiting Hopefully adding RFC stuff doesnt distract too much. Jim Cromie (11): moduleparam: add data member to struct kernel_param dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to control categorized pr_debugs drm_print: add choice to use dynamic debug in drm-debug drm_print: instrument drm_debug_enabled amdgpu_ucode: reduce number of pr_debug calls nouveau: fold multiple DRM_DEBUG_DRIVERs together dyndbg: RFC add debug-trace callback, selftest with it. RFC dyndbg: RFC add print-once and print-ratelimited features. RFC. drivers/gpu/drm/Kconfig | 13 + drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 293 --- .../gpu/drm/amd/display/dc/core/dc_debug.c| 44 ++- drivers/gpu/drm/drm_print.c | 49 ++- drivers/gpu/drm/i915/gvt/Makefile | 4 + drivers/gpu/drm/i915/gvt/debug.h | 18 +- drivers/gpu/drm/i915/i915_params.c| 35 ++ drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +- include/drm/drm_print.h | 148 ++-- include/linux/dynamic_debug.h | 81 - include/linux/moduleparam.h | 11 +- lib/Kconfig.debug | 11 + lib/Makefile | 1 + lib/dynamic_debug.c | 336 -- lib/test_dynamic_debug.c | 279 +++ 15 files changed, 1117 insertions(+), 242 deletions(-) create mode 100644 lib/test_dynamic_debug.c -- 2.31.1
[Bug 214001] [bisected][regression] After commit "drm/ttm: Initialize debugfs from ttm_global_init()" kernels without debugfs explicitly set to 'allow all' fail to boot
https://bugzilla.kernel.org/show_bug.cgi?id=214001 Linux_Chemist (untaintablean...@hotmail.co.uk) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #6 from Linux_Chemist (untaintablean...@hotmail.co.uk) --- All good! CONFIG_DEBUG_FS is not set and can boot again :) Marking as fixed. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214001] [bisected][regression] After commit "drm/ttm: Initialize debugfs from ttm_global_init()" kernels without debugfs explicitly set to 'allow all' fail to boot
https://bugzilla.kernel.org/show_bug.cgi?id=214001 --- Comment #5 from Linux_Chemist (untaintablean...@hotmail.co.uk) --- I can sense you're a smart cookie, Duncan, I've enjoyed this little tete a tete. I think this bug has been addressed, it's just not been mentioned yet (see the following into mainline): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu?id=958f44255058338f4b370d8e4100e1e7d72db0cc " This changes it so that if creation of TTM's debugfs root directory fails, then no biggie: keep calm and carry on." Will test it out as soon as I can and comment/adjust the bug report. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/r128: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
---
drivers/gpu/drm/r128/ati_pcigart.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/r128/ati_pcigart.c
b/drivers/gpu/drm/r128/ati_pcigart.c
index 0ecccf25a3c7..26001c2de9e9 100644
--- a/drivers/gpu/drm/r128/ati_pcigart.c
+++ b/drivers/gpu/drm/r128/ati_pcigart.c
@@ -99,7 +99,8 @@ int drm_ati_pcigart_cleanup(struct drm_device *dev, struct
drm_ati_pcigart_info
for (i = 0; i < pages; i++) {
if (!entry->busaddr[i])
break;
- pci_unmap_page(pdev, entry->busaddr[i], PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(>dev, entry->busaddr[i],
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
}
if (gart_info->gart_table_location == DRM_ATI_GART_MAIN)
@@ -134,7 +135,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
if (gart_info->gart_table_location == DRM_ATI_GART_MAIN) {
DRM_DEBUG("PCI: no table in VRAM: using normal RAM\n");
- if (pci_set_dma_mask(pdev, gart_info->table_mask)) {
+ if (dma_set_mask(>dev, gart_info->table_mask)) {
DRM_ERROR("fail to set dma mask to 0x%Lx\n",
(unsigned long long)gart_info->table_mask);
ret = -EFAULT;
@@ -173,9 +174,9 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
gart_idx = 0;
for (i = 0; i < pages; i++) {
/* we need to support large memory configurations */
- entry->busaddr[i] = pci_map_page(pdev, entry->pagelist[i],
-0, PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
- if (pci_dma_mapping_error(pdev, entry->busaddr[i])) {
+ entry->busaddr[i] = dma_map_page(>dev, entry->pagelist[i],
+0, PAGE_SIZE,
DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(>dev, entry->busaddr[i])) {
DRM_ERROR("unable to map PCIGART pages!\n");
drm_ati_pcigart_cleanup(dev, gart_info);
address = NULL;
--
2.30.2
Re: [PATCH 1/2] mm/vmscan: add sync_shrinkers function v2
On Fri, 20 Aug 2021 14:05:27 +0200 "Christian König" wrote: > While unplugging a device the TTM shrinker implementation > needs a barrier to make sure that all concurrent shrink > operations are done and no other CPU is referring to a > device specific pool any more. > > Taking and releasing the shrinker semaphore on the write > side after unmapping and freeing all pages from the device > pool should make sure that no shrinker is running in > paralell. > > This allows us to avoid the contented mutex in the TTM pool > implementation for every alloc/free operation. > > v2: rework the commit message to make clear why we need this Acked-by: Andrew Morton
[PATCH] drm/radeon: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
---
drivers/gpu/drm/radeon/radeon_device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index ac8c3251b616..4f0fbf667431 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -785,7 +785,7 @@ int radeon_dummy_page_init(struct radeon_device *rdev)
if (rdev->dummy_page.page == NULL)
return -ENOMEM;
rdev->dummy_page.addr = dma_map_page(>pdev->dev,
rdev->dummy_page.page,
- 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ 0, PAGE_SIZE, DMA_BIDIRECTIONAL);
if (dma_mapping_error(>pdev->dev, rdev->dummy_page.addr)) {
dev_err(>pdev->dev, "Failed to DMA MAP the dummy page\n");
__free_page(rdev->dummy_page.page);
@@ -808,8 +808,8 @@ void radeon_dummy_page_fini(struct radeon_device *rdev)
{
if (rdev->dummy_page.page == NULL)
return;
- pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(>pdev->dev, rdev->dummy_page.addr, PAGE_SIZE,
+ DMA_BIDIRECTIONAL);
__free_page(rdev->dummy_page.page);
rdev->dummy_page.page = NULL;
}
--
2.30.2
[PATCH] drm/amdgpu: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index b36405170ff3..76efd5f8950f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -76,7 +76,7 @@ static int amdgpu_gart_dummy_page_init(struct amdgpu_device
*adev)
if (adev->dummy_page_addr)
return 0;
adev->dummy_page_addr = dma_map_page(>pdev->dev, dummy_page, 0,
-PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+PAGE_SIZE, DMA_BIDIRECTIONAL);
if (dma_mapping_error(>pdev->dev, adev->dummy_page_addr)) {
dev_err(>pdev->dev, "Failed to DMA MAP the dummy page\n");
adev->dummy_page_addr = 0;
@@ -96,8 +96,8 @@ void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
- pci_unmap_page(adev->pdev, adev->dummy_page_addr,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(>pdev->dev, adev->dummy_page_addr, PAGE_SIZE,
+ DMA_BIDIRECTIONAL);
adev->dummy_page_addr = 0;
}
--
2.30.2
[PATCH] drm/i915: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
drivers/gpu/drm/i915/gvt/gtt.c | 16
drivers/gpu/drm/i915/gvt/kvmgt.c| 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index a74b72f50cc9..afb35d2e5c73 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -32,7 +32,7 @@ static int init_fake_lmem_bar(struct intel_memory_region *mem)
mem->remap_addr = dma_map_resource(i915->drm.dev,
mem->region.start,
mem->fake_mappable.size,
- PCI_DMA_BIDIRECTIONAL,
+ DMA_BIDIRECTIONAL,
DMA_ATTR_FORCE_CONTIGUOUS);
if (dma_mapping_error(i915->drm.dev, mem->remap_addr)) {
drm_mm_remove_node(>fake_mappable);
@@ -62,7 +62,7 @@ static void release_fake_lmem_bar(struct intel_memory_region
*mem)
dma_unmap_resource(mem->i915->drm.dev,
mem->remap_addr,
mem->fake_mappable.size,
- PCI_DMA_BIDIRECTIONAL,
+ DMA_BIDIRECTIONAL,
DMA_ATTR_FORCE_CONTIGUOUS);
}
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index e5c2fdfc20e3..fb4e96a3e79e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -745,7 +745,7 @@ static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt *spt)
trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
dma_unmap_page(kdev, spt->shadow_page.mfn << I915_GTT_PAGE_SHIFT, 4096,
- PCI_DMA_BIDIRECTIONAL);
+ DMA_BIDIRECTIONAL);
radix_tree_delete(>vgpu->gtt.spt_tree, spt->shadow_page.mfn);
@@ -849,7 +849,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
*/
spt->shadow_page.type = type;
daddr = dma_map_page(kdev, spt->shadow_page.page,
-0, 4096, PCI_DMA_BIDIRECTIONAL);
+0, 4096, DMA_BIDIRECTIONAL);
if (dma_mapping_error(kdev, daddr)) {
gvt_vgpu_err("fail to map dma addr\n");
ret = -EINVAL;
@@ -865,7 +865,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
return spt;
err_unmap_dma:
- dma_unmap_page(kdev, daddr, PAGE_SIZE,
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #48 from i-am-not-a-ro...@riseup.net --- This seems to be a firmware(-related) problem. After downgrading to linux firmware 2020-09-18, I'm running 6 days without a crash on the same work loads. (I was getting multiple crashes per day before). My GPU is Vega8 Mobile (ThinkPad A485). Currently running 5.13.11. An extensive discussion of different firmware versions in the context of a similar issue on Arch Forums: https://bbs.archlinux.org/viewtopic.php?id=266358=5 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v8 01/34] opp: Add dev_pm_opp_sync() helper
20.08.2021 08:18, Viresh Kumar пишет:
> On 19-08-21, 16:55, Ulf Hansson wrote:
>> Right, that sounds reasonable.
>>
>> We already have pm_genpd_opp_to_performance_state() which translates
>> an OPP to a performance state. This function invokes the
>> ->opp_to_performance_state() for a genpd. Maybe we need to allow a
>> genpd to not have ->opp_to_performance_state() callback assigned
>> though, but continue up in the hierarchy to see if the parent has the
>> callback assigned, to make this work for Tegra?
>>
>> Perhaps we should add an API dev_pm_genpd_opp_to_performance_state(),
>> allowing us to pass the device instead of the genpd. But that's a
>> minor thing.
>
> I am not concerned a lot about how it gets implemented, and am not
> sure as well, as I haven't looked into these details since sometime.
> Any reasonable thing will be accepted, as simple as that.
>
>> Finally, the precondition to use the above, is to first get a handle
>> to an OPP table. This is where I am struggling to find a generic
>> solution, because I guess that would be platform or even consumer
>> driver specific for how to do this. And at what point should we do
>> this?
GENPD core can't get OPP table handle, setting up OPP table is a
platform/driver specific operation.
> Hmm, I am not very clear with the whole picture at this point of time.
>
> Dmitry, can you try to frame a sequence of events/calls/etc that will
> define what kind of devices we are looking at here, and how this can
> be made to work ?
Could you please clarify what do you mean by a "kind of devices"?
I made hack based on the recent discussions and it partially works. Getting
clock rate involves resuming device which backs the clock and it also may use
GENPD, so lockings are becoming complicated. It doesn't work at all if device
uses multiple domains because virtual domain device doesn't have OPP table.
Setting up the performance state from a consumer driver is a cleaner variant so
far.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e1c8994ae225..faa0bbe99c98 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -410,11 +410,16 @@ static int genpd_drop_performance_state(struct device
*dev)
return 0;
}
-static void genpd_restore_performance_state(struct device *dev,
- unsigned int state)
+static int genpd_restore_performance_state(struct generic_pm_domain *genpd,
+ struct device *dev,
+ unsigned int state)
{
+ int ret = 0;
+
if (state)
- genpd_set_performance_state(dev, state);
+ ret = genpd_set_performance_state(dev, state);
+
+ return ret;
}
/**
@@ -435,7 +440,7 @@ static void genpd_restore_performance_state(struct device
*dev,
int dev_pm_genpd_set_performance_state(struct device *dev, unsigned int state)
{
struct generic_pm_domain *genpd;
- int ret;
+ int ret = 0;
genpd = dev_to_genpd_safe(dev);
if (!genpd)
@@ -446,7 +451,10 @@ int dev_pm_genpd_set_performance_state(struct device *dev,
unsigned int state)
return -EINVAL;
genpd_lock(genpd);
- ret = genpd_set_performance_state(dev, state);
+ if (pm_runtime_suspended(dev))
+ dev_gpd_data(dev)->rpm_pstate = state;
+ else
+ ret = genpd_set_performance_state(dev, state);
genpd_unlock(genpd);
return ret;
@@ -959,10 +967,25 @@ static int genpd_runtime_resume(struct device *dev)
goto out;
}
+ if (genpd->get_performance_state) {
+ ret = genpd->get_performance_state(genpd, dev);
+ if (ret < 0)
+ return ret;
+
+ if (ret > 0)
+ gpd_data->rpm_pstate = ret;
+ }
+
genpd_lock(genpd);
ret = genpd_power_on(genpd, 0);
- if (!ret)
- genpd_restore_performance_state(dev, gpd_data->rpm_pstate);
+ if (!ret) {
+ ret = genpd_restore_performance_state(genpd, dev,
+ gpd_data->rpm_pstate);
+ if (ret)
+ genpd_power_off(genpd, true, 0);
+ else
+ gpd_data->rpm_pstate = 0;
+ }
genpd_unlock(genpd);
if (ret)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 18016e49605f..982be2dba21e 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -2967,3 +2967,33 @@ int dev_pm_opp_sync(struct device *dev)
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_opp_sync);
+
+/**
+ * dev_pm_opp_from_clk_rate() - Get OPP from current clock rate
+ * @dev: device for which we do this operation
+ *
+ * Get OPP which corresponds to the current clock rate of a device.
+ *
+ * Return: pointer to 'struct dev_pm_opp' on success and errorno otherwise.
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Sun, 22 Aug 2021 at 13:50, Daniel Vetter wrote: > > On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia > wrote: > > > > +danvet > > > > Hi, > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote: > > > > > > This series adds support for multi hardware decode into mtk-vcodec, by > > > first > > > adding component framework to manage each hardware information: interrupt, > > > clock, register bases and power. Secondly add core thread to deal with > > > core > > > hardware message, at the same time, add msg queue for different hardware > > > share messages. Lastly, the architecture of different specs are not the > > > same, > > > using specs type to separate them. > > > > > > > I don't think it's a good idea to introduce the component API in the > > media subsystem. It doesn't seem to be maintained, IRC there's not even > > a maintainer for it, and it has some issues that were never addressed. > > Defacto dri-devel folks are maintainer component.c, but also I'm not > aware of anything missing there? > A while ago, I tried to fix a crash in the Rockchip DRM driver (I was then told there can be similar issues on the IMX driver too, but I forgot the details of that). I sent a patchset trying to address it and got total silence back. Although you could argue the issue is in how drivers use the component API, AFAICR the abuse is spreaded across a few drivers, so it felt more reasonable to improve the component API itself, instead of changing all the drivers. See below: https://patchwork.kernel.org/project/linux-rockchip/cover/20200120170602.3832-1-ezequ...@collabora.com/ > There has been discussions that in various drm subsystems like > drm_bridge or drm_panel a few things are missing, which prevent > drivers from moving _away_ from component.c to the more specific > solutions for panel/bridges. But nothing that's preventing them from > using component.c itself. > > I'm happy to merge a MAINTAINERS patch to clarify the situation if > that's needed. Indeed, that would be good. Thanks, Ezequiel
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia wrote: > > +danvet > > Hi, > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote: > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > adding component framework to manage each hardware information: interrupt, > > clock, register bases and power. Secondly add core thread to deal with core > > hardware message, at the same time, add msg queue for different hardware > > share messages. Lastly, the architecture of different specs are not the > > same, > > using specs type to separate them. > > > > I don't think it's a good idea to introduce the component API in the > media subsystem. It doesn't seem to be maintained, IRC there's not even > a maintainer for it, and it has some issues that were never addressed. Defacto dri-devel folks are maintainer component.c, but also I'm not aware of anything missing there? There has been discussions that in various drm subsystems like drm_bridge or drm_panel a few things are missing, which prevent drivers from moving _away_ from component.c to the more specific solutions for panel/bridges. But nothing that's preventing them from using component.c itself. I'm happy to merge a MAINTAINERS patch to clarify the situation if that's needed. -Daniel > It would be really important to avoid it. Is it really needed in the > first place? > > Thanks, > Ezequiel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Fri, 20 Aug 2021 at 04:59, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Thanks for your detail feedback. > > On Thu, 2021-08-19 at 11:10 -0300, Ezequiel Garcia wrote: > > On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com > > wrote: > > > > > > Hi Ezequiel, > > > > > > Thanks for your suggestion. > > > > > > On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote: > > > > +danvet > > > > > > > > Hi, > > > > > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong > > > > wrote: > > > > > > > > > > This series adds support for multi hardware decode into mtk-vcodec, > > > > > by first > > > > > adding component framework to manage each hardware information: > > > > > interrupt, > > > > > clock, register bases and power. Secondly add core thread to deal > > > > > with core > > > > > hardware message, at the same time, add msg queue for different > > > > > hardware > > > > > share messages. Lastly, the architecture of different specs are not > > > > > the same, > > > > > using specs type to separate them. > > > > > > > > > > > > > I don't think it's a good idea to introduce the component API in the > > > > media subsystem. It doesn't seem to be maintained, IRC there's not > > > > even > > > > a maintainer for it, and it has some issues that were never > > > > addressed. > > > > > > > > It would be really important to avoid it. Is it really needed in the > > > > first place? > > > > > > > > Thanks, > > > > Ezequiel > > > > > > For there are many hardware need to use, mt8192 is three and mt8195 is > > > five. Maybe need more to be used in the feature. > > > > > > Each hardware has independent clk/power/iommu port/irq. > > > Use component interface in prob to get each component's information. > > > Just enable the hardware when need to use it, very convenient and > > > simple. > > > > > > I found that there are many modules use component to manage hardware > > > information, such as iommu and drm etc. > > > > > > > Many drivers support multiple hardware variants, where each variant > > has a different number of clocks or interrupts, see for instance > > struct hantro_variant which allows to expose different codec cores, > > some having both decoder/encoder, and some having just a decoder. > > > > The component API is mostly used by DRM to aggregate independent > > subdevices (called components) into an aggregated driver. > > > > For instance, a DRM driver needs to glue together the HDMI, MIPI, > > and plany controller, or any other hardware arrangement where > > devices can be described independently. > > > The usage scenario is very similar with drm and iommu, So decide to use > component framework. > Decode has three/five or more hardwares, these hardware are independent. > For mt8183 just need core hardware to decode, but mt8192 has lat,soc and > core hardware to decode. When lat need to use, just enable lat hardware, > core is the same.And mt8195 will has two cores, each core can work well > independent. > > For each component device just used to open their power/clk/iommu > port/irq when master need to enable it. The main logic is in master > device. > > > The component API may look simple but has some issues, it's not easy > > to debug, and can cause troubles if not used as expected [1]. > > It's worth making sure you actually need a framework > > to glue different devices together. > > > Each hardware has its index, master can get hardware information > according these index, looks not complex. What do you mean about not > easy to debug? > > > > Do you have any other suggestion for this architecture? > > > > > > > Looking at the different patchsets that are posted, it's not clear > > to me what exactly are the different architectures that you intend > > to support, can you some documentation which clarifies that? > > > Have five hardwares lat,soc,core0,core1 and main. Lat thread can use lat > soc and main, core thread can use soc,lat, core0 and core1. Core thread > can be used or not for different project. Can you explain what are these lat,soc and core threads for? > Also Need to use these > hardware dynamic at the same time. So I use component framework, just > need to know the used hardware index according to different > project.Need not to do complex logic to manage these hardwares. > I am not thrilled to see the component framework introduced to the media subsystem. Like I said, it has no clear maintainer, and it's not easy to use. The media subsystem has some support which AFAIK does the same thing, see v4l2-async, which is maintained by media people. Please push a branch based on media/master containing these changes. I see there are other patch series for this device, but it's hard to track which goes first, etc. Thanks, Ezequiel
Re: [PATCH] drm: adv7511: Convert to SPDX identifier
Hi Cai, Thank you for the patch. On Sun, Aug 22, 2021 at 03:21:11PM +0800, Cai Huoqing wrote: > use SPDX-License-Identifier instead of a verbose license text > > Signed-off-by: Cai Huoqing Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 15 +-- > 1 file changed, 1 insertion(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > index a20a45c0b353..28d9becc939c 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > @@ -1,21 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0-only > /* > * adv7511_cec.c - Analog Devices ADV7511/33 cec driver > * > * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights > reserved. > - * > - * This program is free software; you may redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; version 2 of the License. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > - * SOFTWARE. > - * > */ > > #include -- Regards, Laurent Pinchart
[PATCH] media: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors=158745678307186=4
This patch is purely mechanical and compile tested. I hope it is ok to
update the "drivers/media/pci/" directory all at once.
---
drivers/media/pci/cobalt/cobalt-driver.c | 4 ++--
drivers/media/pci/cx18/cx18-driver.c | 2 +-
drivers/media/pci/cx18/cx18-queue.c | 13 ++--
drivers/media/pci/cx18/cx18-streams.c | 16 +++
drivers/media/pci/ddbridge/ddbridge-main.c| 4 ++--
drivers/media/pci/intel/ipu3/ipu3-cio2-main.c | 2 +-
.../pci/netup_unidvb/netup_unidvb_core.c | 2 +-
drivers/media/pci/pluto2/pluto2.c | 20 +--
drivers/media/pci/pt1/pt1.c | 2 +-
drivers/media/pci/tw5864/tw5864-core.c| 2 +-
10 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/media/pci/cobalt/cobalt-driver.c
b/drivers/media/pci/cobalt/cobalt-driver.c
index 16af58f2f93c..74edcc76d12f 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -332,8 +332,8 @@ static int cobalt_setup_pci(struct cobalt *cobalt, struct
pci_dev *pci_dev,
}
}
- if (pci_set_dma_mask(pci_dev, DMA_BIT_MASK(64))) {
- ret = pci_set_dma_mask(pci_dev, DMA_BIT_MASK(32));
+ if (dma_set_mask(_dev->dev, DMA_BIT_MASK(64))) {
+ ret = dma_set_mask(_dev->dev, DMA_BIT_MASK(32));
if (ret) {
cobalt_err("no suitable DMA available\n");
goto err_disable;
diff --git a/drivers/media/pci/cx18/cx18-driver.c
b/drivers/media/pci/cx18/cx18-driver.c
index f2440eb38820..59497ba6bf1f 100644
--- a/drivers/media/pci/cx18/cx18-driver.c
+++ b/drivers/media/pci/cx18/cx18-driver.c
@@ -804,7 +804,7 @@ static int cx18_setup_pci(struct cx18 *cx, struct pci_dev
*pci_dev,
CX18_ERR("Can't enable device %d!\n", cx->instance);
return -EIO;
}
- if (pci_set_dma_mask(pci_dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask(_dev->dev, DMA_BIT_MASK(32))) {
CX18_ERR("No suitable DMA available, card %d\n", cx->instance);
return -EIO;
}
diff --git a/drivers/media/pci/cx18/cx18-queue.c
b/drivers/media/pci/cx18/cx18-queue.c
index 2f5df471dada..b9ae34a5e427 100644
--- a/drivers/media/pci/cx18/cx18-queue.c
+++ b/drivers/media/pci/cx18/cx18-queue.c
@@ -325,8 +325,8 @@ void _cx18_mdl_sync_for_device(struct cx18_stream *s,
struct cx18_mdl *mdl)
struct cx18_buffer *buf;
list_for_each_entry(buf, >buf_list, list)
- pci_dma_sync_single_for_device(pci_dev, buf->dma_handle,
-
Re: [PATCH v2 45/63] ath11k: Use memset_startat() for clearing queue descriptors
On Sat, Aug 21, 2021 at 01:17:36PM +0300, Kalle Valo wrote: > Kees Cook writes: > > > On Thu, Aug 19, 2021 at 04:19:37PM +0300, Kalle Valo wrote: > >> Kees Cook writes: > >> > >> > In preparation for FORTIFY_SOURCE performing compile-time and run-time > >> > field bounds checking for memset(), avoid intentionally writing across > >> > neighboring fields. > >> > > >> > Use memset_startat() so memset() doesn't get confused about writing > >> > beyond the destination member that is intended to be the starting point > >> > of zeroing through the end of the struct. Additionally split up a later > >> > field-spanning memset() so that memset() can reason about the size. > >> > > >> > Cc: Kalle Valo > >> > Cc: "David S. Miller" > >> > Cc: Jakub Kicinski > >> > Cc: ath...@lists.infradead.org > >> > Cc: linux-wirel...@vger.kernel.org > >> > Cc: net...@vger.kernel.org > >> > Signed-off-by: Kees Cook > >> > >> To avoid conflicts I prefer taking this via my ath tree. > > > > The memset helpers are introduced as part of this series, so that makes > > things more difficult. Do you want me to create a branch with the > > helpers that you can merge? > > Is this patch really worth the extra complexity? Why can't I apply this > ath11k patch after the helpers have landed Linus' tree? That would be > very simple. Not singularly, no. But I have a bit of a catch-22 in that I can't turn on greater FORTIFY strictness without first fixing the false positives, and I can't fix the false positives in "other" trees without those trees first having the helpers that get introduced by the FORTIFY series. :) Anyway, since we're close to the merge window anyway, the FORTIFY series won't land in 1 release at this point regardless, so I'll just get the helpers landed and we can do the individual pieces once the merge window closes. Wheee :) -- Kees Cook
[Bug 204849] amdgpu (RX560X) traceboot in dmesg boot output, system instability
https://bugzilla.kernel.org/show_bug.cgi?id=204849 Justin Clift (jus...@postgresql.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #4 from Justin Clift (jus...@postgresql.org) --- Clearly no-one is ever going to look at this, so I'm just going to close it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/panel: raspberrypi-touchscreen: Convert to SPDX identifier
use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Cai Huoqing --- .../drm/panel/panel-raspberrypi-touchscreen.c | 24 +-- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c index 46029c5610c8..9b4ba04ce39f 100644 --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c @@ -1,32 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 or MIT /* * Copyright © 2016-2017 Broadcom * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * * Portions of this file (derived from panel-simple.c) are: * * Copyright (C) 2013, NVIDIA Corporation. All rights reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sub license, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the - * next paragraph) shall be included in all copies or substantial portions - * of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. */ /* -- 2.25.1
[PATCH] drm/omapdrm: Convert to SPDX identifier
use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Cai Huoqing --- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 14 +- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 14 +- drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 10 +- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +- drivers/gpu/drm/omapdrm/omap_dmm_tiler.h | 10 +- drivers/gpu/drm/omapdrm/tcm-sita.c | 10 +- 6 files changed, 6 insertions(+), 62 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c index 43592c1cf081..852987e67e40 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * HDMI CEC * @@ -10,19 +11,6 @@ * Heavily modified to use the linux CEC framework: * * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights reserved. - * - * This program is free software; you may redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - * SOFTWARE. */ #include diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h index 0292337c97cc..1ca5b5ca8a99 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h @@ -1,20 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ /* * HDMI header definition for OMAP4 HDMI CEC IP * * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights reserved. - * - * This program is free software; you may redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - * SOFTWARE. */ #ifndef _HDMI4_CEC_H_ diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h index 58a8239d3e69..2288ed56f23d 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h +++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h @@ -1,16 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/ * Author: Rob Clark * Andy Gross - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #ifndef OMAP_DMM_PRIV_H diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index ed770caf55c2..852e78a5f142 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c @@ -1,18 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * DMM IOMMU driver support functions for TI OMAP processors. * * Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/ * Author: Rob Clark * Andy Gross - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h index 2f8918fe06d5..87a32b3cd3b0 100644 --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.h @@ -1,16 +1,8 @@ +/*
[PATCH] drm: adv7511: Convert to SPDX identifier
use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Cai Huoqing --- drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c index a20a45c0b353..28d9becc939c 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c @@ -1,21 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0-only /* * adv7511_cec.c - Analog Devices ADV7511/33 cec driver * * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights reserved. - * - * This program is free software; you may redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - * SOFTWARE. - * */ #include -- 2.25.1
