Re: [PATCH v2 0/2] Fix a bunch of allmodconfig errors
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this set.
>
Oh, I get it. Clang. I'll tweak the above para to make that clearer.
cc:stable question still applies? How much trouble will these build
errors be causing people for the next N years?
> With this set applied, I am able to obtain a successful allmodconfig Arm
> build.
Re: [PATCH v2 0/2] Fix a bunch of allmodconfig errors
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this set.
>
I'm not sure who this patchset is aimed at, so I'll take my usual
approach of grabbing it and seeing who complains.
> With this set applied, I am able to obtain a successful allmodconfig Arm
> build.
b339ec9c229aa is a year old and I've been doing arm allmodconfig for
ever. What am I missing here?
A broken arm allmodconfig is pretty irritating - I'm thinking that a
fix should be backported into -stable kernels. But I'm clearly missing
something here.
[PATCH] fbdev: make offb driver tristate
Make the offb (Open Firmware frame buffer) driver tristate, i.e., so that it can be built as a loadable module. However, it still depends on the setting of DRM_OFDRM so that both of these drivers cannot be builtin at the same time nor can one be builtin and the other one a loadable module. Build-tested successfully with all combination of DRM_OFDRM and FB_OF. This fixes a build issue that Michal reported when FB_OF=y and DRM_OFDRM=m: powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined reference to `cfb_fillrect' powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): undefined reference to `cfb_copyarea' powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): undefined reference to `cfb_imageblit' Signed-off-by: Randy Dunlap Suggested-by: Arnd Bergmann Cc: Masahiro Yamada Cc: Thomas Zimmermann Cc: Michal Suchánek Cc: linuxppc-...@lists.ozlabs.org Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org --- drivers/video/fbdev/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -456,8 +456,8 @@ config FB_ATARI chipset found in Ataris. config FB_OF - bool "Open Firmware frame buffer device support" - depends on (FB = y) && PPC && (!PPC_PSERIES || PCI) + tristate "Open Firmware frame buffer device support" + depends on FB && PPC && (!PPC_PSERIES || PCI) depends on !DRM_OFDRM select APERTURE_HELPERS select FB_CFB_FILLRECT
Re: [PATCH RESEND v4 2/2] gpu: drm: meson: Use devm_regulator_*get_enable*()
On Wed, Nov 16, 2022 at 2:03 PM Matti Vaittinen wrote: > > Simplify using the devm_regulator_get_enable_optional(). Also drop the > seemingly unused struct member 'hdmi_supply'. Personally I'd replace "seemingly" with "now" because hdmi_supply was used before (although only in this one function, which makes it a bit pointless). This is minor enough. So with or without that change this gets my: Acked-by: Martin Blumenstingl
[PATCH v3 3/5] drm/i915: Refine VT-d scanout workaround
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
2 files changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce6800..882b91519f92b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -17,6 +17,8 @@
#include "i915_gem_object.h"
#include "i915_vma.h"
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -424,6 +426,17 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
+ /* VT-d may overfetch before/after the vma, so pad with scratch */
+ if (intel_scanout_needs_vtd_wa(i915)) {
+ unsigned int guard = VTD_GUARD;
+
+ if (i915_gem_object_is_tiled(obj))
+ guard = max(guard,
+ i915_gem_object_get_tile_row_size(obj));
+
+ flags |= PIN_OFFSET_GUARD | guard;
+ }
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 133710258eae6..5ccec5c9206d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -367,27 +367,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -959,8 +938,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1121,7 +1098,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
--
2.38.1
[PATCH v3 5/5] drm/i915: Limit the display memory alignment to 32 bit instead of 64
Chris commit "drm/i915: Introduce guard pages to i915_vma" was
"cunningly" changing display_alignment to u32 from u64. The
reason is that the display GGTT is and will be limited o 4GB.
Put it in a separate patch and use "max(...)" instead of
"max_t(64, ...)" when asigning the value. We can safely use max
as we know beforehand that the comparison is between two u32
variables.
Signed-off-by: Chris Wilson
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 +-
drivers/gpu/drm/i915/i915_vma_types.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 6900acbb1381c..1aca7552a85d0 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -91,7 +91,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
goto err;
}
- vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
+ vma->display_alignment = max(vma->display_alignment, alignment);
i915_gem_object_flush_if_display(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 882b91519f92b..9969e687ad857 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -457,7 +457,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (IS_ERR(vma))
return vma;
- vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
+ vma->display_alignment = max(vma->display_alignment, alignment);
i915_vma_mark_scanout(vma);
i915_gem_object_flush_if_display_locked(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index 46f5ce19d4a0a..77fda2244d161 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -197,7 +197,6 @@ struct i915_vma {
struct i915_fence_reg *fence;
u64 size;
- u64 display_alignment;
struct i915_page_sizes page_sizes;
/* mmap-offset associated with fencing for this vma */
@@ -206,6 +205,7 @@ struct i915_vma {
u32 guard; /* padding allocated around vma->pages within the node */
u32 fence_size;
u32 fence_alignment;
+ u32 display_alignment;
/**
* Count of the number of times this vma has been opened by different
--
2.38.1
[PATCH v3 2/5] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson Introduce the concept of padding the i915_vma with guard pages before and after. The major consequence is that all ordinary uses of i915_vma must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size directly, as the drm_mm_node will include the guard pages that surround our object. The biggest connundrum is how exactly to mix requesting a fixed address with guard pages, particularly through the existing uABI. The user does not know about guard pages, so such must be transparent to the user, and so the execobj.offset must be that of the object itself excluding the guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. The caveat is that some placements will be impossible with guard pages, as wrap arounds need to be avoided, and the vma itself will require a larger node. We must not report EINVAL but ENOSPC as these are unavailable locations within the GTT rather than conflicting user requirements. In the next patch, we start using guard pages for scanout objects. While these are limited to GGTT vma, on a few platforms these vma (or at least an alias of the vma) is shared with userspace, so we may leak the existence of such guards if we are not careful to ensure that the execobj.offset is transparent and excludes the guards. (On such platforms like ivb, without full-ppgtt, userspace has to use relocations so the presence of more untouchable regions within its GTT such be of no further issue.) Signed-off-by: Chris Wilson Signed-off-by: Tejas Upadhyay Signed-off-by: Tvrtko Ursulin Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +--- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_vma.c | 43 drivers/gpu/drm/i915/i915_vma.h | 5 +-- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +-- drivers/gpu/drm/i915/i915_vma_resource.h | 7 +++- drivers/gpu/drm/i915/i915_vma_types.h| 1 + 7 files changed, 60 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 8145851ad23d5..133710258eae6 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -287,8 +287,11 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm, */ gte = (gen8_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + gen8_set_pte(gte++, vm->scratch[0]->encode); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) gen8_set_pte(gte++, pte_encode | addr); @@ -338,9 +341,12 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm, dma_addr_t addr; gte = (gen6_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + iowrite32(vm->scratch[0]->encode, gte++); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) iowrite32(vm->pte_encode(addr, level, flags), gte++); GEM_BUG_ON(gte > end); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8c2f57eb5ddaa..2434197830523 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, #define PIN_HIGH BIT_ULL(5) #define PIN_OFFSET_BIASBIT_ULL(6) #define PIN_OFFSET_FIXED BIT_ULL(7) -#define PIN_VALIDATE BIT_ULL(8) /* validate placement only, no need to call unpin() */ +#define PIN_OFFSET_GUARD BIT_ULL(8) +#define PIN_VALIDATE BIT_ULL(9) /* validate placement only, no need to call unpin() */ #define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */ #define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */ diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 2232118babeb3..709a37f1c144b 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -419,7 +419,7 @@ i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res, obj->mm.rsgt, i915_gem_object_is_readonly(obj), i915_gem_object_is_lmem(obj), obj->mm.region, vma->ops, vma->private, __i915_vma_offset(vma), -
[PATCH v3 1/5] drm/i915: Wrap all access to i915_vma.node.start|size
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +
.../drm/i915/gem/selftests/i915_gem_context.c | 15 +++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 +--
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++---
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 +++---
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 25 -
drivers/gpu/drm/i915/i915_vma.h | 51 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 10 ++--
drivers/gpu/drm/i915/selftests/i915_request.c | 20
drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +--
29 files changed, 180 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 5575d7abdc092..03ed4607a46d2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -286,7 +286,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
+ (unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
info->fix.smem_len = vma->size;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 29e9e8d5b6fec..86956b902c978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -379,22 +379,25 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ const u64 start = i915_vma_offset(vma);
+ const u64 size = i915_vma_size(vma);
+
+ if (size < entry->pad_to_size)
return true;
- if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
+ if (entry->alignment && !IS_ALIGNED(start, entry->alignment))
return true;
if (flags & EXEC_OBJECT_PINNED &&
- vma->node.start != entry->offset)
+ start != entry->offset)
return true;
if (flags & __EXEC_OBJECT_NEEDS_BIAS &&
- vma->node.start < BATCH_OFFSET_BIAS)
+ start < BATCH_OFFSET_BIAS)
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size + 4095) >> 32)
+ (start + size + 4095) >> 32)
return true;
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
@@ -440,7 +443,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
int err;
if (vma->node.size)
- pin_flags = vma->node.start;
+ pin_flags = __i915_vma_offset(vma);
else
pin_flags = entry->offset & PIN_OFFSET_MASK;
@@ -663,8 +666,8 @@
[PATCH v3 4/5] Revert "drm/i915: Improve on suspend / resume time with VT-d enabled"
This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.
Checking the presence if the IRST (Intel Rapid Start Technology)
through the ACPI to decide whether to rebuild or not the GGTT
puts us at the mercy of the boot firmware and we need to
unnecessarily rely on third parties.
Because now we avoid adding scratch pages to the entire GGTT we
don't need this hack anymore.
Signed-off-by: Andi Shyti
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69 ++--
drivers/gpu/drm/i915/gt/intel_gtt.h | 24 --
drivers/gpu/drm/i915/i915_driver.c | 16 ---
3 files changed, 13 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 5ccec5c9206d2..9d76a573255f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -26,13 +26,6 @@
#include "intel_gtt.h"
#include "gen8_ppgtt.h"
-static inline bool suspend_retains_ptes(struct i915_address_space *vm)
-{
- return GRAPHICS_VER(vm->i915) >= 8 &&
- !HAS_LMEM(vm->i915) &&
- vm->is_ggtt;
-}
-
static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
unsigned long color,
u64 *start,
@@ -104,23 +97,6 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
return 0;
}
-/*
- * Return the value of the last GGTT pte cast to an u64, if
- * the system is supposed to retain ptes across resume. 0 otherwise.
- */
-static u64 read_last_pte(struct i915_address_space *vm)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- gen8_pte_t __iomem *ptep;
-
- if (!suspend_retains_ptes(vm))
- return 0;
-
- GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
- ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
- return readq(ptep);
-}
-
/**
* i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
* @vm: The VM to suspend the mappings for
@@ -184,10 +160,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
i915_gem_object_unlock(obj);
}
- if (!suspend_retains_ptes(vm))
- vm->clear_range(vm, 0, vm->total);
- else
- i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
+ vm->clear_range(vm, 0, vm->total);
vm->skip_pte_rewrite = save_skip_rewrite;
@@ -536,8 +509,6 @@ static int init_ggtt(struct i915_ggtt *ggtt)
struct drm_mm_node *entry;
int ret;
- ggtt->pte_lost = true;
-
/*
* GuC requires all resources that we're sharing with it to be placed in
* non-WOPCM memory. If GuC is not present or not in use we still need a
@@ -1236,20 +1207,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
{
struct i915_vma *vma;
bool write_domain_objs = false;
- bool retained_ptes;
drm_WARN_ON(>i915->drm, !vm->is_ggtt && !vm->is_dpt);
- /*
-* First fill our portion of the GTT with scratch pages if
-* they were not retained across suspend.
-*/
- retained_ptes = suspend_retains_ptes(vm) &&
- !i915_vm_to_ggtt(vm)->pte_lost &&
- !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte !=
read_last_pte(vm));
-
- if (!retained_ptes)
- vm->clear_range(vm, 0, vm->total);
+ /* First fill our portion of the GTT with scratch pages */
+ vm->clear_range(vm, 0, vm->total);
/* clflush objects bound into the GGTT and rebind them. */
list_for_each_entry(vma, >bound_list, vm_link) {
@@ -1258,16 +1220,16 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
atomic_read(>flags) & I915_VMA_BIND_MASK;
GEM_BUG_ON(!was_bound);
- if (!retained_ptes) {
- /*
-* Clear the bound flags of the vma resource to allow
-* ptes to be repopulated.
-*/
- vma->resource->bound_flags = 0;
- vma->ops->bind_vma(vm, NULL, vma->resource,
- obj ? obj->cache_level : 0,
- was_bound);
- }
+
+ /*
+* Clear the bound flags of the vma resource to allow
+* ptes to be repopulated.
+*/
+ vma->resource->bound_flags = 0;
+ vma->ops->bind_vma(vm, NULL, vma->resource,
+ obj ? obj->cache_level : 0,
+ was_bound);
+
if (obj) { /* only used during resume => exclusive access */
write_domain_objs |= fetch_and_zero(>write_domain);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
@@ -1295,8 +1257,3 @@
[PATCH v3 0/5] Add guard padding around i915_vma
Hi,
This series adds guards around vma's but setting a pages at the
beginning and at the end that work as padding.
The first user of the vma guard are scanout objects which don't
need anymore to add scratch to all the unused ggtt's and speeding
up up considerably the boot and resume by several hundreds of
milliseconds up to over a full second in slower machines.
Because of this we don't need anymore 2ef6efa79fec ("drm/i915:
Improve on suspend / resume time with VT-d enabled") which gets
reverted.
Thanks Tvrtko for the review.
Andi
Changelog
=
v2 -> v3:
- fix Tvrtko's comments: explain in a comment why the guard is
is alligned as the vma and remove a GEM_BUG_ON() in case the
the total padding was exceeding the size of the va.
- the display_alignment is declared as u32 instead of a u64 in
a separate patch.
v1 -> v2:
- Revert 2ef6efa79fec ("drm/i915: Improve on suspend / resume
time with VT-d enabled")
Andi Shyti (2):
Revert "drm/i915: Improve on suspend / resume time with VT-d enabled"
drm/i915: Limit the display memory alignment to 32 bit instead of 64
Chris Wilson (3):
drm/i915: Wrap all access to i915_vma.node.start|size
drm/i915: Introduce guard pages to i915_vma
drm/i915: Refine VT-d scanout workaround
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 15 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 +++---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 23 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 15 ++-
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 +-
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 108 --
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 24
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 +--
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c| 16 ---
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 66 ---
drivers/gpu/drm/i915/i915_vma.h | 52 -
drivers/gpu/drm/i915/i915_vma_resource.c | 4 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 17 ++-
drivers/gpu/drm/i915/i915_vma_types.h | 3 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 20 ++--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-
37 files changed, 267 insertions(+), 259 deletions(-)
--
2.38.1
Re: [PATCH v28 6/7] drm/mediatek: add drm ovl_adaptor sub driver for MT8195
On Mon, Nov 07, 2022 at 03:24:12PM +0800, Nancy.Lin wrote:
> Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
> the component exists in the path.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: CK Hu
> Tested-by: AngeloGioacchino Del Regno
>
> Tested-by: Bo-Chen Chen
> Tested-by: Nícolas F. R. A. Prado
> ---
[..]
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 30dcb65d8a5a..ce5617ad04cb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
[..]
> @@ -897,22 +906,18 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> crtc_i++;
>
> for (i = 0; i < path_len; i++) {
> - enum mtk_ddp_comp_id comp_id = path[i];
> + unsigned int comp_id = path[i];
> struct device_node *node;
> - struct mtk_ddp_comp *comp;
>
> node = priv->comp_node[comp_id];
> - comp = >ddp_comp[comp_id];
> -
> - if (!node) {
> - dev_info(dev,
> - "Not creating crtc %d because component %d is
> disabled or missing\n",
> - crtc_i, comp_id);
> - return 0;
> - }
>
> - if (!comp->dev) {
> - dev_err(dev, "Component %pOF not initialized\n", node);
> + /* Not all drm components have a DTS device node, such as
> ovl_adaptor,
> + * which is the drm bring up sub driver
> + */
> + if (!node && comp_id != DDP_COMPONENT_DRM_OVL_ADAPTOR) {
> + dev_err(dev,
> + "Not creating crtc %d because component %d is
> disabled, missing or not initialized\n",
> + crtc_i, comp_id);
> return -ENODEV;
Why do you change the behavior here? If !node, the return should be 0, because
there are two separate data streams, for internal and external display, and they
are optional. It should be possible to for example have the nodes for external
display disabled in DT and still have the driver probe and have a working
internal display. But with this change you're breaking that. Also, this message
should stay as dev_info and not mention "not initialized", so basically it
should stay the same as before the change.
Thanks,
Nícolas
Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization
On 11/23/22 21:09, Jagan Teki wrote:
On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
On 11/17/22 14:04, Marek Szyprowski wrote:
On 17.11.2022 05:58, Marek Vasut wrote:
On 11/10/22 19:38, Jagan Teki wrote:
DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.
Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.
This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).
v8, v7, v6, v5:
* none
v4:
* update init handling to ensure host init done on first cmd transfer
v3:
* none
v2:
* check initialized state in samsung_dsim_init
v1:
* keep DSI init in host transfer
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 25 +
include/drm/bridge/samsung-dsim.h | 5 +++--
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index bb1f45fd5a88..ec7e01ae02ea 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
samsung_dsim *dsi)
disable_irq(dsi->irq);
}
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
flag)
{
const struct samsung_dsim_driver_data *driver_data =
dsi->driver_data;
+if (dsi->state & flag)
+return 0;
+
samsung_dsim_reset(dsi);
-samsung_dsim_enable_irq(dsi);
+
+if (!(dsi->state & DSIM_STATE_INITIALIZED))
+samsung_dsim_enable_irq(dsi);
if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
samsung_dsim *dsi)
samsung_dsim_set_phy_ctrl(dsi);
samsung_dsim_init_link(dsi);
+dsi->state |= flag;
+
return 0;
}
@@ -1269,6 +1276,10 @@ static void
samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
}
dsi->state |= DSIM_STATE_ENABLED;
+
+ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+if (ret)
+return;
}
static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1458,12 +1469,9 @@ static ssize_t
samsung_dsim_host_transfer(struct mipi_dsi_host *host,
if (!(dsi->state & DSIM_STATE_ENABLED))
return -EINVAL;
-if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-ret = samsung_dsim_init(dsi);
-if (ret)
-return ret;
-dsi->state |= DSIM_STATE_INITIALIZED;
-}
+ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
This triggers full controller reset and reprogramming upon first
command transfer, is such heavy handed reload really necessary ?
Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
DSI. If this is a real issue for you, then maybe the driver could do the
initialization conditionally, in prepare() callback in case of IMX and
on the first transfer in case of Exynos?
That's odd , it does actually break panel support for me, without this
double reset the panel works again. But I have to wonder, why would such
a full reset be necessary at all , even on the exynos ?
Is it breaking samsung_dsim_reset from host_transfer? maybe checking
whether a reset is required before calling it might fix the issue. I
agree with double initialization is odd but it seems it is required on
some panels in Exynos, I think tweaking them and adjusting the panel
code might resolve this discrepancy.
Can someone provide further details on the exynos problem ?
[PATCH -next] drm/amdgpu: update docum. filename following rename
Fix documentation build errors for amdgpu: correct the filename.
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -sphinx-version
5.3.0 -function MMU Notifier ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c' failed
with return code 1
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -sphinx-version
5.3.0 -internal ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c' failed with return
code 2
Fixes: d9483ecd327b ("drm/amdgpu: rename the files for HMM handling")
Signed-off-by: Randy Dunlap
Cc: Christian König
Cc: Alex Deucher
Cc: Felix Kuehling
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
Documentation/gpu/amdgpu/driver-core.rst |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/Documentation/gpu/amdgpu/driver-core.rst
b/Documentation/gpu/amdgpu/driver-core.rst
--- a/Documentation/gpu/amdgpu/driver-core.rst
+++ b/Documentation/gpu/amdgpu/driver-core.rst
@@ -148,10 +148,10 @@ PRIME Buffer Sharing
MMU Notifier
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
:doc: MMU Notifier
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
:internal:
AMDGPU Virtual Memory
[PATCH] drm/amd/display: fix PSR-SU/DSC interoperability support
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.
Signed-off-by: Hamza Mahfooz
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
index 26291db0a3cf..55acadf0b63f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
@@ -53,6 +53,41 @@ static bool link_supports_psrsu(struct dc_link *link)
return true;
}
+static bool psr_su_set_y_granularity(struct dc *dc, struct dc_link *link,
+struct dc_stream_state *stream,
+struct psr_config *config)
+{
+ u16 pic_height;
+ u8 slice_height;
+
+ if (!dc->caps.edp_dsc_support ||
+ link->panel_config.dsc.disable_dsc_edp ||
+
!link->dpcd_caps.dsc_caps.dsc_basic_caps.fields.dsc_support.DSC_SUPPORT ||
+ !stream->timing.dsc_cfg.num_slices_v)
+ return true;
+
+ pic_height = stream->timing.v_addressable +
+ stream->timing.v_border_top + stream->timing.v_border_bottom;
+ slice_height = pic_height / stream->timing.dsc_cfg.num_slices_v;
+
+ if (slice_height) {
+ if (config->su_y_granularity &&
+ (slice_height % config->su_y_granularity)) {
+ WARN(1,
+"%s: dsc: %d, slice_height: %d, num_slices_v:
%d\n",
+__func__,
+
stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported,
+slice_height,
+stream->timing.dsc_cfg.num_slices_v);
+ return false;
+ }
+
+ config->su_y_granularity = slice_height;
+ }
+
+ return true;
+}
+
/*
* amdgpu_dm_set_psr_caps() - set link psr capabilities
* @link: link
@@ -122,6 +157,9 @@ bool amdgpu_dm_link_setup_psr(struct dc_stream_state
*stream)
psr_config.allow_multi_disp_optimizations =
(amdgpu_dc_feature_mask & DC_PSR_ALLOW_MULTI_DISP_OPT);
+ if (!psr_su_set_y_granularity(dc, link, stream, _config))
+ return false;
+
ret = dc_link_setup_psr(link, stream, _config,
_context);
}
--
2.38.1
[PATCH/RFC 0/3] Atari DRM driver
Hi all,
This RFC patch series adds a DRM driver for the good old Atari
ST/TT/Falcon hardware. It was developed and tested (only) on the ARAnyM
emulator.
Supported formats:
- C[1248],
- RG16 (both standard DRM (little-endian) and native (big-endian)),
- XR24.
Patch overview:
1. The first patch adds two new helper functions for chunky-to-planar
conversion,
2. The second patch, posted by Thomas Zimmermann a long time ago,
introduces a mode_fixup simple kms helper function (more helpers
from his fbdev conversion helper function series have been included
(partially) in the Atari DRM driver itself),
3. The third patch is the actual Atari DRM driver. The patch was
created with "git format-patch -C", to avoid spamming you with code
that is identical to the existing Atari fbdev driver.
The driver is definitely not yet ready for upstream inclusion.
While mode switching usually works, it is far from optimal, and may
suffer from hick-ups. Hence the main objective for posting this
preliminary version is to receive feedback about the (wrong) helper
functions and callbacks I am using, and about what/how to improve.
Dependencies:
- drm-next
- Patch series [1] and [2],
- For running modetest, you want to apply patch series [3], [4], and
[5] to libdrm.
For your testing convenience, I have pushed this series and its
dependencies to [6].
Thanks for your comments!
P.S. If you are more interested in the journey than in the destination,
perhaps you are interested in the presentation I gave at last
ELC-E?[7]
[1] "[PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and
RGB565 formats"
https://lore.kernel.org/r/3ee1f8144feb96c28742b22384189f1f83bcfc1a.1669221671.git.ge...@linux-m68k.org
[2] "[PATCH v3 0/2] drm/modes: Command line mode selection improvements"
https://lore.kernel.org/r/cover.1669405382.git.ge...@linux-m68k.org
[3] "[PATCH libdrm v2 00/10] Add support for low-color frame buffer
formats"
https://lore.kernel.org/r/cover.1657302034.git.ge...@linux-m68k.org
[4] "[PATCH libdrm v2 00/10] Big-endian fixes"
https://lore.kernel.org/r/cover.1657302103.git.ge...@linux-m68k.org
[5] "[PATCH libdrm] modetest: Add support for named modes containing
dashes"
[6]
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=atari-drm-wip-v1
[7]
https://osseu2022.sched.com/event/15z6T/trading-fbdev-for-drm-no-returns-accepted-geert-uytterhoeven-glider-bv
Geert Uytterhoeven (2):
video: fbdev: c2p: Add transp2() and transp2x()
drm: atari: Add a DRM driver for Atari graphics hardware
Thomas Zimmermann (1):
drm/simple-kms-helper: Add mode_fixup() to simple display pipe
drivers/gpu/drm/drm_simple_kms_helper.c | 15 +
drivers/gpu/drm/tiny/Kconfig |8 +
drivers/gpu/drm/tiny/Makefile |1 +
.../atafb.c => gpu/drm/tiny/atari_drm.c} | 2536 +
drivers/video/fbdev/c2p_core.h| 38 +
include/drm/drm_simple_kms_helper.h | 43 +
6 files changed, 2113 insertions(+), 528 deletions(-)
copy drivers/{video/fbdev/atafb.c => gpu/drm/tiny/atari_drm.c} (57%)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH/RFC 2/3] drm/simple-kms-helper: Add mode_fixup() to simple display pipe
From: Thomas Zimmermann
The mode fix-up function for simple display helpers is equivalent to the
regular pipeline's CRTC mode fix-up function. It's called to adjust the
CRTC's display mode for the encoder. Add this function for DRM fbconv
helpers.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/drm_simple_kms_helper.c | 15 +
include/drm/drm_simple_kms_helper.h | 43 +
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 3ef420ec4534aab5..3d7f859ac9de6814 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -96,6 +96,20 @@ drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
return pipe->funcs->mode_valid(pipe, mode);
}
+static bool
+drm_simple_kms_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct drm_simple_display_pipe *pipe;
+
+ pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+ if (!pipe->funcs || !pipe->funcs->mode_fixup)
+ return true;
+
+ return pipe->funcs->mode_fixup(crtc, mode, adjusted_mode);
+}
+
static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -141,6 +155,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc
*crtc,
static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
.mode_valid = drm_simple_kms_crtc_mode_valid,
+ .mode_fixup = drm_simple_kms_crtc_mode_fixup,
.atomic_check = drm_simple_kms_crtc_check,
.atomic_enable = drm_simple_kms_crtc_enable,
.atomic_disable = drm_simple_kms_crtc_disable,
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index 2298fe3af4cd7abb..2312d089ae85a2b6 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -52,6 +52,49 @@ struct drm_simple_display_pipe_funcs {
enum drm_mode_status (*mode_valid)(struct drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode);
+ /**
+* @mode_fixup:
+*
+* This callback is used to validate a mode. The parameter mode is the
+* display mode that userspace requested, adjusted_mode is the mode the
+* encoders need to be fed with. Note that this is the inverse semantics
+* of the meaning for the _encoder and _bridge_funcs.mode_fixup
+* vfunc. If the CRTC of the simple display pipe cannot support the
+* requested conversion from mode to adjusted_mode it should reject the
+* modeset.
+*
+* This function is optional.
+*
+* NOTE:
+*
+* This function is called in the check phase of atomic modesets, which
+* can be aborted for any reason (including on userspace's request to
+* just check whether a configuration would be possible). Atomic drivers
+* MUST NOT touch any persistent state (hardware or software) or data
+* structures except the passed in adjusted_mode parameter.
+*
+* Atomic drivers which need to inspect and adjust more state should
+* instead use the @atomic_check callback, but note that they're not
+* perfectly equivalent: @mode_valid is called from
+* drm_atomic_helper_check_modeset(), but @atomic_check is called from
+* drm_atomic_helper_check_planes(), because originally it was meant for
+* plane update checks only.
+*
+* Also beware that userspace can request its own custom modes, neither
+* core nor helpers filter modes to the list of probe modes reported by
+* the GETCONNECTOR IOCTL and stored in _connector.modes. To ensure
+* that modes are filtered consistently put any CRTC constraints and
+* limits checks into @mode_valid.
+*
+* RETURNS:
+*
+* True if an acceptable configuration is possible, false if the modeset
+* operation should be rejected.
+*/
+ bool (*mode_fixup)(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+
/**
* @enable:
*
--
2.25.1
[PATCH v3 1/2] drm/modes: parse_cmdline: Make mode->*specified handling more uniform
The various mode->*specified flags are not handled in an uniform way:
some flags are set by the corresponding drm_mode_parse_cmdline_*()
function, some flags by the caller of the function, and some flags by
both.
Make this uniform by making this the responsibility of the various
parsing helpers, i.e.
- Move the setting of mode->specified from caller to callee,
- Drop the duplicate setting of mode->bpp_specified and
mode->refresh_specified from callers.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Hans de Goede
Acked-by: Thomas Zimmermann
Acked-by: Maxime Ripard
---
v3:
- Add Acked-by,
v2:
- Add Reviewed-by, Acked-by,
---
drivers/gpu/drm/drm_modes.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3c8034a8c27bd25a..45b9e6aab766002a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1605,6 +1605,7 @@ static int drm_mode_parse_cmdline_res_mode(const char
*str, unsigned int length,
mode->yres = yres;
mode->cvt = cvt;
mode->rb = rb;
+ mode->specified = true;
return 0;
}
@@ -1921,8 +1922,6 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
mode);
if (ret)
return false;
-
- mode->specified = true;
}
/* No mode? Check for freestanding extras and/or options */
@@ -1944,8 +1943,6 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
ret = drm_mode_parse_cmdline_bpp(bpp_ptr, _end_ptr, mode);
if (ret)
return false;
-
- mode->bpp_specified = true;
}
if (refresh_ptr) {
@@ -1953,8 +1950,6 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
_end_ptr, mode);
if (ret)
return false;
-
- mode->refresh_specified = true;
}
/*
--
2.25.1
[PATCH/RFC 1/3] video: fbdev: c2p: Add transp2() and transp2x()
Add transpose operations on two 32-bit words, using normal or reverse
order.
To be used by the Atari DRM driver.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/c2p_core.h | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/video/fbdev/c2p_core.h b/drivers/video/fbdev/c2p_core.h
index cf5f1ebce65e6afd..480bd80fb31b57c0 100644
--- a/drivers/video/fbdev/c2p_core.h
+++ b/drivers/video/fbdev/c2p_core.h
@@ -142,6 +142,44 @@ static __always_inline void transp4x(u32 d[], unsigned int
n, unsigned int m)
}
+/*
+ * Transpose operations on 2 32-bit words
+ */
+
+static __always_inline void transp2(u32 d[], unsigned int n, unsigned int m)
+{
+ u32 mask = get_mask(n);
+
+ switch (m) {
+ case 1:
+ /* Single n x 1 block */
+ _transp(d, 0, 1, n, mask);
+ return;
+ }
+
+ BUILD_BUG();
+}
+
+
+/*
+ * Transpose operations on 2 32-bit words (reverse order)
+ */
+
+static __always_inline void transp2x(u32 d[], unsigned int n, unsigned int m)
+{
+ u32 mask = get_mask(n);
+
+ switch (m) {
+ case 1:
+ /* Single n x 1 block */
+ _transp(d, 1, 0, n, mask);
+ return;
+ }
+
+ BUILD_BUG();
+}
+
+
/*
* Compose two values, using a bitmask as decision value
* This is equivalent to (a & mask) | (b & ~mask)
--
2.25.1
[PATCH/RFC 3/3] drm: atari: Add a DRM driver for Atari graphics hardware
Supported formats: - C[1248], - RG16 (both standard DRM (little-endian) and native (big-endian)), - XR24. RG16 and XR24 are only supported with the underlying RGB565 hardware mode on Falcon, and are subject to hardware restrictions (limited to e.g. "qvga" and "hvga" modes). All formats use a shadow buffer (TODO: BE RG16 buffers from ST-RAM). Initial mode setting works, later mode changes sometimes fail. Developed and tested on ARAnyM. Probably this should not be under /tiny ;-) root@atari:~# modetest -M atari_drm Encoders: id crtctypepossible crtcs possible clones 35 34 none0x0001 0x0001 Connectors: id encoder status namesize (mm) modes encoders 31 35 connected VGA-1 0x0 9 35 modes: index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot #0 vga70 70.72 640 658 758 800 400 411 414 445 25176 flags: nhsync, pvsync, pcsync; type: preferred, driver #1 tt-mid 60.33 640 740 880 1000 480 496 526 534 32216 flags: nhsync, nvsync, ncsync; type: driver #2 vga 59.94 640 658 758 800 480 491 494 525 25176 flags: nhsync, nvsync, ncsync; type: driver #3 st-high 78.51 640 640 768 896 400 414 418 458 32216 flags: nhsync, nvsync, ncsync; type: driver #4 tt-low 88.72 320 420 560 680 480 496 526 534 32216 flags: nhsync, nvsync, ncsync; type: driver #5 hvga 59.94 320 329 379 400 480 491 494 525 12588 flags: nhsync, nvsync, ncsync; type: driver #6 st-mid 165.03 640 656 752 784 200 214 218 249 32216 flags: nhsync, nvsync, ncsync; type: driver #7 qvga 60.06 320 329 379 400 240 245 247 262 12588 flags: nhsync, nvsync, dblscan, ncsync; type: driver #8 st-low 278.84 320 336 432 464 200 214 218 249 32216 flags: nhsync, nvsync, ncsync; type: driver props: 1 EDID: flags: immutable blob blobs: value: 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 4 TILE: flags: immutable blob blobs: value: CRTCs: id fb pos size 34 36 (0,0) (320x240) #0 qvga 60.06 320 329 379 400 240 245 247 262 12588 flags: nhsync, nvsync, dblscan, ncsync; type: driver props: 24 VRR_ENABLED: flags: range values: 0 1 value: 0 28 GAMMA_LUT: flags: blob blobs: value: 100010001000110011001100 120012001200130013001300 140014001400150015001500 160016001600170017001700 180018001800190019001900 1a001a001a001b001b001b00 1c001c001c001d001d001d00 1e001e001e001f001f001f00 200020002000210021002100 220022002200230023002300 240024002400250025002500 260026002600270027002700 280028002800290029002900 2a002a002a002b002b002b00 2c002c002c002d002d002d00 2e002e002e002f002f002f00 300030003000310031003100 320032003200330033003300 340034003400350035003500 360036003600370037003700 380038003800390039003900 3a003a003a003b003b003b00 3c003c003c003d003d003d00 3e003e003e003f003f003f00 400040004000410041004100 420042004200430043004300 440044004400450045004500 460046004600470047004700 480048004800490049004900 4a004a004a004b004b004b00 4c004c004c004d004d004d00
[PATCH v3 0/2] drm/modes: Command line mode selection improvements
Hi all,
This patch series contains improvements for specifying video modes on the
kernel command line.
I don't expect the second patch to be acceptable as-is, but it's a
dependency for posting the RFC Atari DRM driver...
Changes compared to v2[1]:
- Drop applied and obsolete patches,
- Add Acked-by,
- Update for the switch from names to named mode descriptors.
Changes compared to v1[2]:
- Add Reviewed-by, Acked-by,
- Keep length check.
This has been tested on ARAnyM using a work-in-progress Atari DRM
driver.
Thanks for your comments!
[1] "[PATCH v2 0/5] drm/modes: Command line mode selection fixes and
improvements"
https://lore.kernel.org/r/cover.1657788997.git.ge...@linux-m68k.org
[2] "[PATCH 0/5] drm/modes: Command line mode selection fixes and
improvements"
https://lore.kernel.org/r/cover.1657301107.git.ge...@linux-m68k.org
Geert Uytterhoeven (2):
drm/modes: parse_cmdline: Make mode->*specified handling more uniform
drm/modes: Add support for driver-specific named modes
drivers/gpu/drm/drm_modes.c | 26 +-
include/drm/drm_connector.h | 18 ++
2 files changed, 27 insertions(+), 17 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v3 2/2] drm/modes: Add support for driver-specific named modes
The mode parsing code recognizes named modes only if they are explicitly
listed in the internal named mode list, which is currently limited to
"NTSC" and "PAL".
Provide a mechanism for drivers to override this list to support custom
modes.
Ideally, this list should just come from the driver's actual list of
modes, but connector->probed_modes is not yet populated at the time of
parsing.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Hans de Goede
---
I don't expect this patch to be acceptable as-is, but it's a dependency
for posting the RFC Atari DRM driver.
v3:
- Update for the switch from names to named mode descriptors,
v2:
- Add Reviewed-by.
---
drivers/gpu/drm/drm_modes.c | 19 ---
include/drm/drm_connector.h | 18 ++
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 45b9e6aab766002a..9ea928b35e728d13 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1751,14 +1751,6 @@ static int drm_mode_parse_cmdline_options(const char
*str,
return 0;
}
-struct drm_named_mode {
- const char *name;
- unsigned int pixel_clock_khz;
- unsigned int xres;
- unsigned int yres;
- unsigned int flags;
-};
-
#define NAMED_MODE(_name, _pclk, _x, _y, _flags) \
{ \
.name = _name, \
@@ -1771,12 +1763,15 @@ struct drm_named_mode {
static const struct drm_named_mode drm_named_modes[] = {
NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
+ { /* sentinel */ }
};
static int drm_mode_parse_cmdline_named_mode(const char *name,
unsigned int name_end,
+const struct drm_connector
*connector,
struct drm_cmdline_mode
*cmdline_mode)
{
+ const struct drm_named_mode *named_modes;
unsigned int i;
if (!name_end)
@@ -1802,8 +1797,9 @@ static int drm_mode_parse_cmdline_named_mode(const char
*name,
* We're sure we're a named mode at this point, iterate over the
* list of modes we're aware of.
*/
- for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
- const struct drm_named_mode *mode = _named_modes[i];
+ named_modes = connector->named_modes ? : drm_named_modes;
+ for (i = 0; named_modes[i].name; i++) {
+ const struct drm_named_mode *mode = _modes[i];
int ret;
ret = str_has_prefix(name, mode->name);
@@ -1903,7 +1899,8 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
if (!mode_end)
return false;
- ret = drm_mode_parse_cmdline_named_mode(name, mode_end, mode);
+ ret = drm_mode_parse_cmdline_named_mode(name, mode_end, connector,
+ mode);
if (ret < 0)
return false;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 565cf9d3c550926f..ff78ac214e475086 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1315,6 +1315,14 @@ struct drm_cmdline_mode {
struct drm_connector_tv_margins tv_margins;
};
+struct drm_named_mode {
+ const char *name;
+ unsigned int pixel_clock_khz;
+ unsigned int xres;
+ unsigned int yres;
+ unsigned int flags;
+};
+
/**
* struct drm_connector - central DRM connector control structure
*
@@ -1708,6 +1716,16 @@ struct drm_connector {
/** @hdr_sink_metadata: HDR Metadata Information read from sink */
struct hdr_sink_metadata hdr_sink_metadata;
+
+ /**
+* @named_modes:
+*
+* Optional NULL-terminated array of names to be considered valid mode
+* names. This lets the command line option parser distinguish between
+* mode names and freestanding extras and/or options.
+* If not set, a set of defaults will be used.
+*/
+ const struct drm_named_mode *named_modes;
};
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
--
2.25.1
Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: A collection of typo and documentation fixes
On Thu, Nov 24, 2022 at 1:43 AM Christian König wrote: > > Am 24.11.22 um 10:05 schrieb Daniel Vetter: > > On Thu, Nov 24, 2022 at 08:03:09AM +0100, Christian König wrote: > >> Am 23.11.22 um 20:35 schrieb T.J. Mercier: > >>> I've been collecting these typo fixes for a while and it feels like > >>> time to send them in. > >>> > >>> Signed-off-by: T.J. Mercier > >> Acked-by: Christian König > > Will you also push this? I think tj doesn't have commit rights yet, and I > > somehow can't see the patch locally (I guess it's stuck in moderation). > > I was just about to complain that this doesn't apply cleanly to > drm-misc-next. > > Trivial problem, one of the typos was just removed by Dimitry a few > weeks ago. > > I've fixed that up locally and pushed the result, but nevertheless > please make sure that DMA-buf patches are based on the drm branches. > I'm sorry, this was on top of a random spot in Linus's 6.1-rc5. (84368d882b96 Merge tag 'soc-fixes-6.1-3') I'm not sure why I did that, but I suspect it was after a fresh git pull. I have too many repos. Thanks all for the reviews. > Thanks, > Christian. > > > -Daniel > > > >>> --- > >>>drivers/dma-buf/dma-buf.c | 14 +++--- > >>>include/linux/dma-buf.h | 6 +++--- > >>>2 files changed, 10 insertions(+), 10 deletions(-) > >>> > >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > >>> index dd0f83ee505b..614ccd208af4 100644 > >>> --- a/drivers/dma-buf/dma-buf.c > >>> +++ b/drivers/dma-buf/dma-buf.c > >>> @@ -1141,7 +1141,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, > >>> DMA_BUF); > >>> * > >>> * @dmabuf: [in]buffer which is moving > >>> * > >>> - * Informs all attachmenst that they need to destroy and recreated all > >>> their > >>> + * Informs all attachments that they need to destroy and recreate all > >>> their > >>> * mappings. > >>> */ > >>>void dma_buf_move_notify(struct dma_buf *dmabuf) > >>> @@ -1159,11 +1159,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, > >>> DMA_BUF); > >>>/** > >>> * DOC: cpu access > >>> * > >>> - * There are mutliple reasons for supporting CPU access to a dma buffer > >>> object: > >>> + * There are multiple reasons for supporting CPU access to a dma buffer > >>> object: > >>> * > >>> * - Fallback operations in the kernel, for example when a device is > >>> connected > >>> * over USB and the kernel needs to shuffle the data around first > >>> before > >>> - * sending it away. Cache coherency is handled by braketing any > >>> transactions > >>> + * sending it away. Cache coherency is handled by bracketing any > >>> transactions > >>> * with calls to dma_buf_begin_cpu_access() and > >>> dma_buf_end_cpu_access() > >>> * access. > >>> * > >>> @@ -1190,7 +1190,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF); > >>> * replace ION buffers mmap support was needed. > >>> * > >>> * There is no special interfaces, userspace simply calls mmap on > >>> the dma-buf > >>> - * fd. But like for CPU access there's a need to braket the actual > >>> access, > >>> + * fd. But like for CPU access there's a need to bracket the actual > >>> access, > >>> * which is handled by the ioctl (DMA_BUF_IOCTL_SYNC). Note that > >>> * DMA_BUF_IOCTL_SYNC can fail with -EAGAIN or -EINTR, in which case > >>> it must > >>> * be restarted. > >>> @@ -1264,10 +1264,10 @@ static int __dma_buf_begin_cpu_access(struct > >>> dma_buf *dmabuf, > >>> * preparations. Coherency is only guaranteed in the specified range > >>> for the > >>> * specified access direction. > >>> * @dmabuf: [in]buffer to prepare cpu access for. > >>> - * @direction: [in]length of range for cpu access. > >>> + * @direction: [in]direction of access. > >>> * > >>> * After the cpu access is complete the caller should call > >>> - * dma_buf_end_cpu_access(). Only when cpu access is braketed by both > >>> calls is > >>> + * dma_buf_end_cpu_access(). Only when cpu access is bracketed by both > >>> calls is > >>> * it guaranteed to be coherent with other DMA access. > >>> * > >>> * This function will also wait for any DMA transactions tracked > >>> through > >>> @@ -1307,7 +1307,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, > >>> DMA_BUF); > >>> * actions. Coherency is only guaranteed in the specified range for the > >>> * specified access direction. > >>> * @dmabuf: [in]buffer to complete cpu access for. > >>> - * @direction: [in]length of range for cpu access. > >>> + * @direction: [in]direction of access. > >>> * > >>> * This terminates CPU access started with dma_buf_begin_cpu_access(). > >>> * > >>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > >>> index 71731796c8c3..1d61a4f6db35 100644 > >>> --- a/include/linux/dma-buf.h > >>> +++ b/include/linux/dma-buf.h > >>> @@ -330,7 +330,7
Re: [PATCH 2/2] drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()
Applied the series. Thanks!
Alex
On Tue, Nov 22, 2022 at 6:13 AM Xiongfeng Wang
wrote:
>
> As comment of pci_get_class() says, it returns a pci_device with its
> refcount increased and decreased the refcount for the input parameter
> @from if it is not NULL.
>
> If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we
> need to call pci_dev_put() to decrease the refcount. Add the missing
> pci_dev_put() to avoid refcount leak.
>
> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> Signed-off-by: Xiongfeng Wang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index e363f56c72af..30c28a69e847 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@ -317,6 +317,7 @@ static bool amdgpu_atrm_get_bios(struct amdgpu_device
> *adev)
>
> if (!found)
> return false;
> + pci_dev_put(pdev);
>
> adev->bios = kmalloc(size, GFP_KERNEL);
> if (!adev->bios) {
> --
> 2.20.1
>
Re: [git pull] drm fixes for 6.1-rc7
The pull request you sent on Fri, 25 Nov 2022 13:47:02 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-11-25 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6fe0e074e76985c7be3eaa7a8fd51401a8999cae Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 1/9] drm/amdgpu: generally allow over-commit during BO allocation
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
>
> We already fallback to a dummy BO with no backing store when we
> allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
>
> Drop all those workarounds and generalize this for GTT as well. This
> fixes ENOMEM issues with runaway applications which try to allocate/free
> GTT in a loop and are otherwise only limited by the CPU speed.
>
> The CS will wait for the cleanup of freed up BOs to satisfy the
> various domain specific limits and so effectively throttle those
> buggy applications down to a sane allocation behavior again.
>
> Signed-off-by: Christian König
This looks like a good bug fix and unrelated to the rest of this series.
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 16 +++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
> 2 files changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index a0780a4e3e61..62e98f1ad770 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -113,7 +113,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev,
> unsigned long size,
> bp.resv = resv;
> bp.preferred_domain = initial_domain;
> bp.flags = flags;
> - bp.domain = initial_domain;
> + bp.domain = initial_domain | AMDGPU_GEM_DOMAIN_CPU;
> bp.bo_ptr_size = sizeof(struct amdgpu_bo);
>
> r = amdgpu_bo_create_user(adev, , );
> @@ -332,20 +332,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev,
> void *data,
> }
>
> initial_domain = (u32)(0x & args->in.domains);
> -retry:
> r = amdgpu_gem_object_create(adev, size, args->in.alignment,
> -initial_domain,
> -flags, ttm_bo_type_device, resv, );
> +initial_domain, flags,
> ttm_bo_type_device,
> +resv, );
> if (r && r != -ERESTARTSYS) {
> - if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
> - flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> - goto retry;
> - }
> -
> - if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
> - initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
> - goto retry;
> - }
> DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu,
> %d)\n",
> size, initial_domain, args->in.alignment, r);
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 974e85d8b6cc..919bbea2e3ac 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -581,11 +581,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
>
> bo->tbo.bdev = >mman.bdev;
> - if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
> - AMDGPU_GEM_DOMAIN_GDS))
> - amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
> - else
> - amdgpu_bo_placement_from_domain(bo, bp->domain);
> + amdgpu_bo_placement_from_domain(bo, bp->domain);
> if (bp->type == ttm_bo_type_kernel)
> bo->tbo.priority = 1;
>
> --
> 2.34.1
>
[pull] amdgpu, amdkfd drm-next-6.2
Hi Dave, Daniel, More stuff for 6.2. Mostly bug fixes at this point. The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6: Merge tag 'drm-intel-next-2022-11-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.2-2022-11-25 for you to fetch changes up to 10d2d1fc05f03ee1626b60761a3425622767513e: drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read" (2022-11-23 10:31:31 -0500) amd-drm-next-6.2-2022-11-25: amdgpu: - Old GCC fix - GFX11 fixes - PSP suspend/resume fix - PCI ref count fix - DC KASAN fix - DCN 3.2.x fixes - Dell platform suspend/resume fixes - DCN 3.1.4 fixes - RAS fixes - SMU 13.x fixes - Flex array changes - VCN 4.0 RAS updates - Add missing licsense to some files - Documentation updates - SR-IOV fixes - DP MST DSC fix amdkfd: - Fix topology locking in error case Alex Deucher (4): drm/amdgpu/psp: don't free PSP buffers on suspend Revert "drm/amd/display: fix dpms_off issue when disabling bios mode" drm/amdgpu: add missing license to some files drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read" Alvin Lee (6): drm/amd/display: Add margin on DRR vblank start for subvp drm/amd/display: Limit HW cursor size of >= 4k drm/amd/display: Check if PSR enabled when entering MALL drm/amd/display: Add debug options for increasing phantom lines drm/amd/display: Retain phantom plane/stream if validation fails drm/amd/display: Revert check for phantom BPP Aric Cyr (1): drm/amd/display: 3.2.213 Aurabindo Pillai (1): drm/amd/display: trigger timing sync only if TG is running Bob zhou (1): drm/amd/display: fix compilation issue with legacy gcc Camille Cho (1): drm/amd/display: new ABM config 2 Candice Li (1): drm/amd/pm: Enable bad memory page/channel recording support for smu v13_0_0 David Galiffi (1): drm/amd/display: Fix rotated cursor offset calculation Dillon Varone (5): drm/amd/display: Update soc bounding box for dcn32/dcn321 drm/amd/display: Use dummy pstate latency for subvp when needed on dcn32 drm/amd/display: Add check for DET fetch latency hiding for dcn32 drm/amd/display: Use viewport height for subvp mall allocation size drm/amd/display: Use new num clk levels struct for max mclk index Felix Kuehling (1): drm/amdkfd: Release the topology_lock in error case Ilya Bakoulin (1): drm/amd/display: Fix display corruption w/ VSR enable Jack Xiao (1): drm/amd/amdgpu: reserve vm invalidation engine for firmware Jane Jian (1): drm/amdgpu/vcn: re-use original vcn0 doorbell value Luben Tuikov (1): drm/amdgpu: Fix minmax warning Lyude Paul (2): drm/amdgpu/dm/mst: Fix uninitialized var in pre_compute_mst_dsc_configs_for_state() drm/amd/dc/dce120: Fix audio register mapping, stop triggering KASAN Mustapha Ghaddar (1): drm/amd/display: Phase 1 Add Bw Allocation source and header files Nicholas Kazlauskas (2): drm/amd/display: Update Z8 watermarks for DCN314 drm/amd/display: Add Z8 allow states to z-state support list Paulo Miguel Almeida (1): drm/amdgpu: Replace remaining 1-element array with flex-array Ren Zhijie (1): drm/amdgpu: fix unused-function error Rodrigo Siqueira (1): drm/amd/display: Add YCBCR2020 coefficients to CSC matrix Shikang Fan (1): drm/amdgpu: fix for suspend/resume kiq fence fallback under sriov Stanley.Yang (1): drm/amdgpu: fix use-after-free during gpu recovery Taimur Hassan (1): drm/amd/display: Avoid setting pixel rate divider to N/A Tao Zhou (2): drm/amdgpu: add register definition for VCN RAS initialization drm/amdgpu: enable RAS poison for VCN 2.6 Tsung-hua Lin (1): drm/amd/display: No display after resume from WB/CB Yang Yingliang (1): drm/amdgpu: fix pci device refcount leak ZhenGuo Yin (1): drm/amdgpu: update documentation of parameter amdgpu_gtt_size lyndonli (2): drm/amd/pm: update driver if header for smu_13_0_7 drm/amdgpu: add the fan abnormal detection feature drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 27 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 6 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 16 +-- drivers/gpu/drm/amd/amdgpu/mmsch_v4_0.h| 1 - drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
>
> Patches 1 to 4 prepare the MIPI code for the change and simplify
> the restof the patchset.
>
> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
> helpers and get the update automatically. Only ili9225 and st7586
> require changes to their source code.
>
> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
> needed, but streamlines the driver code and make sense overall.
>
> Testing is welcome, as I don't have any hardware to test these
> changes myself.
>
Tested-by: Noralf Trønnes # drm/tiny/mi0283qt
> Thomas Zimmermann (8):
> drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()
> drm/ili9225: Call MIPI DBI mode_valid helper
> drm/st7586: Call MIPI DBI mode_valid helper
> drm/mipi-dbi: Initialize default driver functions with macro
> drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update
> helpers
> drm/mipi-dbi: Support shadow-plane state
> drm/mipi-dbi: Use shadow-plane mappings
> drm/mipi-dbi: Move drm_dev_{enter,exit}() out from fb_dirty functions
>
> drivers/gpu/drm/drm_gem_atomic_helper.c | 31 +---
> drivers/gpu/drm/drm_mipi_dbi.c | 175 +++
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 6 +-
> drivers/gpu/drm/tiny/hx8357d.c | 5 +-
> drivers/gpu/drm/tiny/ili9163.c | 6 +-
> drivers/gpu/drm/tiny/ili9225.c | 42 +++--
> drivers/gpu/drm/tiny/ili9341.c | 5 +-
> drivers/gpu/drm/tiny/ili9486.c | 5 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 5 +-
> drivers/gpu/drm/tiny/panel-mipi-dbi.c| 5 +-
> drivers/gpu/drm/tiny/st7586.c| 45 +++--
> drivers/gpu/drm/tiny/st7735r.c | 5 +-
> include/drm/drm_gem_atomic_helper.h | 2 -
> include/drm/drm_mipi_dbi.h | 50 +-
> include/drm/drm_plane.h | 4 +-
> include/drm/drm_simple_kms_helper.h | 4 +-
> 17 files changed, 265 insertions(+), 132 deletions(-)
>
>
> base-commit: b7598e2b3a3116bb5ddbf756db30a0e5dc0877ea
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
Re: [PATCH 8/8] drm/mipi-dbi: Move drm_dev_{enter,exit}() out from fb_dirty functions
Den 21.11.2022 11.45, skrev Thomas Zimmermann: > Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks > of the modesetting pipeline. If drm_dev_enter() fails, the driver can > thus avoid unnecessary work. > > Signed-off-by: Thomas Zimmermann > --- Makes sense in order to make the code more readable, the other *_fb_dirty call sites (*_enable) are already protected. Reviewed-by: Noralf Trønnes
[PATCH v3 2/2] drm/amdgpu: Add work function for GPU reset event
Add a work function to send a GPU reset uevent and scheduled it during
a GPU reset.
Co-developed-by: Shashank Sharma
Signed-off-by: Shashank Sharma
Signed-off-by: André Almeida
---
V3:
- Merge two last commits
V2: Addressed review comments from Christian
- Changed the name of the work to gpu_reset_event_work
- Added a structure to accommodate some additional information
(like a PID and some flags)
- Do not add new structure in amdgpu.h
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 6b74df446694..88cb5b739c5d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -60,6 +60,8 @@
#include
#include
#include
+#include
+#include
#include
#include "dm_pp_interface.h"
@@ -1003,6 +1005,7 @@ struct amdgpu_device {
int asic_reset_res;
struct work_struct xgmi_reset_work;
+ struct work_struct gpu_reset_event_work;
struct list_headreset_list;
longgfx_timeout;
@@ -1036,6 +1039,7 @@ struct amdgpu_device {
pci_channel_state_t pci_channel_state;
struct amdgpu_reset_control *reset_cntl;
+ struct drm_reset_event_info reset_event_info;
uint32_t
ip_versions[MAX_HWIP][HWIP_MAX_INSTANCE];
boolram_is_direct_mapped;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b2b1c66bfe39..d04541fdb606 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -77,6 +77,7 @@
#include
#include
+#include
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
@@ -3365,6 +3366,19 @@ bool amdgpu_device_has_dc_support(struct amdgpu_device
*adev)
return amdgpu_device_asic_has_dc_support(adev->asic_type);
}
+static void amdgpu_device_reset_event_func(struct work_struct *__work)
+{
+ struct amdgpu_device *adev = container_of(__work, struct amdgpu_device,
+ gpu_reset_event_work);
+ /*
+* A GPU reset has happened, inform the userspace and pass the reset
+* related information
+*/
+ drm_sysfs_reset_event(>ddev, >reset_event_info);
+
+ put_pid(adev->reset_event_info.pid);
+}
+
static void amdgpu_device_xgmi_reset_func(struct work_struct *__work)
{
struct amdgpu_device *adev =
@@ -3616,6 +3630,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
amdgpu_device_delay_enable_gfx_off);
INIT_WORK(>xgmi_reset_work, amdgpu_device_xgmi_reset_func);
+ INIT_WORK(>gpu_reset_event_work, amdgpu_device_reset_event_func);
adev->gfx.gfx_off_req_count = 1;
adev->gfx.gfx_off_residency = 0;
@@ -4920,6 +4935,21 @@ int amdgpu_do_asic_reset(struct list_head
*device_list_handle,
goto out;
vram_lost =
amdgpu_device_check_vram_lost(tmp_adev);
+
+ if (reset_context->job &&
reset_context->job->vm) {
+ tmp_adev->reset_event_info.pid =
+
find_get_pid(reset_context->job->vm->task_info.pid);
+ } else {
+ tmp_adev->reset_event_info.pid = NULL;
+ }
+
+ if (vram_lost)
+ tmp_adev->reset_event_info.flags |=
+ DRM_RESET_EVENT_VRAM_LOST;
+
+ /* Send GPU reset event */
+ schedule_work(_adev->gpu_reset_event_work);
+
#ifdef CONFIG_DEV_COREDUMP
tmp_adev->reset_vram_lost = vram_lost;
memset(_adev->reset_task_info, 0,
--
2.38.1
[PATCH v3 1/2] drm: Add GPU reset sysfs event
From: Shashank Sharma
Add a sysfs event to notify userspace about GPU resets providing:
- PID that triggered the GPU reset, if any. Resets can happen from
kernel threads as well, in that case no PID is provided
- Information about the reset (e.g. was VRAM lost?)
Co-developed-by: André Almeida
Signed-off-by: André Almeida
Signed-off-by: Shashank Sharma
---
V3:
- Reduce information to just PID and flags
- Use pid pointer instead of just pid number
- BUG() if no reset info is provided
V2:
- Addressed review comments from Christian and Amar
- move the reset information structure to DRM layer
- drop _ctx from struct name
- make pid 32 bit(than 64)
- set flag when VRAM invalid (than valid)
- add process name as well (Amar)
---
drivers/gpu/drm/drm_sysfs.c | 26 ++
include/drm/drm_sysfs.h | 13 +
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 430e00b16eec..85777abf4194 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -409,6 +409,32 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_reset_event - generate a DRM uevent to indicate GPU reset
+ * @dev: DRM device
+ * @reset_info: The contextual information about the reset (like PID, flags)
+ *
+ * Send a uevent for the DRM device specified by @dev. This informs
+ * user that a GPU reset has occurred, so that an interested client
+ * can take any recovery or profiling measure.
+ */
+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event_info
*reset_info)
+{
+ unsigned char pid_str[13];
+ unsigned char flags_str[18];
+ unsigned char reset_str[] = "RESET=1";
+ char *envp[] = { reset_str, pid_str, flags_str, NULL };
+
+ DRM_DEBUG("generating reset event\n");
+
+ BUG_ON(!reset_info);
+
+ snprintf(pid_str, sizeof(pid_str), "PID=%u", pid_vnr(reset_info->pid));
+ snprintf(flags_str, sizeof(flags_str), "FLAGS=0x%llx",
reset_info->flags);
+ kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_reset_event);
+
/**
* drm_sysfs_connector_hotplug_event - generate a DRM uevent for any connector
* change
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 6273cac44e47..dbb0ac6230b8 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -2,15 +2,28 @@
#ifndef _DRM_SYSFS_H_
#define _DRM_SYSFS_H_
+#define DRM_RESET_EVENT_VRAM_LOST (1 << 0)
+
struct drm_device;
struct device;
struct drm_connector;
struct drm_property;
+/**
+ * struct drm_reset_event_info - Information about a GPU reset event
+ * @pid: Process that triggered the reset, if any
+ * @flags: Extra information around the reset event (e.g. is VRAM lost?)
+ */
+struct drm_reset_event_info {
+ struct pid *pid;
+ uint64_t flags;
+};
+
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event_info
*reset_info);
void drm_sysfs_connector_hotplug_event(struct drm_connector *connector);
void drm_sysfs_connector_status_event(struct drm_connector *connector,
struct drm_property *property);
--
2.38.1
[PATCH v3 0/2] drm: Add GPU reset sysfs
This patchset adds a udev event for DRM device's resets. Userspace apps can trigger GPU resets by misuse of graphical APIs or driver bugs. Either way, the GPU reset might lead the system to a broken state[1], that might be recovered if user has access to a tty or a remote shell. Arguably, this recovery could happen automatically by the system itself, thus this is the goal of this patchset. For debugging and report purposes, device coredump support was already added for amdgpu[2], but it's not suitable for programmatic usage like this one given the uAPI not being stable and the need for parsing. GL/VK is out of scope for this use, giving that we are dealing with device resets regardless of API. A basic userspace daemon is provided at [3] showing how the interface is used to recovery from resets. [1] A search for "reset" in DRM/AMD issue tracker shows reports of resets making the system unusable: https://gitlab.freedesktop.org/drm/amd/-/issues/?search=reset [2] https://lore.kernel.org/amd-gfx/20220602081538.1652842-2-amaranath.somalapu...@amd.com/ [3] https://gitlab.freedesktop.org/andrealmeid/gpu-resetd v2: https://lore.kernel.org/dri-devel/20220308180403.75566-1-contactshashanksha...@gmail.com/ André Almeida (1): drm/amdgpu: Add work function for GPU reset event Shashank Sharma (1): drm: Add GPU reset sysfs event drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 ++ drivers/gpu/drm/drm_sysfs.c| 26 +++ include/drm/drm_sysfs.h| 13 ++ 4 files changed, 73 insertions(+) -- 2.38.1
Re: [PATCH 6/8] drm/mipi-dbi: Support shadow-plane state
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce struct drm_mipi_dbi_plane_state that contains state related to
> MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
> so that MIPI DBI drivers can use the vmap'ed GEM-buffer memory. Implement
> state helpers, the {begin,end}_fb_access helpers and wire up everything.
>
> With this commit, MIPI DBI drivers can access the GEM object's memory
> that is provided by shadow-plane state. The actual changes to drivers
> are implemented separately. The new struct drm_mipi_dbi_plane was added
> to avoid exposing struct drm_shadow_plane_state directly. The latter is
> a detail of the actual implementation and having it in the MIPI driver
> interface seems unintuitive.
I don't understand this reasoning. The update functions still uses
drm_shadow_plane_state in order to access ->data[0]. If you want to
avoid exposing it, can't you add an accessor function for ->data[0]
instead? That would actually be useful to me at least since when I first
read the shadow plane code I didn't understand what data really was
referring to. fb_map would have been more clear to me.
Noralf.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 113 +
> drivers/gpu/drm/tiny/ili9225.c | 5 ++
> drivers/gpu/drm/tiny/st7586.c | 5 ++
> include/drm/drm_mipi_dbi.h | 30 -
> 4 files changed, 152 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 40e59a3a6481e..3030344d25b48 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -436,6 +436,119 @@ void mipi_dbi_pipe_disable(struct
> drm_simple_display_pipe *pipe)
> }
> EXPORT_SYMBOL(mipi_dbi_pipe_disable);
>
> +/**
> + * mipi_dbi_pipe_begin_fb_access - MIPI DBI pipe begin-access helper
> + * @pipe: Display pipe
> + * @plane_state: Plane state
> + *
> + * This function implements struct _simple_display_funcs.begin_fb_access.
> + *
> + * See drm_gem_begin_shadow_fb_access() for details and
> mipi_dbi_pipe_cleanup_fb()
> + * for cleanup.
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + */
> +int mipi_dbi_pipe_begin_fb_access(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *plane_state)
> +{
> + return drm_gem_begin_shadow_fb_access(>plane, plane_state);
> +}
> +EXPORT_SYMBOL(mipi_dbi_pipe_begin_fb_access);
> +
> +/**
> + * mipi_dbi_pipe_end_fb_access - MIPI DBI pipe end-access helper
> + * @pipe: Display pipe
> + * @plane_state: Plane state
> + *
> + * This function implements struct _simple_display_funcs.end_fb_access.
> + *
> + * See mipi_dbi_pipe_begin_fb_access().
> + */
> +void mipi_dbi_pipe_end_fb_access(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *plane_state)
> +{
> + drm_gem_end_shadow_fb_access(>plane, plane_state);
> +}
> +EXPORT_SYMBOL(mipi_dbi_pipe_end_fb_access);
> +
> +/**
> + * mipi_dbi_pipe_reset_plane - MIPI DBI plane-reset helper
> + * @pipe: Display pipe
> + *
> + * This function implements struct _simple_display_funcs.reset_plane
> + * for MIPI DBI planes.
> + */
> +void mipi_dbi_pipe_reset_plane(struct drm_simple_display_pipe *pipe)
> +{
> + struct drm_plane *plane = >plane;
> + struct mipi_dbi_plane_state *mipi_dbi_plane_state;
> +
> + if (plane->state) {
> + mipi_dbi_pipe_destroy_plane_state(pipe, plane->state);
> + plane->state = NULL; /* must be set to NULL here */
> + }
> +
> + mipi_dbi_plane_state = kzalloc(sizeof(*mipi_dbi_plane_state),
> GFP_KERNEL);
> + if (!mipi_dbi_plane_state)
> + return;
> + __drm_gem_reset_shadow_plane(plane,
> _dbi_plane_state->shadow_plane_state);
> +}
> +EXPORT_SYMBOL(mipi_dbi_pipe_reset_plane);
> +
> +/**
> + * mipi_dbi_pipe_duplicate_plane_state - duplicates MIPI DBI plane state
> + * @pipe: Display pipe
> + *
> + * This function implements struct
> _simple_display_funcs.duplicate_plane_state
> + * for MIPI DBI planes.
> + *
> + * See drm_gem_duplicate_shadow_plane_state() for additional details.
> + *
> + * Returns:
> + * A pointer to a new plane state on success, or NULL otherwise.
> + */
> +struct drm_plane_state *mipi_dbi_pipe_duplicate_plane_state(struct
> drm_simple_display_pipe *pipe)
> +{
> + struct drm_plane *plane = >plane;
> + struct drm_plane_state *plane_state = plane->state;
> + struct mipi_dbi_plane_state *new_mipi_dbi_plane_state;
> + struct drm_shadow_plane_state *new_shadow_plane_state;
> +
> + if (!plane_state)
> + return NULL;
> +
> + new_mipi_dbi_plane_state = kzalloc(sizeof(*new_mipi_dbi_plane_state),
> GFP_KERNEL);
> + if (!new_mipi_dbi_plane_state)
> + return NULL;
> + new_shadow_plane_state = _mipi_dbi_plane_state->shadow_plane_state;
> +
> + __drm_gem_duplicate_shadow_plane_state(plane,
Re: [PATCH 5/8] drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update helpers
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Move the vmap/vunmap blocks from the inner fb_dirty helpers into the
> MIPI DBI update helpers. The function calls can result in waiting and/or
> processing overhead. Reduce the penalties by executing the functions once
> in the outer-most function of the pipe update.
>
> This change also prepares for MIPI DBI for shadow-plane helpers. With
> shadow-plane helpers, transfer source buffers are mapped into kernel
> address space automatically.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 60 +++---
> drivers/gpu/drm/tiny/ili9225.c | 31 ++
> drivers/gpu/drm/tiny/st7586.c | 28 +++-
> include/drm/drm_mipi_dbi.h | 6 ++--
> 4 files changed, 81 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index a6ac565808765..40e59a3a6481e 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -192,6 +192,7 @@ EXPORT_SYMBOL(mipi_dbi_command_stackbuf);
> /**
> * mipi_dbi_buf_copy - Copy a framebuffer, transforming it if necessary
> * @dst: The destination buffer
> + * @src: The source buffer
> * @fb: The source framebuffer
> * @clip: Clipping rectangle of the area to be copied
> * @swap: When true, swap MSB/LSB of 16-bit values
> @@ -199,12 +200,13 @@ EXPORT_SYMBOL(mipi_dbi_command_stackbuf);
> * Returns:
> * Zero on success, negative error code on failure.
> */
> -int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
> +int mipi_dbi_buf_copy(void *dst, struct iosys_map *src, struct
> drm_framebuffer *fb,
> struct drm_rect *clip, bool swap)
> {
> struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> - struct iosys_map map[DRM_FORMAT_MAX_PLANES];
> - struct iosys_map data[DRM_FORMAT_MAX_PLANES];
> + struct iosys_map data[DRM_FORMAT_MAX_PLANES] = {
> + *src,
> + };
I would prefer that you used src directly when calling the drm_fb_*
functions, data can be anything and to me it isn't clear what that
contains when I see it (ofc now I know, but next year I've forgotten).
And is the array necessary, this helper will only ever support one color
plane after all?
> struct iosys_map dst_map = IOSYS_MAP_INIT_VADDR(dst);
> int ret;
>
> @@ -212,10 +214,6 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> if (ret)
> return ret;
>
> - ret = drm_gem_fb_vmap(fb, map, data);
> - if (ret)
> - goto out_drm_gem_fb_end_cpu_access;
> -
> switch (fb->format->format) {
> case DRM_FORMAT_RGB565:
> if (swap)
> @@ -232,8 +230,6 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> ret = -EINVAL;
> }
>
> - drm_gem_fb_vunmap(fb, map);
> -out_drm_gem_fb_end_cpu_access:
> drm_gem_fb_end_cpu_access(fb, DMA_FROM_DEVICE);
>
> return ret;
> @@ -257,10 +253,9 @@ static void mipi_dbi_set_window_address(struct
> mipi_dbi_dev *dbidev,
>ys & 0xff, (ye >> 8) & 0xff, ye & 0xff);
> }
>
> -static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect
> *rect)
> +static void mipi_dbi_fb_dirty(struct iosys_map *src, struct drm_framebuffer
> *fb,
> + struct drm_rect *rect)
> {
> - struct iosys_map map[DRM_FORMAT_MAX_PLANES];
> - struct iosys_map data[DRM_FORMAT_MAX_PLANES];
> struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> unsigned int height = rect->y2 - rect->y1;
> unsigned int width = rect->x2 - rect->x1;
> @@ -270,16 +265,9 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> *fb, struct drm_rect *rect)
> bool full;
> void *tr;
>
> - if (WARN_ON(!fb))
> - return;
> -
> if (!drm_dev_enter(fb->dev, ))
> return;
>
> - ret = drm_gem_fb_vmap(fb, map, data);
> - if (ret)
> - goto err_drm_dev_exit;
> -
> full = width == fb->width && height == fb->height;
>
> DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> DRM_RECT_ARG(rect));
> @@ -287,11 +275,11 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> *fb, struct drm_rect *rect)
> if (!dbi->dc || !full || swap ||
> fb->format->format == DRM_FORMAT_XRGB) {
> tr = dbidev->tx_buf;
> - ret = mipi_dbi_buf_copy(dbidev->tx_buf, fb, rect, swap);
> + ret = mipi_dbi_buf_copy(tr, src, fb, rect, swap);
> if (ret)
> goto err_msg;
> } else {
> - tr = data[0].vaddr; /* TODO: Use mapping abstraction properly */
> + tr = src->vaddr; /* TODO: Use mapping abstraction properly */
> }
>
> mipi_dbi_set_window_address(dbidev, rect->x1, rect->x2 - 1, rect->y1,
> @@ -303,9 +291,6 @@ static void
Re: [PATCH 4/8] drm/mipi-dbi: Initialize default driver functions with macro
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI
> helpers to default values and convert drivers. The prepare_fb function
> set by some drivers is called implicitly by simple-kms helpers, so leave
> it out.
>
> Signed-off-by: Thomas Zimmermann
> ---
> static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
> - .mode_valid = mipi_dbi_pipe_mode_valid,
> - .enable = yx240qv29_enable,
> - .disable = mipi_dbi_pipe_disable,
> - .update = mipi_dbi_pipe_update,
> + DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
> };
> static const struct drm_simple_display_pipe_funcs ili9163_pipe_funcs = {
> - .mode_valid = mipi_dbi_pipe_mode_valid,
> - .enable = yx240qv29_enable,
> - .disable = mipi_dbi_pipe_disable,
> - .update = mipi_dbi_pipe_update,
> + DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
> };
> static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
> - .mode_valid = mipi_dbi_pipe_mode_valid,
> - .enable = yx240qv29_enable,
> - .disable = mipi_dbi_pipe_disable,
> - .update = mipi_dbi_pipe_update,
> + DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
> };
3 drivers have the same enable function name, ili9163 and hx8357d has
clearly copied from ili9341 which actually supports the yx240qv29 panel.
At least hx8357d managed to update the display mode variable name,
ili9163 didn't. It's not unlikely that I reviewed these drivers...
But that has nothing to do with this patch:
Reviewed-by: Noralf Trønnes
Re: [PATCH 3/8] drm/st7586: Call MIPI DBI mode_valid helper
Den 21.11.2022 11.45, skrev Thomas Zimmermann: > MIPI DBI drivers validate each mode against their native resolution. > Add this test to st7586. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Noralf Trønnes
Re: [PATCH 2/8] drm/ili9225: Call MIPI DBI mode_valid helper
Den 21.11.2022 11.45, skrev Thomas Zimmermann: > MIPI DBI drivers validate each mode against their native resolution. > Add this test to ili9225. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Noralf Trønnes
Re: [PATCH 1/8] drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()
Den 21.11.2022 11.45, skrev Thomas Zimmermann: > The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS' > default implementation for prepare_fb. Remove the call from drivers > that set it explicitly. Then inline the helper into the only caller > within simple-kms helpers and remove . No functional changes. > > Simple-KMS drivers that implement the prepare_fb callback should call > drm_gem_plane_helper_prepare_fb() directly. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Noralf Trønnes
[linux-next:master] BUILD REGRESSION 9e46a79967326efb03c481ddfd58902475bd920d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 9e46a79967326efb03c481ddfd58902475bd920d Add linux-next specific files for 20221125 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242021.fdzrfna8-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242120.mzzvguln-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: No such file or directory arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end(): can't find starting instruction arch/powerpc/kernel/optprobes_head.o: warning: objtool: optprobe_template_end(): can't find starting instruction drivers/clk/clk.c:1022:5: error: redefinition of 'clk_prepare' drivers/clk/clk.c:1268:6: error: redefinition of 'clk_is_enabled_when_prepared' drivers/clk/clk.c:941:6: error: redefinition of 'clk_unprepare' drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4968: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: warning: implicit conversion from 'enum ' to 'enum dc_status' [-Wenum-conversion] drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: warning: no previous prototype for 'to_dal_irq_source_dcn201' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' set but not used [-Wunused-but-set-variable] net/netfilter/nf_conntrack_netlink.c:2674:6: warning: unused variable 'mark' [-Wunused-variable] vmlinux.o: warning: objtool: __btrfs_map_block+0x1d77: unreachable instruction Unverified Error/Warning (likely false positive, please contact us if interested): ERROR: modpost: "input_ff_create_memless" [drivers/hid/hid-axff.ko] undefined! ERROR: modpost: "input_ff_create_memless" [drivers/hid/hid-sjoy.ko] undefined! ERROR: modpost: "input_ff_create_memless" [drivers/input/misc/arizona-haptics.ko] undefined! ERROR: modpost: "input_ff_create_memless" [drivers/input/misc/drv2667.ko] undefined! drivers/dma/at_hdmac.c:1371 atc_prep_slave_sg() warn: possible memory leak of 'desc' Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:implicit-conversion-from-enum-anonymous-to-enum-dc_status | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-irq-dcn201-irq_service_dcn201.c:warning:no-previous-prototype-for-to_dal_irq_source_dcn201 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-nouveau-nvkm-nvfw-acr.c:warning:no-previous-prototype-for-wpr_generic_header_dump | `-- drivers-gpu-drm-nouveau-nvkm-subdev-acr-lsfw.c:warning:variable-loc-set-but-not-used |-- alpha-randconfig-r003-20221124 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:implicit-conversion-from-enum-anonymous-to-enum-dc_status | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-irq-dcn201-irq_service_dcn201.c:warning:no-previous-prototype-for-to_dal_irq_source_dcn201 |-- alpha-randconfig-r016-20221124 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-nouveau-nvkm-nvfw-acr.c:warning:no-previous-prototype-for-wpr_generic_head
Re: Try to address the DMA-buf coherency problem
Le mercredi 23 novembre 2022 à 17:33 +0100, Daniel Vetter a écrit : > On Wed, Nov 23, 2022 at 10:33:38AM +0200, Pekka Paalanen wrote: > > On Tue, 22 Nov 2022 18:33:59 +0100 > > Christian König wrote: > > > > > We should have come up with dma-heaps earlier and make it clear that > > > exporting a DMA-buf from a device gives you something device specific > > > which might or might not work with others. > > > > > > Apart from that I agree, DMA-buf should be capable of handling this. > > > Question left is what documentation is missing to make it clear how > > > things are supposed to work? > > > > Perhaps somewhat related from Daniel Stone that seems to have been > > forgotten: > > https://lore.kernel.org/dri-devel/20210905122742.86029-1-dani...@collabora.com/ > > > > It aimed mostly at userspace, but sounds to me like the coherency stuff > > could use a section of its own there? > > Hm yeah it would be great to land that and then eventually extend. Daniel? There is a lot of things documented in this document that have been said to be completely wrong user-space behaviour in this thread. But it seems to pre-date the DMA Heaps. The document also assume that DMA Heaps completely solves the CMA vs system memory issue. But it also underline a very important aspect, that userland is not aware which one to use. What this document suggest though seems more realist then what has been said here. Its overall a great document, it unfortunate that it only makes it into the DRM mailing list. Nicolas
Re: [PATCH v2] drm/mediatek: Clean dangling pointer on bind error path
On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote:
> Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto:
> > mtk_drm_bind() can fail, in which case drm_dev_put() is called,
> > destroying the drm_device object. However a pointer to it was still
> > being held in the private object, and that pointer would be passed along
> > to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that
> > point, resulting in a panic. Clean the pointer when destroying the
> > object in the error path to prevent this from happening.
> >
> > Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
> > MT8173.")
> > Signed-off-by: Nícolas F. R. A. Prado
> >
> > ---
> >
> > Changes in v2:
> > - Added Fixes tag
> >
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 39a42dc8fb85..a21ff1b3258c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev)
> > err_deinit:
> > mtk_drm_kms_deinit(drm);
> > err_free:
> > + private->drm = NULL;
>
> Sorry for not noticing that in v1, but I've rechecked this function and,
> while this
> commit does indeed actually solve the described issue, I think it's
> incomplete.
>
> A few lines before, we have a loop that sets
>
> private->all_drm_private[i]->drm = drm;
Actually that line only exists with [1] applied, but that commit hasn't been
merged as of yet. I debated whether it would be better to send this fix as is,
or ask Nancy Lin to add the tweaked fix you mention below to that series, but
sending this fix as is seemed better since it can be backported to older kernel
versions.
So assuming this commit gets merged first, Nancy should make that tweak you
mentioned below to ensure all the pointers are zeroed out, which is why I've
added Nancy to CC. (As a side note, given that only the mmsys with drm_master =
true would ever call the drm suspend helper, even this patch as is is enough to
avoid the panic even with that series applied, still we should zero out all
pointers for good measure)
[1]
https://lore.kernel.org/linux-mediatek/20221107072413.16178-6-nancy@mediatek.com/
Thanks,
Nícolas
>
> ...so here you should do...
>
> private->drm = NULL;
>
> while (i--) /* a for loop will also do, your choice */
> private->all_drm_private[i]->drm = NULL;
>
> That makes sure that you cleanup *everything* :-)
>
> Cheers,
> Angelo
>
[GIT PULL v2] drm/tegra: Changes for v6.2-rc1
Hi Dave, Daniel, The following changes since commit c2418f911a31a266af4fbaca998dc73d3676475a: gpu: host1x: Avoid trying to use GART on Tegra20 (2022-11-18 09:33:20 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-6.2-rc1 for you to fetch changes up to 08fef75f5e17c80cdb9ab56d65685cb43c8e44d3: gpu: host1x: Staticize host1x_syncpt_fence_ops (2022-11-25 16:14:59 +0100) I was a bit confused by the mismatching SHA1 at first, but turns out that the commit being fixed was originally meant to go into v6.1-rc1 but didn't. So when I rolled forward the for-next branch it got a different SHA1. Given that there's really nothing to fix here, I've just squashed the fix into the buggy commit. I've now also installed a pre-push script that should catch these kinds of mistakes. Thanks, Thierry drm/tegra: Changes for v6.2-rc1 This contains a bunch of cleanups across the board as well as support for the NVDEC hardware found on the Tegra234 SoC. Dmitry Torokhov (1): drm/tegra: Switch to using devm_fwnode_gpiod_get() Jani Nikula (1): drm/tegra: Convert to using is_hdmi from display info Liu Shixin (1): gpu: host1x: Use DEFINE_SHOW_ATTRIBUTE to simplify debugfs code Mikko Perttunen (6): gpu: host1x: Select context device based on attached IOMMU memory: tegra: Add API for retrieving carveout bounds gpu: host1x: Add stream ID register data for NVDEC on Tegra234 drm/tegra: nvdec: Support multiple clocks drm/tegra: Add code for booting RISC-V based engines drm/tegra: Add Tegra234 support to NVDEC driver Qing Wang (1): drm/tegra: Switch over to vmemdup_user() Thierry Reding (1): gpu: host1x: Staticize host1x_syncpt_fence_ops Zhang Zekun (1): drm/tegra: Add missing clk_disable_unprepare() in tegra_dc_probe() ruanjinjie (1): drm/tegra: Make gather_bo_ops static drivers/gpu/drm/tegra/Makefile | 3 +- drivers/gpu/drm/tegra/dc.c | 4 +- drivers/gpu/drm/tegra/drm.c | 1 + drivers/gpu/drm/tegra/hdmi.c| 9 +-- drivers/gpu/drm/tegra/nvdec.c | 171 ++-- drivers/gpu/drm/tegra/output.c | 10 +-- drivers/gpu/drm/tegra/riscv.c | 106 + drivers/gpu/drm/tegra/riscv.h | 30 +++ drivers/gpu/drm/tegra/submit.c | 13 +-- drivers/gpu/drm/tegra/uapi.c| 2 +- drivers/gpu/host1x/context.c| 4 + drivers/gpu/host1x/debug.c | 28 +-- drivers/gpu/host1x/dev.c| 12 +++ drivers/gpu/host1x/fence.c | 2 +- drivers/memory/tegra/mc.c | 25 ++ drivers/memory/tegra/tegra234.c | 5 ++ include/linux/host1x.h | 2 + include/soc/tegra/mc.h | 11 +++ 18 files changed, 362 insertions(+), 76 deletions(-) create mode 100644 drivers/gpu/drm/tegra/riscv.c create mode 100644 drivers/gpu/drm/tegra/riscv.h
Re: [RFC 0/2] drm/connector: connector iterator with filtering
On 10/5/22 06:51, Jani Nikula wrote: > Currently i915 assumes all drm_connectors it encounters are embedded in > intel_connectors that i915 allocated. The drm_writeback_connector forces > a design where this is not the case; we can't provide our own connector, > and writeback embeds the drm_connector it initializes itself. > > To use drm writeback, none of the i915 connector iteration could assume > the drm connector is embedded in intel_connector. Checking this is > tedious, and would require an intermediate step with > drm_connector. Here's an idea I came up with; filtering at the drm > connector iterator level with a caller supplied function. Not too much > code, and could be used for other things as well. > We've been trying to hook up drm_writeback_connector in amdgpu and this would be really helpful. I've had to do liberal sprinkling of "!= DRM_MODE_CONNECTOR_WRITEBACK" all over the place. > Mind you, we'd still much rather modify drm writeback to allow passing > the connector i915 allocated, instead of the current midlayer design > that forces drivers to a certain model. Working around this is a bunch > of error prone and tedious code that we really could do without. > I think this would be even better but also be much more work and impact every driver that implements writeback. FWIW, there was no way for me to add writeback connector handling without KASAN. Interpreting the connector wrong in one place leads to memory corruption and undefined behavior and is almost impossible to spot without KASAN. This series is Acked-by: Harry Wentland Harry > > BR, > Jani. > > > Cc: Arun R Murthy > Cc: Dave Airlie > Cc: Laurent Pinchart > Cc: Suraj Kandpal > Cc: Ville Syrjälä > > Jani Nikula (2): > drm/connector: add connector list iteration with filtering > drm/i915: iterate intel_connectors only > > drivers/gpu/drm/drm_connector.c | 57 +++ > drivers/gpu/drm/i915/display/intel_display.c | 3 +- > .../drm/i915/display/intel_display_types.h| 7 +++ > drivers/gpu/drm/i915/display/intel_dp.c | 6 +- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +- > drivers/gpu/drm/i915/display/intel_hotplug.c | 12 ++-- > .../drm/i915/display/intel_modeset_setup.c| 6 +- > drivers/gpu/drm/i915/display/intel_opregion.c | 9 ++- > include/drm/drm_connector.h | 9 +++ > 10 files changed, 89 insertions(+), 26 deletions(-) >
Re: [PATCH 01/24] drm/tests: helpers: Rename the device init helper
Hi, On Fri, Nov 25, 2022 at 11:10:02AM -0300, Maíra Canal wrote: > On 11/23/22 12:25, Maxime Ripard wrote: > > The name doesn't really fit the conventions for the other helpers in > > DRM/KMS, so let's rename it to make it obvious that we allocate a new > > DRM device. > > > > Signed-off-by: Maxime Ripard > > Although I believe using "drm_device" on the function name is a bit > redundant (maybe drm_kunit_helper_alloc_dev or drm_kunit_helper_alloc_device > would be cleaner), Yeah, I don't quite like the name either, but we'll need to also allocate a struct device in the next few patches so we need to make the distinction between a struct drm_device and a struct device. Maxime signature.asc Description: PGP signature
Re: [PATCH] drm: Fix possible memleak and UAF in drm_addmap_core()
On Thu, Nov 24, 2022 at 09:02:19AM +0800, Gaosheng Cui wrote:
> The dma_free_coherent() should be called when memory fails to
> be allocated for list, or drm_map_handle() fails, otherwise there
> will be a memory leak, so add dma_free_coherent to fix it.
>
> In addition, if drm_map_handle() fails in drm_addmap_core(), list
> will be freed, but list->head will not be removed from dev->map_list,
> then list traversal may cause UAF, fix it by removeing it from
> dev->map_list before kfree().
>
> Fixes: 8e4ff9b56957 ("drm: Remove the dma_alloc_coherent wrapper for internal
> usage")
> Fixes: 8d153f7107ff ("drm: update user token hashing and map handles")
> Signed-off-by: Gaosheng Cui
Reviewed-by: Stanislaw Gruszka
Re: [PATCH 01/24] drm/tests: helpers: Rename the device init helper
On 11/23/22 12:25, Maxime Ripard wrote:
The name doesn't really fit the conventions for the other helpers in
DRM/KMS, so let's rename it to make it obvious that we allocate a new
DRM device.
Signed-off-by: Maxime Ripard
Although I believe using "drm_device" on the function name is a bit
redundant (maybe drm_kunit_helper_alloc_dev or
drm_kunit_helper_alloc_device would be cleaner),
Reviewed-by: Maíra Canal
Best Regards,
- Maíra Canal
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 2 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 4 +++-
drivers/gpu/drm/tests/drm_kunit_helpers.h | 5 -
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 362a5fbd82f5..e469d1634e2d 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -41,7 +41,7 @@ static int drm_client_modeset_test_init(struct kunit *test)
test->priv = priv;
- priv->drm = drm_kunit_device_init(test, DRIVER_MODESET, "drm-client-modeset-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET,
"drm-client-modeset-test");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
ret = drmm_connector_init(priv->drm, >connector,
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index f1662091f250..a4ad030ed101 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -36,7 +36,9 @@ static void dev_free(struct kunit_resource *res)
root_device_unregister(dev);
}
-struct drm_device *drm_kunit_device_init(struct kunit *test, u32 features, char *name)
+struct drm_device *
+drm_kunit_helper_alloc_drm_device(struct kunit *test,
+ u32 features, char *name)
{
struct kunit_dev *kdev;
struct drm_device *drm;
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.h
b/drivers/gpu/drm/tests/drm_kunit_helpers.h
index 20ab6eec4c89..e9870c7911fe 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.h
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.h
@@ -6,6 +6,9 @@
struct drm_device;
struct kunit;
-struct drm_device *drm_kunit_device_init(struct kunit *test, u32 features, char *name);
+struct drm_device *
+drm_kunit_helper_alloc_drm_device(struct kunit *test,
+ u32 features,
+ char *name);
#endif // DRM_KUNIT_HELPERS_H_
Re: [PATCH v2 2/2] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
On Fri, Nov 25, 2022, at 14:40, Lee Jones wrote: > On Fri, 25 Nov 2022, Lee Jones wrote: > >> When enabled, KASAN enlarges function's stack-frames. Pushing quite a >> few over the current threshold. This can mainly be seen on 32-bit >> architectures where the present limit (when !GCC) is a lowly >> 1024-Bytes. >> >> Signed-off-by: Lee Jones >> --- >> lib/Kconfig.debug | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index c3c0b077ade33..82d475168db95 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -399,6 +399,7 @@ config FRAME_WARN >> default 2048 if GCC_PLUGIN_LATENT_ENTROPY >> default 2048 if PARISC >> default 1536 if (!64BIT && XTENSA) >> +default 1280 if KASAN && !64BIT >> default 1024 if !64BIT >> default 2048 if 64BIT >> help > > Note this also fixes 61 warnings when > > (GCC && !GCC_PLUGIN_LATENT_ENTROPY) > > ... which as Arnd says should not be enabled by default. We'll > address that issue once this set has been applied. Thanks a lot for checking this! Reviewed-by: Arnd Bergmann
Re: [PATCH] drm/i915/huc: fix leak of debug object in huc load fence on driver unload
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> The fence is always initialized in huc_init_early, but the cleanup in
> huc_fini is only being run if HuC is enabled. This causes a leaking of
> the debug object when HuC is disabled/not supported, which can in turn
> trigger a warning if we try to register a new debug offset at the same
> address on driver reload.
>
> To fix the issue, make sure to always run the cleanup code.
This oopsing in ci now. Somehow the patchwork run did not
hit that oops.
>
> Reported-by: Tvrtko Ursulin
> Reported-by: Brian Norris
> Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence")
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Cc: Brian Norris
> Cc: Alan Previn
> Cc: John Harrison
> ---
>
> Note: I didn't manage to repro the reported warning, but I did confirm
> that we weren't correctly calling i915_sw_fence_fini and that this patch
> fixes that.
>
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 12 +++-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 1 +
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index fbc8bae14f76..83735a1528fe 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -300,13 +300,15 @@ int intel_huc_init(struct intel_huc *huc)
>
> void intel_huc_fini(struct intel_huc *huc)
> {
> - if (!intel_uc_fw_is_loadable(>fw))
> - return;
> -
> + /*
> + * the fence is initialized in init_early, so we need to clean it up
> + * even if HuC loading is off.
> + */
> delayed_huc_load_complete(huc);
> -
> i915_sw_fence_fini(>delayed_load.fence);
> - intel_uc_fw_fini(>fw);
> +
> + if (intel_uc_fw_is_loadable(>fw))
> + intel_uc_fw_fini(>fw);
> }
>
> void intel_huc_suspend(struct intel_huc *huc)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index dbd048b77e19..41f08b55790e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -718,6 +718,7 @@ int intel_uc_runtime_resume(struct intel_uc *uc)
>
> static const struct intel_uc_ops uc_ops_off = {
> .init_hw = __uc_check_hw,
> + .fini = __uc_fini, /* to clean-up the init_early initialization */
> };
>
> static const struct intel_uc_ops uc_ops_on = {
> --
> 2.37.3
--
Ville Syrjälä
Intel
Re: [PATCH v2 2/2] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
On Fri, 25 Nov 2022, Lee Jones wrote: > When enabled, KASAN enlarges function's stack-frames. Pushing quite a > few over the current threshold. This can mainly be seen on 32-bit > architectures where the present limit (when !GCC) is a lowly > 1024-Bytes. > > Signed-off-by: Lee Jones > --- > lib/Kconfig.debug | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index c3c0b077ade33..82d475168db95 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -399,6 +399,7 @@ config FRAME_WARN > default 2048 if GCC_PLUGIN_LATENT_ENTROPY > default 2048 if PARISC > default 1536 if (!64BIT && XTENSA) > + default 1280 if KASAN && !64BIT > default 1024 if !64BIT > default 2048 if 64BIT > help Note this also fixes 61 warnings when (GCC && !GCC_PLUGIN_LATENT_ENTROPY) ... which as Arnd says should not be enabled by default. We'll address that issue once this set has been applied. -- Lee Jones [李琼斯]
Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait
Am 25.11.22 um 12:14 schrieb Tvrtko Ursulin:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13..d409a77449a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct
drm_i915_gem_object *obj,
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- int err;
+ long err;
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
- err = ttm_bo_wait(bo, true, false);
- if (err)
+ err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ true, 15 * HZ);
This 15 second stuck out a bit for me and then on a slightly deeper
look it seems this timeout will "leak" into a few of i915 code paths.
If we look at the difference between the legacy shmem and ttm backend
I am not sure if the legacy one is blocking or not - but if it can
block I don't think it would have an arbitrary timeout like this. Matt
your thoughts?
That's exactly the reason why I try to remove the ttm_bo_wait() as mid
layer here. It hides the fact that we don't wait forever for BOs to
become idle.
This is functional identical to the old code. If you want some other
behavior feel free to note what's desired and I will implement it.
Regards,
Christian.
Regards,
Tvrtko
+ if (err < 0)
return err;
+ if (err == 0)
+ return -EBUSY;
err = i915_ttm_move_notify(bo);
if (err)
Re: [PATCH 2/5] driver core: make struct class.devnode() take a const *
Hello Greg,
On Fri, 25 Nov 2022 at 17:25, Mauro Carvalho Chehab wrote:
>
> Em Wed, 23 Nov 2022 13:25:20 +0100
> Greg Kroah-Hartman escreveu:
>
> > The devnode() in struct class should not be modifying the device that is
> > passed into it, so mark it as a const * and propagate the function
> > signature changes out into all relevant subsystems that use this
> > callback.
>
> Acked-by: Mauro Carvalho Chehab
> >
Please feel free to add my
Acked-by: Sumit Semwal
for the dma-buf portion.
Best,
Sumit.
> > Cc: Fenghua Yu
> > Cc: Reinette Chatre
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: Borislav Petkov
> > Cc: Dave Hansen
> > Cc: x...@kernel.org
> > Cc: "H. Peter Anvin"
> > Cc: FUJITA Tomonori
> > Cc: Jens Axboe
> > Cc: Justin Sanders
> > Cc: Arnd Bergmann
> > Cc: Sumit Semwal
> > Cc: Benjamin Gaignard
> > Cc: Liam Mark
> > Cc: Laura Abbott
> > Cc: Brian Starkey
> > Cc: John Stultz
> > Cc: "Christian König"
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Leon Romanovsky
> > Cc: Dennis Dalessandro
> > Cc: Dmitry Torokhov
> > Cc: Mauro Carvalho Chehab
> > Cc: Sean Young
> > Cc: Frank Haverkamp
> > Cc: Jiri Slaby
> > Cc: "Michael S. Tsirkin"
> > Cc: Jason Wang
> > Cc: Alex Williamson
> > Cc: Cornelia Huck
> > Cc: Kees Cook
> > Cc: Anton Vorontsov
> > Cc: Colin Cross
> > Cc: Tony Luck
> > Cc: Jaroslav Kysela
> > Cc: Takashi Iwai
> > Cc: Hans Verkuil
> > Cc: Christophe JAILLET
> > Cc: Xie Yongji
> > Cc: Gautam Dawar
> > Cc: Dan Carpenter
> > Cc: Eli Cohen
> > Cc: Parav Pandit
> > Cc: Maxime Coquelin
> > Cc: alsa-de...@alsa-project.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: k...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-bl...@vger.kernel.org
> > Cc: linux-in...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-s...@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 ++--
> > arch/x86/kernel/cpuid.c| 2 +-
> > arch/x86/kernel/msr.c | 2 +-
> > block/bsg.c| 2 +-
> > drivers/block/aoe/aoechr.c | 2 +-
> > drivers/char/mem.c | 2 +-
> > drivers/char/misc.c| 4 ++--
> > drivers/dma-buf/dma-heap.c | 2 +-
> > drivers/gpu/drm/drm_sysfs.c| 2 +-
> > drivers/infiniband/core/user_mad.c | 2 +-
> > drivers/infiniband/core/uverbs_main.c | 2 +-
> > drivers/infiniband/hw/hfi1/device.c| 4 ++--
> > drivers/input/input.c | 2 +-
> > drivers/media/dvb-core/dvbdev.c| 4 ++--
> > drivers/media/pci/ddbridge/ddbridge-core.c | 4 ++--
> > drivers/media/rc/rc-main.c | 2 +-
> > drivers/misc/genwqe/card_base.c| 2 +-
> > drivers/tty/tty_io.c | 2 +-
> > drivers/usb/core/file.c| 2 +-
> > drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
> > drivers/vfio/vfio_main.c | 2 +-
> > fs/pstore/pmsg.c | 2 +-
> > include/linux/device/class.h | 2 +-
> > sound/sound_core.c | 2 +-
> > 24 files changed, 29 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > index d961ae3ed96e..4e4231a58f38 100644
> > --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > @@ -1560,9 +1560,9 @@ static const struct file_operations
> > pseudo_lock_dev_fops = {
> > .mmap = pseudo_lock_dev_mmap,
> > };
> >
> > -static char *pseudo_lock_devnode(struct device *dev, umode_t *mode)
> > +static char *pseudo_lock_devnode(const struct device *dev, umode_t *mode)
> > {
> > - struct rdtgroup *rdtgrp;
> > + const struct rdtgroup *rdtgrp;
> >
> > rdtgrp = dev_get_drvdata(dev);
> > if (mode)
> > diff --git a/arch/x86/kernel/cpuid.c b/arch/x86/kernel/cpuid.c
> > index 6f7b8cc1bc9f..621ba9c0f17a 100644
> > --- a/arch/x86/kernel/cpuid.c
> > +++ b/arch/x86/kernel/cpuid.c
> > @@ -139,7 +139,7 @@ static int cpuid_device_destroy(unsigned int cpu)
> > return 0;
> > }
> >
> > -static char *cpuid_devnode(struct device *dev, umode_t *mode)
> > +static char *cpuid_devnode(const struct device *dev, umode_t *mode)
> > {
> > return kasprintf(GFP_KERNEL, "cpu/%u/cpuid", MINOR(dev->devt));
> > }
> > diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> > index ed8ac6bcbafb..708751311786 100644
> > --- a/arch/x86/kernel/msr.c
> > +++ b/arch/x86/kernel/msr.c
> > @@ -250,7 +250,7 @@ static int
[PATCH v4 17/18] arm64: dts: qcom: sdm845: Add compat qcom, sdm845-dsi-ctrl
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5420205417c81..c14e49c9655c3 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4522,7 +4522,8 @@ opp-43000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
@@ -4593,7 +4594,8 @@ dsi0_phy: dsi-phy@ae94400 {
};
dsi1: dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae96000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 18/18] arm64: dts: qcom: sm8250: Add compat qcom, sm8250-dsi-ctrl
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 0d47c5b7148e1..8a73f1b487043 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3528,7 +3528,8 @@ opp-46000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
@@ -3619,7 +3620,8 @@ dsi0_phy: dsi-phy@ae94400 {
};
dsi1: dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae96000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 10/18] ARM: dts: qcom: msm8974: Add compat qcom, msm8974-dsi-ctrl
Add silicon specific compatible qcom,msm8974-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8974 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 21d943d4b02d7..b4361f4318ece 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1545,7 +1545,8 @@ mdp5_intf1_out: endpoint {
};
dsi0: dsi@fd922800 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8974-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0xfd922800 0x1f8>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 11/18] arm64: dts: qcom: msm8916: Add compat qcom, msm8916-dsi-ctrl
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c1d8a1b388d27..20e72038cadfe 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1021,7 +1021,8 @@ mdp5_intf1_out: endpoint {
};
dsi0: dsi@1a98000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8916-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x01a98000 0x25c>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 13/18] arm64: dts: qcom: sc7180: Add compat qcom, sc7180-dsi-ctrl
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d2c374e9d8c03..cfe44afc52b4a 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2985,7 +2985,8 @@ opp-46000 {
};
dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 08/18] dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back in
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement appears to have been in error.
Taking the example of sc7180-trogdor-wormdingler.dtsi. The avdd and avee
come from GPIO controlled external regulators, not the SoC and in this case
there's no need for vddio to power an I/O bus. Similarly the regulators for
the LCD are controlled by the panel driver not by the dsi-ctrl driver.
It would be possible to connect a different type of panel to the DSI bus
here in which case we may or may not want to make use of vdd, vdda or
vddio.
This is also the case for older chipsets like apq8064, msm8916 etc the vdd*
regulators in the dsi-ctrl block are helpers not dependencies.
Add the description of vdd, vdda and vddio back in for the existing
upstream dts where vdd, vdda or vddio are already declared but, don't
declare those regulators required - they are not SoC requirements.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Signed-off-by: Bryan O'Donoghue
---
.../bindings/display/msm/dsi-controller-main.yaml| 12
1 file changed, 12 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 0fbb0c04f4b06..bcbcbdca1a78a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -133,6 +133,18 @@ properties:
- port@0
- port@1
+ vdd-supply:
+description:
+ vdd regulator device node
+
+ vddio-supply:
+description:
+ vdd-io regulator device node
+
+ vdda-supply:
+description:
+ vdda regulator device node
+
required:
- compatible
- reg
--
2.38.1
[PATCH v4 05/18] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis
Each compatible has a different set of clocks which are associated with it. Add in the list of clocks for each compatible. Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 152 -- 1 file changed, 142 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 0cd2079137b02..88aac7d33555c 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -9,9 +9,6 @@ title: Qualcomm Display DSI controller maintainers: - Krishna Manikandan -allOf: - - $ref: "../dsi-controller.yaml#" - properties: compatible: items: @@ -48,13 +45,8 @@ properties: - description: Display AXI clock clock-names: -items: - - const: byte - - const: byte_intf - - const: pixel - - const: core - - const: iface - - const: bus +minItems: 6 +maxItems: 9 phys: maxItems: 1 @@ -147,6 +139,146 @@ required: - assigned-clock-parents - ports +allOf: + - $ref: "../dsi-controller.yaml#" + - if: + properties: +compatible: + contains: +enum: + - qcom,apq8064-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: iface +- const: bus +- const: core_mmss +- const: src +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8916-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8974-dsi-ctrl +then: + properties: +clocks: + maxItems: 3 +clock-names: + items: +- const: iface +- const: bus +- const: vsync + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8996-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: mdp_core +- const: byte +- const: iface +- const: bus +- const: core_mmss +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,sc7180-dsi-ctrl + - qcom,sc7280-dsi-ctrl + - qcom,sm8250-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +- const: iface +- const: bus + + - if: + properties: +compatible: + contains: +enum: + - qcom,sdm630-dsi-ctrl + - qcom,sdm660-dsi-ctrl +then: + properties: +clocks: + maxItems: 9 +clock-names: + items: +- const: mdp_core +- const: byte +- const: byte_intf +- const: mnoc +- const: iface +- const: bus +- const: core_mmss +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,sdm845-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +- const: iface +- const: bus + additionalProperties: false examples: -- 2.38.1
[PATCH v4 15/18] arm64: dts: qcom: sdm630: Add compat qcom, sdm630-dsi-ctrl
Add silicon specific compatible qcom,sdm630-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm630 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 0e7764f66b104..905ddb57318dd 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1581,7 +1581,8 @@ opp-41250 {
};
dsi0: dsi@c994000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm630-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x0c994000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 14/18] arm64: dts: qcom: sc7280: Add compat qcom, sc7280-dsi-ctrl
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index a4d6e866b5999..3368531e004e8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3903,7 +3903,8 @@ opp-50667 {
};
mdss_dsi: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7280-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 06/18] dt-bindings: msm: dsi-controller-main: Fix description of core clock
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 88aac7d33555c..0c09b9230b7f5 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -40,7 +40,7 @@ properties:
- description: Display byte clock
- description: Display byte interface clock
- description: Display pixel clock
- - description: Display escape clock
+ - description: Display core clock
- description: Display AHB clock
- description: Display AXI clock
--
2.38.1
[PATCH v4 07/18] dt-bindings: msm: dsi-controller-main: Fix clock declarations
When converting from .txt to .yaml dt-binding descriptions we appear to
have missed some of the previous detail on the number and names of
permissible clocks.
Fix this by listing the clock descriptions against the clock names at a
high level.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 20 ---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 0c09b9230b7f5..0fbb0c04f4b06 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -36,13 +36,19 @@ properties:
maxItems: 1
clocks:
-items:
- - description: Display byte clock
- - description: Display byte interface clock
- - description: Display pixel clock
- - description: Display core clock
- - description: Display AHB clock
- - description: Display AXI clock
+description: |
+ Several clocks are used, depending on the variant. Typical ones are::
+ - bus:: Display AHB clock.
+ - byte:: Display byte clock.
+ - byte_intf:: Display byte interface clock.
+ - core:: Display core clock.
+ - core_mss:: Core MultiMedia SubSystem clock.
+ - iface:: Display AXI clock.
+ - mdp_core:: MDP Core clock.
+ - mnoc:: MNOC clock
+ - pixel:: Display pixel clock.
+minItems: 6
+maxItems: 9
clock-names:
minItems: 6
--
2.38.1
[PATCH v4 04/18] dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following compatible strings
- qcom,apq8064-dsi-ctrl
- qcom,msm8916-dsi-ctrl
- qcom,msm8974-dsi-ctrl
- qcom,msm8996-dsi-ctrl
- qcom,sc7180-dsi-ctrl
- qcom,sc7280-dsi-ctrl
- qcom,sdm630-dsi-ctrl
- qcom,sdm660-dsi-ctrl
- qcom,sdm845-dsi-ctrl
- qcom,sm8250-dsi-ctrl
Each SoC dtsi should declare "qcom,socname-dsi-ctrl", "qcom,mdss-dsi-ctrl";
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 67d08dc338925..0cd2079137b02 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -14,9 +14,20 @@ allOf:
properties:
compatible:
-enum:
- - qcom,mdss-dsi-ctrl
- - qcom,qcm2290-dsi-ctrl
+items:
+ - enum:
+ - qcom,apq8064-dsi-ctrl
+ - qcom,msm8916-dsi-ctrl
+ - qcom,msm8974-dsi-ctrl
+ - qcom,msm8996-dsi-ctrl
+ - qcom,qcm2290-dsi-ctrl
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sdm630-dsi-ctrl
+ - qcom,sdm660-dsi-ctrl
+ - qcom,sdm845-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
reg:
maxItems: 1
@@ -146,7 +157,7 @@ examples:
#include
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 02/18] dt-bindings: msm: dsi-controller-main: Fix power-domain constraint
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the aqp8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084, msm8226, msm8916,
msm8974.
https://review.carbonrom.org/plugins/gitiles/CarbonROM/android_kernel_oneplus_msm8994/+/7b5c011a770daa2811778937ed646237a28a8694
"ARM: dts: msm: add mdss gdsc supply to dsi controller device
It is possible for the DSI controller to be active when MDP is
power collapsed. DSI controller needs to have it's own vote for
mdss gdsc to ensure that gdsc remains on in such cases."
This however doesn't appear to be the case for the apq8064 so we shouldn't
be marking power-domain as required in yaml checks.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 27ebfd5ffb22f..cf782c5f5bdb0 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -134,7 +134,6 @@ required:
- phys
- assigned-clocks
- assigned-clock-parents
- - power-domains
- ports
additionalProperties: false
--
2.38.1
[PATCH v4 12/18] arm64: dts: qcom: msm8996: Add compat qcom, msm8996-dsi-ctrl
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 081e20a63c610..9f6543579dcf0 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -968,7 +968,8 @@ mdp5_intf2_out: endpoint {
};
dsi0: dsi@994000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8996-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x00994000 0x400>;
reg-names = "dsi_ctrl";
@@ -1035,7 +1036,8 @@ dsi0_phy: dsi-phy@994400 {
};
dsi1: dsi@996000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8996-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x00996000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 01/18] dt-bindings: msm: dsi-controller-main: Fix operating-points-v2 constraint
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 7782bff89afc7..27ebfd5ffb22f 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -135,7 +135,6 @@ required:
- assigned-clocks
- assigned-clock-parents
- power-domains
- - operating-points-v2
- ports
additionalProperties: false
--
2.38.1
[PATCH v4 09/18] ARM: dts: qcom: apq8064: add compat qcom, apq8064-dsi-ctrl
Append silicon specific compatible qcom,apq8064-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for apq8064 against the yaml documentation.
Reviewed-by: David Heidelberg
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index d036dff4b14f7..a8b089eb0dad2 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1287,7 +1287,8 @@ mmss_sfpb: syscon@570 {
};
dsi0: dsi@470 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,apq8064-dsi-ctrl"
+"qcom,mdss-dsi-ctrl";
label = "MDSS DSI CTRL->0";
#address-cells = <1>;
#size-cells = <0>;
--
2.38.1
[PATCH v4 03/18] dt-bindings: msm: dsi-controller-main: Rename qcom, dsi-ctrl-6g-qcm2290 to qcom, qcm2290-dsi-ctrl
We will add in a number of compat strings to dsi-controller-main.yaml in the format "qcom,socname-dsi-ctrl" convert the currently unused qcom,dsi-ctrl-6g-qcm2290 to qcom,qcm2290-dsi-ctrl. Signed-off-by: Bryan O'Donoghue --- .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index cf782c5f5bdb0..67d08dc338925 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -16,7 +16,7 @@ properties: compatible: enum: - qcom,mdss-dsi-ctrl - - qcom,dsi-ctrl-6g-qcm2290 + - qcom,qcm2290-dsi-ctrl reg: maxItems: 1 -- 2.38.1
[PATCH v4 16/18] arm64: dts: qcom: sdm660: Add compat qcom, sdm660-dsi-ctrl
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index 10bf1c45cf6ec..f8ec728e67f3d 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -154,7 +154,8 @@ mdp5_intf2_out: endpoint {
{
dsi1: dsi@c996000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm660-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
reg = <0x0c996000 0x400>;
reg-names = "dsi_ctrl";
--
2.38.1
[PATCH v4 00/18] mdss-dsi-ctrl binding and dts fixes
V4: - Moves the update of the example from patch #5 to patch #4 V3: - Moves declaration of mdss-dsi-ctrl into compat string declaration patch - Krzysztof, Dmitry - Renames qcm-2290 compat string to agreed compat "qcom,socname-dsi-ctrl" Dmirty, Krzysztof - Adds empty line after if clause in yaml control flow section - Dmirty - Adds Rb/Ack - Krzysztof, Dmitry, Doug, David - vdd* Looking into this some more, I don't believe vdd, vdda, vddio ought to be required properties. Its up to the PCB manufacturer and the panel in-use how that panel is powered. Powering the panel is not something that even necessarily needs to be done from the dsi-ctrl driver. Originally marking vdd* as required in the .txt was an error, its not a SoC level dtsi requirement. - clock-names Rather than replicate the clock-name in each if block I listed them with a specific description from a similar reference in usb/qcom,dwc3.yaml. https://lore.kernel.org/linux-arm-msm/eb80681f-2e0b-605f-0444-ec65562f7...@linaro.org/ V2: https://www.spinics.net/lists/linux-arm-msm/msg116326.html - Moves the DSI PHY changes to a different later series. There are enough dsi-controller-main changes to justify its own standalone series. - The original phy-name binding change given discussion with Rob and Krzysztof became its own standalone series that has since been merged. https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg403214.html - Retains the drop of power-domain from yaml as a required property. I dug into the available dtsi. The apq8064 doesn't appear to have any GDSC which can be attached as a power-domain, which means the power-domain requirement is not universal across the various silicon versions. - Adds Dmitry's RB to power-domain drop - For the clock declarations I've * I noticed that the simple change I had worked for msm8939 but subsquently broke other dtsi which drove a bigger change to document the clocks on a per compatible basis. * Added compat strings in yaml. * Moved the allOf down later in the file to acomodate the if/then. * Number of clocks validated on a per compatible basis * The driver code which doesn't care about the number of clocks can still operate on the mdss-dsi-ctrl compat but the dts checks will validate against the compat string and yaml. - vdd descriptions Took the previous text I missed from the .txt file - Krzysztof, Dmitry Adds vdd, vdda and vddio to the required list. This exposes warnings in existing dtsi but the previous .txt declared these regulators as required. - Krzysztof V1: This series fixes up a number of dtbs checks which are being flagged adding in the msm8939 dtsi. When converting from .txt to .yaml a number of the parameters for the older msm8916 silicon were not transmitted into the yaml. Adding in the msm8939 which is a near 1:1 copy of the msm8916 in terms of dtsi triggers a rake of dtbs checks as a result. https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg403211.html Bryan O'Donoghue (18): dt-bindings: msm: dsi-controller-main: Fix operating-points-v2 constraint dt-bindings: msm: dsi-controller-main: Fix power-domain constraint dt-bindings: msm: dsi-controller-main: Rename qcom,dsi-ctrl-6g-qcm2290 to qcom,qcm2290-dsi-ctrl dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis dt-bindings: msm: dsi-controller-main: Fix description of core clock dt-bindings: msm: dsi-controller-main: Fix clock declarations dt-bindings: msm: dsi-controller-main: Add vdd* descriptions back in ARM: dts: qcom: apq8064: add compat qcom,apq8064-dsi-ctrl ARM: dts: qcom: msm8974: Add compat qcom,msm8974-dsi-ctrl arm64: dts: qcom: msm8916: Add compat qcom,msm8916-dsi-ctrl arm64: dts: qcom: msm8996: Add compat qcom,msm8996-dsi-ctrl arm64: dts: qcom: sc7180: Add compat qcom,sc7180-dsi-ctrl arm64: dts: qcom: sc7280: Add compat qcom,sc7280-dsi-ctrl arm64: dts: qcom: sdm630: Add compat qcom,sdm630-dsi-ctrl arm64: dts: qcom: sdm660: Add compat qcom,sdm660-dsi-ctrl arm64: dts: qcom: sdm845: Add compat qcom,sdm845-dsi-ctrl arm64: dts: qcom: sm8250: Add compat qcom,sm8250-dsi-ctrl .../display/msm/dsi-controller-main.yaml | 205 -- arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +- arch/arm/boot/dts/qcom-msm8974.dtsi | 3 +- arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +- arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 +- arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +- arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 +- arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 +- arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 +- 11 files changed, 208 insertions(+), 36 deletions(-) --
Re: [RFC 0/2] drm/connector: connector iterator with filtering
On Wed, 05 Oct 2022, Jani Nikula wrote: > Currently i915 assumes all drm_connectors it encounters are embedded in > intel_connectors that i915 allocated. The drm_writeback_connector forces > a design where this is not the case; we can't provide our own connector, > and writeback embeds the drm_connector it initializes itself. > > To use drm writeback, none of the i915 connector iteration could assume > the drm connector is embedded in intel_connector. Checking this is > tedious, and would require an intermediate step with > drm_connector. Here's an idea I came up with; filtering at the drm > connector iterator level with a caller supplied function. Not too much > code, and could be used for other things as well. > > Mind you, we'd still much rather modify drm writeback to allow passing > the connector i915 allocated, instead of the current midlayer design > that forces drivers to a certain model. Working around this is a bunch > of error prone and tedious code that we really could do without. Any feedback on this one? BR, Jani. > > > BR, > Jani. > > > Cc: Arun R Murthy > Cc: Dave Airlie > Cc: Laurent Pinchart > Cc: Suraj Kandpal > Cc: Ville Syrjälä > > Jani Nikula (2): > drm/connector: add connector list iteration with filtering > drm/i915: iterate intel_connectors only > > drivers/gpu/drm/drm_connector.c | 57 +++ > drivers/gpu/drm/i915/display/intel_display.c | 3 +- > .../drm/i915/display/intel_display_types.h| 7 +++ > drivers/gpu/drm/i915/display/intel_dp.c | 6 +- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +- > drivers/gpu/drm/i915/display/intel_hotplug.c | 12 ++-- > .../drm/i915/display/intel_modeset_setup.c| 6 +- > drivers/gpu/drm/i915/display/intel_opregion.c | 9 ++- > include/drm/drm_connector.h | 9 +++ > 10 files changed, 89 insertions(+), 26 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Fri, Nov 25, 2022 at 05:44:11PM +0800, Jiaxin Yu wrote:
> + /*
> + * PCM trigger callback.
> + * Mandatory
> + */
> + int (*trigger)(struct device *dev, int cmd);
> +
Making this mandatory would break all existing users, though...
> + switch (event) {
> + case SND_SOC_DAPM_PRE_PMU:
> + if (hcp->hcd.ops->trigger)
> + hcp->hcd.ops->trigger(component->dev->parent,
> SNDRV_PCM_TRIGGER_START);
...it's not actually mandatory so it's just the comment that's wrong.
I'm a little unclear why this is being implemented as a DAPM operation
rather than having the driver forward the PCM trigger op if it's needed?
Or alternatively if a DAPM callback is needed why not provide one
directly rather than hooking into the trigger function - that's going to
be called out of sequence with the rest of DAPM and be potentially
confusing given the very different environments that trigger and DAPM
operations run in. A quick glance at the it6505 driver suggests it'd be
happier with a DAPM callback.
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] drm/amdgpu: Temporarily disable broken Clang builds due to blown stack-frame
On Fri, Nov 25, 2022, at 13:07, Lee Jones wrote: > calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) > architectures built with Clang (all released versions), whereby the stack > frame gets blown up to well over 5k. This would cause an immediate kernel > panic on most architectures. We'll revert this when the following bug report > has been resolved: https://github.com/llvm/llvm-project/issues/41896. > > Suggested-by: Arnd Bergmann > Signed-off-by: Lee Jones Acked-by: Arnd Bergmann
[PATCH v2 2/2] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
When enabled, KASAN enlarges function's stack-frames. Pushing quite a few over the current threshold. This can mainly be seen on 32-bit architectures where the present limit (when !GCC) is a lowly 1024-Bytes. Signed-off-by: Lee Jones --- lib/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c3c0b077ade33..82d475168db95 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -399,6 +399,7 @@ config FRAME_WARN default 2048 if GCC_PLUGIN_LATENT_ENTROPY default 2048 if PARISC default 1536 if (!64BIT && XTENSA) + default 1280 if KASAN && !64BIT default 1024 if !64BIT default 2048 if 64BIT help -- 2.38.1.584.g0f3c55d4c2-goog
[PATCH v2 1/2] drm/amdgpu: Temporarily disable broken Clang builds due to blown stack-frame
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) architectures built with Clang (all released versions), whereby the stack frame gets blown up to well over 5k. This would cause an immediate kernel panic on most architectures. We'll revert this when the following bug report has been resolved: https://github.com/llvm/llvm-project/issues/41896. Suggested-by: Arnd Bergmann Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 6925e0280dbe6..f4f3d2665a6b2 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -5,6 +5,7 @@ menu "Display Engine Configuration" config DRM_AMD_DC bool "AMD DC - Enable new display engine" default y + depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64 select SND_HDA_COMPONENT if SND_HDA_CORE select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128) help @@ -12,6 +13,12 @@ config DRM_AMD_DC support for AMDGPU. This adds required support for Vega and Raven ASICs. + calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) + architectures built with Clang (all released versions), whereby the stack + frame gets blown up to well over 5k. This would cause an immediate kernel + panic on most architectures. We'll revert this when the following bug report + has been resolved: https://github.com/llvm/llvm-project/issues/41896. + config DRM_AMD_DC_DCN def_bool n help -- 2.38.1.584.g0f3c55d4c2-goog
[PATCH v2 0/2] Fix a bunch of allmodconfig errors
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
With this set applied, I am able to obtain a successful allmodconfig Arm build.
v1 => v2:
- Remove superfluous change (these two override it)
- Mark only DRM_AMD_DC ("the new display engine) as Broken
- Change logic to only *include* working arches, not *preclude* them
Lee Jones (2):
drm/amdgpu: Temporarily disable broken Clang builds due to blown
stack-frame
Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is
enabled
drivers/gpu/drm/amd/display/Kconfig | 7 +++
lib/Kconfig.debug | 1 +
2 files changed, 8 insertions(+)
--
2.38.1.584.g0f3c55d4c2-goog
Re: [PATCH 2/5] driver core: make struct class.devnode() take a const *
Em Wed, 23 Nov 2022 13:25:20 +0100
Greg Kroah-Hartman escreveu:
> The devnode() in struct class should not be modifying the device that is
> passed into it, so mark it as a const * and propagate the function
> signature changes out into all relevant subsystems that use this
> callback.
Acked-by: Mauro Carvalho Chehab
>
> Cc: Fenghua Yu
> Cc: Reinette Chatre
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: x...@kernel.org
> Cc: "H. Peter Anvin"
> Cc: FUJITA Tomonori
> Cc: Jens Axboe
> Cc: Justin Sanders
> Cc: Arnd Bergmann
> Cc: Sumit Semwal
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: John Stultz
> Cc: "Christian König"
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Dennis Dalessandro
> Cc: Dmitry Torokhov
> Cc: Mauro Carvalho Chehab
> Cc: Sean Young
> Cc: Frank Haverkamp
> Cc: Jiri Slaby
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: Kees Cook
> Cc: Anton Vorontsov
> Cc: Colin Cross
> Cc: Tony Luck
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Hans Verkuil
> Cc: Christophe JAILLET
> Cc: Xie Yongji
> Cc: Gautam Dawar
> Cc: Dan Carpenter
> Cc: Eli Cohen
> Cc: Parav Pandit
> Cc: Maxime Coquelin
> Cc: alsa-de...@alsa-project.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: k...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-bl...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 ++--
> arch/x86/kernel/cpuid.c| 2 +-
> arch/x86/kernel/msr.c | 2 +-
> block/bsg.c| 2 +-
> drivers/block/aoe/aoechr.c | 2 +-
> drivers/char/mem.c | 2 +-
> drivers/char/misc.c| 4 ++--
> drivers/dma-buf/dma-heap.c | 2 +-
> drivers/gpu/drm/drm_sysfs.c| 2 +-
> drivers/infiniband/core/user_mad.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 2 +-
> drivers/infiniband/hw/hfi1/device.c| 4 ++--
> drivers/input/input.c | 2 +-
> drivers/media/dvb-core/dvbdev.c| 4 ++--
> drivers/media/pci/ddbridge/ddbridge-core.c | 4 ++--
> drivers/media/rc/rc-main.c | 2 +-
> drivers/misc/genwqe/card_base.c| 2 +-
> drivers/tty/tty_io.c | 2 +-
> drivers/usb/core/file.c| 2 +-
> drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
> drivers/vfio/vfio_main.c | 2 +-
> fs/pstore/pmsg.c | 2 +-
> include/linux/device/class.h | 2 +-
> sound/sound_core.c | 2 +-
> 24 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> index d961ae3ed96e..4e4231a58f38 100644
> --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> @@ -1560,9 +1560,9 @@ static const struct file_operations
> pseudo_lock_dev_fops = {
> .mmap = pseudo_lock_dev_mmap,
> };
>
> -static char *pseudo_lock_devnode(struct device *dev, umode_t *mode)
> +static char *pseudo_lock_devnode(const struct device *dev, umode_t *mode)
> {
> - struct rdtgroup *rdtgrp;
> + const struct rdtgroup *rdtgrp;
>
> rdtgrp = dev_get_drvdata(dev);
> if (mode)
> diff --git a/arch/x86/kernel/cpuid.c b/arch/x86/kernel/cpuid.c
> index 6f7b8cc1bc9f..621ba9c0f17a 100644
> --- a/arch/x86/kernel/cpuid.c
> +++ b/arch/x86/kernel/cpuid.c
> @@ -139,7 +139,7 @@ static int cpuid_device_destroy(unsigned int cpu)
> return 0;
> }
>
> -static char *cpuid_devnode(struct device *dev, umode_t *mode)
> +static char *cpuid_devnode(const struct device *dev, umode_t *mode)
> {
> return kasprintf(GFP_KERNEL, "cpu/%u/cpuid", MINOR(dev->devt));
> }
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index ed8ac6bcbafb..708751311786 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -250,7 +250,7 @@ static int msr_device_destroy(unsigned int cpu)
> return 0;
> }
>
> -static char *msr_devnode(struct device *dev, umode_t *mode)
> +static char *msr_devnode(const struct device *dev, umode_t *mode)
> {
> return kasprintf(GFP_KERNEL, "cpu/%u/msr", MINOR(dev->devt));
> }
> diff --git a/block/bsg.c b/block/bsg.c
> index 2ab1351eb082..08046bd9207d 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -232,7 +232,7 @@ struct bsg_device
Re: [PATCH 21/24] drm/vc4: hvs: Provide a function to initialize the HVS structure
On 11/23/22 16:26, Maxime Ripard wrote: > We'll need to initialize the HVS structure without a backing device to > create a mock we'll use for testing. > > Split the structure initialization part into a separate function. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 20/24] drm/vc4: crtc: Provide a CRTC name
On 11/23/22 16:26, Maxime Ripard wrote:
> It's fairly hard to figure out the instance of the CRTC affected by an
> atomic change using the default name.
>
> Since we can provide our own to the CRTC initialization functions, let's
> do so to make the debugging sessions easier.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 10 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_txp.c | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 8bc30ad0904b..59e473059fa2 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -1118,6 +1118,7 @@ static const struct drm_crtc_helper_funcs
> vc4_crtc_helper_funcs = {
>
> static const struct vc4_pv_data bcm2835_pv0_data = {
> .base = {
> + .name = "pixelvalve-0",
I wonder if would make sense to add the SoC name too, but either way:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 19/24] drm/vc4: crtc: Make encoder lookup helper public
On 11/23/22 16:26, Maxime Ripard wrote: > We'll need a function that looks up an encoder by its vc4_encoder_type. > Such a function is already present in the CRTC code, so let's make it > public so that we can reuse it in the unit tests. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 18/24] drm/vc4: crtc: Introduce a lower-level crtc init helper
On 11/23/22 16:26, Maxime Ripard wrote: > The current vc4_crtc_init() helper assumes that we will be using > hardware planes and calls vc4_plane_init(). > > While it's a reasonable assumption, we'll want to mock the plane and > thus provide our own. Let's create a helper that will take the plane as > an argument. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH] drm/imx: move IPUv3 driver into separate subdirectory
The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
one of them live in the drivers/gpu/drm/imx toplevel directory and the
other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
into its own subdirectory to make the separation more clear.
Signed-off-by: Lucas Stach
---
MAINTAINERS | 2 +-
drivers/gpu/drm/imx/Kconfig | 41 +-
drivers/gpu/drm/imx/Makefile | 10 +
drivers/gpu/drm/imx/ipuv3/Kconfig | 42 +++
drivers/gpu/drm/imx/ipuv3/Makefile| 11 +
drivers/gpu/drm/imx/{ => ipuv3}/dw_hdmi-imx.c | 0
.../gpu/drm/imx/{ => ipuv3}/imx-drm-core.c| 0
drivers/gpu/drm/imx/{ => ipuv3}/imx-drm.h | 0
drivers/gpu/drm/imx/{ => ipuv3}/imx-ldb.c | 0
drivers/gpu/drm/imx/{ => ipuv3}/imx-tve.c | 0
drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-crtc.c | 0
drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.c | 0
drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.h | 0
.../drm/imx/{ => ipuv3}/parallel-display.c| 0
14 files changed, 56 insertions(+), 50 deletions(-)
create mode 100644 drivers/gpu/drm/imx/ipuv3/Kconfig
create mode 100644 drivers/gpu/drm/imx/ipuv3/Makefile
rename drivers/gpu/drm/imx/{ => ipuv3}/dw_hdmi-imx.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/imx-drm-core.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/imx-drm.h (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/imx-ldb.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/imx-tve.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-crtc.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.c (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.h (100%)
rename drivers/gpu/drm/imx/{ => ipuv3}/parallel-display.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2585e7edc335..7a2ff684b4df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6896,7 +6896,7 @@ M:Philipp Zabel
L: dri-devel@lists.freedesktop.org
S: Maintained
F: Documentation/devicetree/bindings/display/imx/
-F: drivers/gpu/drm/imx/
+F: drivers/gpu/drm/imx/ipuv3/
F: drivers/gpu/ipu-v3/
DRM DRIVERS FOR FREESCALE IMX BRIDGE
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index fd5b2471fdf0..e5749927fd6c 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -1,43 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-config DRM_IMX
- tristate "DRM Support for Freescale i.MX"
- select DRM_KMS_HELPER
- select VIDEOMODE_HELPERS
- select DRM_GEM_DMA_HELPER
- depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
- depends on IMX_IPUV3_CORE
- help
- enable i.MX graphics support
-
-config DRM_IMX_PARALLEL_DISPLAY
- tristate "Support for parallel displays"
- select DRM_PANEL
- depends on DRM_IMX
- select VIDEOMODE_HELPERS
-
-config DRM_IMX_TVE
- tristate "Support for TV and VGA displays"
- depends on DRM_IMX
- depends on COMMON_CLK
- select REGMAP_MMIO
- help
- Choose this to enable the internal Television Encoder (TVe)
- found on i.MX53 processors.
-
-config DRM_IMX_LDB
- tristate "Support for LVDS displays"
- depends on DRM_IMX && MFD_SYSCON
- depends on COMMON_CLK
- select DRM_PANEL
- help
- Choose this to enable the internal LVDS Display Bridge (LDB)
- found on i.MX53 and i.MX6 processors.
-
-config DRM_IMX_HDMI
- tristate "Freescale i.MX DRM HDMI"
- select DRM_DW_HDMI
- depends on DRM_IMX && OF
- help
- Choose this if you want to use HDMI on i.MX6.
source "drivers/gpu/drm/imx/dcss/Kconfig"
+source "drivers/gpu/drm/imx/ipuv3/Kconfig"
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index b644deffe948..909622864716 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -1,12 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-imxdrm-objs := imx-drm-core.o ipuv3-crtc.o ipuv3-plane.o
-
-obj-$(CONFIG_DRM_IMX) += imxdrm.o
-
-obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
-obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
-obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
-
-obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
+obj-$(CONFIG_DRM_IMX) += ipuv3/
diff --git a/drivers/gpu/drm/imx/ipuv3/Kconfig
b/drivers/gpu/drm/imx/ipuv3/Kconfig
new file mode 100644
index ..f518eb47a18e
--- /dev/null
+++ b/drivers/gpu/drm/imx/ipuv3/Kconfig
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_IMX
+ tristate "DRM Support for Freescale i.MX"
+ select DRM_KMS_HELPER
+ select VIDEOMODE_HELPERS
+ select DRM_GEM_DMA_HELPER
+ depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
+ depends on IMX_IPUV3_CORE
+ help
+ enable i.MX graphics support
+
+config DRM_IMX_PARALLEL_DISPLAY
+
Re: [PATCH] drm/msm/mdp5: fix reading hw revision on db410c platform
On 11/25/2022 1:21 AM, Dmitry Baryshkov wrote:
On 25/11/2022 07:45, Abhinav Kumar wrote:
On 11/24/2022 4:02 PM, Dmitry Baryshkov wrote:
Since the commit commit c6122688f265 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC is not enabled. Revert a part of the offending commit
(moving rpm enablement) and set priv->kms earlier. This make it possible
to use pm_runtime_get_sync() during read_mdp_hw_revision(), which will
power up both the MDP5 and MDSS devices.
This is the exact concern I had even when c6122688f265 was pushed.
https://patchwork.freedesktop.org/patch/508334/#comment_917689
Was the response given that time not correct then?
Not fully correct. I did not notice, that non-rpm-enabled mdp5 node
doesn't force mdss to be in the on state. (Which is strange. Maybe we
are leaking pm_runtime_enable() for it somewhere.)
hmmm, this is a safer change as we are atleast not bypassing pm runtime.
From that perspective,
Reviewed-by: Abhinav Kumar
https://patchwork.freedesktop.org/patch/508334/#comment_917713
Fixes: c6122688f265 ("drm/msm/mdp5: stop overriding drvdata")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index b46f983f2b46..29ae5c9613f3 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -519,10 +519,9 @@ static void read_mdp_hw_revision(struct mdp5_kms
*mdp5_kms,
struct device *dev = _kms->pdev->dev;
u32 version;
- /* Manually enable the MDP5, as pm runtime isn't usable yet. */
- mdp5_enable(mdp5_kms);
+ pm_runtime_get_sync(dev);
version = mdp5_read(mdp5_kms, REG_MDP5_HW_VERSION);
- mdp5_disable(mdp5_kms);
+ pm_runtime_put_sync(dev);
*major = FIELD(version, MDP5_HW_VERSION_MAJOR);
*minor = FIELD(version, MDP5_HW_VERSION_MINOR);
@@ -839,6 +838,12 @@ static int mdp5_init(struct platform_device
*pdev, struct drm_device *dev)
*/
clk_set_rate(mdp5_kms->core_clk, 2);
+ /* set uninit-ed kms */
+ priv->kms = _kms->base.base;
+
+ pm_runtime_enable(>dev);
+ mdp5_kms->rpm_enabled = true;
+
read_mdp_hw_revision(mdp5_kms, , );
mdp5_kms->cfg = mdp5_cfg_init(mdp5_kms, major, minor);
@@ -887,12 +892,6 @@ static int mdp5_init(struct platform_device
*pdev, struct drm_device *dev)
if (ret)
goto fail;
- /* set uninit-ed kms */
- priv->kms = _kms->base.base;
-
- pm_runtime_enable(>dev);
- mdp5_kms->rpm_enabled = true;
-
return 0;
fail:
if (mdp5_kms)
[PATCH 6/6] drm/etnaviv: add HWDB entry for VIPNano-QI.7120.0055
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
index f2fc645c7956..3f6fd9a3c088 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
@@ -130,6 +130,37 @@ static const struct etnaviv_chip_identity
etnaviv_chip_identities[] = {
.minor_features10 = 0x90044250,
.minor_features11 = 0x0024,
},
+ {
+ .model = 0x8000,
+ .revision = 0x7120,
+ .product_id = 0x45080009,
+ .customer_id = 0x88,
+ .eco_id = 0,
+ .stream_count = 8,
+ .register_max = 64,
+ .thread_count = 256,
+ .shader_core_count = 1,
+ .vertex_cache_size = 16,
+ .vertex_output_buffer_size = 1024,
+ .pixel_pipes = 1,
+ .instruction_count = 512,
+ .num_constants = 320,
+ .buffer_size = 0,
+ .varyings_count = 16,
+ .features = 0xe0287cac,
+ .minor_features0 = 0xc1799eff,
+ .minor_features1 = 0xfefbfadb,
+ .minor_features2 = 0xeb9d6fbf,
+ .minor_features3 = 0xedfffced,
+ .minor_features4 = 0xd30dafc7,
+ .minor_features5 = 0x7b5ac333,
+ .minor_features6 = 0xfc8ee200,
+ .minor_features7 = 0x03fffa6f,
+ .minor_features8 = 0x00fe0ef0,
+ .minor_features9 = 0x0088003c,
+ .minor_features10 = 0x108048c0,
+ .minor_features11 = 0x0010,
+ },
};
bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu)
--
2.38.1
[PATCH 0/6] Support for the NPU in Vim3
Hi, This series adds support for the Verisilicon VIPNano-QI NPU in the A311D as in the VIM3 board. The IP is very closeley based on previous Vivante GPUs, so the etnaviv driver works basically unchanged. Regards, Tomeu Tomeu Vizoso (6): dt-bindings: reset: meson-g12a: Add missing NNA reset dt-bindings: power: Add NNA power domain soc: amlogic: meson-pwrc: Add NNA power domain for A311D arm64: dts: meson-g12-common: Add reference to NNA reset to pwrc arm64: dts: Add DT node for the VIPNano-QI on the A311D drm/etnaviv: add HWDB entry for VIPNano-QI.7120.0055 .../boot/dts/amlogic/meson-g12-common.dtsi| 15 +++-- .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 4 +++ drivers/gpu/drm/etnaviv/etnaviv_hwdb.c| 31 +++ drivers/soc/amlogic/meson-ee-pwrc.c | 17 ++ include/dt-bindings/power/meson-g12a-power.h | 1 + .../reset/amlogic,meson-g12a-reset.h | 4 ++- 6 files changed, 69 insertions(+), 3 deletions(-) -- 2.38.1
Re: [Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5247d88b3c13..d409a77449a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- int err;
+ long err;
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
- err = ttm_bo_wait(bo, true, false);
- if (err)
+ err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ true, 15 * HZ);
This 15 second stuck out a bit for me and then on a slightly deeper look
it seems this timeout will "leak" into a few of i915 code paths. If we
look at the difference between the legacy shmem and ttm backend I am not
sure if the legacy one is blocking or not - but if it can block I don't
think it would have an arbitrary timeout like this. Matt your thoughts?
Regards,
Tvrtko
+ if (err < 0)
return err;
+ if (err == 0)
+ return -EBUSY;
err = i915_ttm_move_notify(bo);
if (err)
Re: [PATCH 17/24] drm/vc4: crtc: Pass the device and data in vc4_crtc_init
On 11/23/22 16:25, Maxime Ripard wrote: > Both users of vc4_crtc_init need the same extra initialization to set > the pointer to the platform_device and the CRTC data. Since it's > mandatory, let's make them both arguments of vc4_crtc_init(). > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 16/24] drm/vc4: txp: Initialise the CRTC before the encoder and connector
On 11/23/22 16:25, Maxime Ripard wrote: > It makes more sense to register the CRTC before the encoder and > connectors, so let's move our call around. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 15/24] drm/vc4: Add TXP encoder type
On 11/23/22 16:25, Maxime Ripard wrote: > The TXP is integrated as a separate CRTC/Encoder/Connector combo, but > for some reason doesn't rely on the vc4_encoder type and it's associated > type. > > Let's create a type to make it consistent with the other encoders. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 14/24] drm/vc4: txp: Reorder the variable assignments
On 11/23/22 16:25, Maxime Ripard wrote: > The current order of variable assignments is unneccessarily complex, > let's make it simpler. > > Signed-off-by: Maxime Ripard > --- Much easier to follow indeed. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 13/24] drm/vc4: kms: Constify the HVS old/new state helpers
On 11/23/22 16:25, Maxime Ripard wrote: > The vc4_hvs_get_(old|new)_global_state functions don't modify the > drm_atomic_state passed as an argument, so let's make it const. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 12/24] drm/vc4: Move HVS state to main header
On 11/23/22 16:25, Maxime Ripard wrote: > In order to introduce unit tests for the HVS state computation, we'll > need access to the vc4_hvs_state struct definition and its associated > helpers. > > Let's move them in our driver header. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 11/24] drm/vc4: Constify container_of wrappers
On 11/23/22 16:25, Maxime Ripard wrote: > None of our wrappers around container_of to access our objects from the > DRM object pointer actually modify the latter. > > Let's make them const. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 10/24] drm/vc4: kms: Sort the CRTCs by output before assigning them
On 11/23/22 16:25, Maxime Ripard wrote:
> On the vc4 devices (and later), the blending is done by a single device
> called the HVS. The HVS has three FIFO that can operate in parallel, and
> route their output to 6 CRTCs and 7 encoders on the BCM2711.
>
> Each of these CRTCs and encoders have some contraints on which FIFO they
constraints.
> can feed from, so we need some code to take all those constraints into
> account and assign FIFOs to CRTCs.
>
> The problem can be simplified by assigning those FIFOs to CRTCs by
> ascending output index number. We had a comment mentioning it already,
> but we were never actually enforcing it.
>
> It was working still in most situations because the probe order is
> roughly equivalent, except for the (optional, and fairly rarely used on
> the Pi4) VEC which was last in the probe order sequence, but one of the
> earliest device to assign.
>
> This resulted in configurations that were rejected by our code but were
> still valid with a different assignment.
>
> We can fix this by making sure we assign CRTCs to FIFOs by ordering
> them by ascending HVS output index.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
> ---
[...]
>
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> - struct vc4_crtc_state *old_vc4_crtc_state =
> - to_vc4_crtc_state(old_crtc_state);
> - struct vc4_crtc_state *new_vc4_crtc_state =
> - to_vc4_crtc_state(new_crtc_state);
> - struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + /*
> + * The problem we have to solve here is that we have up to 7
> + * encoders, connected to up to 6 CRTCs.
> + *
> + * Those CRTCs, depending on the instance, can be routed to 1, 2
> + * or 3 HVS FIFOs, and we need to set the change the muxing
This sentence sounds a little bit off to me. Did you mean:
"we need to set the muxing between" or "we need to change the muxing" ?
I'm not familiar with VC4 but the patch seems to do what the commit message
says, so the changes look good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 09/24] drm/atomic: Constify the old/new state accessors
On 11/23/22 16:25, Maxime Ripard wrote: > The drm_atomic_get_(old|new)_*_state don't modify the passed > drm_atomic_state, so we can make it const. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 08/24] drm/tests: Add a test for DRM managed actions
On 11/23/22 16:25, Maxime Ripard wrote: > DRM-managed actions are supposed to be ran whenever the device is > released. Let's introduce a basic unit test to make sure it happens. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/tests/Makefile | 1 + > drivers/gpu/drm/tests/drm_managed_test.c | 68 > > 2 files changed, 69 insertions(+) > > diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile > index b29ef1085cad..35962c6ef0c4 100644 > --- a/drivers/gpu/drm/tests/Makefile > +++ b/drivers/gpu/drm/tests/Makefile > @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \ > drm_format_test.o \ > drm_framebuffer_test.o \ > drm_kunit_helpers.o \ > + drm_managed_test.o \ > drm_mm_test.o \ > drm_plane_helper_test.o \ > drm_rect_test.o > diff --git a/drivers/gpu/drm/tests/drm_managed_test.c > b/drivers/gpu/drm/tests/drm_managed_test.c > new file mode 100644 > index ..4fc11b289d9e > --- /dev/null > +++ b/drivers/gpu/drm/tests/drm_managed_test.c > @@ -0,0 +1,68 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +#include > +#include > + > +#include > + > +#include > + > +#include "drm_kunit_helpers.h" > + > +#define TEST_TIMEOUT_MS 100 > + Why did you choose this timeout value? Maybe we can add some comments explaining the rationale. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 07/24] drm/tests: helpers: Allow to pass a custom drm_driver
On 11/23/22 16:25, Maxime Ripard wrote: > Some tests will need to provide their own drm_driver instead of relying > on the dumb one in the helpers, so let's create a helper that allows to > do so. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 06/24] drm/tests: kunit: Allow for a custom device struct to be allocated
On 11/23/22 16:25, Maxime Ripard wrote: > The current helper to allocate a DRM device doesn't allow for any > subclassing by drivers, which is going to be troublesome as we work on > getting some kunit testing on atomic modesetting code. > > Let's use a similar pattern to the other allocation helpers by providing > the structure size and offset as arguments. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH] drm/tegra: Add check for dma_alloc_coherent()
Since the dma_alloc_coherent() may return NULL,
the pointer returned needs to be checked to avoid
null-poineter dereference.
Fixes: 46f226c93d35 ("drm/tegra: Add NVDEC driver")
Signed-off-by: Zeng Heng
---
drivers/gpu/drm/tegra/nvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/nvdec.c b/drivers/gpu/drm/tegra/nvdec.c
index 276fe0472730..4f667fb502d8 100644
--- a/drivers/gpu/drm/tegra/nvdec.c
+++ b/drivers/gpu/drm/tegra/nvdec.c
@@ -216,6 +216,8 @@ static int nvdec_load_firmware(struct nvdec *nvdec)
} else {
virt = tegra_drm_alloc(tegra, size, );
}
+ if (IS_ERR_OR_NULL(virt))
+ return -ENOMEM;
nvdec->falcon.firmware.virt = virt;
nvdec->falcon.firmware.iova = iova;
--
2.25.1
[PATCH 9/9] drm/ttm: move ttm_bo_wait into VMWGFX
Not used anymore by other drivers or TTM itself.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 44 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 -
drivers/gpu/drm/vmwgfx/ttm_object.h | 11
include/drm/ttm/ttm_bo.h| 1 -
4 files changed, 39 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cd266a067773..326a3d13a829 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1087,47 +1087,35 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
EXPORT_SYMBOL(ttm_bo_unmap_virtual);
/**
- * ttm_bo_wait - wait for buffer idle.
+ * ttm_bo_wait_ctx - wait for buffer idle.
*
* @bo: The buffer object.
- * @interruptible: Use interruptible wait.
- * @no_wait: Return immediately if buffer is busy.
+ * @ctx: defines how to wait
*
- * This function must be called with the bo::mutex held, and makes
- * sure any previous rendering to the buffer is completed.
- * Note: It might be necessary to block validations before the
- * wait by reserving the buffer.
- * Returns -EBUSY if no_wait is true and the buffer is busy.
- * Returns -ERESTARTSYS if interrupted by a signal.
+ * Waits for the buffer to be idle. Used timeout depends on the context.
+ * Returns -EBUSY if wait timed outt, -ERESTARTSYS if interrupted by a signal
or
+ * zero on success.
*/
-int ttm_bo_wait(struct ttm_buffer_object *bo,
- bool interruptible, bool no_wait)
+int ttm_bo_wait_ctx(struct ttm_buffer_object *bo, struct ttm_operation_ctx
*ctx)
{
- long timeout = 15 * HZ;
+ long ret;
- if (no_wait) {
- if (dma_resv_test_signaled(bo->base.resv,
DMA_RESV_USAGE_BOOKKEEP))
+ if (ctx->no_wait_gpu) {
+ if (dma_resv_test_signaled(bo->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP))
return 0;
else
return -EBUSY;
}
- timeout = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
- interruptible, timeout);
- if (timeout < 0)
- return timeout;
-
- if (timeout == 0)
+ ret = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ ctx->interruptible, 15 * HZ);
+ if (unlikely(ret < 0))
+ return ret;
+ if (unlikely(ret == 0))
return -EBUSY;
-
return 0;
}
-EXPORT_SYMBOL(ttm_bo_wait);
-
-int ttm_bo_wait_ctx(struct ttm_buffer_object *bo, struct ttm_operation_ctx
*ctx)
-{
- return ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
-}
EXPORT_SYMBOL(ttm_bo_wait_ctx);
int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
@@ -1135,7 +1123,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
{
struct ttm_place place;
bool locked;
- int ret;
+ long ret;
/*
* While the bo may already reside in SYSTEM placement, set
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fee7c20775c0..ed2b28734541 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -547,9 +547,13 @@ EXPORT_SYMBOL(ttm_bo_vunmap);
static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
bool dst_use_tt)
{
- int ret;
- ret = ttm_bo_wait(bo, false, false);
- if (ret)
+ long ret;
+
+ ret = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ false, 15 * HZ);
+ if (ret == 0)
+ return -EBUSY;
+ if (ret < 0)
return ret;
if (!dst_use_tt)
@@ -710,8 +714,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
return ret;
/* If already idle, no need for ghost object dance. */
- ret = ttm_bo_wait(bo, false, true);
- if (ret != -EBUSY) {
+ if (dma_resv_test_signaled(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP)) {
if (!bo->ttm) {
/* See comment below about clearing. */
ret = ttm_tt_create(bo, true);
@@ -748,8 +751,10 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
ret = dma_resv_copy_fences(>base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
- if (ret)
- ttm_bo_wait(bo, false, false);
+ if (ret) {
+ dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
+ false, MAX_SCHEDULE_TIMEOUT);
+ }
dma_resv_unlock(>base._resv);
ttm_bo_put(ghost);
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.h
b/drivers/gpu/drm/vmwgfx/ttm_object.h
index f0ebbe340ad6..95a9679f9d39
[PATCH 8/9] drm/ttm: use ttm_bo_wait_ctx instead of ttm_bo_wait
Make sure that we use the correct settings from the context.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f9d9fd2d865d..cd266a067773 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -439,7 +439,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bdev->funcs->evict_flags(bo, );
if (!placement.num_placement && !placement.num_busy_placement) {
- ret = ttm_bo_wait(bo, true, false);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
return ret;
@@ -1190,7 +1190,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
/*
* Make sure BO is idle.
*/
- ret = ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (unlikely(ret != 0))
goto out;
--
2.34.1
