[PATCH v7 5/5] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Acked-by: Jordan Justen
Reviewed-by: Ramalingam C
Reviewed-by: Thomas Hellström
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE (which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
[PATCH v7 1/5] drm/i915: add needs_compact_pt flag
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
* minor doc formatting
Suggested-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_drv.h | 11 ---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
[PATCH v7 2/5] drm/i915: enforce min GTT alignment for discrete cards
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../i915/gem/selftests/i915_gem_client_blt.c | 21 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 18
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
5 files changed, 115 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(>ce->vm->mutex);
memset(, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct
rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+>buffers[2], t->hole + t->align,
>buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+
[PATCH v7 3/5] drm/i915: support 64K GTT pages for discrete cards
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
[PATCH v7 4/5] drm/i915: add gtt misalignment test
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..9afea008192d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct
intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(>node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 <<
(ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* compact-pt should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size !=
expected_node_size) {
+ err = i915_vma_unbind_unlocked(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind_unlocked(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum
intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_up(hole_start + (hole_size / 2),
min_alignment);
+
+ /* we can't test < 4k alignment due to flags being encoded in
lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large
alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else
[PATCH v7 0/5] discrete card 64K page support
This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed v3: * fix uapi doc typos * add needs_compact_pt flag patch * cleanup vma expansion to use vm->min_alignment instead of hard coding v4: * fix err return in igt_ppgtt_compact test * placate ci robot with explicit enum conversion in misaligned_pin * remove some blank lines v5: * fix obj alignment requirements querying for internal buffers that have no memory region associated. (fixes v3 bug) v6: * use NEEDS_COMPACT_PT inead of hard coding in misalignment test * tiled_blits_create correctly pick largest required alignment * minor doc formatting v7: * use i915_vma_unbind_unlocked in misalignment test Reviewed-by: Thomas Hellström Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (1): drm/i915: add needs_compact_pt flag Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 + .../i915/gem/selftests/i915_gem_client_blt.c | 21 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 - drivers/gpu/drm/i915/gt/intel_gtt.c | 12 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 ++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_vma.c | 9 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 224 +++--- include/uapi/drm/i915_drm.h | 44 +++- 12 files changed, 462 insertions(+), 52 deletions(-) -- 2.25.1
Re: [PATCH v3 3/3] fbcon: Add option to enable legacy hardware acceleration
On Tue, Feb 1, 2022 at 7:59 PM Helge Deller wrote:
>
> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
> enable bitblt and fillrect hardware acceleration in the framebuffer
> console. If disabled, such acceleration will not be used, even if it is
> supported by the graphics hardware driver.
>
> If you plan to use DRM as your main graphics output system, you should
> disable this option since it will prevent compiling in code which isn't
> used later on when DRM takes over.
>
> For all other configurations, e.g. if none of your graphic cards support
> DRM (yet), DRM isn't available for your architecture, or you can't be
> sure that the graphic card in the target system will support DRM, you
> most likely want to enable this option.
>
> In the non-accelerated case (e.g. when DRM is used), the inlined
> fb_scrollmode() function is hardcoded to return SCROLL_REDRAW and as such the
> compiler is able to optimize much unneccesary code away.
>
> In this v3 patch version I additionally changed the GETVYRES() and GETVXRES()
> macros to take a pointer to the fbcon_display struct. This fixes the build
> when
> console rotation is enabled and helps the compiler again to optimize out code.
>
> Signed-off-by: Helge Deller
> Cc: sta...@vger.kernel.org # v5.10+
> Signed-off-by: Helge Deller
> ---
> drivers/video/console/Kconfig | 11 +++
> drivers/video/fbdev/core/fbcon.c| 39 ++---
> drivers/video/fbdev/core/fbcon.h| 15 +-
> drivers/video/fbdev/core/fbcon_ccw.c| 10 +++
> drivers/video/fbdev/core/fbcon_cw.c | 10 +++
> drivers/video/fbdev/core/fbcon_rotate.h | 4 +--
> drivers/video/fbdev/core/fbcon_ud.c | 20 ++---
> 7 files changed, 75 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index 840d9813b0bc..6029fd41d7d0 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE
> help
> Low-level framebuffer-based console driver.
>
> +config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + bool "Framebuffer Console hardware acceleration support"
> + depends on FRAMEBUFFER_CONSOLE
> + default n if DRM
> + default y
> + help
> + If you use a system on which DRM is fully supported you usually
> want to say N,
> + otherwise you probably want to enable this option.
> + If enabled the framebuffer console will utilize the hardware
> acceleration
> + of your graphics card by using hardware bitblt and fillrect
> features.
This really doesn't have much to do with DRM but more about running
questionable code. That's why I went with the generalized stern
warning and default n, and explained when it's ok to do this (single
user and you care more about fbcon performance than potential issues
because you only run trusted stuff with access to your vt and fbdev
/dev node). Also you didn't keep any todo entry for removing DRM accel
code, and iirc some nouveau folks also complained that they at least
once had some kind of accel, so that's another reason to not tie this
to DRM.
Anyway aside from this looks reasonable, can you pls respin with a
more cautious Kconfig text?
Thanks, Daniel
> +
> config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
> bool "Map the console to the primary display device"
> depends on FRAMEBUFFER_CONSOLE
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index b813985f1403..f7b7d35953e8 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1136,11 +1136,13 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> if ((cap & FBINFO_HWACCEL_COPYAREA) &&
> !(cap & FBINFO_HWACCEL_DISABLED))
> p->scrollmode = SCROLL_MOVE;
> else /* default to something safe */
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
> * ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1705,7 +1707,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> count = vc->vc_rows;
> if (logo_shown >= 0)
> goto redraw_up;
> - switch (p->scrollmode) {
> + switch (fb_scrollmode(p)) {
> case SCROLL_MOVE:
> fbcon_redraw_blit(vc, info, p, t, b - t - count,
> count);
> @@ -1795,7 +1797,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> count = vc->vc_rows;
> if (logo_shown >= 0)
> goto redraw_down;
> - switch (p->scrollmode) {
> + switch
Re: [PATCH 1/4] drm: Add I2C connector type
On Tuesday, February 1st, 2022 at 21:57, Sam Ravnborg wrote: > As I wrote in another part of this thread(s) - typing the patch is easy. > But I do not understand the userspace implications so I need someone > else to say go. User-space shouldn't really use the connector for anything except making it easier for the user to understand where to plug the display cable. I think a generic "panel" connector type makes sense.
Re: [PATCH v3 3/3] fbcon: Add option to enable legacy hardware acceleration
Hello Daniel, On 2/1/22 21:11, Daniel Vetter wrote: > On Tue, Feb 1, 2022 at 7:59 PM Helge Deller wrote: >> >> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to >> enable bitblt and fillrect hardware acceleration in the framebuffer >> console. If disabled, such acceleration will not be used, even if it is >> supported by the graphics hardware driver. >> >> If you plan to use DRM as your main graphics output system, you should >> disable this option since it will prevent compiling in code which isn't >> used later on when DRM takes over. >> >> For all other configurations, e.g. if none of your graphic cards support >> DRM (yet), DRM isn't available for your architecture, or you can't be >> sure that the graphic card in the target system will support DRM, you >> most likely want to enable this option. >> >> In the non-accelerated case (e.g. when DRM is used), the inlined >> fb_scrollmode() function is hardcoded to return SCROLL_REDRAW and as such the >> compiler is able to optimize much unneccesary code away. >> >> In this v3 patch version I additionally changed the GETVYRES() and GETVXRES() >> macros to take a pointer to the fbcon_display struct. This fixes the build >> when >> console rotation is enabled and helps the compiler again to optimize out >> code. >> >> Signed-off-by: Helge Deller >> Cc: sta...@vger.kernel.org # v5.10+ >> Signed-off-by: Helge Deller >> --- >> drivers/video/console/Kconfig | 11 +++ >> drivers/video/fbdev/core/fbcon.c| 39 ++--- >> drivers/video/fbdev/core/fbcon.h| 15 +- >> drivers/video/fbdev/core/fbcon_ccw.c| 10 +++ >> drivers/video/fbdev/core/fbcon_cw.c | 10 +++ >> drivers/video/fbdev/core/fbcon_rotate.h | 4 +-- >> drivers/video/fbdev/core/fbcon_ud.c | 20 ++--- >> 7 files changed, 75 insertions(+), 34 deletions(-) >> >> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig >> index 840d9813b0bc..6029fd41d7d0 100644 >> --- a/drivers/video/console/Kconfig >> +++ b/drivers/video/console/Kconfig >> @@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE >> help >> Low-level framebuffer-based console driver. >> >> +config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION >> + bool "Framebuffer Console hardware acceleration support" >> + depends on FRAMEBUFFER_CONSOLE >> + default n if DRM >> + default y >> + help >> + If you use a system on which DRM is fully supported you usually >> want to say N, >> + otherwise you probably want to enable this option. >> + If enabled the framebuffer console will utilize the hardware >> acceleration >> + of your graphics card by using hardware bitblt and fillrect >> features. > > This really doesn't have much to do with DRM but more about running > questionable code. That's why I went with the generalized stern > warning and default n, and explained when it's ok to do this (single > user and you care more about fbcon performance than potential issues > because you only run trusted stuff with access to your vt and fbdev > /dev node). I think this is something we both will keep to have different opinion about :-) This console acceleration code is not exported or visible to userspace, e.g. you can't access or trigger it via /dev/fb0. It's only called internally from inside fbcon, so it's independed if it's a single- or multi-user system. The only way to "access" it is via standard stdio, where fbcon then either scrolls the screen via redrawing characters at new positions or by using hardware bitblt to move screen contents. IMHO there is nothing which is critical here. Even when I analyzed the existing bug reports, there was none which affected that specific code. Anyway, let's look at that part in your patch: + bool "Enable legacy fbcon code for hw acceleration" + depends on FRAMEBUFFER_CONSOLE + default n + help +Only enable this options if you are in full control of machine since +the fbcon acceleration code is essentially unmaintained and known +problematic. + +If unsure, select n. Since I'm willing to maintain that scrolling/panning code, I'd like to drop the "is essentially unmaintained" part. And the "known problematic" part is up to now just speculative (which would be valid for other parts of the kernel too, btw). As this whole disussions showed, there are some few architectures/platforms which really still need this acceleration, while others don't. So, why not leave the decision up to the arch maintainers, which may opt-in or opt-out, while keeping the default on "n"? With that, here is a new proposal: +config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION + bool "Enable legacy fbcon hardware acceleration code" + depends on FRAMEBUFFER_CONSOLE + default y if (PARISC) # a few other arches may want to be listed here too... + default n + help + This
Re: [PATCH 1/4] drm: Add I2C connector type
Hi Noralf,
On Tue, Feb 01, 2022 at 01:58:16PM +0100, Noralf Trønnes wrote:
>
>
> Den 31.01.2022 21.52, skrev Sam Ravnborg:
> > On Mon, Jan 31, 2022 at 09:12:21PM +0100, Javier Martinez Canillas wrote:
> >> There isn't a connector type for display controllers accesed through I2C,
> >> most drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.
> >>
> >> Add an I2C connector type to match the actual connector.
> >>
> >> As Noralf Trønnes mentions in commit fc06bf1d76d6 ("drm: Add SPI connector
> >> type"), user-space should be able to cope with a connector type that does
> >> not yet understand.
> >>
>
> It turned out that I wasn't entirely correct here, mpv didn't cope with
> unknown types. In the PR to add support Emil Velikov wondered if libdrm
> should handle these connector names:
> https://github.com/mpv-player/mpv/pull/8989#issuecomment-879187711
>
> >> Tested with `modetest -M ssd1307 -c` and shows the connector as unknown-1.
> > I had expected unknown-21??
> >
> >>
> >> Signed-off-by: Javier Martinez Canillas
> > Reviewed-by: Sam Ravnborg
>
> Sam, didn't you and Laurent discuss adding DRM_MODE_CONNECTOR_PANEL for
> such a use case?
You have a splendid memory - yes we did. But no conclusions:
https://lore.kernel.org/dri-devel/?q=DRM_MODE_CONNECTOR_PANEL
As I wrote in another part of this thread(s) - typing the patch is easy.
But I do not understand the userspace implications so I need someone
else to say go.
Sam
Re: [Intel-gfx] [PATCH v2 04/11] drm/i915: Use str_enable_disable()
On Wed, Jan 26, 2022 at 01:39:44AM -0800, Lucas De Marchi wrote:
> Remove the local enabledisable() implementation and adopt the
> str_enable_disable() from linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Daniel Vetter
> Acked-by: Jani Nikula
There's an open-coded version of this in display/intel_pps.c,
intel_pps_backlight_power(). Up to you whether you squash it into this
patch or convert it as a follow-up. Either way.
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_display_power.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_dp.c| 8
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 3 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 4 +++-
> drivers/gpu/drm/i915/i915_utils.h | 5 -
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2f20abc5122d..4b35a8597632 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -25,6 +25,8 @@
> *
> */
>
> +#include
> +
> #include
> #include
>
> @@ -2152,7 +2154,7 @@ static void
> intel_dp_sink_set_msa_timing_par_ignore_state(struct intel_dp *intel
> enable ? DP_MSA_TIMING_PAR_IGNORE_EN : 0) <= 0)
> drm_dbg_kms(>drm,
> "Failed to %s MSA_TIMING_PAR_IGNORE in the sink\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
> }
>
> static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 369317805d24..1f77cb9edddf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -3,6 +3,8 @@
> * Copyright © 2019 Intel Corporation
> */
>
> +#include
> +
> #include "i915_drv.h"
> #include "i915_irq.h"
> #include "intel_cdclk.h"
> @@ -5302,7 +5304,7 @@ static void gen9_dbuf_slice_set(struct drm_i915_private
> *dev_priv,
> state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> drm_WARN(_priv->drm, enable != state,
>"DBuf slice %d power %s timeout!\n",
> - slice, enabledisable(enable));
> + slice, str_enable_disable(enable));
> }
>
> void gen9_dbuf_slices_update(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 62c1535d696d..933fc316ea53 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1987,7 +1987,7 @@ void intel_dp_sink_set_decompression_state(struct
> intel_dp *intel_dp,
> if (ret < 0)
> drm_dbg_kms(>drm,
> "Failed to %s sink decompression state\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
> }
>
> static void
> @@ -2463,7 +2463,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> if (drm_dp_dpcd_writeb(_dp->aux,
> DP_PROTOCOL_CONVERTER_CONTROL_0, tmp) != 1)
> drm_dbg_kms(>drm, "Failed to %s protocol converter HDMI
> mode\n",
> - enabledisable(intel_dp->has_hdmi_sink));
> + str_enable_disable(intel_dp->has_hdmi_sink));
>
> tmp = crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
> intel_dp->dfp.ycbcr_444_to_420 ?
> DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
> @@ -2472,7 +2472,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> DP_PROTOCOL_CONVERTER_CONTROL_1, tmp) != 1)
> drm_dbg_kms(>drm,
> "Failed to %s protocol converter YCbCr 4:2:0
> conversion mode\n",
> - enabledisable(intel_dp->dfp.ycbcr_444_to_420));
> + str_enable_disable(intel_dp->dfp.ycbcr_444_to_420));
>
> tmp = 0;
> if (intel_dp->dfp.rgb_to_ycbcr) {
> @@ -2510,7 +2510,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> if (drm_dp_pcon_convert_rgb_to_ycbcr(_dp->aux, tmp) < 0)
> drm_dbg_kms(>drm,
> "Failed to %s protocol converter RGB->YCbCr
> conversion mode\n",
> -enabledisable(tmp));
> +str_enable_disable(tmp));
> }
>
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index de89d40abd38..31c3c3bceb95 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++
Re: [PATCH v3 1/3] dt-bindings: sharp,lq101r1sx01: Add compatible for LQ101R1SX03
On Mon, 31 Jan 2022 02:59:43 +0300, Dmitry Osipenko wrote: > From: Anton Bambura > > LQ101R1SX03 is compatible with LQ101R1SX01 from software perspective, > document it. The LQ101R1SX03 is a newer revision of LQ101R1SX01, it has > minor differences in hardware pins in comparison to the older version. > The newer version of the panel can be found on Android tablets, like > ASUS TF701T. > > Signed-off-by: Anton Bambura > Signed-off-by: Dmitry Osipenko > --- > .../bindings/display/panel/sharp,lq101r1sx01.yaml | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH v1 1/4] fbtft: Unorphan the driver
Hi Daniel, On Tue, Feb 01, 2022 at 06:06:33PM +0100, Daniel Vetter wrote: > On Tue, Feb 1, 2022 at 6:01 PM Geert Uytterhoeven > wrote: > > > > Hi Thomas, > > > > On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann > > wrote: > > > Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas: > > > > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I > > > > used for > > > > now a DRM_MODE_CONNECTOR_Unknown. > > > > > > That might have implications on userspace. Maybe ask around. (Not that > > > we actually run userspace on the device). > > > > Looking at the list of connector types (and wondering if we're gonna > > need more when converting existing fbdev drivers to drm drivers), > > there seem to be two different families of connector types, for > > 1. transports between CRTC and display (e.g. VGA, DVID, HDMI), > > 2. transports between CPU and CRTC (e.g. SPI, possibly USB, and > > the proposed I2C)? > > I was trying to argue for a panel connector type and stop doing all > these internal things because like you point out, it kinda doesn't, > only the external connectors are relevant to users. But it didn't > stick anywhere yet, we keep adding more connector types and then > having to update userspace, which should map these all to "it's the > panel" or something like that. But also since various technicolor > abbreviations are about as useful to end-users as "unknown" it really > doesn't matter, so I'm happy to let this bikeshed get a tad fancier > every year :-) We discussed DRM_MODE_CONNECTOR_PANEL or some sort - but I recall we ended up with worrying about breaking userspace. See https://lore.kernel.org/dri-devel/?q=DRM_MODE_CONNECTOR_PANEL For this kind of change I chicken out due to lack of understanding of the userspace implications. Typing the patch is simple but taking the correct decision not so. The discussion popped up when we made it mandatory to specify a connector so we could better match up stuff between display drivers/bridges and panel drivers. Sam
Re: [PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset
On 1/26/2022 12:36 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
each register needs to be added and moved in the final array. The second
phase may actually happen in IO memory rather than system memory and
accessing IO memory by simply dereferencing the pointer doesn't work on
all architectures. Other places of the ADS initializaition were
converted to use the dma_buf_map API, but here there may be a lot more
accesses to IO memory. So, instead of following that same approach,
convert the regset initialization to calculate the final array in 1
pass and in the second pass that array is just copied to its final
location, updating the pointers for each engine written to the ADS blob.
One important thing is that struct temp_regset now have
different semantics: `registers` continues to track the registers of a
single engine, however the other fields are updated together, according
to the newly added `storage`, which tracks the memory allocated for
all the registers. So rename some of these fields and add a
__mmio_reg_add(): this function (possibly) allocates memory and operates
on the storage pointer while guc_mmio_reg_add() continues to manage the
registers pointer.
On a Tiger Lake system using enable_guc=3, the following log message is
now seen:
[ 187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]]
Used 4 KB for temporary ADS regset
This change has also been tested on an ARM64 host with DG2 and other
discrete graphics cards.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 117 +
2 files changed, 79 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e2e0df1c3d91..4c852eee3ad8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -152,6 +152,13 @@ struct intel_guc {
struct dma_buf_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
+ /**
+* @ads_regset_count: number of save/restore registers in the ADS for
+* each engine
+*/
+ u32 ads_regset_count[I915_NUM_ENGINES];
+ /** @ads_regset: save/restore regsets in the ADS */
+ struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
/** @ads_engine_usage_size: size of engine usage in the ADS */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 73ca34de44f7..390101ee3661 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -226,14 +226,13 @@ static void guc_mapping_table_init(struct intel_gt *gt,
/*
* The save/restore register list must be pre-calculated to a temporary
- * buffer of driver defined size before it can be generated in place
- * inside the ADS.
+ * buffer before it can be copied inside the ADS.
*/
-#define MAX_MMIO_REGS 128 /* Arbitrary size, increase as needed */
struct temp_regset {
struct guc_mmio_reg *registers;
- u32 used;
- u32 size;
+ struct guc_mmio_reg *storage;
I think this could use a comment to distinguish between registers and
storage. Something like.:
/* ptr to the base of the allocated storage for all engines */
struct guc_mmio_reg *storage;
/* ptr to the section of the storage for the engine currently being
worked on */
struct guc_mmio_reg *registers;
+ u32 storage_used;
+ u32 storage_max;
};
static int guc_mmio_reg_cmp(const void *a, const void *b)
@@ -244,18 +243,44 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
}
+static struct guc_mmio_reg * __must_check
+__mmio_reg_add(struct temp_regset *regset, struct guc_mmio_reg *reg)
+{
+ u32 pos = regset->storage_used;
+ struct guc_mmio_reg *slot;
+
+ if (pos >= regset->storage_max) {
+ size_t size = ALIGN((pos + 1) * sizeof(*slot), PAGE_SIZE);
+ struct guc_mmio_reg *r = krealloc(regset->storage,
+ size, GFP_KERNEL);
+ if (!r) {
+ WARN_ONCE(1, "Incomplete regset list: can't add register
(%d)\n",
+ -ENOMEM);
+ return ERR_PTR(-ENOMEM);
+ }
+
+
Re: [PATCH v12 3/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
On Mon, 31 Jan 2022 13:26:49 +0100, H. Nikolaus Schaller wrote: > From: Sam Ravnborg > > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. > Based on .txt binding from Zubair Lutfullah Kakakhel > > Signed-off-by: Sam Ravnborg > Signed-off-by: H. Nikolaus Schaller > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > --- > .../display/bridge/ingenic,jz4780-hdmi.yaml | 83 +++ > 1 file changed, 83 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml > Reviewed-by: Rob Herring
[PATCH v3 1/3] Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
This reverts commit b3ec8cdf457e5e63d396fe1346cc788cf7c1b578. Revert the second (of 2) commits which disabled scrolling acceleration in fbcon/fbdev. It introduced a regression for fbdev-supported graphic cards because of the performance penalty by doing screen scrolling by software instead of using the existing graphic card 2D hardware acceleration. Console scrolling acceleration was disabled by dropping code which checked at runtime the driver hardware capabilities for the BINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags and if set, it enabled scrollmode SCROLL_MOVE which uses hardware acceleration to move screen contents. After dropping those checks scrollmode was hard-wired to SCROLL_REDRAW instead, which forces all graphic cards to redraw every character at the new screen position when scrolling. This change effectively disabled all hardware-based scrolling acceleration for ALL drivers, because now all kind of 2D hardware acceleration (bitblt, fillrect) in the drivers isn't used any longer. The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm and gma500) used hardware acceleration in the past and thus code for checking and using scrolling acceleration is obsolete. This statement is NOT TRUE, because beside the DRM drivers there are around 35 other fbdev drivers which depend on fbdev/fbcon and still provide hardware acceleration for fbdev/fbcon. The original commit message also states that syzbot found lots of bugs in fbcon and thus it's "often the solution to just delete code and remove features". This is true, and the bugs - which actually affected all users of fbcon, including DRM - were fixed, or code was dropped like e.g. the support for software scrollback in vgacon (commit 973c096f6a85). So to further analyze which bugs were found by syzbot, I've looked through all patches in drivers/video which were tagged with syzbot or syzkaller back to year 2005. The vast majority fixed the reported issues on a higher level, e.g. when screen is to be resized, or when font size is to be changed. The few ones which touched driver code fixed a real driver bug, e.g. by adding a check. But NONE of those patches touched code of either the SCROLL_MOVE or the SCROLL_REDRAW case. That means, there was no real reason why SCROLL_MOVE had to be ripped-out and just SCROLL_REDRAW had to be used instead. The only reason I can imagine so far was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it could go away. That argument completely missed the fact that SCROLL_MOVE is still heavily used by fbdev (non-DRM) drivers. Some people mention that using memcpy() instead of the hardware acceleration is pretty much the same speed. But that's not true, at least not for older graphic cards and machines where we see speed decreases by factor 10 and more and thus this change leads to console responsiveness way worse than before. That's why the original commit is to be reverted. By reverting we reintroduce hardware-based scrolling acceleration and fix the performance regression for fbdev drivers. There isn't any impact on DRM when reverting those patches. Signed-off-by: Helge Deller Acked-by: Geert Uytterhoeven Acked-by: Sven Schnelle Cc: sta...@vger.kernel.org # v5.16+ Signed-off-by: Helge Deller --- Documentation/gpu/todo.rst | 13 +- drivers/video/fbdev/core/bitblit.c | 16 + drivers/video/fbdev/core/fbcon.c| 509 +++- drivers/video/fbdev/core/fbcon.h| 59 +++ drivers/video/fbdev/core/fbcon_ccw.c| 28 +- drivers/video/fbdev/core/fbcon_cw.c | 28 +- drivers/video/fbdev/core/fbcon_rotate.h | 9 + drivers/video/fbdev/core/fbcon_ud.c | 37 +- drivers/video/fbdev/core/tileblit.c | 16 + drivers/video/fbdev/skeletonfb.c| 12 +- include/linux/fb.h | 2 +- 11 files changed, 678 insertions(+), 51 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index da138dd39883..29506815d24a 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -303,19 +303,16 @@ Level: Advanced Garbage collect fbdev scrolling acceleration -Scroll acceleration has been disabled in fbcon. Now it works as the old -SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was -removed from fbcon_ops. -Remaining tasks: +Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = +SCROLL_REDRAW. There's a ton of code this will allow us to remove: -- a bunch of the hooks in fbcon_ops could be removed or simplified by calling +- lots of code in fbcon.c + +- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called directly instead of the function table (with a switch on p->rotate) - fb_copyarea is unused after this, and can be deleted from all drivers -- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as - well as
[PATCH v3 0/3] Fix regression introduced by disabling accelerated scrolling in fbcon
This series reverts two patches which disabled scrolling acceleration in fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic cards because of the performance penalty by doing screen scrolling by software instead of using existing 2D hardware acceleration. The third patch introduces a new config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION, which -if enabled- switches fbcon to utilize the bitblt and fillrect hardware acceleration in the framebuffer console. If disabled, such acceleration will not be used, even if it is supported by the graphics hardware driver. This series is being discussed on linux-fbdev and dri-devel mailing lists. Helge Helge Deller (3): Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" Revert "fbcon: Disable accelerated scrolling" fbcon: Add option to enable legacy hardware acceleration Documentation/gpu/todo.rst | 24 - drivers/video/console/Kconfig | 11 + drivers/video/fbdev/core/bitblit.c | 16 + drivers/video/fbdev/core/fbcon.c| 557 +++- drivers/video/fbdev/core/fbcon.h| 72 +++ drivers/video/fbdev/core/fbcon_ccw.c| 28 +- drivers/video/fbdev/core/fbcon_cw.c | 28 +- drivers/video/fbdev/core/fbcon_rotate.h | 9 + drivers/video/fbdev/core/fbcon_ud.c | 37 +- drivers/video/fbdev/core/tileblit.c | 16 + drivers/video/fbdev/skeletonfb.c| 12 +- include/linux/fb.h | 2 +- 12 files changed, 744 insertions(+), 68 deletions(-) -- 2.34.1
[PATCH v3 2/3] Revert "fbcon: Disable accelerated scrolling"
This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151. Revert the first (of 2) commits which disabled scrolling acceleration in fbcon/fbdev. It introduced a regression for fbdev-supported graphic cards because of the performance penalty by doing screen scrolling by software instead of using the existing graphic card 2D hardware acceleration. Console scrolling acceleration was disabled by dropping code which checked at runtime the driver hardware capabilities for the BINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags and if set, it enabled scrollmode SCROLL_MOVE which uses hardware acceleration to move screen contents. After dropping those checks scrollmode was hard-wired to SCROLL_REDRAW instead, which forces all graphic cards to redraw every character at the new screen position when scrolling. This change effectively disabled all hardware-based scrolling acceleration for ALL drivers, because now all kind of 2D hardware acceleration (bitblt, fillrect) in the drivers isn't used any longer. The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm and gma500) used hardware acceleration in the past and thus code for checking and using scrolling acceleration is obsolete. This statement is NOT TRUE, because beside the DRM drivers there are around 35 other fbdev drivers which depend on fbdev/fbcon and still provide hardware acceleration for fbdev/fbcon. The original commit message also states that syzbot found lots of bugs in fbcon and thus it's "often the solution to just delete code and remove features". This is true, and the bugs - which actually affected all users of fbcon, including DRM - were fixed, or code was dropped like e.g. the support for software scrollback in vgacon (commit 973c096f6a85). So to further analyze which bugs were found by syzbot, I've looked through all patches in drivers/video which were tagged with syzbot or syzkaller back to year 2005. The vast majority fixed the reported issues on a higher level, e.g. when screen is to be resized, or when font size is to be changed. The few ones which touched driver code fixed a real driver bug, e.g. by adding a check. But NONE of those patches touched code of either the SCROLL_MOVE or the SCROLL_REDRAW case. That means, there was no real reason why SCROLL_MOVE had to be ripped-out and just SCROLL_REDRAW had to be used instead. The only reason I can imagine so far was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it could go away. That argument completely missed the fact that SCROLL_MOVE is still heavily used by fbdev (non-DRM) drivers. Some people mention that using memcpy() instead of the hardware acceleration is pretty much the same speed. But that's not true, at least not for older graphic cards and machines where we see speed decreases by factor 10 and more and thus this change leads to console responsiveness way worse than before. That's why the original commit is to be reverted. By reverting we reintroduce hardware-based scrolling acceleration and fix the performance regression for fbdev drivers. There isn't any impact on DRM when reverting those patches. Signed-off-by: Helge Deller Acked-by: Geert Uytterhoeven Acked-by: Sven Schnelle Cc: sta...@vger.kernel.org # v5.10+ Signed-off-by: Helge Deller --- Documentation/gpu/todo.rst | 21 --- drivers/video/fbdev/core/fbcon.c | 45 ++-- 2 files changed, 37 insertions(+), 29 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 29506815d24a..a1212b5b3026 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -300,27 +300,6 @@ Contact: Daniel Vetter, Noralf Tronnes Level: Advanced -Garbage collect fbdev scrolling acceleration - - -Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = -SCROLL_REDRAW. There's a ton of code this will allow us to remove: - -- lots of code in fbcon.c - -- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called - directly instead of the function table (with a switch on p->rotate) - -- fb_copyarea is unused after this, and can be deleted from all drivers - -Note that not all acceleration code can be deleted, since clearing and cursor -support is still accelerated, which might be good candidates for further -deletion projects. - -Contact: Daniel Vetter - -Level: Intermediate - idr_init_base() --- diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 22bb3892f6bd..b813985f1403 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1025,7 +1025,7 @@ static void fbcon_init(struct vc_data *vc, int init) struct vc_data *svc = *default_mode; struct fbcon_display *t, *p = _display[vc->vc_num]; int logo = 1, new_rows, new_cols, rows, cols; - int ret; + int cap, ret; if (WARN_ON(info_idx == -1))
[PATCH v3 3/3] fbcon: Add option to enable legacy hardware acceleration
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
If you plan to use DRM as your main graphics output system, you should
disable this option since it will prevent compiling in code which isn't
used later on when DRM takes over.
For all other configurations, e.g. if none of your graphic cards support
DRM (yet), DRM isn't available for your architecture, or you can't be
sure that the graphic card in the target system will support DRM, you
most likely want to enable this option.
In the non-accelerated case (e.g. when DRM is used), the inlined
fb_scrollmode() function is hardcoded to return SCROLL_REDRAW and as such the
compiler is able to optimize much unneccesary code away.
In this v3 patch version I additionally changed the GETVYRES() and GETVXRES()
macros to take a pointer to the fbcon_display struct. This fixes the build when
console rotation is enabled and helps the compiler again to optimize out code.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org # v5.10+
Signed-off-by: Helge Deller
---
drivers/video/console/Kconfig | 11 +++
drivers/video/fbdev/core/fbcon.c| 39 ++---
drivers/video/fbdev/core/fbcon.h| 15 +-
drivers/video/fbdev/core/fbcon_ccw.c| 10 +++
drivers/video/fbdev/core/fbcon_cw.c | 10 +++
drivers/video/fbdev/core/fbcon_rotate.h | 4 +--
drivers/video/fbdev/core/fbcon_ud.c | 20 ++---
7 files changed, 75 insertions(+), 34 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 840d9813b0bc..6029fd41d7d0 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ bool "Framebuffer Console hardware acceleration support"
+ depends on FRAMEBUFFER_CONSOLE
+ default n if DRM
+ default y
+ help
+ If you use a system on which DRM is fully supported you usually want
to say N,
+ otherwise you probably want to enable this option.
+ If enabled the framebuffer console will utilize the hardware
acceleration
+ of your graphics card by using hardware bitblt and fillrect features.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b813985f1403..f7b7d35953e8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1136,11 +1136,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
if ((cap & FBINFO_HWACCEL_COPYAREA) &&
!(cap & FBINFO_HWACCEL_DISABLED))
p->scrollmode = SCROLL_MOVE;
else /* default to something safe */
p->scrollmode = SCROLL_REDRAW;
+#endif
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1705,7 +1707,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
count = vc->vc_rows;
if (logo_shown >= 0)
goto redraw_up;
- switch (p->scrollmode) {
+ switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, t, b - t - count,
count);
@@ -1795,7 +1797,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
count = vc->vc_rows;
if (logo_shown >= 0)
goto redraw_down;
- switch (p->scrollmode) {
+ switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
-count);
@@ -1946,12 +1948,12 @@ static void fbcon_bmove_rec(struct vc_data *vc, struct
fbcon_display *p, int sy,
height, width);
}
-static void updatescrollmode(struct fbcon_display *p,
+static void updatescrollmode_accel(struct fbcon_display *p,
struct fb_info *info,
struct vc_data *vc)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
struct fbcon_ops *ops = info->fbcon_par;
- int fh = vc->vc_font.height;
int cap = info->flags;
u16 t = 0;
int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
@@ -1972,12 +1974,6 @@ static void updatescrollmode(struct fbcon_display *p,
int fast_imageblit
Re: [PATCH v1 1/4] fbtft: Unorphan the driver
Hi
Am 01.02.22 um 18:00 schrieb Geert Uytterhoeven:
Hi Thomas,
On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann wrote:
Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas:
Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
now a DRM_MODE_CONNECTOR_Unknown.
That might have implications on userspace. Maybe ask around. (Not that
we actually run userspace on the device).
Looking at the list of connector types (and wondering if we're gonna
need more when converting existing fbdev drivers to drm drivers),
there seem to be two different families of connector types, for
1. transports between CRTC and display (e.g. VGA, DVID, HDMI),
2. transports between CPU and CRTC (e.g. SPI, possibly USB, and
the proposed I2C)?
I think I had a similar discussion when we merged the gud driver. gud is
a driver for a RasPi-based usb display adapter. My point was that USB
is just an internal transport bus, like PCI. But that wasn't convincing.
So now we have USB and other busses as connector types.
My preference would be to use a panel type as Daniel suggested; and
maybe 'Unknown' for a few special cases.
Best regards
Thomas
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
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] drm/vc4: add tracepoints for CL submissions
Trace submit_cl_ioctl and related IRQs for CL submission and bin/render
jobs execution. It might be helpful to get a rendering timeline and
track job throttling.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/vc4/vc4_gem.c | 7 +++
drivers/gpu/drm/vc4/vc4_irq.c | 5 ++
drivers/gpu/drm/vc4/vc4_trace.h | 95 +
3 files changed, 107 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 445d3bab89e0..4abf10b66fe8 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -485,6 +485,8 @@ vc4_submit_next_bin_job(struct drm_device *dev)
* immediately move it to the to-be-rendered queue.
*/
if (exec->ct0ca != exec->ct0ea) {
+ trace_vc4_submit_cl(dev, false, exec->seqno, exec->ct0ca,
+ exec->ct0ea);
submit_cl(dev, 0, exec->ct0ca, exec->ct0ea);
} else {
struct vc4_exec_info *next;
@@ -519,6 +521,7 @@ vc4_submit_next_render_job(struct drm_device *dev)
*/
vc4_flush_texture_caches(dev);
+ trace_vc4_submit_cl(dev, true, exec->seqno, exec->ct1ca, exec->ct1ea);
submit_cl(dev, 1, exec->ct1ca, exec->ct1ea);
}
@@ -1135,6 +1138,10 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct dma_fence *in_fence;
int ret = 0;
+ trace_vc4_submit_cl_ioctl(dev, args->bin_cl_size,
+ args->shader_rec_size,
+ args->bo_handle_count);
+
if (!vc4->v3d) {
DRM_DEBUG("VC4_SUBMIT_CL with no VC4 V3D probed\n");
return -ENODEV;
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 20fa8e34c20b..4342fb43e8c1 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -51,6 +51,7 @@
#include "vc4_drv.h"
#include "vc4_regs.h"
+#include "vc4_trace.h"
#define V3D_DRIVER_IRQS (V3D_INT_OUTOMEM | \
V3D_INT_FLDONE | \
@@ -123,6 +124,8 @@ vc4_irq_finish_bin_job(struct drm_device *dev)
if (!exec)
return;
+ trace_vc4_bcl_end_irq(dev, exec->seqno);
+
vc4_move_job_to_render(dev, exec);
next = vc4_first_bin_job(vc4);
@@ -161,6 +164,8 @@ vc4_irq_finish_render_job(struct drm_device *dev)
if (!exec)
return;
+ trace_vc4_rcl_end_irq(dev, exec->seqno);
+
vc4->finished_seqno++;
list_move_tail(>head, >job_done_list);
diff --git a/drivers/gpu/drm/vc4/vc4_trace.h b/drivers/gpu/drm/vc4/vc4_trace.h
index 1cccde0b09a7..7f4c49e7e011 100644
--- a/drivers/gpu/drm/vc4/vc4_trace.h
+++ b/drivers/gpu/drm/vc4/vc4_trace.h
@@ -52,6 +52,101 @@ TRACE_EVENT(vc4_wait_for_seqno_end,
__entry->dev, __entry->seqno)
);
+TRACE_EVENT(vc4_submit_cl_ioctl,
+ TP_PROTO(struct drm_device *dev, u32 bin_cl_size, u32
shader_rec_size, u32 bo_count),
+ TP_ARGS(dev, bin_cl_size, shader_rec_size, bo_count),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u32, bin_cl_size)
+__field(u32, shader_rec_size)
+__field(u32, bo_count)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->bin_cl_size = bin_cl_size;
+ __entry->shader_rec_size = shader_rec_size;
+ __entry->bo_count = bo_count;
+ ),
+
+ TP_printk("dev=%u, bin_cl_size=%u, shader_rec_size=%u, bo_count=%u",
+ __entry->dev,
+ __entry->bin_cl_size,
+ __entry->shader_rec_size,
+ __entry->bo_count)
+);
+
+TRACE_EVENT(vc4_submit_cl,
+ TP_PROTO(struct drm_device *dev, bool is_render,
+uint64_t seqno,
+u32 ctnqba, u32 ctnqea),
+ TP_ARGS(dev, is_render, seqno, ctnqba, ctnqea),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(bool, is_render)
+__field(u64, seqno)
+__field(u32, ctnqba)
+__field(u32, ctnqea)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->is_render = is_render;
+ __entry->seqno = seqno;
+ __entry->ctnqba = ctnqba;
+ __entry->ctnqea = ctnqea;
+ ),
+
+ TP_printk("dev=%u, %s, seqno=%llu, 0x%08x..0x%08x",
+ __entry->dev,
+ __entry->is_render ? "RCL" : "BCL",
+
Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On Tue, 1 Feb 2022 at 07:06, Daniel Vetter wrote: > > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin Acked-by: Dave Airlie
Re: [PATCH 3/6] drm/msm/dpu: allow just single IRQ callback
Hi Dmitry, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v5.17-rc2 next-20220201] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Dmitry-Baryshkov/drm-msm-dpu-simplify-IRQ-helpers/20220201-231430 base: git://anongit.freedesktop.org/drm/drm drm-next config: s390-randconfig-r044-20220130 (https://download.01.org/0day-ci/archive/20220202/202202020613.vjszn4m6-...@intel.com/config) compiler: s390-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/c3da64f5022acf9d942f497a3e3cff092648d6c3 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Dmitry-Baryshkov/drm-msm-dpu-simplify-IRQ-helpers/20220201-231430 git checkout c3da64f5022acf9d942f497a3e3cff092648d6c3 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=s390 SHELL=/bin/bash drivers/gpu/drm/msm/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from include/trace/define_trace.h:102, from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:973, from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34: drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h: In function 'ftrace_test_probe_dpu_core_irq_unregister_callback': include/trace/trace_events.h:870:42: error: passing argument 1 of 'check_trace_callback_type_dpu_core_irq_unregister_callback' from incompatible pointer type [-Werror=incompatible-pointer-types] 870 | check_trace_callback_type_##call(trace_event_raw_event_##template); \ | ^~ | | | void (*)(void *, int, void *) drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h:892:1: note: in expansion of macro 'DEFINE_EVENT' 892 | DEFINE_EVENT(dpu_core_irq_callback_template, dpu_core_irq_unregister_callback, | ^~~~ In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:10, from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34: include/linux/tracepoint.h:279:49: note: expected 'void (*)(void *, int)' but argument is of type 'void (*)(void *, int, void *)' 279 | check_trace_callback_type_##name(void (*cb)(data_proto)) \ | ~~~^~~ include/linux/tracepoint.h:419:9: note: in expansion of macro '__DECLARE_TRACE' 419 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \ | ^~~ include/linux/tracepoint.h:542:9: note: in expansion of macro 'DECLARE_TRACE' 542 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) | ^ drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:892:1: note: in expansion of macro 'DEFINE_EVENT' 892 | DEFINE_EVENT(dpu_core_irq_callback_template, dpu_core_irq_unregister_callback, | ^~~~ In file included from include/trace/define_trace.h:103, from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:973, from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34: drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h: In function 'perf_test_probe_dpu_core_irq_unregister_callback': >> include/trace/perf.h:99:42: error: passing argument 1 of >> 'check_trace_callback_type_dpu_core_irq_unregister_callback' from >> incompatible pointer type [-Werror=incompatible-pointer-types] 99 | check_trace_callback_type_##call(perf_trace_##template); \ | ^~~ | | | void (*)(void *, int, void *) drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h:892:1: note: in expansion of macro 'DEFINE_EVENT' 892 | DEFINE_EVENT(dpu_core_irq_callback_template, dpu_core_irq_unregister_callback, | ^~~~ In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:10, from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34: include/linux/tracepoint.h:279:49: note: expected 'void (*)(void *, int)' but argument is of type 'void (*)(void *, int, void *)' 279 | check_trace_callback_type_##na
Re: [PATCH 3/6] drm/msm/dpu: allow just single IRQ callback
Hi Dmitry,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v5.17-rc2 next-20220201]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Baryshkov/drm-msm-dpu-simplify-IRQ-helpers/20220201-231430
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arc-randconfig-r043-20220130
(https://download.01.org/0day-ci/archive/20220202/202202020658.fjtv4cap-...@intel.com/config)
compiler: arc-elf-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/c3da64f5022acf9d942f497a3e3cff092648d6c3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dmitry-Baryshkov/drm-msm-dpu-simplify-IRQ-helpers/20220201-231430
git checkout c3da64f5022acf9d942f497a3e3cff092648d6c3
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/trace/define_trace.h:102,
from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:973,
from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34:
drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h: In function
'ftrace_test_probe_dpu_core_irq_unregister_callback':
>> include/trace/trace_events.h:870:42: error: passing argument 1 of
>> 'check_trace_callback_type_dpu_core_irq_unregister_callback' from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
870 |
check_trace_callback_type_##call(trace_event_raw_event_##template); \
| ^~
| |
| void (*)(void *, int, void
*)
drivers/gpu/drm/msm/disp/dpu1/./dpu_trace.h:892:1: note: in expansion of
macro 'DEFINE_EVENT'
892 | DEFINE_EVENT(dpu_core_irq_callback_template,
dpu_core_irq_unregister_callback,
| ^~~~
In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:10,
from drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:34:
include/linux/tracepoint.h:279:49: note: expected 'void (*)(void *, int)'
but argument is of type 'void (*)(void *, int, void *)'
279 | check_trace_callback_type_##name(void (*cb)(data_proto))
\
| ~~~^~~
include/linux/tracepoint.h:419:9: note: in expansion of macro
'__DECLARE_TRACE'
419 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),
\
| ^~~
include/linux/tracepoint.h:542:9: note: in expansion of macro 'DECLARE_TRACE'
542 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h:892:1: note: in expansion of macro
'DEFINE_EVENT'
892 | DEFINE_EVENT(dpu_core_irq_callback_template,
dpu_core_irq_unregister_callback,
| ^~~~
cc1: some warnings being treated as errors
vim +/check_trace_callback_type_dpu_core_irq_unregister_callback +870
include/trace/trace_events.h
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 830)
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 831) #undef
DECLARE_EVENT_CLASS
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 832) #define
DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print)\
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 833)
\
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 834) static notrace void
\
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 835)
trace_event_raw_event_##call(void *__data, proto) \
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 836) {
\
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 837) struct
trace_event_file *trace_file = __data; \
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 838) struct
trace_event_data_offsets_##call __maybe_unused __data_offsets;\
46ac51822a6a0b8 Steven Rostedt (Red Hat 2015-09-23 839) struct
trace_event_buffer fbuffer; \
46ac51822a6a0b8 Steven R
[PATCH v3] drm/cma-helper: Describe what a "contiguous chunk" actually means
Since it's inception in 2012 it has been understood that the DRM GEM CMA helpers do not depend on CMA as the backend allocator. In fact the first bug fix to ensure the cma-helpers work correctly with an IOMMU backend appeared in 2014. However currently the documentation for drm_gem_cma_create() talks about "a contiguous chunk of memory" without making clear which address space it will be a contiguous part of. Additionally the CMA introduction is actively misleading because it only contemplates the CMA backend. This matters because when the device accesses the bus through an IOMMU (and don't use the CMA backend) then the allocated memory is contiguous only in the IOVA space. This is a significant difference compared to the CMA backend and the behaviour can be a surprise even to someone who does a reasonable level of code browsing (but doesn't find all the relevant function pointers ;-) ). Improve the kernel doc comments accordingly. Signed-off-by: Daniel Thompson --- Notes: Changes in v3: - Rebased on v5.17-rc2 - Minor improvements to wording. Changes in v2: - Oops. I did a final proof read and acidentally committed these changes as a seperate patch. This means that v1 contains only one tenth of the actual patch. This is fixed in v2. Many apologies for the noise! drivers/gpu/drm/drm_gem_cma_helper.c | 39 +--- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index cefd0cbf9debb..ee003af40ffe6 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -26,12 +26,22 @@ /** * DOC: cma helpers * - * The Contiguous Memory Allocator reserves a pool of memory at early boot - * that is used to service requests for large blocks of contiguous memory. + * The DRM GEM/CMA helpers are a means to provide buffer objects that are + * presented to the device as a contiguous chunk of memory. This is useful + * for devices that do not support scatter-gather DMA (either directly or + * by using an intimately attached IOMMU). * - * The DRM GEM/CMA helpers use this allocator as a means to provide buffer - * objects that are physically contiguous in memory. This is useful for - * display drivers that are unable to map scattered buffers via an IOMMU. + * Despite the name, the DRM GEM/CMA helpers are not hardwired to use the + * Contiguous Memory Allocator (CMA). + * + * For devices that access the memory bus through an (external) IOMMU then + * the buffer objects are allocated using a traditional page-based + * allocator and may be scattered through physical memory. However they + * are contiguous in the IOVA space so appear contiguous to devices using + * them. + * + * For other devices then the helpers rely on CMA to provide buffer + * objects that are physically contiguous in memory. * * For GEM callback helpers in struct _gem_object functions, see likewise * named functions with an _object_ infix (e.g., drm_gem_cma_object_vmap() wraps @@ -111,8 +121,14 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size, bool private) * @drm: DRM device * @size: size of the object to allocate * - * This function creates a CMA GEM object and allocates a contiguous chunk of - * memory as backing store. + * This function creates a CMA GEM object and allocates memory as backing store. + * The allocated memory will occupy a contiguous chunk of bus address space. + * + * For devices that are directly connected to the memory bus then the allocated + * memory will be physically contiguous. For devices that access through an + * IOMMU, then the allocated memory is not expected to be physically contiguous + * because having contiguous IOVAs is sufficient to meet a devices DMA + * requirements. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative @@ -162,9 +178,12 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_create); * @size: size of the object to allocate * @handle: return location for the GEM handle * - * This function creates a CMA GEM object, allocating a physically contiguous - * chunk of memory as backing store. The GEM object is then added to the list - * of object associated with the given file and a handle to it is returned. + * This function creates a CMA GEM object, allocating a chunk of memory as + * backing store. The GEM object is then added to the list of object associated + * with the given file and a handle to it is returned. + * + * The allocated memory will occupy a contiguous chunk of bus address space. + * See drm_gem_cma_create() for more details. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c -- 2.34.1
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Use str_on_off()
On Wed, Jan 26, 2022 at 01:39:46AM -0800, Lucas De Marchi wrote:
> Remove the local onoff() implementation and adopt the
> str_on_off() from linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Daniel Vetter
> Acked-by: Jani Nikula
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c | 6 --
> drivers/gpu/drm/i915/display/intel_display.c | 7 ---
> drivers/gpu/drm/i915/display/intel_display_trace.h | 3 ++-
> drivers/gpu/drm/i915/display/intel_dpll.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 7 +--
> drivers/gpu/drm/i915/display/intel_fdi.c | 8 +---
> drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_rc6.c| 5 +++--
> drivers/gpu/drm/i915/i915_utils.h | 5 -
> drivers/gpu/drm/i915/vlv_suspend.c | 3 ++-
> 10 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index f37677df6ebf..3e729bff1232 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -5,6 +5,8 @@
> * DisplayPort support for G4x,ILK,SNB,IVB,VLV,CHV (HSW+ handled by the DDI
> code).
> */
>
> +#include
> +
> #include "g4x_dp.h"
> #include "intel_audio.h"
> #include "intel_backlight.h"
> @@ -191,7 +193,7 @@ static void assert_dp_port(struct intel_dp *intel_dp,
> bool state)
> I915_STATE_WARN(cur_state != state,
> "[ENCODER:%d:%s] state assertion failure (expected %s,
> current %s)\n",
> dig_port->base.base.base.id, dig_port->base.base.name,
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
> }
> #define assert_dp_port_disabled(d) assert_dp_port((d), false)
>
> @@ -201,7 +203,7 @@ static void assert_edp_pll(struct drm_i915_private
> *dev_priv, bool state)
>
> I915_STATE_WARN(cur_state != state,
> "eDP PLL state assertion failure (expected %s, current
> %s)\n",
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
> }
> #define assert_edp_pll_enabled(d) assert_edp_pll((d), true)
> #define assert_edp_pll_disabled(d) assert_edp_pll((d), false)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8920bdb53b7b..49f994f36fce 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -377,7 +377,7 @@ static void wait_for_pipe_scanline_moving(struct
> intel_crtc *crtc, bool state)
> if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
> drm_err(_priv->drm,
> "pipe %c scanline %s wait timed out\n",
> - pipe_name(pipe), onoff(state));
> + pipe_name(pipe), str_on_off(state));
> }
>
> static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
> @@ -435,7 +435,7 @@ void assert_transcoder(struct drm_i915_private *dev_priv,
> I915_STATE_WARN(cur_state != state,
> "transcoder %s assertion failure (expected %s, current
> %s)\n",
> transcoder_name(cpu_transcoder),
> - onoff(state), onoff(cur_state));
> + str_on_off(state), str_on_off(cur_state));
> }
>
> static void assert_plane(struct intel_plane *plane, bool state)
> @@ -447,7 +447,8 @@ static void assert_plane(struct intel_plane *plane, bool
> state)
>
> I915_STATE_WARN(cur_state != state,
> "%s assertion failure (expected %s, current %s)\n",
> - plane->base.name, onoff(state), onoff(cur_state));
> + plane->base.name, str_on_off(state),
> + str_on_off(cur_state));
> }
>
> #define assert_plane_enabled(p) assert_plane(p, true)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h
> b/drivers/gpu/drm/i915/display/intel_display_trace.h
> index dcdd242fffd9..2dd5a4b7f5d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_trace.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
> @@ -9,6 +9,7 @@
> #if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ)
> #define __INTEL_DISPLAY_TRACE_H__
>
> +#include
> #include
> #include
>
> @@ -161,7 +162,7 @@ TRACE_EVENT(intel_memory_cxsr,
> ),
>
> TP_printk("%s->%s, pipe A: frame=%u, scanline=%u, pipe B: frame=%u,
> scanline=%u, pipe C: frame=%u, scanline=%u",
> - onoff(__entry->old), onoff(__entry->new),
> + str_on_off(__entry->old), str_on_off(__entry->new),
> __entry->frame[PIPE_A],
Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Use str_yes_no()
On Wed, Jan 26, 2022 at 01:39:43AM -0800, Lucas De Marchi wrote: > Remove the local yesno() implementation and adopt the str_yes_no() from > linux/string_helpers.h. > > Signed-off-by: Lucas De Marchi > Acked-by: Daniel Vetter > Acked-by: Jani Nikula Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_display.c | 23 +++ > .../drm/i915/display/intel_display_debugfs.c | 66 +++ > .../drm/i915/display/intel_display_trace.h| 6 +- > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++-- > drivers/gpu/drm/i915/display/intel_fbc.c | 4 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +- > drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 9 +-- > .../drm/i915/gem/selftests/i915_gem_context.c | 7 +- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-- > .../drm/i915/gt/intel_execlists_submission.c | 7 +- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 3 +- > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 52 --- > drivers/gpu/drm/i915/gt/intel_reset.c | 3 +- > drivers/gpu/drm/i915/gt/intel_rps.c | 13 ++-- > drivers/gpu/drm/i915/gt/intel_sseu.c | 9 ++- > drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 10 +-- > drivers/gpu/drm/i915/gt/selftest_timeline.c | 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 4 +- > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +-- > drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 20 +++--- > drivers/gpu/drm/i915/i915_debugfs.c | 15 +++-- > drivers/gpu/drm/i915/i915_gpu_error.c | 9 +-- > drivers/gpu/drm/i915/i915_params.c| 5 +- > drivers/gpu/drm/i915/i915_utils.h | 5 -- > drivers/gpu/drm/i915/intel_device_info.c | 8 ++- > drivers/gpu/drm/i915/intel_dram.c | 10 +-- > drivers/gpu/drm/i915/intel_pm.c | 10 +-- > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +- > drivers/gpu/drm/i915/selftests/i915_active.c | 3 +- > 31 files changed, 203 insertions(+), 148 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 80bc52425e47..bd453861088e 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -3008,7 +3009,7 @@ static int intel_crtc_compute_config(struct intel_crtc > *crtc, > drm_dbg_kms(_priv->drm, > "requested pixel clock (%d kHz) too high (max: %d > kHz, double wide: %s)\n", > pipe_mode->crtc_clock, clock_limit, > - yesno(pipe_config->double_wide)); > + str_yes_no(pipe_config->double_wide)); > return -EINVAL; > } > > @@ -5586,7 +5587,7 @@ static void intel_dump_plane_state(const struct > intel_plane_state *plane_state) > drm_dbg_kms(>drm, > "[PLANE:%d:%s] fb: [NOFB], visible: %s\n", > plane->base.base.id, plane->base.name, > - yesno(plane_state->uapi.visible)); > + str_yes_no(plane_state->uapi.visible)); > return; > } > > @@ -5594,7 +5595,7 @@ static void intel_dump_plane_state(const struct > intel_plane_state *plane_state) > "[PLANE:%d:%s] fb: [FB:%d] %ux%u format = %p4cc modifier = > 0x%llx, visible: %s\n", > plane->base.base.id, plane->base.name, > fb->base.id, fb->width, fb->height, >format->format, > - fb->modifier, yesno(plane_state->uapi.visible)); > + fb->modifier, str_yes_no(plane_state->uapi.visible)); > drm_dbg_kms(>drm, "\trotation: 0x%x, scaler: %d\n", > plane_state->hw.rotation, plane_state->scaler_id); > if (plane_state->uapi.visible) > @@ -5617,7 +5618,7 @@ static void intel_dump_pipe_config(const struct > intel_crtc_state *pipe_config, > > drm_dbg_kms(_priv->drm, "[CRTC:%d:%s] enable: %s %s\n", > crtc->base.base.id, crtc->base.name, > - yesno(pipe_config->hw.enable), context); > + str_yes_no(pipe_config->hw.enable), context); > > if (!pipe_config->hw.enable) > goto dump_planes; > @@ -5625,7 +5626,7 @@ static void intel_dump_pipe_config(const struct > intel_crtc_state *pipe_config, > snprintf_output_types(buf, sizeof(buf), pipe_config->output_types); > drm_dbg_kms(_priv->drm, > "active: %s, output_types: %s (0x%x), output format: %s\n", > - yesno(pipe_config->hw.active), > + str_yes_no(pipe_config->hw.active), > buf, pipe_config->output_types, >
Re: [PATCH 00/14] Rename dma-buf-map
On Tue, Feb 01, 2022 at 08:46:15AM +0100, Christian König wrote: Am 01.02.22 um 01:36 schrieb Lucas De Marchi: On Fri, Jan 28, 2022 at 10:48:42AM +0100, Christian König wrote: Am 28.01.22 um 10:40 schrieb Lucas De Marchi: On Fri, Jan 28, 2022 at 10:22:00AM +0100, Christian König wrote: Am 28.01.22 um 10:12 schrieb Lucas De Marchi: On Fri, Jan 28, 2022 at 09:41:14AM +0100, Christian König wrote: Rule #1 is to never ever break the build. Because of this all those patches needs to be squashed into a single one as far as I can see. what config are you building on? Well I'm not building at all, I'm just looking at the patches as an engineer with 25 years of experience with Linux patches. Just take a look at patch number 2: -static int fastrpc_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map) +static int fastrpc_vmap(struct dma_buf *dmabuf, struct iosys_map *map) You are changing the functions signature without changing any of the callers. At bare minimum that causes a warning and on runtime this only works by coincident now because the structure pointers just happen to have the same layout. This is not something we usually do. you missed the magic/hack on patch 1: 1) dma-buf-map.h includes iosys-map.h _at the end_ 2) iosys-map.h includes dma-buf-map.h at the beginning and initially does a "define iosys_map dma_buf_map". So, it doesn't work by coincidence, It's because it was done to allow converting it piecemeal. Oh, my. Please never do stuff like that again. It's not uncommon approach to be required by other subsystems. Even drm-intel already used similar approach for macro conversions crossing drm-intel-next and drm-intel-gt-next branches recently. As I said, I don't mind one way or the other. The key point is that you seemed to have a misunderstanding why we separate changes into functional independent patches. The goal of that is *not* to reduce the number of lines in a patch, but rather to reduce the complexity of the review. When you do an automated renamed with a cocci or sed script you can have a 100k line patch as result, which is perfectly fine to send out like this as long as you include the script/commands used to autogenerate the patch. The background is that everybody on the planet can generate the patch with those commands himself and see if the results matches your patch no, as I said in the cover letter there were tweaks needed. or not. The maintainer of the component can then just puts an Acked-by on the patch and move on, but separating the patch causes additional work for both you as well as the reviewers. Separating the change into individual patches as much as possible is nice to have when you do a functional change and want or need a review from each individual driver maintainer. This is usually the default case, so sticking with separated changes as much as possible is usually still the best practice. Not sure if I should continue replying on why I split these specific patches. I even mentioned in this cover letter about squashing everything in a single patch, and I'm fine with that. Anyway, there are other reasons to split the patches when it crosses branches you don't seem to acknowledge. It's harder for maintainers of the specific branches to review/ack only the changes on their part. It's harder to find the best timing to merge it. The mega patch doesn't apply to *any* specific branch, potentially leaving silent conflicts behind. You may notice the patch was split by branch boundary for these very reasons. If maintainers prefer to have a single patch, I'm fine, I had already said that. Before I go and respin this into a single mega patch, I'd like to gather some feedback on the following topics: 1) Daniel Vetter and Thomas Zimmermann seemed to be ok with staying with the current name, dma_buf_map, while you prefer it renamed. Or at least not make the rename a pre-requisite for the API additions in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220126203702.1784589-1-lucas.demarchi%40intel.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C01142fa3ce484040ade008d9e51aef5d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637792726123940514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ieMZ9Jiwo%2FQpT5kyyQgHNlepiusN%2Fkfff1Op6TVQ%2BaA%3Dreserved=0 One thing I like about the rename is that it makes clear the separation between this small shim and dma-buf. There are also some APIs that are really dma-buf API (e.g. dma_buf_map_attachment()), but if you don't look carefully you may think it's from dma_buf_map. Exactly that's the reason why I see this rename as mandatory. Adding the functionality goes beyond the inter driver interface DMA-buf provides into driver internal territory and I want to make sure that people understand just from the name alone that this is not part of DMA-buf but rather an
Re: [PATCH] fbdev: fbmem: Fix the implicit type casting
Hi Helge:
I shipped a new patch which moves the check before the function call,
please take a look and see if this one makes sense to you.
Modifying the type of function argument is a bit risky because fb_blank()
has more than one caller and some of them passed in an integer.
Signed-off-by: Yizhuo Zhai
---
drivers/video/fbdev/core/fbmem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c
b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..991711bfd647 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1162,6 +1162,8 @@ static long do_fb_ioctl(struct fb_info *info,
unsigned int cmd,
case FBIOBLANK:
console_lock();
lock_fb_info(info);
+ if (arg > FB_BLANK_POWERDOWN)
+ arg = FB_BLANK_POWERDOWN;
ret = fb_blank(info, arg);
/* might again call into fb_blank */
fbcon_fb_blanked(info, arg);
--
2.25.1
On Tue, Feb 1, 2022 at 7:03 AM Helge Deller wrote:
> On 1/31/22 07:57, Yizhuo Zhai wrote:
> > In function do_fb_ioctl(), the "arg" is the type of unsigned long,
>
> yes, because it comes from the ioctl framework...
>
> > and in "case FBIOBLANK:" this argument is casted into an int before
> > passig to fb_blank().
>
> which makes sense IMHO.
>
> > In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would
> > be bypass if the original "arg" is a large number, which is possible
> > because it comes from the user input.
>
> The main problem I see with your patch is that you change the behaviour.
> Let's assume someone passes in -1UL.
> With your patch applied, this means the -1 (which is e.g. 0x on
> 32bit)
> is converted to a positive integer and will be capped to
> FB_BLANK_POWERDOWN.
> Since most blank functions just check and react on specific values, you
> changed
> the behaviour that the screen now gets blanked at -1, while it wasn't
> before.
>
> One could now argue, that it's undefined behaviour if people
> pass in wrong values, but anyway, it's different now.
>
> So, your patch isn't wrong. I'm just not sure if this is what we want...
>
> Helge
>
>
> > Signed-off-by: Yizhuo Zhai
> > ---
> > drivers/video/fbdev/core/fbmem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> > index 0fa7ede94fa6..a5f71c191122 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1064,7 +1064,7 @@ fb_set_var(struct fb_info *info, struct
> fb_var_screeninfo *var)
> > EXPORT_SYMBOL(fb_set_var);
> >
> > int
> > -fb_blank(struct fb_info *info, int blank)
> > +fb_blank(struct fb_info *info, unsigned long blank)
> > {
>
--
Kind Regards,
*Yizhuo Zhai*
*Computer Science, Graduate Student*
*University of California, Riverside *
kmscube: GLES3/gl3.h: No such file or directory
Hi Rob, We are getting the following kmscube build error in Buildroot: ../cube-shadertoy.c:37:10: fatal error: GLES3/gl3.h: No such file or directory 37 | #include Complete log: http://autobuild.buildroot.net/results/7f559e89a96273fc019056eae13104e14161a484/build-end.log In OpenEmbedded the following patch is used: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/kmscube/kmscube/0001-texturator-Use-correct-GL-extension-header.patch?h=master What would be the appropriate fix for this issue? Thanks, Fabio Estevam
Re: Kconfig CONFIG_FB dependency regression
On 2/1/22 15:01, Thinh Nguyen wrote:
> Hi,
>
> One of our test setups is unable to boot (stuck at initramfs). Git
> bisection points to the commit below:
>
> f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
>
> Reverting this patch resolves the issue. This issue persists in mainline
> also. Unfortunately there isn't any meaningful log. Hopefully someone
> can give some insight as to what could be the issue and revert/fix this
> issue.
Hi,
Did you enable DRM_FBDEV_EMULATION?
Please provide the failing .config file.
--
~Randy
Re: Kconfig CONFIG_FB dependency regression
Hi Thinh,
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap wrote:
>
> On 2/1/22 15:01, Thinh Nguyen wrote:
> > Hi,
> >
> > One of our test setups is unable to boot (stuck at initramfs). Git
> > bisection points to the commit below:
> >
> > f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> >
> > Reverting this patch resolves the issue. This issue persists in mainline
> > also. Unfortunately there isn't any meaningful log. Hopefully someone
> > can give some insight as to what could be the issue and revert/fix this
> > issue.
>
> Hi,
> Did you enable DRM_FBDEV_EMULATION?
> Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
We had to manually select this option in imx_v6_v7_defconfig after f611b1e7624c.
Please see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.17-rc2=c54467482ffd407a4404c990697f432bfcb6cdc4
Re: [PATCH -next 1/2 v2] video: fbdev: pxa168fb: Remove unnecessary print function dev_err()
On 2/1/22 13:32, Yang Li wrote:
> The print function dev_err() is redundant because platform_get_irq()
> already prints an error.
>
> Eliminate the follow coccicheck warning:
> ./drivers/video/fbdev/pxa168fb.c:621:2-9: line 621 is redundant because
> platform_get_irq() already prints an error
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
>
> -Change in v2:
> drop the surrounding braces
Both applied to fbdev-next tree.
Thanks,
Helge
>
> drivers/video/fbdev/pxa168fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
> index c25739f6934d..e943300d23e8 100644
> --- a/drivers/video/fbdev/pxa168fb.c
> +++ b/drivers/video/fbdev/pxa168fb.c
> @@ -617,10 +617,8 @@ static int pxa168fb_probe(struct platform_device *pdev)
> }
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(>dev, "no IRQ defined\n");
> + if (irq < 0)
> return -ENOENT;
> - }
>
> info = framebuffer_alloc(sizeof(struct pxa168fb_info), >dev);
> if (info == NULL) {
>
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
Hi Javier, On Tue, Feb 01, 2022 at 04:03:30PM +0100, Javier Martinez Canillas wrote: > Hello Geert, > > On 2/1/22 15:14, Geert Uytterhoeven wrote: > > Hi Javier, > > > > On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas > > wrote: > >> On 2/1/22 12:38, Geert Uytterhoeven wrote: > Since the current binding has a compatible "ssd1305fb-i2c", we could > make the > new one "ssd1305drm-i2c" or better, just "ssd1305-i2c". > >>> > >>> DT describes hardware, not software policy. > >>> If the hardware is the same, the DT bindings should stay the same. Only if the bindings describe the HW in a correct way that is. > >>> > >> > >> Yes I know that but the thing is that the current binding don't describe > >> the hardware correctly. For instance, don't use a backlight DT node as a > >> property of the panel and have this "fb" suffix in the compatible strings. > >> > >> Having said that, my opinion is that we should just keep with the existing > >> bindings and make compatible to that even if isn't completely correct. > >> > >> Since that will ease adoption of the new DRM driver and allow users to use > >> it without the need to update their DTBs. > > > > To me it looks like the pwms property is not related to the backlight > > at all, and only needed for some variants? > > > > I was reading the datasheets of the ssd1305, ssd1306 and ssd1307. Only the > first one mentions anything about a PWM and says: > > In phase 3, the OLED driver switches to use current source to drive the > OLED pixels and this is the current drive stage. SSD1305 employs PWM > (Pulse Width Modulation) method to control the brightness of area color > A, B, C, D color individually. The longer the waveform in current drive > stage is, the brighter is the pixel and vice versa. > > After finishing phase 3, the driver IC will go back to phase 1 to display > the next row image data. This threestep cycle is run continuously to refresh > image display on OLED panel. > > The way I understand this is that the PWM isn't used for the backlight > but instead to power the IC and allow to display the actual pixels ? > > And this matches what Maxime mentioned in this patch: > > https://linux-arm-kernel.infradead.narkive.com/5i44FnQ8/patch-1-2-video-ssd1307fb-add-support-for-ssd1306-oled-controller > > The Solomon SSD1306 OLED controller is very similar to the SSD1307, > except for the fact that the power is given through an external PWM for > the 1307, and while the 1306 can generate its own power without any PWM. I took a look at the datasheets - and all ssd1305, ssd1306 and ssd1307 are the same. They have timing constrains on the Vcc. The random schematic I found on the net showed me that a PWM was used to control the Vcc voltage - which again is used to control the brightness. All the above has nothing to do with backlight - I had this mixed up in my head. So my current understanding: - solomon,ssd1307fb.yaml should NOT include a backlight node - because the backlight is something included in the ssd130x device and not something separate. - 1305, 1306, and 1307 (I did not check 1309) all requires a Vcc supply that shall be turned on/off according to the datasheet. This implies that we need a regulaator for Vcc - and the regulator could be a pwm based regulator or something else - the HW do not care. - But I can see that several design connect Vcc to a fixed voltage, so I am not too sure about this part. I think the correct binding would have ssd1307 => regulator => pwm So the ssd1307 binding references a regulator, and the regulator may use an pwm or may use something else. The current binding references a vbat supply - but the datasheet do not mention any vbat. It is most likely modelling the Vdd supply. Right now my take is to go the simple route: - Keep the binding as is and just use the pwm as already implemented - Likewise keep the backlight as is Last I recommend to drop the fbdev variant - if the drm driver has any regressions we can fix them. And I do not see any other way to move users over. Unless their setup breaks then they do not change. > > > And the actual backlight code seems to be about internal contrast > > adjustment? > > > > So if the pwms usage is OK, what other reasons are there to break > > DT compatibility? IMHO just the "fb" suffix is not a good reason. > > > > Absolutely agreed with you on this. It seems we should just use the existing > binding and make the driver compatible with that. The only value is that the > drm_panel infrastructure could be used, but making it backward compatible is > more worthy IMO. Using drm_panel here would IMO just complicate things - it is not that we will see many different panels (I think). Sam
Re: [Intel-gfx] [PATCH v2 05/11] drm/i915: Use str_enabled_disabled()
On Wed, Jan 26, 2022 at 01:39:45AM -0800, Lucas De Marchi wrote:
> Remove the local enableddisabled() implementation and adopt the
> str_enabled_disabled() from linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Daniel Vetter
> Acked-by: Jani Nikula
There's two open-coded versions of this in intel_dp_hdcp.c
(intel_dp_mst_hdcp_stream_encryption() and
intel_dp_mst_hdcp2_stream_encryption()) that you might want to convert
as well. Up to you whether you squash them into this patch or convert
them as a separate patch. Either way,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_display.c | 16
> .../gpu/drm/i915/display/intel_display_debugfs.c | 8
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c| 4 ++--
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_driver.c | 4 +++-
> drivers/gpu/drm/i915/i915_utils.h| 6 +-
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 14 files changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 98f7ea44042f..c8e1fc53a881 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> #include "intel_backlight.h"
> #include "intel_connector.h"
> @@ -1633,7 +1634,7 @@ int intel_backlight_setup(struct intel_connector
> *connector, enum pipe pipe)
> drm_dbg_kms(_priv->drm,
> "Connector %s backlight initialized, %s, brightness
> %u/%u\n",
> connector->base.name,
> - enableddisabled(panel->backlight.enabled),
> + str_enabled_disabled(panel->backlight.enabled),
> panel->backlight.level, panel->backlight.max);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bd453861088e..8920bdb53b7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3110,8 +3110,8 @@ static void intel_panel_sanitize_ssc(struct
> drm_i915_private *dev_priv)
> if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
> drm_dbg_kms(_priv->drm,
> "SSC %s by BIOS, overriding VBT which says
> %s\n",
> - enableddisabled(bios_lvds_use_ssc),
> -
> enableddisabled(dev_priv->vbt.lvds_use_ssc));
> + str_enabled_disabled(bios_lvds_use_ssc),
> +
> str_enabled_disabled(dev_priv->vbt.lvds_use_ssc));
> dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
> }
> }
> @@ -5648,7 +5648,7 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> pipe_config->bigjoiner ? "master" : "no");
>
> drm_dbg_kms(_priv->drm, "splitter: %s, link count %d, overlap %d\n",
> - enableddisabled(pipe_config->splitter.enable),
> + str_enabled_disabled(pipe_config->splitter.enable),
> pipe_config->splitter.link_count,
> pipe_config->splitter.pixel_overlap);
>
> @@ -5736,7 +5736,7 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> drm_dbg_kms(_priv->drm,
> "pch pfit: " DRM_RECT_FMT ", %s, force thru: %s\n",
> DRM_RECT_ARG(_config->pch_pfit.dst),
> - enableddisabled(pipe_config->pch_pfit.enabled),
> + str_enabled_disabled(pipe_config->pch_pfit.enabled),
> str_yes_no(pipe_config->pch_pfit.force_thru));
>
> drm_dbg_kms(_priv->drm, "ips: %i, double wide: %i\n",
> @@ -10300,7 +10300,7 @@ static void readout_plane_state(struct
> drm_i915_private *dev_priv)
> drm_dbg_kms(_priv->drm,
> "[PLANE:%d:%s] hw state readout: %s, pipe %c\n",
> plane->base.base.id, plane->base.name,
> - enableddisabled(visible), pipe_name(pipe));
> + str_enabled_disabled(visible), pipe_name(pipe));
> }
>
> for_each_intel_crtc(_priv->drm, crtc) {
> @@ -10346,7
[PATCH] iommu/vt-d: Remove comment reference to iommu_dev_has_feature
iommu_dev_has_feature() api has been removed by the commit 262948f8ba573
("iommu: Delete iommu_dev_has_feature()") - So this patch removes comment
about the api to avoid any confusion.
Signed-off-by: Akeem G Abodunrin
Cc: Lu Baolu
---
include/linux/iommu.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index de0c57a567c8..bea054f2bd4d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -153,8 +153,7 @@ struct iommu_resv_region {
* supported, this feature must be enabled before and
* disabled after %IOMMU_DEV_FEAT_SVA.
*
- * Device drivers query whether a feature is supported using
- * iommu_dev_has_feature(), and enable it using iommu_dev_enable_feature().
+ * Device drivers enable the feature via iommu_dev_enable_feature().
*/
enum iommu_dev_features {
IOMMU_DEV_FEAT_AUX,
--
2.21.3
Re: [PATCH v10 1/6] dt-bindings: mfd: logicvc: Add a compatible with the major version only
On Thu, 20 Jan 2022 16:00:19 +0100, Paul Kocialkowski wrote: > There are lots of different versions of the logicvc block and it > makes little sense to list them all in compatibles since all versions > with the same major are found to be register-compatible. > > Introduce a new compatible with the major version only. > > Signed-off-by: Paul Kocialkowski > --- > Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
[PATCH v5 3/3] dt-bindings: mips: loongson: introduce board specific dts
From: suijingfeng
For board specific devices which is outside of the cpu and bridge chip.
this patch introduce two dts, one for lemote a1901(aka LX-6901) motherboard.
documnet can be found from [1].
Another one is loongson 3A4000 evb board, this board have a vga and dvi
interface.
We need introduce board specific dts because of we need the device tree
to tell how does the connectors and encoders are connected to the DVO port
of the display controller.
[1] https://wiki.godson.ac.cn/device:lemote_a1901
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
arch/mips/boot/dts/loongson/lemote_a1901.dts | 64 +
.../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 68 +++
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 2 +-
3 files changed, 133 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts
create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
diff --git a/arch/mips/boot/dts/loongson/lemote_a1901.dts
b/arch/mips/boot/dts/loongson/lemote_a1901.dts
new file mode 100644
index ..81828945ba52
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/lemote_a1901.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "loongson64g-package.dtsi"
+#include "ls7a-pch.dtsi"
+
+/ {
+ compatible = "lemode,a1901", "loongson,loongson64g-4core-ls7a";
+ model = "lemode,a1901";
+};
+
+ {
+ htvec: interrupt-controller@efdfb80 {
+ compatible = "loongson,htvec-1.0";
+ reg = <0xefd 0xfb80 0x40>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+<25 IRQ_TYPE_LEVEL_HIGH>,
+<26 IRQ_TYPE_LEVEL_HIGH>,
+<27 IRQ_TYPE_LEVEL_HIGH>,
+<28 IRQ_TYPE_LEVEL_HIGH>,
+<29 IRQ_TYPE_LEVEL_HIGH>,
+<30 IRQ_TYPE_LEVEL_HIGH>,
+<31 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
+
+ {
+ msi: msi-controller@2ff0 {
+ compatible = "loongson,pch-msi-1.0";
+ reg = <0 0x2ff0 0 0x8>;
+ interrupt-controller;
+ msi-controller;
+ loongson,msi-base-vec = <64>;
+ loongson,msi-num-vecs = <192>;
+ interrupt-parent = <>;
+ };
+};
+
+ {
+ /* use_vram_helper; */
+ output-ports = < >;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dvo0: dvo@0 {
+ /* 0 for DVO0 */
+ reg = <0>;
+ status = "disabled";
+ };
+
+ dvo1: dvo@1 {
+ /* 1 for DVO1 */
+ reg = <1>;
+ connector = "vga-connector";
+ encoder = "adi,adv7125";
+ status = "okay";
+ };
+};
diff --git a/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
new file mode 100644
index ..ff07f529ea43
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "loongson64g-package.dtsi"
+#include "ls7a-pch.dtsi"
+
+/ {
+ compatible = "loongson,loongson64g-4core-ls7a";
+ model = "loongson,ls3a4000_7a1000_evb";
+ version = "v1.4";
+};
+
+ {
+ htvec: interrupt-controller@efdfb80 {
+ compatible = "loongson,htvec-1.0";
+ reg = <0xefd 0xfb80 0x40>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+<25 IRQ_TYPE_LEVEL_HIGH>,
+<26 IRQ_TYPE_LEVEL_HIGH>,
+<27 IRQ_TYPE_LEVEL_HIGH>,
+<28 IRQ_TYPE_LEVEL_HIGH>,
+<29 IRQ_TYPE_LEVEL_HIGH>,
+<30 IRQ_TYPE_LEVEL_HIGH>,
+<31 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
+
+ {
+ msi: msi-controller@2ff0 {
+ compatible = "loongson,pch-msi-1.0";
+ reg = <0 0x2ff0 0 0x8>;
+ interrupt-controller;
+ msi-controller;
+ loongson,msi-base-vec = <64>;
+ loongson,msi-num-vecs = <192>;
+ interrupt-parent = <>;
+ };
+};
+
+ {
+ /* use_vram_helper; */
+ output-ports = < >;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dvo0: dvo@0 {
+ /* 0 for DVO0 */
+ reg = <0>;
+ connector = "vga-connector";
+ encoder = "adi,adv7125";
+ status = "okay";
+ };
+
+ dvo1: dvo@1 {
+ /*
Re: linux-next: build warning after merge of the drm tree
Hi all, On Wed, 2 Feb 2022 15:02:01 +1100 Stephen Rothwell wrote: > > After merging the drm tree, today's linux-next build (htmldocs) produced > this warning: > > drivers/gpu/drm/drm_privacy_screen.c:X: warning: Function parameter or member > 'data' not described in 'drm_privacy_screen_register' Actually: drivers/gpu/drm/drm_privacy_screen.c:392: warning: Function parameter or member 'data' not described in 'drm_privacy_screen_register' -- Cheers, Stephen Rothwell pgpZH4iifkBsO.pgp Description: OpenPGP digital signature
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
drivers/gpu/drm/drm_privacy_screen.c:X: warning: Function parameter or member
'data' not described in 'drm_privacy_screen_register'
Introduced by commit
30598d925d46 ("drm/privacy_screen: Add drvdata in drm_privacy_screen")
--
Cheers,
Stephen Rothwell
pgpZz5KFId8iM.pgp
Description: OpenPGP digital signature
Re: Kconfig CONFIG_FB dependency regression
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen wrote:
> Fabio Estevam wrote:
> > On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap wrote:
> >>
> >> On 2/1/22 15:01, Thinh Nguyen wrote:
> >>> Hi,
> >>>
> >>> One of our test setups is unable to boot (stuck at initramfs). Git
> >>> bisection points to the commit below:
> >>>
> >>> f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> >>>
> >>> Reverting this patch resolves the issue. This issue persists in mainline
> >>> also. Unfortunately there isn't any meaningful log. Hopefully someone
> >>> can give some insight as to what could be the issue and revert/fix this
> >>> issue.
> >>
> >> Hi,
> >> Did you enable DRM_FBDEV_EMULATION?
>
> I did not enable it.
>
> >> Please provide the failing .config file.
> >
> > Does selecting CONFIG_FB=y help?
> >
>
> On the config that has the issue, this isn't set. After reverting the
> commit above, this was set. Maybe this is what's needed? I need to test it.
CONFIG_FB should not normally be needed for booting, so unless
you have a graphical application in your initramfs that requires the /dev/fb0
device to work, it is not supposed to make a difference.
Are there any other differences in your .config before and after the patch?
It's possible that you use some other driver that in turn depends on
CONFIG_FB. Does your machine have any graphical output device?
If yes, which driver do you use?
You may also want to make sure that you have 9d6366e743f3 ("drm:
fb_helper: improve CONFIG_FB dependency") in your kernel, which
fixes a minor problem with my original patch.
Arnd
[PATCH v5 0/3] drm/lsdc: add drm driver for loongson display controller
There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge, and the DC in those chip is a PCI device. This display controller have two display pipes but with only one hardware cursor. Each way has a DVO output interface and the CRTC is able to scanout from 1920x1080 resolution at 60Hz. LS2K1000 is a SoC, only system memory is available. Therefore scanout form system memory is the only choice and we prefer the cma helper base solution even through it is possible to use VRAM helper base solution on ls2k1000 by carving out part of system memory as VRAM. The dc in ls7a1000 can scanout from both the system memory and the dedicate VRAM attached to the ddr3 memory controller. Sadly, only scanout from the VRAM is proved to be a reliable solution for massive product. Scanout from the system memory suffer from some hardware deficiency which cause the screen flickering under RAM pressure. This is the reason why we integrate two distict helpers into one piece of device driver. +--+ | DDR4 | +--+ || MC0+---++ +--+ Hyper | LS7A1000 |DDR3| +--+ | LS3A4000 |<->| ++ +---+ | memory |<->| VRAM | | CPU|<->| | GC1000 | | LSDC | | controller | +--+ +--+ Transport | ++ +-+---+-+ +| || MC1+---|---|+ +--+ | | | DDR4 | +---+DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<-+ +--->|TFP410|--> DVI/HDMI +---+ +--+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, it is a choice of the downstream board manufacturer. Other candicate encoder can be ch7034b, sil9022 and ite66121 etc. This is the reason why we still need device tree to provide board specific information. Beside, the dc in both LS2L1000 and LS7A1000 have the vendor:device id of 0x0014:0x7a06. even the reverison id is also same. We can't tell it apart simply(this is the firmware engineer's mistake). But firmware already flushed to the board and sold out, so we resolve those issues by using the device tree which already have certain support. Nevertheless, this patch try to provided a minimal support for this display controller which is mainly for graphic environment bring up. Hope that the code can speak for itself. For LS7A1000, there are 4 gpios who register is located at dc register space which is used to emulation i2c. LS2K1000 and LS2K0500 SoC don't have those hardware, they use general purpose gpio or hardware i2c to serve this purpose. For ladc, there is only a 1:1 mapping of encoders and connectors. +---+ _ | | | | | CRTC0 --> DVO0 -> Encoder0 --> Connector0 ---> | Monotor | | | ^^|_| | | || |<- i2c0 + | LSDC IP CORE| |<- i2c1 + | | || _ | | ||| | | CRTC1 --> DVO1 -> Encoder1 --> Connector1 ---> | Panel | | | |_| +---+ Below is a brief introduction of loongson's CPU, bridge chip and SoC. LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[1]. LS7A1000 is a bridge chip made by Loongson corporation which act as north and/or south bridge of loongson's desktop and server level processor. It is equivalent to RS780E or something like that. More details can be read from its user manual[2]. This bridge chip is typically use with LS3A3000, LS3A4000 and LS3A5000 cpu. LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu. LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu. LS3A5000 is 4 core 2.5gHz loongarch cpu[3]. v2: fixup warnings reported by kernel test robot v3: fix more grammar mistakes in Kconfig reported by Randy Dunlap and give more details about lsdc. v4: 1) Add dts required and explain why device tree is required. 2) Give more description about lsdc and vram helper base driver. 3) Fix warnings reported by kernel test robot. 4) Introduce stride_alignment member into struct lsdc_chip_desc, the stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500 SoC. But ls7a2000 improve it to 32 bytes, We are prepare for extend the support for the on coming device. v5: 1) using writel and readl replace writeq and readq, to fix kernel test robot report build error on other archtecture 2) set
[PATCH v5 1/3] drm/lsdc: add drm driver for loongson display controller
From: suijingfeng There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge, and the DC in those chip is a PCI device. This display controller have two display pipes but with only one hardware cursor. Each way has a DVO output interface and the CRTC is able to scanout from 1920x1080 resolution at 60Hz. LS2K1000 is a SoC, only system memory is available. Therefore scanout form system memory is the only choice and we prefer the cma helper base solution even through it is possible to use VRAM helper base solution on ls2k1000 by carving out part of system memory as VRAM. The dc in ls7a1000 can scanout from both the system memory and the dedicate VRAM attached to the ddr3 memory controller. Sadly, only scanout from the VRAM is proved to be a reliable solution for massive product. Scanout from the system memory suffer from some hardware deficiency which cause the screen flickering under RAM pressure. This is the reason why we integrate two distict helpers into one piece of device driver. +--+ | DDR4 | +--+ || MC0+---++ +--+ Hyper | LS7A1000 |DDR3| +--+ | LS3A4000 |<->| ++ +---+ | memory |<->| VRAM | | CPU|<->| | GC1000 | | LSDC | | controller | +--+ +--+ Transport | ++ +-+---+-+ +| || MC1+---|---|+ +--+ | | | DDR4 | +---+DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<-+ +--->|TFP410|--> DVI/HDMI +---+ +--+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, it is a choice of the downstream board manufacturer. Other candicate encoder can be ch7034b, sil9022 and ite66121 etc. This is the reason why we still need device tree to provide board specific information. Beside, the dc in both ls2k1000 and ls7k1000 have the vendor:device id of 0x0014:0x7a06. even the reverison id is also same. We can't tell it apart simply(this is the firmware engineer's mistake). But firmware already flushed to the board and sold out, so we resolve those issues by using the device tree which already have certain support. Nevertheless, this patch try to provided a minimal support for this display controller which is mainly for graphic environment bring up. Hope that the code can speak for itself. For ls7a1000, there are 4 gpios who register is located at dc register space which is used to emulation i2c. LS2K1000 and LS2K0500 SoC don't have those hardware, they use general purpose gpio or hardware i2c to serve this purpose. For ladc, there is only a 1:1 mapping of encoders and connectors. +---+ _ | | | | | CRTC0 --> DVO0 -> Encoder0 --> Connector0 ---> | Monotor | | | ^^|_| | | || |<- i2c0 + | LSDC IP CORE| |<- i2c1 + | | || _ | | ||| | | CRTC1 --> DVO1 -> Encoder1 --> Connector1 ---> | Panel | | | |_| +---+ Below is a brief introduction of loongson's CPU, bridge chip and SoC. LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[1]. LS7A1000 is a bridge chip made by Loongson corporation which act as north and/or south bridge of loongson's desktop and server level processor. It is equivalent to RS780E or something like that. More details can be read from its user manual[2]. This bridge chip is typically use with LS3A3000, LS3A4000 and LS3A5000 cpu. LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu. LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu. LS3A5000 is 4 core 2.5gHz loongarch cpu[3]. v2: fixup warnings reported by kernel test robot v3: fix more grammar mistakes in Kconfig reported by Randy Dunlap and give more details about lsdc. v4: 1) Add dts required and explain why device tree is required. 2) Give more description about lsdc and vram helper base driver. 3) Fix warnings reported by kernel test robot. 4) Introduce stride_alignment member into struct lsdc_chip_desc, the stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500 SoC. But ls7a2000 improve it to 32 bytes, We are prepare for extend the support for the on coming device. v5: 1) using writel and readl replace writeq and readq, to fix kernel test robot report build error on other
[PATCH v5 2/3] dt-bindings: ls2k1000: add the display controller device node
From: suijingfeng
The display controller is a pci device, its vendor id is 0x0014
its device id is 0x7a06.
Signed-off-by: suijingfeng
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a6e3..6510b0e6928a 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,17 @@
interrupt-parent = <>;
};
+ lsdc: dc@6,0 {
+ compatible = "pci0014,7a06.0",
+ "pci0014,7a06",
+ "pciclass03",
+ "pciclass0300";
+
+ reg = <0x3000 0x0 0x0 0x0 0x0>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <>;
+ };
+
pci_bridge@9,0 {
compatible = "pci0014,7a19.0",
"pci0014,7a19",
--
2.20.1
[PATCH v2] drm/msm/dp: add wide bus support
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
width from 32 bits to 64 bits so that it can push two
pixel of data per pixel clock to interface to display.
This feature is pre requirement to support 4k resolution
since it will reduce pixel clock rate to half of original
rate. Hence pixel clock rate used to drive 4k panel will
not exceed limitation.
changes in v2:
-- remove compression related code from timing
-- remove op_info from struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 8 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 2 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 99 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h| 2 +
drivers/gpu/drm/msm/dp/dp_catalog.c| 15 +++-
drivers/gpu/drm/msm/dp/dp_catalog.h| 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 13 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c| 11 +++
drivers/gpu/drm/msm/dp/dp_display.h| 21 -
drivers/gpu/drm/msm/dp/dp_panel.c | 4 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 2 +-
drivers/gpu/drm/msm/msm_drv.h | 25 ++
14 files changed, 154 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db..7bbdfb9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
+{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ return dpu_enc->dp->wide_bus_en;
+}
+
static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp, unsigned
bpc)
{
struct dpu_hw_dither_cfg dither_cfg = { 0 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index e241914..0d73550 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
+
#endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index ddd9d89..b72c33b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
timing->v_back_porch += timing->v_front_porch;
timing->v_front_porch = 0;
}
+
+ timing->wide_bus_en = dpu_encoder_is_widebus_enabled(phys_enc->parent);
+
+ /*
+* for DP, divide the horizonal parameters by 2 when
+* widebus is enabled
+*/
+ if (timing->wide_bus_en) {
+ timing->width = timing->width >> 1;
+ timing->xres = timing->xres >> 1;
+ timing->h_back_porch = timing->h_back_porch >> 1;
+ timing->h_front_porch = timing->h_front_porch >> 1;
+ timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
+ }
}
static u32 get_horizontal_total(const struct intf_timing_params *timing)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 116e2b5..35d4aaa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -33,6 +33,7 @@
#define INTF_TP_COLOR1 0x05C
#define INTF_CONFIG20x060
#define INTF_DISPLAY_DATA_HCTL 0x064
+#define INTF_ACTIVE_DATA_HCTL 0x068
#define INTF_FRAME_LINE_COUNT_EN0x0A8
#define INTF_FRAME_COUNT0x0AC
#define INTF_LINE_COUNT 0x0B0
@@ -90,68 +91,95 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
u32 hsync_period, vsync_period;
u32 display_v_start, display_v_end;
u32 hsync_start_x, hsync_end_x;
+ u32 hsync_data_start_x, hsync_data_end_x;
u32 active_h_start, active_h_end;
u32 active_v_start, active_v_end;
u32 active_hctl, display_hctl, hsync_ctl;
u32 polarity_ctl, den_polarity, hsync_polarity, vsync_polarity;
u32 panel_format;
- u32 intf_cfg, intf_cfg2 = 0,
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
include/drm/drm_connector.h:637: warning: Function parameter or member
'edid_hdmi_rgb444_dc_modes' not described in 'drm_display_info'
include/drm/drm_connector.h:637: warning: Function parameter or member
'edid_hdmi_ycbcr444_dc_modes' not described in 'drm_display_info'
Introduced by commit
4adc33f36d80 ("drm/edid: Split deep color modes between RGB and YUV444")
--
Cheers,
Stephen Rothwell
pgp8MwAsEO_lW.pgp
Description: OpenPGP digital signature
[PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_mm.c | 28
include/drm/drm_mm.h | 32
2 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..416c849c10e5 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
return node;
}
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
- u64 start, u64 end, u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
}
+EXPORT_SYMBOL(drm_mm_first_hole);
/**
* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
*entry, u64 size) \
DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+drm_mm_next_hole(struct drm_mm *mm,
+struct drm_mm_node *node,
+u64 size,
+enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return >hole_stack == >hole_stack ? NULL : node;
}
}
+EXPORT_SYMBOL(drm_mm_next_hole);
/**
* drm_mm_reserve_node - insert an pre-initialized node
@@ -520,7 +522,6 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
DRM_MM_BUG_ON(range_start > range_end);
@@ -533,13 +534,8 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
- for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+ drm_mm_for_each_best_hole(hole, mm, range_start, range_end, size, mode)
{
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index ac33ba1b18bc..5055447697fa 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -322,6 +322,17 @@ static inline u64 __drm_mm_hole_node_end(const struct
drm_mm_node *hole_node)
return list_next_entry(hole_node, node_list)->start;
}
+struct drm_mm_node *
+drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode);
+
+struct drm_mm_node *
+drm_mm_next_hole(struct drm_mm *mm,
+struct drm_mm_node *node,
+u64 size,
+enum drm_mm_insert_mode mode);
+
/**
* drm_mm_hole_node_end - computes the end of the hole following @node
* @hole_node: drm_mm_node which implicitly tracks the following hole
@@ -400,6 +411,27 @@ static inline u64 drm_mm_hole_node_end(const struct
drm_mm_node *hole_node)
1 : 0; \
pos = list_next_entry(pos, hole_stack))
+/**
+ * drm_mm_for_each_best_hole - iterator to optimally walk over all holes >=
@size
+ * @pos: _mm_node used internally to track progress
+ * @mm: _mm allocator to walk
+ * @range_start: start of the allowed range for the allocation
+ * @range_end: end of the allowed range for the allocation
+ * @size: size of the allocation
+ * @mode: fine-tune the allocation search
+ *
+ * This iterator walks over all holes suitable for the allocation of given
+ * @size in a very efficient manner. It is implemented by calling
+ * drm_mm_first_hole() and drm_mm_next_hole() which identify the
+ * appropriate holes within the given range by efficently traversing the
+ * rbtree associated with @mm.
+ */
+#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode)
\
+
Re: [PATCH 1/2] dt-bindings: display: imx: Add fsl,imx21-lcdc docs
On Fri, Jan 28, 2022 at 06:58:29PM +0100, Uwe Kleine-König wrote: > Hello Rob, > > On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote: > > On Fri, Jan 28, 2022 at 4:59 AM Uwe Kleine-König > > wrote: > > > > > > From: Marian Cichy > > > > > > This files documents the device tree for the new imx21-lcdc DRM driver. > > > > No, bindings document h/w and the h/w has not changed. We already have > > a binding for the LCDC. > > Just to be sure we're talking about the same thing: You're refering to > Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt, right? Looks right... > I'm unsure what to do now. Should the two different bindings just be > described in the same file? Should I stick to fsl,imx21-fb even for the > new binding? (The hardware unit is named LCDC, so the name chosen here > is the better one.) Please advise. Yes, the name is unfortunate, but it should be 1 binding, 1 file, and unchanged (unless you want to add new optional properties). Rob
Re: [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote: On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote: Only x86 and in some cases PPC have support added in drm_cache.c for the clflush class of functions. However warning once is sufficient to taint the log instead of spamming it with "Architecture has no drm_cache.c support" every few millisecond. Switch to WARN_ONCE() so we still get the log message, but only once, together with the warning. E.g: [ cut here ] Architecture has no drm_cache.c support WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 drm_clflush_sg+0x40/0x50 [drm] ... v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err() Reviewed-by: José Roberto de Souza But while at it, why not add a drm_device parameter to this function so we can use drm_WARN_ONCE()? Anyways, it is better than before. I thought about that, but it didn't seem justifiable because: 1) drm_WARN_ONCE will basically add dev_driver_string() to the log. However the warning message here is basically helping the bootstrap of additional archs. They shouldn't be seen on anything properly supported. 2) This seems all to be a layer below drm anyway and could even be used in places outside easy access to a drm pointer. So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE doesn't justify the hassle of changing the callers, possibly adding additional back pointers to have access to the drm device pointer. thanks Lucas De Marchi
Re: [PATCH] Revert "drm/panel-edp: Allow querying the detected panel via sysfs"
Hi, On Tue, Feb 1, 2022 at 9:22 AM Douglas Anderson wrote: > > This reverts commit 363c4c3811db330dee9ce27dd3cee6f590d44e4c. > > Since the point of this attribute is for a test, this should be done > in debugfs, not sysfs. Let's revert and a new patch can be added later > doing it in debugfs. > > Signed-off-by: Douglas Anderson > --- > > drivers/gpu/drm/panel/panel-edp.c | 39 --- > 1 file changed, 5 insertions(+), 34 deletions(-) Pushed the revert with Javier's R-B, provided on #dri-devel IRC. 2bf68bbdb6f5 Revert "drm/panel-edp: Allow querying the detected panel via sysfs" -Doug
[Bug 214801] polaris11 (rx560) regression
https://bugzilla.kernel.org/show_bug.cgi?id=214801 Roman Elshin (roxm...@list.ru) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Roman Elshin (roxm...@list.ru) --- Looks like this bug report are incorrect and the reason are using old amdgpu firmware. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 0/2] drm/msm: Remove spurious IRQF_ONESHOT flags from dsi & hdmi
This series corrects incorrect calls to request_irq(..., IRQF_ONESHOT, ...). These anomalies are harmless on regular kernels but cause odd behaviour on threadirq kernels and break entirely on PREEMPT_RT kernels I'm pretty certain these problems would also provoke lockdep splats on kernels with CONFIG_PROVE_RAW_LOCK_NESTING enabled (because that is intended to find code that breaks entirely on PREEMPT_RT kernels ;-) ). Finally, and just in case anybody asks, yes! I did use coccinelle to do a quick scan for similar issues. I didn't find any other instances in drivers/drm/ . Changes in v2: - Split into separate patches (Dmitry B) Daniel Thompson (2): drm/msm/dsi: Remove spurious IRQF_ONESHOT flag drm/msm/hdmi: Remove spurious IRQF_ONESHOT flag drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c -- 2.34.1
[PATCH v2 2/2] drm/msm/hdmi: Remove spurious IRQF_ONESHOT flag
Quoting the header comments, IRQF_ONESHOT is "Used by threaded interrupts
which need to keep the irq line disabled until the threaded handler has
been run.". When applied to an interrupt that doesn't request a threaded
irq then IRQF_ONESHOT has a lesser known (undocumented?) side effect,
which it to disable the forced threading of irqs. For "normal" kernels
if there is no thread_fn then IRQF_ONESHOT is a nop.
In this case disabling forced threading is not appropriate because the
driver calls wake_up_all() (via msm_hdmi_i2c_irq) and also directly uses
the regular spinlock API for locking (in msm_hdmi_hdcp_irq() ). Neither
of these APIs can be called from no-thread interrupt handlers on
PREEMPT_RT systems.
Fix this by removing IRQF_ONESHOT.
Signed-off-by: Daniel Thompson
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 719720709e9e7..e167817b42958 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -306,7 +306,7 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
}
ret = devm_request_irq(>dev, hdmi->irq,
- msm_hdmi_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+ msm_hdmi_irq, IRQF_TRIGGER_HIGH,
"hdmi_isr", hdmi);
if (ret < 0) {
DRM_DEV_ERROR(dev->dev, "failed to request IRQ%u: %d\n",
--
2.34.1
[PATCH v2 1/2] drm/msm/dsi: Remove spurious IRQF_ONESHOT flag
Quoting the header comments, IRQF_ONESHOT is "Used by threaded interrupts
which need to keep the irq line disabled until the threaded handler has
been run.". When applied to an interrupt that doesn't request a threaded
irq then IRQF_ONESHOT has a lesser known (undocumented?) side effect,
which it to disable the forced threading of irqs (and for "normal" kernels
it is a nop). In this case I can find no evidence that suppressing forced
threading is intentional. Had it been intentional then a driver must adopt
the raw_spinlock API in order to avoid deadlocks on PREEMPT_RT kernels
(and avoid calling any kernel API that uses regular spinlocks).
Fix this by removing the spurious additional flag.
This change is required for my Snapdragon 7cx Gen2 tablet to boot-to-GUI
with PREEMPT_RT enabled.
Signed-off-by: Daniel Thompson
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 6b3ced4aaaf5d..3a3f53f0c8ae1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1877,7 +1877,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
/* do not autoenable, will be enabled later */
ret = devm_request_irq(>dev, msm_host->irq, dsi_host_irq,
- IRQF_TRIGGER_HIGH | IRQF_ONESHOT | IRQF_NO_AUTOEN,
+ IRQF_TRIGGER_HIGH | IRQF_NO_AUTOEN,
"dsi_isr", msm_host);
if (ret < 0) {
dev_err(>dev, "failed to request IRQ%u: %d\n",
--
2.34.1
[PATCH v2 1/2] drm/msm/gpu: Add ctx to get_param()
From: Rob Clark
Prep work for next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
drivers/gpu/drm/msm/msm_gpu.h | 3 ++-
drivers/gpu/drm/msm/msm_rd.c| 6 --
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f33cfa4ef1c8..caa9076197de 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -227,7 +227,8 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
return aspace;
}
-int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
+int adreno_get_param(struct msm_gpu *gpu, struct msm_file_private *ctx,
+uint32_t param, uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index cffabe7d33c1..432590036b31 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -279,7 +279,8 @@ static inline int adreno_is_a650_family(struct adreno_gpu
*gpu)
adreno_is_a660_family(gpu);
}
-int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
+int adreno_get_param(struct msm_gpu *gpu, struct msm_file_private *ctx,
+uint32_t param, uint64_t *value);
const struct firmware *adreno_request_fw(struct adreno_gpu *adreno_gpu,
const char *fwname);
struct drm_gem_object *adreno_fw_create_bo(struct msm_gpu *gpu,
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 555666e3f960..72060247e43c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -763,7 +763,8 @@ static int msm_ioctl_get_param(struct drm_device *dev, void
*data,
if (!gpu)
return -ENXIO;
- return gpu->funcs->get_param(gpu, args->param, >value);
+ return gpu->funcs->get_param(gpu, file->driver_priv,
+args->param, >value);
}
static int msm_ioctl_gem_new(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 92aa1e9196c6..ba8407231340 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -42,7 +42,8 @@ struct msm_gpu_config {
*+ z180_gpu
*/
struct msm_gpu_funcs {
- int (*get_param)(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
+ int (*get_param)(struct msm_gpu *gpu, struct msm_file_private *ctx,
+uint32_t param, uint64_t *value);
int (*hw_init)(struct msm_gpu *gpu);
int (*pm_suspend)(struct msm_gpu *gpu);
int (*pm_resume)(struct msm_gpu *gpu);
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 7e4d6460719e..dd3605b46264 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -197,13 +197,15 @@ static int rd_open(struct inode *inode, struct file *file)
/* the parsing tools need to know gpu-id to know which
* register database to load.
+*
+* Note: These particular param does not require a context
*/
- gpu->funcs->get_param(gpu, MSM_PARAM_GPU_ID, );
+ gpu->funcs->get_param(gpu, NULL, MSM_PARAM_GPU_ID, );
gpu_id = val;
rd_write_section(rd, RD_GPU_ID, _id, sizeof(gpu_id));
- gpu->funcs->get_param(gpu, MSM_PARAM_CHIP_ID, );
+ gpu->funcs->get_param(gpu, NULL, MSM_PARAM_CHIP_ID, );
rd_write_section(rd, RD_CHIP_ID, , sizeof(val));
out:
--
2.34.1
[PATCH v2 2/2] drm/msm/gpu: Track global faults per address-space
From: Rob Clark
Other processes don't need to know about faults that they are isolated
from by virtue of address space isolation. They are only interested in
whether some of their state might have been corrupted.
But to be safe, also track unattributed faults. This case should really
never happen unless there is a kernel bug (and that would never happen,
right?)
v2: Instead of adding a new param, just change the behavior of the
existing param to match what userspace actually wants [anholt]
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5934
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 8 +++-
drivers/gpu/drm/msm/msm_gpu.h | 5 -
4 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index caa9076197de..58dfb23cf2af 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -269,7 +269,7 @@ int adreno_get_param(struct msm_gpu *gpu, struct
msm_file_private *ctx,
*value = 0;
return 0;
case MSM_PARAM_FAULTS:
- *value = gpu->global_faults;
+ *value = gpu->global_faults + ctx->aspace->faults;
return 0;
case MSM_PARAM_SUSPENDS:
*value = gpu->suspend_count;
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 54ca0817d807..af612add5264 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -35,6 +35,9 @@ struct msm_gem_address_space {
* will be non-NULL:
*/
struct pid *pid;
+
+ /* @faults: the number of GPU hangs associated with this address space
*/
+ int faults;
};
struct msm_gem_vma {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 2c1049c0ea14..942bf41403ff 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -370,8 +370,8 @@ static void recover_worker(struct kthread_work *work)
struct task_struct *task;
/* Increment the fault counts */
- gpu->global_faults++;
submit->queue->faults++;
+ submit->aspace->faults++;
task = get_pid_task(submit->pid, PIDTYPE_PID);
if (task) {
@@ -389,6 +389,12 @@ static void recover_worker(struct kthread_work *work)
} else {
msm_rd_dump_submit(priv->hangrd, submit, NULL);
}
+ } else {
+ /*
+* We couldn't attribute this fault to any particular context,
+* so increment the global fault count instead.
+*/
+ gpu->global_faults++;
}
/* Record the crash state */
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index ba8407231340..c99627fc99dd 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -200,7 +200,10 @@ struct msm_gpu {
/* does gpu need hw_init? */
bool needs_hw_init;
- /* number of GPU hangs (for all contexts) */
+ /**
+* global_faults: number of GPU hangs not attributed to a particular
+* address space
+*/
int global_faults;
void __iomem *mmio;
--
2.34.1
[Bug 215511] Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- Here's a howto for doing a bisect: https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html Here's a howto for building a kernel: https://kernelnewbies.org/KernelBuild Basic process: # create a directly to store your git source mkdir kernel # change to that directory cd kernel # clone the stable git tree git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git # copy your distros config to use for your build, replace #whatever with # whatever config your distro is using cp /boot/config-#whatever .config # start bisecting git bisect start # tag 5.15.13 as bad git bisect bad v5.15.13 # tag 5.15.2 as good git bisect good v5.15.12 # build the first kernel to test make clean make make modules_install make install # test the new kernel # if it's good, mark it as good git bisect good # if it's bad, mark it as bad git bisect bad # build the next kernel to test make make modules_install make install # test the new kernel # repeat until the bisect is complete -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm/panel-edp: Allow querying the detected panel via sysfs
Hi, On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas wrote: > > On 1/26/22 00:25, Doug Anderson wrote: > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > wrote: > > [snip] > > >> Should this new sysfs entry be documented in Documentation/ABI/ ? > > > > I'm not sure what the policy is here. I actually don't know that I'm > > too worried about this being an ABI. For the purposes of our tests > > then if something about this file changed (path changed or something > > like that) it wouldn't be a huge deal. Presumably the test itself > > would just "fail" in this case and that would clue us in that the ABI > > changed and we could adapt to whatever new way was needed to discover > > this. > > > > That being said, if the policy is that everything in sysfs is supposed > > to be ABI then I can add documentation for this... > > > > I also don't know the policy, hence the question. But in any case, I > think that it could even be done as a follow-up if is needed. Sounds good. Since it's been pretty silent and I had your review I pushed this to drm-misc-next. If there are comments or someone has an opinion documenting this as a stable ABI then please yell. 363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs
Re: [PATCH v1 1/4] fbtft: Unorphan the driver
On Tue, Feb 1, 2022 at 6:01 PM Geert Uytterhoeven wrote:
>
> Hi Thomas,
>
> On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann wrote:
> > Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas:
> > > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used
> > > for
> > > now a DRM_MODE_CONNECTOR_Unknown.
> >
> > That might have implications on userspace. Maybe ask around. (Not that
> > we actually run userspace on the device).
>
> Looking at the list of connector types (and wondering if we're gonna
> need more when converting existing fbdev drivers to drm drivers),
> there seem to be two different families of connector types, for
> 1. transports between CRTC and display (e.g. VGA, DVID, HDMI),
> 2. transports between CPU and CRTC (e.g. SPI, possibly USB, and
> the proposed I2C)?
I was trying to argue for a panel connector type and stop doing all
these internal things because like you point out, it kinda doesn't,
only the external connectors are relevant to users. But it didn't
stick anywhere yet, we keep adding more connector types and then
having to update userspace, which should map these all to "it's the
panel" or something like that. But also since various technicolor
abbreviations are about as useful to end-users as "unknown" it really
doesn't matter, so I'm happy to let this bikeshed get a tad fancier
every year :-)
-Daniel
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Architectures others than x86 have a stub implementation calling
> WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
> the header-test target will fail with:
>
> HDRTEST drivers/gpu/drm/i915/i915_mm.h
> In file included from :
> ./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
> ./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of
> function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
>26 | WARN_ON_ONCE(1);
> | ^~~~
>
> v2: Do not include since call to pr_err() has been
> removed
Reviewed-by: José Roberto de Souza
>
> Fixes: 67c430bbaae1 ("drm/i915: Skip remap_io_mapping() for non-x86
> platforms")
> Cc: Siva Mullati
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/i915/i915_mm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 76f1d53bdf34..3ad22bbe80eb 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -6,6 +6,7 @@
> #ifndef __I915_MM_H__
> #define __I915_MM_H__
>
> +#include
> #include
>
> struct vm_area_struct;
Re: [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Only x86 and in some cases PPC have support added in drm_cache.c for the
> clflush class of functions. However warning once is sufficient to taint
> the log instead of spamming it with "Architecture has no drm_cache.c
> support" every few millisecond. Switch to WARN_ONCE() so we still get
> the log message, but only once, together with the warning. E.g:
>
> [ cut here ]
> Architecture has no drm_cache.c support
> WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139
> drm_clflush_sg+0x40/0x50 [drm]
> ...
>
> v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()
Reviewed-by: José Roberto de Souza
But while at it, why not add a drm_device parameter to this function so we can
use drm_WARN_ONCE()?
Anyways, it is better than before.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/drm_cache.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index f19d9acbe959..2c3fa5677f7e 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,8 +112,7 @@ drm_clflush_pages(struct page *pages[], unsigned long
> num_pages)
> kunmap_atomic(page_virtual);
> }
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_pages);
> @@ -143,8 +142,7 @@ drm_clflush_sg(struct sg_table *st)
> if (wbinvd_on_all_cpus())
> pr_err("Timed out waiting for cache flush\n");
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_sg);
> @@ -177,8 +175,7 @@ drm_clflush_virt_range(void *addr, unsigned long length)
> if (wbinvd_on_all_cpus())
> pr_err("Timed out waiting for cache flush\n");
> #else
> - pr_err("Architecture has no drm_cache.c support\n");
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_virt_range);
[PATCH v2 0/2] drm/msm: Add tracking for faults associated with an address space
From: Rob Clark Currently, for GL_EXT_robustness userspace uses the global and per- submitqueue fault counters to determine GUILTY_CONTEXT_RESET_EXT vs INNOCENT_CONTEXT_RESET_EXT. But that is a bit overly paranoid, in that a fault in a different process's context (when it has it's own isolated address space) should not hurt anything. This is particularly annoying with CrOS and chrome's exit_on_context_lost quirk, while running deqp in the android container, as the deqp-egl suite has tests that intentionally trigger gpu hangs (for the purpose of testing the robustness extension), which triggers chrome to restart, which restarts the android container! But chrome doesn't need to know about these faults, thanks to address space isolation. Applies on top of https://patchwork.freedesktop.org/series/98907/ Rob Clark (2): drm/msm/gpu: Add ctx to get_param() drm/msm/gpu: Track global faults per address-space drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 +++-- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++- drivers/gpu/drm/msm/msm_drv.c | 3 ++- drivers/gpu/drm/msm/msm_gem.h | 3 +++ drivers/gpu/drm/msm/msm_gpu.c | 8 +++- drivers/gpu/drm/msm/msm_gpu.h | 8 ++-- drivers/gpu/drm/msm/msm_rd.c| 6 -- 7 files changed, 27 insertions(+), 9 deletions(-) -- 2.34.1
Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On Tue, Feb 1, 2022 at 3:52 PM Helge Deller wrote:
>
> On 2/1/22 14:45, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 12:01 PM Helge Deller wrote:
> >> On 2/1/22 11:36, Daniel Vetter wrote:
> >>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still
> prevent the
> console acceleration.
> >>>
> >>> Duh :-(
> >>>
> >>> But before we dig into details I think the big picture would be
> >>> better. I honestly don't like the #ifdef pile here that much.
> >>
> >> Me neither.
> >> The ifdefs give a better separation, but prevents that the compiler
> >> checks the various paths when building.
> >>
> >>> I wonder whether your approach, also with GETVX/YRES adjusted
> >>> somehow, wouldn't look cleaner?
> >> I think so.
> >> You wouldn't even need to touch GETVX/YRES because the compiler
> >> will optimize/reduce it from
> >>
> >> #define GETVYRES(s,i) ({ \
> >> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> >> (i)->var.yres : (i)->var.yres_virtual; })
> >>
> >> to just become:
> >>
> >> #define GETVYRES(s,i) ((i)->var.yres)
> >
> > Yeah, but you need to roll out your helper to all the callsites. But
> > since you #ifdef out info->scrollmode we should catch them all I
> > guess.
>
> Right. That was the only reason why I ifdef'ed it out.
> Technically we don't need that ifdef.
>
> >>> Like I said in the cover letter I got mostly distracted with fbcon
> >>> locking last week, not really with this one here at all, so maybe
> >>> going with your 4 (or 2 if we squash them like I did here) patches is
> >>> neater?
> >>
> >> The benefit of my patch series was, that it could be easily backported
> >> first,
> >> and then cleaned up afterwards. Even a small additional backport patch to
> >> disable
> >> the fbcon acceleration for DRM in the old releases would be easy.
> >> But I'm not insisting on backporting the patches, if we find good way
> >> forward.
> >>
> >> So, either with the 4 (or 2) patches would be OK for me (or even your
> >> approach).
> >
> > The idea behind the squash was that it's then impossible to backport
> > without the Kconfig,
>
> Yes, my proposal was to simply revert the 2 patches and immediatly send
> the Kconfig patch to disable it again.
>
> > and so we'll only enable this code when people
> > intentionally want it. Maybe I'm too paranoid?
>
> I think you are too paranoid :-)
> If all patches incl. the Kconfig patch are backported then people shouldn't
> do it wrong.
>
> > Anyway, you feel like finishing off your approach? Or should I send
> > out v2 of this with the issues fixed you spotted? Like I said either
> > is fine with me.
>
> Ok, then let me try to finish my approach until tomorrow, and then you
> check if you can and want to add your locking and other patches on top of it.
> In the end I leave the decision which approach to take to you.
> Ok?
Sounds good, and yeah rough idea is that the maintainers + revert +
Kconfig should go in for rc3 or rc4 if we hit another bump, and the
locking stuff then in for -next (since it needs a backmerge and is
defo tricky stuff).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v1 1/4] fbtft: Unorphan the driver
Hi Thomas,
On Tue, Feb 1, 2022 at 5:16 PM Thomas Zimmermann wrote:
> Am 31.01.22 um 11:18 schrieb Javier Martinez Canillas:
> > Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
> > now a DRM_MODE_CONNECTOR_Unknown.
>
> That might have implications on userspace. Maybe ask around. (Not that
> we actually run userspace on the device).
Looking at the list of connector types (and wondering if we're gonna
need more when converting existing fbdev drivers to drm drivers),
there seem to be two different families of connector types, for
1. transports between CRTC and display (e.g. VGA, DVID, HDMI),
2. transports between CPU and CRTC (e.g. SPI, possibly USB, and
the proposed I2C)?
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
Re: [PATCH] drm/panel-edp: Allow querying the detected panel via sysfs
On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson wrote: > > Hi, > > On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas > wrote: > > > > On 1/26/22 00:25, Doug Anderson wrote: > > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > > wrote: > > > > [snip] > > > > >> Should this new sysfs entry be documented in Documentation/ABI/ ? > > > > > > I'm not sure what the policy is here. I actually don't know that I'm > > > too worried about this being an ABI. For the purposes of our tests > > > then if something about this file changed (path changed or something > > > like that) it wouldn't be a huge deal. Presumably the test itself > > > would just "fail" in this case and that would clue us in that the ABI > > > changed and we could adapt to whatever new way was needed to discover > > > this. > > > > > > That being said, if the policy is that everything in sysfs is supposed > > > to be ABI then I can add documentation for this... > > > > > > > I also don't know the policy, hence the question. But in any case, I > > think that it could even be done as a follow-up if is needed. > > Sounds good. Since it's been pretty silent and I had your review I > pushed this to drm-misc-next. If there are comments or someone has an > opinion documenting this as a stable ABI then please yell. > > 363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs Generally stuff for tests should be put into debugfs. We print everything there in various files. sysfs is uapi, and so come with the full baggage of you need open userspace (which for some sysfs stuff might just be a script), and explicitly not for tests (because that just opens the door to merge anything binary blobs might want and just slide it all in). So please retcon at least some plausible deniability here :-) But if it's really only for a test then maybe dumping this into a debugfs file (we do have connector directories already) would be much better. That doable? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Do not spam log with missing arch support
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Following what was done in drm_cache.c, when the stub for
> remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
> remap_io_mapping() for non-x86 platforms"), it included a log message
> with pr_err(). However just the warning is already enough and switching
> to WARN_ONCE() allows us to keep the log message while avoiding log
> spam.
Reviewed-by: José Roberto de Souza
But same suggestion as the first patch in this series about drm_WARN_ONCE().
>
> Signed-off-by: Lucas De Marchi
> ---
>
> v3: No changes from previous version, just submitting to the right
> mailing list
>
> drivers/gpu/drm/i915/i915_mm.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_mm.h b/drivers/gpu/drm/i915/i915_mm.h
> index 3ad22bbe80eb..04c8974d822b 100644
> --- a/drivers/gpu/drm/i915/i915_mm.h
> +++ b/drivers/gpu/drm/i915/i915_mm.h
> @@ -23,8 +23,7 @@ int remap_io_mapping(struct vm_area_struct *vma,
>unsigned long addr, unsigned long pfn, unsigned long size,
>struct io_mapping *iomap)
> {
> - pr_err("Architecture has no %s() and shouldn't be calling this
> function\n", __func__);
> - WARN_ON_ONCE(1);
> + WARN_ONCE(1, "Architecture has no drm_cache.c support\n");
> return 0;
> }
> #endif
Re: [PATCH 17/27] dt-bindings: display: rockchip: Add binding for VOP2
On Wed, Jan 26, 2022 at 03:55:39PM +0100, Sascha Hauer wrote:
> The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
> The binding differs slightly from the existing VOP binding, so add a new
> binding file for it.
>
> Changes since v3:
> - drop redundant _vop suffix from clock names
>
> Signed-off-by: Sascha Hauer
> ---
> .../display/rockchip/rockchip-vop2.yaml | 146 ++
> 1 file changed, 146 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> new file mode 100644
> index ..572cfb307c20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> @@ -0,0 +1,146 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip SoC display controller (VOP2)
> +
> +description:
> + VOP2 (Video Output Processor v2) is the display controller for the Rockchip
> + series of SoCs which transfers the image data from a video memory
> + buffer to an external LCD interface.
> +
> +maintainers:
> + - Sandy Huang
> + - Heiko Stuebner
> +
> +properties:
> + compatible:
> +enum:
> + - rockchip,rk3566-vop
> + - rockchip,rk3568-vop
> +
> + reg:
> +minItems: 1
> +items:
> + - description:
> + Must contain one entry corresponding to the base address and length
> + of the register space.
> + - description:
> + Can optionally contain a second entry corresponding to
> + the CRTC gamma LUT address.
> +
> + interrupts:
> +maxItems: 1
> +description:
> + The VOP interrupt is shared by several interrupt sources, such as
> + frame start (VSYNC), line flag and other status interrupts.
> +
> + clocks:
> +items:
> + - description: Clock for ddr buffer transfer.
> + - description: Clock for the ahb bus to R/W the phy regs.
> + - description: Pixel clock for video port 0.
> + - description: Pixel clock for video port 1.
> + - description: Pixel clock for video port 2.
> +
> + clock-names:
> +items:
> + - const: aclk
> + - const: hclk
> + - const: dclk_vp0
> + - const: dclk_vp1
> + - const: dclk_vp2
> +
> + rockchip,grf:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> + Phandle to GRF regs used for misc control
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output endpoint of VP0
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output endpoint of VP1
> +
> + port@2:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output endpoint of VP2
> +
> + assigned-clocks: true
> +
> + assigned-clock-rates: true
> +
> + assigned-clock-parents: true
You can drop these. They are implicitly allowed with 'clocks'.
> +
> + iommus:
> +maxItems: 1
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +bus {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +vop: vop@fe04 {
> +compatible = "rockchip,rk3568-vop";
> +reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0
> 0x1000>;
> +interrupts = ;
> +clocks = < ACLK_VOP>,
> + < HCLK_VOP>,
> + < DCLK_VOP0>,
> + < DCLK_VOP1>,
> + < DCLK_VOP2>;
> +clock-names = "aclk_vop",
> + "hclk_vop",
> + "dclk_vp0",
> + "dclk_vp1",
> + "dclk_vp2";
> +power-domains = < RK3568_PD_VO>;
> +iommus = <_mmu>;
> +vop_out: ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +vp0: port@0 {
> +reg = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +};
> +vp1: port@1 {
> +reg = <1>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
[PATCH] Revert "drm/panel-edp: Allow querying the detected panel via sysfs"
This reverts commit 363c4c3811db330dee9ce27dd3cee6f590d44e4c.
Since the point of this attribute is for a test, this should be done
in debugfs, not sysfs. Let's revert and a new patch can be added later
doing it in debugfs.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-edp.c | 39 ---
1 file changed, 5 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 23da4040e263..a394a15dc3fb 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -222,8 +222,6 @@ struct panel_edp {
struct gpio_desc *enable_gpio;
struct gpio_desc *hpd_gpio;
- const struct edp_panel_entry *detected_panel;
-
struct edid *edid;
struct drm_display_mode override_mode;
@@ -668,6 +666,7 @@ static const struct edp_panel_entry *find_edp_panel(u32
panel_id);
static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
{
+ const struct edp_panel_entry *edp_panel;
struct panel_desc *desc;
u32 panel_id;
char vend[4];
@@ -706,14 +705,14 @@ static int generic_edp_panel_probe(struct device *dev,
struct panel_edp *panel)
}
drm_edid_decode_panel_id(panel_id, vend, _id);
- panel->detected_panel = find_edp_panel(panel_id);
+ edp_panel = find_edp_panel(panel_id);
/*
* We're using non-optimized timings and want it really obvious that
* someone needs to add an entry to the table, so we'll do a WARN_ON
* splat.
*/
- if (WARN_ON(!panel->detected_panel)) {
+ if (WARN_ON(!edp_panel)) {
dev_warn(dev,
"Unknown panel %s %#06x, using conservative timings\n",
vend, product_id);
@@ -735,14 +734,12 @@ static int generic_edp_panel_probe(struct device *dev,
struct panel_edp *panel)
*/
desc->delay.unprepare = 2000;
desc->delay.enable = 200;
-
- panel->detected_panel = ERR_PTR(-EINVAL);
} else {
dev_info(dev, "Detected %s %s (%#06x)\n",
-vend, panel->detected_panel->name, product_id);
+vend, edp_panel->name, product_id);
/* Update the delay; everything else comes from EDID */
- desc->delay = *panel->detected_panel->delay;
+ desc->delay = *edp_panel->delay;
}
ret = 0;
@@ -753,28 +750,6 @@ static int generic_edp_panel_probe(struct device *dev,
struct panel_edp *panel)
return ret;
}
-static ssize_t detected_panel_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct panel_edp *p = dev_get_drvdata(dev);
-
- if (IS_ERR(p->detected_panel))
- return sysfs_emit(buf, "UNKNOWN\n");
- else if (!p->detected_panel)
- return sysfs_emit(buf, "HARDCODED\n");
- else
- return sysfs_emit(buf, "%s\n", p->detected_panel->name);
-}
-
-static const DEVICE_ATTR_RO(detected_panel);
-
-static void edp_panel_remove_detected_panel(void *data)
-{
- struct panel_edp *p = data;
-
- device_remove_file(p->base.dev, _attr_detected_panel);
-}
-
static int panel_edp_probe(struct device *dev, const struct panel_desc *desc,
struct drm_dp_aux *aux)
{
@@ -874,10 +849,6 @@ static int panel_edp_probe(struct device *dev, const
struct panel_desc *desc,
drm_panel_add(>base);
- err = device_create_file(dev, _attr_detected_panel);
- if (!err)
- devm_add_action_or_reset(dev, edp_panel_remove_detected_panel,
panel);
-
return 0;
err_finished_pm_runtime:
--
2.35.0.rc2.247.g8bbb082509-goog
Re: [PATCH] drm/panel-edp: Allow querying the detected panel via sysfs
Hi, On Tue, Feb 1, 2022 at 9:02 AM Daniel Vetter wrote: > > On Tue, Feb 1, 2022 at 5:42 PM Doug Anderson wrote: > > > > Hi, > > > > On Wed, Jan 26, 2022 at 12:25 AM Javier Martinez Canillas > > wrote: > > > > > > On 1/26/22 00:25, Doug Anderson wrote: > > > > On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas > > > > wrote: > > > > > > [snip] > > > > > > >> Should this new sysfs entry be documented in Documentation/ABI/ ? > > > > > > > > I'm not sure what the policy is here. I actually don't know that I'm > > > > too worried about this being an ABI. For the purposes of our tests > > > > then if something about this file changed (path changed or something > > > > like that) it wouldn't be a huge deal. Presumably the test itself > > > > would just "fail" in this case and that would clue us in that the ABI > > > > changed and we could adapt to whatever new way was needed to discover > > > > this. > > > > > > > > That being said, if the policy is that everything in sysfs is supposed > > > > to be ABI then I can add documentation for this... > > > > > > > > > > I also don't know the policy, hence the question. But in any case, I > > > think that it could even be done as a follow-up if is needed. > > > > Sounds good. Since it's been pretty silent and I had your review I > > pushed this to drm-misc-next. If there are comments or someone has an > > opinion documenting this as a stable ABI then please yell. > > > > 363c4c3811db drm/panel-edp: Allow querying the detected panel via sysfs > > Generally stuff for tests should be put into debugfs. We print > everything there in various files. > > sysfs is uapi, and so come with the full baggage of you need open > userspace (which for some sysfs stuff might just be a script), and > explicitly not for tests (because that just opens the door to merge > anything binary blobs might want and just slide it all in). So please > retcon at least some plausible deniability here :-) OK, fair enough. It really is just for a test. Let me post a revert then while we discuss more. If someone can add a Reviewed-by to the revert then I'll push that just so we're not in an awkward situation. https://lore.kernel.org/r/20220201092152.1.Ibc65ec6fa05017e9856ba9ef557310268429c3ce@changeid > But if it's really only for a test then maybe dumping this into a > debugfs file (we do have connector directories already) would be much > better. That doable? I did spend a little time looking at how to do this in debugfs and it wasn't at all obvious to me without plumbing in a lot of extra code, but I can spend more time on it if it's a requirement. If you think this is something that should just be easy, I certainly wouldn't say no to a pointer to what I should look at! ;-) -Doug
Re: [PATCH 00/14] Rename dma-buf-map
Hi Am 01.02.22 um 08:46 schrieb Christian König: [..] 2) If renaming, would it still keep the same entry in MAINTAINERS? Thomas suggested drivers core, but this all seem to be used mainly on drm/, with just one exception. I would just add a complete new entry for this and use Thomas as maintainer (with his permission of course) and dri as mailing list. Sure, no problem. Best regards Thomas 3) If renaming, do we have another preferred name? Nope, as Daniel said the name itself is only bikesheed. What is important is that we see this as functionality separated from the inter driver interface. Regards, Christian. thanks Lucas De Marchi But as I said, I don't really have a preference. When crossing subsystems one thing that is hard is that different people have different preferences on these things. At least squashing now is much easier than if I had to split it Try to imagine how much complain I received on going the other way in 25985edcedea6396277003854657b5f3cb31a628 with 2463 files changed, 4252 insertions(+), 4252 deletions(-) Well exactly that is perfectly fine. What you do here is applying your personal hack which is absolutely not welcomed. Regards, Christian. :) Lucas De Marchi Regards, Christian. I built this series, full config with CONFIG_COMPILE_TEST and doing: git rebase -i -x "make -j$(nproc)" I split these patches in a way that wouldn't break the build on purpose. There were a couple that I couldn't build without cross compiling: tegra and rockchip. The others were ok. I'm not really against squashing everything in one to merge, though. It will be hard on the conflicts later, but should get the job done much quicker. Lucas De Marchi Regards, Christian. Am 28.01.22 um 09:36 schrieb Lucas De Marchi: Motivation for this started in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20220126203702.1784589-1-lucas.demarchi%40intel.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C01142fa3ce484040ade008d9e51aef5d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637792726123940514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=p8rR28Hn0yMTbwy%2F7bpiGyG9fAu9kG1VUzX2MF44mcs%3Dreserved=0 when trying to extend the dma-buf-map API to cover new use cases: help a single driver with allocations and sharing code paths for IO and system memory. I'm leaving the API additions aside and first renaming the interface as requested. There are already some users in tree outside the context of dma-buf importer/exporter. So before extending the API, let's dissociate it from dma-buf. The iosys-map.h is introduced in the first patch in a way that allows the conversion of each driver to happen separately. After all the conversions are done we can remove the old one, which is the last patch. Another possible way is to squash everything and merge together, but I believe this would make much harder for review. The conversion was done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include + #include and then some files had their includes adjusted so we can build everything on each commit in this series. Also some comments were update to remove mentions to dma-buf-map. Simply doing a sed to rename didn't work as dma-buf has some APIs using the dma_buf_map prefix. Once finalized, I think most of this, if not all, could go through the drm-misc-next branch. I split i915, msm, nouveau, and radeon in their own patches in case it's preferred to take those through their own trees. Lucas De Marchi Lucas De Marchi (14): iosys-map: Introduce renamed dma-buf-map misc: fastrpc: Replace dma-buf-map with iosys-map dma-buf: Replace dma-buf-map with iosys-map media: Replace dma-buf-map with iosys-map drm/ttm: Replace dma-buf-map with iosys-map drm: Replace dma-buf-map with iosys-map in drivers drm/i915: Replace dma-buf-map with iosys-map drm/msm: Replace dma-buf-map with iosys-map drm/nouveau: Replace dma-buf-map with iosys-map drm/tegra: Replace dma-buf-map with iosys-map drm/radeon: Replace dma-buf-map with iosys-map drm: Replace dma-buf-map with iosys-map in common code Documentation: Refer to iosys-map instead of dma-buf-map dma-buf-map: Remove API in favor of iosys-map Documentation/driver-api/dma-buf.rst
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
On Mon, Jan 31, 2022 at 9:39 PM Simon Ser wrote:
> On Monday, January 31st, 2022 at 21:36, Simon Ser wrote:
>
> > This driver only advertises XRGB in ssd1307_formats. It would be nice to
> > expose R8 as well so that user-space can directly produce suitable buffers.
> > It would also be nice to have some kind of preferred format, so that
> > user-space
> > knows R8 is preferred over XRGB.
>
> Hm, since the format used by the hw is actually R1, adding that to
> drm_fourcc.h
> would be even better.
What's the story with the Rn formats?
The comments say "n bpp Red", while this is a monochrome (even
inverted) display?
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] dt-bindings: ltk050h3146w: replace Heiko Stuebner by myself as maintainer
From: Quentin Schulz Heiko does not work at Theobroma Systems anymore and the boards using those panels are downstream, maintained internally by the company, so let's relieve Heiko of maintainership duties. Cc: Heiko Stuebner Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- .../devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml index 63d2a00348e9..a40ab887ada7 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel maintainers: - - Heiko Stuebner + - Quentin Schulz allOf: - $ref: panel-common.yaml# -- 2.34.1
[PATCH 2/3] drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant
From: Klaus Goger
The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
controller is a Himax HX8394-F, slightly different from LTK050H3146W by
its init sequence, mode details and mode flags.
Cc: Quentin Schulz
Signed-off-by: Klaus Goger
Signed-off-by: Quentin Schulz
---
.../drm/panel/panel-leadtek-ltk050h3146w.c| 87 +++
1 file changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
index 67eb474e28c6..3be815c3be68 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -253,6 +253,89 @@ struct ltk050h3146w *panel_to_ltk050h3146w(struct
drm_panel *panel)
return ret; \
} while (0)
+static int ltk050h3148w_init_sequence(struct ltk050h3146w *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor without much
+* documentation.
+*/
+ dsi_dcs_write_seq(dsi, 0xb9, 0xff, 0x83, 0x94);
+ dsi_dcs_write_seq(dsi, 0xb1, 0x50, 0x15, 0x75, 0x09, 0x32, 0x44, 0x71,
+ 0x31, 0x55, 0x2f);
+ dsi_dcs_write_seq(dsi, 0xba, 0x63, 0x03, 0x68, 0x6b, 0xb2, 0xc0);
+ dsi_dcs_write_seq(dsi, 0xd2, 0x88);
+ dsi_dcs_write_seq(dsi, 0xb2, 0x00, 0x80, 0x64, 0x10, 0x07);
+ dsi_dcs_write_seq(dsi, 0xb4, 0x05, 0x70, 0x05, 0x70, 0x01, 0x70, 0x01,
+ 0x0c, 0x86, 0x75, 0x00, 0x3f, 0x01, 0x74, 0x01, 0x74,
+ 0x01, 0x74, 0x01, 0x0c, 0x86);
+ dsi_dcs_write_seq(dsi, 0xd3, 0x00, 0x00, 0x07, 0x07, 0x40, 0x1e, 0x08,
+ 0x00, 0x32, 0x10, 0x08, 0x00, 0x08, 0x54, 0x15, 0x10,
+ 0x05, 0x04, 0x02, 0x12, 0x10, 0x05, 0x07, 0x33, 0x34,
+ 0x0c, 0x0c, 0x37, 0x10, 0x07, 0x17, 0x11, 0x40);
+ dsi_dcs_write_seq(dsi, 0xd5, 0x19, 0x19, 0x18, 0x18, 0x1b, 0x1b, 0x1a,
+ 0x1a, 0x04, 0x05, 0x06, 0x07, 0x00, 0x01, 0x02, 0x03,
+ 0x20, 0x21, 0x18, 0x18, 0x22, 0x23, 0x18, 0x18, 0x18,
+ 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
+ 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
+ 0x18);
+dsi_dcs_write_seq(dsi, 0xd6, 0x18, 0x18, 0x19, 0x19, 0x1b, 0x1b, 0x1a,
+ 0x1a, 0x03, 0x02, 0x01, 0x00, 0x07, 0x06, 0x05, 0x04,
+ 0x23, 0x22, 0x18, 0x18, 0x21, 0x20, 0x18, 0x18, 0x18,
+ 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
+ 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
+ 0x18);
+ dsi_dcs_write_seq(dsi, 0xe0, 0x00, 0x03, 0x09, 0x11, 0x11, 0x14, 0x18,
+ 0x16, 0x2e, 0x3d, 0x4d, 0x4d, 0x58, 0x6c, 0x72, 0x78,
+ 0x88, 0x8b, 0x86, 0xa4, 0xb2, 0x58, 0x55, 0x59, 0x5b,
+ 0x5d, 0x60, 0x64, 0x7f, 0x00, 0x03, 0x09, 0x0f, 0x11,
+ 0x14, 0x18, 0x16, 0x2e, 0x3d, 0x4d, 0x4d, 0x58, 0x6d,
+ 0x73, 0x78, 0x88, 0x8b, 0x87, 0xa5, 0xb2, 0x58, 0x55,
+ 0x58, 0x5b, 0x5d, 0x61, 0x65, 0x7f);
+ dsi_dcs_write_seq(dsi, 0xcc, 0x0b);
+ dsi_dcs_write_seq(dsi, 0xc0, 0x1f, 0x31);
+ dsi_dcs_write_seq(dsi, 0xb6, 0xc4, 0xc4);
+ dsi_dcs_write_seq(dsi, 0xbd, 0x01);
+ dsi_dcs_write_seq(dsi, 0xb1, 0x00);
+ dsi_dcs_write_seq(dsi, 0xbd, 0x00);
+ dsi_dcs_write_seq(dsi, 0xc6, 0xef);
+ dsi_dcs_write_seq(dsi, 0xd4, 0x02);
+ dsi_dcs_write_seq(dsi, 0x11);
+ dsi_dcs_write_seq(dsi, 0x29);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi, 1);
+ if (ret < 0) {
+ dev_err(ctx->dev, "failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ msleep(60);
+
+ return 0;
+}
+
+static const struct drm_display_mode ltk050h3148w_mode = {
+ .hdisplay = 720,
+ .hsync_start= 720 + 12,
+ .hsync_end = 720 + 12 + 6,
+ .htotal = 720 + 12 + 6 + 24,
+ .vdisplay = 1280,
+ .vsync_start= 1280 + 9,
+ .vsync_end = 1280 + 9 + 2,
+ .vtotal = 1280 + 9 + 2 + 16,
+ .clock = 59756,
+ .width_mm = 62,
+ .height_mm = 110,
+};
+
+static const struct ltk050h3146w_desc ltk050h3148w_data = {
+ .mode = _mode,
+ .init = ltk050h3148w_init_sequence,
+ .mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+};
+
static int ltk050h3146w_init_sequence(struct ltk050h3146w *ctx)
{
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
@@ -657,6 +740,10 @@ static const struct of_device_id ltk050h3146w_of_match[] =
{
[PATCH 3/3] dt-bindings: ltk050h3146w: add compatible for LTK050H3148W-CTA6 variant
From: Quentin Schulz The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving controller is a Himax HX8394-F, slightly different from LTK050H3146W by its init sequence, mode details and mode flags. Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- .../devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml index 3715882b63b6..63d2a00348e9 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -17,6 +17,7 @@ properties: enum: - leadtek,ltk050h3146w - leadtek,ltk050h3146w-a2 + - leadtek,ltk050h3148w reg: true backlight: true reset-gpios: true -- 2.34.1
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
On Tuesday, February 1st, 2022 at 09:43, Geert Uytterhoeven wrote: > Does there exist another simple test program for showing something > using the DRM API? If you're fine with going low-level, there's tentative [1] which can apply an arbitrary KMS state. See for instance [2] for basic mode-setting. [1]: https://git.sr.ht/~emersion/tentative [2]: https://git.sr.ht/~emersion/tentative/tree/master/item/examples/modeset
Re: [PATCH 4/4] MAINTAINERS: Add entry for Solomon SSD1307 OLED displays DRM driver
On Mon, Jan 31, 2022 at 09:15:37PM +0100, Javier Martinez Canillas wrote: > To make sure that tools like the get_maintainer.pl script will suggest > to Cc me if patches are posted for this driver. > > Also include the Device Tree binding for the old ssd1307fb fbdev driver > since the new DRM driver was made compatible with the existing binding. Dunno why you have patches 3 and 4 missed references (in terms of email thread). > +DRM DRIVER FOR SOLOMON SSD1307 OLED DISPLAYS > +M: Javier Martinez Canillas > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml > +F: drivers/gpu/drm/tiny/ssd1307.c I think it makes sense to add ssd1307fb as well. At least you may point out people patching old driver about new one until it's gone completely. -- With Best Regards, Andy Shevchenko
Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.
you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - /*
> - * No more hw acceleration for fbcon.
> - *
> - * FIXME: Garbage collect all the now dead code after sufficient time
> - * has passed.
> - */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
>* ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> + info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + p->scrollmode = SCROLL_REDRAW;
> +#endif
> }
>
> #define PITCH(w) (((w) + 7) >> 3)
>
still reviewing the other patches...
Helge
Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On 1/31/22 22:05, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. Yes, agreed. Acked-by: Helge Deller Since the code is used by drm and existing fbdev drivers, please just make sure to not break fbdev... Thanks! Helge > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea3e6c914384..49809eaa3096 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7573,6 +7573,12 @@ S: Maintained > W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > +FRAMEBUFFER CORE > +M: Daniel Vetter > +F: drivers/video/fbdev/core/ > +S: Odd Fixes > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > FRAMEBUFFER LAYER > M: Helge Deller > L: linux-fb...@vger.kernel.org >
Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On Tue, Feb 1, 2022 at 11:16 AM Helge Deller wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
Duh :-(
But before we dig into details I think the big picture would be
better. I honestly don't like the #ifdef pile here that much. I wonder
whether your approach, also with GETVX/YRES adjusted somehow, wouldn't
look cleaner? Like I said in the cover letter I got mostly distracted
with fbcon locking last week, not really with this one here at all, so
maybe going with your 4 (or 2 if we squash them like I did here)
patches is neater?
Cheers, Daniel
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 2ff90061c7f3..39dc18a5de86 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - /*
> > - * No more hw acceleration for fbcon.
> > - *
> > - * FIXME: Garbage collect all the now dead code after sufficient time
> > - * has passed.
> > - */
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> > + !(info->flags & FBINFO_HWACCEL_DISABLED))
> > + p->scrollmode = SCROLL_MOVE;
> > + else /* default to something safe */
> > + p->scrollmode = SCROLL_REDRAW;
> > +#else
> > p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >
> > /*
> >* ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display
> > *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > + int cap = info->flags;
> > + u16 t = 0;
> > + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > + info->fix.xpanstep);
> > + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > + divides(ypan, vc->vc_font.height) && vyres > yres;
> > + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > + divides(ywrap, vc->vc_font.height) &&
> > + divides(vc->vc_font.height, vyres) &&
> > + divides(vc->vc_font.height, yres);
> > + int reading_fast = cap & FBINFO_READS_FAST;
> > + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> > + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> >
> > p->vrows = vyres/fh;
> > if (yres > (fh * (vc->vc_rows + 1)))
> > p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> > if ((yres % fh) && (vyres % fh < yres % fh))
> > p->vrows--;
> > +
> > + if (good_wrap || good_pan) {
> > + if (reading_fast || fast_copyarea)
> > + p->scrollmode = good_wrap ?
> > + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> > + else
> > + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> > + SCROLL_PAN_REDRAW;
> > + } else {
> > + if (reading_fast || (fast_copyarea && !fast_imageblit))
> > + p->scrollmode = SCROLL_MOVE;
> > + else
> > + p->scrollmode = SCROLL_REDRAW;
> > + }
> > +
> > +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + p->scrollmode = SCROLL_REDRAW;
> > +#endif
> > }
> >
> > #define PITCH(w) (((w) + 7) >> 3)
> >
>
> still reviewing the other patches...
>
> Helge
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
Hello Geert, On 2/1/22 09:43, Geert Uytterhoeven wrote: > Hi Javier, > > On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas > wrote: >> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306, >> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver. > > Thanks for your series! > > I'll give it a try on an Adafruit FeatherWing 128x32 OLED, connected > to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V > softcore. > Awesome! let me know if you have any issues. I keep an update-to-date version at https://github.com/martinezjavier/linux/tree/ssd1307 >> Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest >> (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes: >> >> ./fbtest -f /dev/fb1 >> Using drawops cfb32 (32 bpp packed pixels) >> Available visuals: >> Monochrome >> Grayscale 256 >> Truecolor 8:8:8:0 > > Oh, fake 32-bpp truecolor ;-) > Yes :) that's what the repaper drivers does to have maximum compatibility with existing user-space and I followed the same. > Does it run modetest, too? > It does, yes. And for example `modetest -M ssd1307` will print all the info about encoders, connectors, CRTs, etc. > I'm trying to get modetest working on my atari DRM driver. > Comparing to the cirrus driver doesn't help much, as modetest doesn't > seem to work with the cirrus driver (modified to not do hardware > access, as I don't have cirrus hardware): > > # modetest -M cirrus -s 31:1024x768-60Hz > setting mode 1024x768-60.00Hz on connectors 31, crtc 34 > failed to set gamma: Function not implemented > # modetest -M ssd1307 -c -s 31:128x64-0.12Hz ... setting mode 128x64-0.12Hz on connectors 31, crtc 33 failed to set gamma: Function not implemented this seems to be a bug in modetest. I found a patch posted some time ago but never landed: https://www.spinics.net/lists/dri-devel/msg251356.html > Does there exist another simple test program for showing something > using the DRM API? > I tested with plymouth and gdm that make use of the DRM API, they do start and I see something on the screen but don't really handle that well the fact that's a 128x64 resolution. I didn't test with more DRM programs because was mostly interested in making sure that the fbdev emulation was working correctly. Noticed that Simon shared some simple examples, I'll give them a try. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH v5 15/19] drm/i915/dg2: Add DG2 unified compression
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the actual
compression algorithm is different from any previous platform; as such,
we need a new framebuffer modifier to represent buffers in this format,
but otherwise we can re-use the existing gen12 compression driver logic.
v2:
Display version fix [Imre]
Signed-off-by: Matt Roper
cc: Radhakrishna Sripada
Signed-off-by: Mika Kahola (v2)
cc: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_fb.c | 13 ++
.../drm/i915/display/skl_universal_plane.c| 26 ---
include/uapi/drm/drm_fourcc.h | 22
3 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 94c57facbb46..4d4d01963f15 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -141,6 +141,14 @@ struct intel_modifier_desc {
static const struct intel_modifier_desc intel_modifiers[] = {
{
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
+ .display_ver = { 13, 13 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
+ .display_ver = { 13, 13 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
+ }, {
.modifier = I915_FORMAT_MOD_4_TILED,
.display_ver = { 13, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_4,
@@ -550,6 +558,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
case I915_FORMAT_MOD_4_TILED:
/*
* Each 4K tile consists of 64B(8*8) subtiles, with
@@ -752,6 +762,9 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ return 16 * 1024;
default:
MISSING_CASE(fb->modifier);
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 5299dfe68802..c38ae0876c15 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -764,6 +764,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_Y;
case I915_FORMAT_MOD_4_TILED:
return PLANE_CTL_TILED_4;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ return PLANE_CTL_TILED_4 |
+ PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ return PLANE_CTL_TILED_4 |
+ PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2094,6 +2102,10 @@ static bool gen12_plane_has_mc_ccs(struct
drm_i915_private *i915,
if (IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
return false;
+ /* Wa_14013215631 */
+ if (IS_DG2_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
+ return false;
+
return plane_id < PLANE_SPRITE4;
}
@@ -2335,9 +2347,10 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
case PLANE_CTL_TILED_Y:
plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
- fb->modifier = DISPLAY_VER(dev_priv) >= 12 ?
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS :
- I915_FORMAT_MOD_Y_TILED_CCS;
+ if (DISPLAY_VER(dev_priv) >= 12)
+ fb->modifier =
I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS;
+ else
+ fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS;
else
@@ -2345,7 +2358,12 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
[PATCH v5 16/19] uapi/drm/dg2: Introduce format modifier for DG2 clear color
From: Mika Kahola
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
v2:
Display version is fixed. [Imre]
KDoc is enhanced for cc modifier. [Nanley & Lionel]
Signed-off-by: Mika Kahola
cc: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_fb.c| 8
drivers/gpu/drm/i915/display/skl_universal_plane.c | 9 -
include/uapi/drm/drm_fourcc.h | 10 ++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 4d4d01963f15..3df6ef5ffec5 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -144,6 +144,12 @@ static const struct intel_modifier_desc intel_modifiers[]
= {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
.display_ver = { 13, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
+ .display_ver = { 13, 13 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 |
INTEL_PLANE_CAP_CCS_RC_CC,
+
+ .ccs.cc_planes = BIT(1),
}, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
.display_ver = { 13, 13 },
@@ -559,6 +565,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
else
return 512;
case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
case I915_FORMAT_MOD_4_TILED:
/*
@@ -763,6 +770,7 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
return 16 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index c38ae0876c15..b4dced1907c5 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -772,6 +772,8 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_4 |
PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
PLANE_CTL_CLEAR_COLOR_DISABLE;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
+ return PLANE_CTL_TILED_4 |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2358,10 +2360,15 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
break;
case PLANE_CTL_TILED_YF: /* aka PLANE_CTL_TILED_4 on XE_LPD+ */
if (HAS_4TILE(dev_priv)) {
- if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
+ u32 rc_mask = PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
+
+ if ((val & rc_mask) == rc_mask)
fb->modifier =
I915_FORMAT_MOD_4_TILED_DG2_RC_CCS;
else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
fb->modifier =
I915_FORMAT_MOD_4_TILED_DG2_MC_CCS;
+ else if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
+ fb->modifier =
I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC;
else
fb->modifier = I915_FORMAT_MOD_4_TILED;
} else {
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b8fb7b44c03c..697614ea4b84 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -605,6 +605,16 @@ extern "C" {
*/
#define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
+/*
+ * Intel color control surfaces (CCS) for DG2 clear color render compression.
+ *
+ * DG2 uses a unified compression format for clear color render compression.
+ * The general layout is a tiled layout using 4Kb tiles i.e. Tile4 layout.
+ *
+ * Fast clear color value expected by HW is located in fb at offset 0 of
plane#1
+ */
+#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
[PATCH v5 13/19] drm/i915: Introduce new Tile 4 format
From: Stanislav Lisovskiy
This tiling layout uses 4KB tiles in a row-major layout. It has the same
shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
only differs from Tile Y at the 256B granularity in between. At this
granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape
of 64B x 8 rows.
Reviewed-by: Imre Deak
Acked-by: Nanley Chery
Signed-off-by: Stanislav Lisovskiy
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index fc0c1454d275..b73fe6797fc3 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -572,6 +572,17 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
+/*
+ * Intel Tile 4 layout
+ *
+ * This is a tiled layout using 4KB tiles in a row-major layout. It has the
same
+ * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
+ * only differs from Tile Y at the 256B granularity in between. At this
+ * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a
shape
+ * of 64B x 8 rows.
+ */
+#define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
On Tue, 1 Feb 2022 10:49:03 +0100 Javier Martinez Canillas wrote: > On 2/1/22 09:38, Daniel Vetter wrote: > > On Tue, Feb 1, 2022 at 9:34 AM Simon Ser wrote: > >> > >> On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven > >> wrote: > >> > >>> What's the story with the Rn formats? > >>> > >>> The comments say "n bpp Red", while this is a monochrome (even > >>> inverted) display? > >> > >> I don't think the color matters that much. "Red" was picked just because > >> it was > >> an arbitrary color, to make the difference with e.g. C8. Or am I mistaken? > >> > > > > The red comes from gl, where with shaders it really doesn't matter > > what meaning you attach to channels, but really just how many you > > have. So 2-channel formats are called RxGx, 3-channel RxGxBx, > > 4-channel RxGxBxAx and single-channel Rx. And we use drm_fourcc for > > interop in general, hence why these exist. > > > > We should probably make a comment that this really isn't a red channel > > when used for display it's a greyscale/intensity format. Aside from > > that documentation gap I think reusing Rx formats for > > greyscale/intensity for display makes perfect sense. > > -Daniel > > To sump up the conversation in the #dri-devel channel, these drivers > should support the following formats: > > 1) Dx (Daniel suggested that for darkness, but inverted mono) Did you consider format C1 instead? To my understanding, the C formats are paletted, which would also fit very nicely semantically. You have an enumerated list of pixel values and each of them produces some arbitrary color on screen. This would fit e.g. blue/white LCD panels nicely. The little problem there is the palette. C8 format is traditionally translated to RGB triplets through GAMMA LUT. Therefore the display itself is still three-channel, it's just the framebuffer format that is single-channel. But now, we are dealing with truly paletted displays. Furthermore, the palette is fixed, ingrained in the panel hardware. So we would probably need a new KMS property for the fixed palette of the panel. What would it be called? Would it be a connector property? The property would be a read-only blob, an array that maps Cx values to "colors". How do we represent "colors"? How do we accommodate C1, C2, C4 and C8 with the same blob? Since the blob is a mapping from color index to "color", and the array in the blob has N entries, we could simply say that Cx integer value is the color index. If the Cx you use does not go up to N, then you miss some colors. If the Cx you use can go higher than N, then Cx values >= N will clamp to N-1, for example. Of course, if your panel palette has only 4 entries, you can expose C1 and C2 and have no reason to expose C4 or C8, avoiding the Cx >= N issue. How do we define the array contents then, the "colors"... plain old RGB triplets do not mean much[1], but that would be better than nothing. I also suppose that people would not be keen on seeing something like CIE 1931 XYZ or Lab values, even though those would probably have the most useful definition. Coming up with those values properly would require a colorimeter. As a compromise, maybe we could use an RGB triplet, and assume sRGB SDR color space and transfer function, just like we do with all displays whether they are that or not. If someone needs to know better, then they can profile the display. sRGB triplets would likely give enough intuition to what color the indices result in, that it could be used in automated color conversions or quantizations from larger color spaces like sRGB with some rough degree of color similarity. It is a lot of hassle, but it would have a clear benefit: userspace would know very well how the display behaves (what colors it shows, roughly), and you could use Cx formats to drive a panel in its "native" format. Possible problems are around interactions with the old GAMMA property, which is traditionally used for the C8 palette. But if you have a fixed-palette panel, then maybe you wouldn't expose GAMMA property on the CRTC at all? I have no idea how this would map to fbdev API though. [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/pixels_color.md Thanks, pq > 2) Rx (single-channel for grayscale) > 3) RxGxBxAx (4-channel fake 32-bpp truecolor) > > The format preference will be in that order, so if user-space is able > to use Dx then there won't be a need for any conversion and just the > native format will be used. > > If using Rx then only a Rx -> Dx conversion will happen and the last > format will require the less performant RxGxBxAx -> Rx -> Dx path. > > But we still need RxGxBxAx as a fallback for compatibility with the > existing user-space, so all this could be done as a follow-up as an > optimization and shouldn't block monochromatic panel drivers IMO. > > Best regards, pgpbE0gGk1VXT.pgp Description: OpenPGP digital signature
[PATCH v5 14/19] drm/i915/dg2: Tile 4 plane format support
From: Stanislav Lisovskiy
Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Moved Tile4 assocating struct for modifier/display to
the beginning(Imre Deak)
- Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
checks(Imre Deak)
- Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
(Imre Deak)
v3: - Rebased patch on top of new changes related to plane_caps.
- Added static assert to check that PLANE_CTL_TILING_YF
matches PLANE_CTL_TILING_4(Nanley Chery)
- Fixed naming and layout description for Tile 4 in drm uapi
header(Nanley Chery)
v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
Reviewed-by: Imre Deak
Cc: Matt Roper
Cc: Maarten Lankhorst
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Matt Roper
Signed-off-by: Juha-Pekka Heikkilä
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
drivers/gpu/drm/i915/display/intel_fb.h | 1 +
drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
.../drm/i915/display/intel_plane_initial.c| 1 +
.../drm/i915/display/skl_universal_plane.c| 23 ---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
11 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 75de794185b2..189767cef356 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7737,6 +7737,7 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state, struct int
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+ case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg_kms(>drm,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 23cfe2e5ce2a..94c57facbb46 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -135,11 +135,16 @@ struct intel_modifier_desc {
INTEL_PLANE_CAP_CCS_MC)
#define INTEL_PLANE_CAP_TILING_MASK(INTEL_PLANE_CAP_TILING_X | \
INTEL_PLANE_CAP_TILING_Y | \
-INTEL_PLANE_CAP_TILING_Yf)
+INTEL_PLANE_CAP_TILING_Yf | \
+INTEL_PLANE_CAP_TILING_4)
#define INTEL_PLANE_CAP_TILING_NONE0
static const struct intel_modifier_desc intel_modifiers[] = {
{
+ .modifier = I915_FORMAT_MOD_4_TILED,
+ .display_ver = { 13, 13 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4,
+ }, {
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
.display_ver = { 12, 13 },
.plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
@@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED:
+ /*
+* Each 4K tile consists of 64B(8*8) subtiles, with
+* same shape as Y Tile(i.e 4*16B OWords)
+*/
+ return 128;
case I915_FORMAT_MOD_Y_TILED_CCS:
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
@@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
return I915_TILING_Y;
case INTEL_PLANE_CAP_TILING_X:
return I915_TILING_X;
+ case INTEL_PLANE_CAP_TILING_4:
case INTEL_PLANE_CAP_TILING_Yf:
case INTEL_PLANE_CAP_TILING_NONE:
return I915_TILING_NONE;
@@ -737,6 +749,7 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
b/drivers/gpu/drm/i915/display/intel_fb.h
index ba9df8986c1e..12386f13a4e0 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -27,6 +27,7 @@ struct intel_plane_state;
#define INTEL_PLANE_CAP_TILING_X BIT(3)
#define
[PATCH v5 17/19] drm/i915/dg2: Flat CCS Support
From: Anshuman Gupta
DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displayable surfaces must use tile4 format.
HAS: 1407880786
B.Spec : 7655
B.Spec : 53902
Cc: Mika Kahola
Signed-off-by: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fb.c | 32 +--
.../drm/i915/display/skl_universal_plane.c| 16 ++
3 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 189767cef356..2828ae612179 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8588,7 +8588,9 @@ static void
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
/*
* The layout of the fast clear color value expected by HW
-* (the DRM ABI requiring this value to be located in fb at
offset 0 of plane#2):
+* (the DRM ABI requiring this value to be located in fb at
+* offset 0 of cc plane, plane #2 previous generations or
+* plane #1 for flat ccs):
* - 4 x 4 bytes per-channel value
* (in surface type specific float/int format provided by the
fb user)
* - 8 bytes native color value used by the display
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 3df6ef5ffec5..e94923e9dbb1 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -107,6 +107,21 @@ static const struct drm_format_info gen12_ccs_cc_formats[]
= {
.hsub = 1, .vsub = 1, .has_alpha = true },
};
+static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+};
+
struct intel_modifier_desc {
u64 modifier;
struct {
@@ -150,6 +165,8 @@ static const struct intel_modifier_desc intel_modifiers[] =
{
.plane_caps = INTEL_PLANE_CAP_TILING_4 |
INTEL_PLANE_CAP_CCS_RC_CC,
.ccs.cc_planes = BIT(1),
+
+ FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
}, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
.display_ver = { 13, 13 },
@@ -399,17 +416,13 @@ bool intel_fb_plane_supports_modifier(struct intel_plane
*plane, u64 modifier)
static bool format_is_yuv_semiplanar(const struct intel_modifier_desc *md,
const struct drm_format_info *info)
{
- int yuv_planes;
-
if (!info->is_yuv)
return false;
- if (plane_caps_contain_any(md->plane_caps, INTEL_PLANE_CAP_CCS_MASK))
- yuv_planes = 4;
+ if (hweight8(md->ccs.planar_aux_planes) == 2)
+ return info->num_planes == 4;
else
- yuv_planes = 2;
-
- return info->num_planes == yuv_planes;
+ return info->num_planes == 2;
}
/**
@@ -534,12 +547,13 @@ static unsigned int gen12_ccs_aux_stride(struct
intel_framebuffer *fb, int ccs_p
int skl_main_to_aux_plane(const struct drm_framebuffer *fb, int main_plane)
{
+ const struct intel_modifier_desc *md = lookup_modifier(fb->modifier);
struct drm_i915_private *i915 = to_i915(fb->dev);
- if (intel_fb_is_ccs_modifier(fb->modifier))
+ if (md->ccs.packed_aux_planes | md->ccs.planar_aux_planes)
return main_to_ccs_plane(fb, main_plane);
else if (DISPLAY_VER(i915) < 11 &&
-intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+format_is_yuv_semiplanar(md, fb->format))
return 1;
else
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index b4dced1907c5..18e50583abaa 100644
---
[PATCH v5 18/19] drm/i915/Flat-CCS: Document on Flat-CCS memory compression
Documents the Flat-CCS feature and kernel handling required along with
modifiers used.
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3e1cf224cdf0..5bdab0b3c735 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -596,6 +596,53 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
}
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ *
+ *
+ * Flat-CCS Modifiers for different compression formats
+ *
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat
CCS
+ * render compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is
+ * used. Render compression uses 128 byte compression blocks
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS
+ * media compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is
+ * used. Media compression uses 256 byte compression blocks.
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat
+ * CCS clear color render compression formats. Unified compression format for
+ * clear color render compression. The genral layout is a tiled layout using
+ * 4Kb tiles i.e Tile4 layout.
+ */
+
static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
{
/* Mask the 3 LSB to use the PPGTT address space */
--
2.20.1
[PATCH v5 19/19] Doc/gpu/rfc/i915: i915 DG2 flat-CCS uAPI
Details of the Flat-CCS getting added as part of DG2 enabling and its implicit impact on the uAPI. Signed-off-by: Ramalingam C cc: Daniel Vetter cc: Matthew Auld cc: Simon Ser cc: Pekka Paalanen Cc: Jordan Justen Cc: Kenneth Graunke Cc: mesa-...@lists.freedesktop.org Cc: Tony Ye Cc: Slawomir Milczarek --- Documentation/gpu/rfc/i915_dg2.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/gpu/rfc/i915_dg2.rst b/Documentation/gpu/rfc/i915_dg2.rst index f4eb5a219897..9d28b1812bc7 100644 --- a/Documentation/gpu/rfc/i915_dg2.rst +++ b/Documentation/gpu/rfc/i915_dg2.rst @@ -23,3 +23,10 @@ handling the 64k page size. .. kernel-doc:: include/uapi/drm/i915_drm.h :functions: drm_i915_gem_create_ext + + +Flat CCS support for lmem += + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c +:doc: Flat-CCS - Memory compression for Local memory -- 2.20.1
Re: [PATCH] drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check()
On 2/1/22 12:03, Christoph Niedermaier wrote:
If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the function
drm_bus_flags_from_videomode() e.g. called in the
panel-simple driver this flag got into the bus flags,
but then in imx_pd_bridge_atomic_check() the bus flag
check failed and will not initialize the display. The
original commit fe141cedc433 does not explain why this
check was introduced. So remove the bus flags check,
because it stops the initialization of the display with
valid bus flags.
Fixes: fe141cedc433 ("drm/imx: pd: Use bus format/flags provided by the bridge when
available")
Signed-off-by: Christoph Niedermaier
Cc: Marek Vasut
Cc: Philipp Zabel
Cc: David Airlie
Cc: Daniel Vetter
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/imx/parallel-display.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index a8aba0141ce7..06cb1a59b9bc 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -217,14 +217,6 @@ static int imx_pd_bridge_atomic_check(struct drm_bridge
*bridge,
if (!imx_pd_format_supported(bus_fmt))
return -EINVAL;
- if (bus_flags &
- ~(DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_DE_HIGH |
- DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
- DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)) {
- dev_warn(imxpd->dev, "invalid bus_flags (%x)\n", bus_flags);
- return -EINVAL;
- }
+CC Boris
Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20220201/202202011603.vczwpod7-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/245da5ab93b17c0cf1521713d5bde655a72efb65
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 245da5ab93b17c0cf1521713d5bde655a72efb65
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/staging/olpc_dcon/olpc_dcon.c: In function 'dcon_probe':
>> drivers/staging/olpc_dcon/olpc_dcon.c:605:6: error: 'num_registered_fb'
>> undeclared (first use in this function); did you mean 'WB_registered'?
605 | if (num_registered_fb < 1) {
| ^
| WB_registered
drivers/staging/olpc_dcon/olpc_dcon.c:605:6: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/staging/olpc_dcon/olpc_dcon.c:610:17: error: 'registered_fb'
>> undeclared (first use in this function)
610 | dcon->fbinfo = registered_fb[0];
| ^
vim +605 drivers/staging/olpc_dcon/olpc_dcon.c
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 584
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 585 static int
dcon_probe(struct i2c_client *client, const struct i2c_device_id *id)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 586 {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 587 struct dcon_priv *dcon;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 588 int rc, i, j;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 589
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 590 if (!pdata)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 591 return -ENXIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 592
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 593 dcon =
kzalloc(sizeof(*dcon), GFP_KERNEL);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 594 if (!dcon)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 595 return -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 596
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 597 dcon->client = client;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 598
init_waitqueue_head(>waitq);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 599
INIT_WORK(>switch_source, dcon_source_switch);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 600
dcon->reboot_nb.notifier_call = dcon_reboot_notify;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 601
dcon->reboot_nb.priority = -1;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 602
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 603
i2c_set_clientdata(client, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 604
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @605 if (num_registered_fb <
1) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 606
dev_err(>dev, "DCON driver requires a registered fb\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 607 rc = -EIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 608 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 609 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @610 dcon->fbinfo =
registered_fb[0];
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 611
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 612 rc = dcon_hw_init(dcon,
1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 613 if (rc)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 614 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 615
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 616 /* Add the DCON device
*/
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 617
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 618 dcon_device =
platform_device_alloc("dcon", -1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 619
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 620 if (!dcon_device)
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
Hi Javier,
On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
Thanks for your series!
I'll give it a try on an Adafruit FeatherWing 128x32 OLED, connected
to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V
softcore.
> Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
> (https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes:
>
> ./fbtest -f /dev/fb1
> Using drawops cfb32 (32 bpp packed pixels)
> Available visuals:
> Monochrome
> Grayscale 256
> Truecolor 8:8:8:0
Oh, fake 32-bpp truecolor ;-)
Does it run modetest, too?
I'm trying to get modetest working on my atari DRM driver.
Comparing to the cirrus driver doesn't help much, as modetest doesn't
seem to work with the cirrus driver (modified to not do hardware
access, as I don't have cirrus hardware):
# modetest -M cirrus -s 31:1024x768-60Hz
setting mode 1024x768-60.00Hz on connectors 31, crtc 34
failed to set gamma: Function not implemented
Does there exist another simple test program for showing something
using the DRM API?
Thanks!
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
Re: [PATCH v11] drm/bridge: add it6505 driver
Il 31/01/22 19:36, Robert Foss ha scritto:
On Mon, 31 Jan 2022 at 17:55, Hsin-Yi Wang wrote:
On Tue, Feb 1, 2022 at 12:37 AM Robert Foss wrote:
On Thu, 20 Jan 2022 at 16:25, AngeloGioacchino Del Regno
wrote:
Il 14/01/22 10:14, allen ha scritto:
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
From: Allen Chen
Tested-by: Hsin-yi Wang
Signed-off-by: Hermes Wu
Signed-off-by: Allen Chen
---
v10 -> v11 : remove drm_bridge_new_crtc_state
---
drivers/gpu/drm/bridge/Kconfig |8 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ite-it6505.c | 3352 +++
3 files changed, 3361 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
...snip...
+static const struct of_device_id it6505_of_match[] = {
+ { .compatible = "ite,it6505" },
+ { }
+};
If you want to have a DT compatible and DT properties, you have to also add
dt-bindings (yaml) for this driver, otherwise, any SoC/device DT will fail
the dt binding check So, please, add that.
Let me second this. A dt-binding is needed for this driver to be
complete, it functions as both documentation and a way to test the DTS
that use this device, so it is really important.
The binding seems to be accepted before the driver:
https://elixir.bootlin.com/linux/v5.16.4/source/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
I completely missed that. In that case we're only missing the
reviewed-by tag from someone.
You have mine... the intention was to give a Reviewed-by, not a Acked-by - I'm
sorry for that, I was sending more than one email and the wrong tag slipped
through.
So, please change my Acked-by tag to
Reviewed-by: AngeloGioacchino Del Regno
For the driver by itself, though:
Acked-by: AngeloGioacchino Del Regno
+
+static struct i2c_driver it6505_i2c_driver = {
+ .driver = {
+ .name = "it6505",
+ .of_match_table = it6505_of_match,
+ .pm = _bridge_pm_ops,
+ },
+ .probe = it6505_i2c_probe,
+ .remove = it6505_i2c_remove,
+ .shutdown = it6505_shutdown,
+ .id_table = it6505_id,
+};
+
+module_i2c_driver(it6505_i2c_driver);
+
+MODULE_AUTHOR("Allen Chen ");
+MODULE_DESCRIPTION("IT6505 DisplayPort Transmitter driver");
+MODULE_LICENSE("GPL v2");
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
On 31/01/2022 22:27, Stephen Rothwell wrote:
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/i915_vma.c: In function 'i915_vma_bind':
drivers/gpu/drm/i915/i915_vma.c:451:25: error: 'ret' undeclared (first use in
this function); did you mean 'net'?
451 | ret =
i915_gem_object_wait_moving_fence(vma->obj, true);
| ^~~
| net
Caused by commit
2e872d87cbf2 ("drm/i915: delete shadow "ret" variable")
I have reverted that commit for today.
Dropping was the right call - I have since removed it from
drm-intel-fixes as well.
Root cause was a bad Fixes: tag in that patch which caused it to be
wrongly cherry-picked and I did not build test before pushing.
We can't edit the wrong Fixes: tag now, so for future reference only,
2e872d87cbf2 ("drm/i915: delete shadow "ret" variable") should not be
backported to 5.17 by anyone.
Wrong tag:
Fixes: f6c466b84cfa ("drm/i915: Add support for moving fence waiting")
Correct tag should have been:
Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Regards,
Tvrtko
Re: [PATCH 3/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
Hi Javier,
please see comments and questions below.
Am 31.01.22 um 21:29 schrieb Javier Martinez Canillas:
Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
controllers that can be programmed via an I2C interface. This is a port
of the ssd1307fb driver that already supports these devices.
A Device Tree binding is not added because the DRM driver is compatible
with the existing binding for the ssd1307fb driver.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/Kconfig | 12 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ssd1307.c | 976 +
3 files changed, 989 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ssd1307.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 712e0004e96e..25c9c013bcda 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -157,6 +157,18 @@ config TINYDRM_REPAPER
If M is selected the module will be called repaper.
+config TINYDRM_SSD1307
TINYDRM is so 2010's. Just call it DRM.
Some of the drivers use TINY for historical reasons. Simple pipe and
mipi helpers originated from here IIRC. And now it's just regular DRM
drivers.
+ tristate "DRM support for Solomon SSD1307 OLED displays"
+ depends on DRM && I2C
+ select DRM_KMS_HELPER
+ select DRM_GEM_SHMEM_HELPER
+ select BACKLIGHT_CLASS_DEVICE
Alphabetical order please.
+ help
+ DRM driver for the SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
+ OLED controllers that can be programmed via an I2C interface.
+
+ If M is selected the module will be called ssd1307.
+
config TINYDRM_ST7586
tristate "DRM support for Sitronix ST7586 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 5d5505d40e7b..38c4ce96 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
+obj-$(CONFIG_TINYDRM_SSD1307) += ssd1307.o
Maybe call it ssd130x
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
diff --git a/drivers/gpu/drm/tiny/ssd1307.c b/drivers/gpu/drm/tiny/ssd1307.c
new file mode 100644
index ..4ea223674587
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ssd1307.c
@@ -0,0 +1,976 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Solomon SSD1307 OLED displays
+ *
+ * Copyright 2022 Red Hat Inc.
+ *
+ * Based on drivers/video/fbdev/ssd1307fb.c
+ * Copyright 2012 Free Electrons
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"ssd1307"
+#define DRIVER_DESC"DRM driver for Solomon SSD1307 OLED displays"
+#define DRIVER_DATE"20220131"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define SSD1307_DATA 0x40
+#define SSD1307_COMMAND0x80
+
+#define SSD1307_SET_ADDRESS_MODE 0x20
+#define SSD1307_SET_ADDRESS_MODE_HORIZONTAL(0x00)
+#define SSD1307_SET_ADDRESS_MODE_VERTICAL (0x01)
+#define SSD1307_SET_ADDRESS_MODE_PAGE (0x02)
+#define SSD1307_SET_COL_RANGE 0x21
+#define SSD1307_SET_PAGE_RANGE 0x22
+#define SSD1307_CONTRAST 0x81
+#define SSD1307_SET_LOOKUP_TABLE 0x91
+#define SSD1307_CHARGE_PUMP0x8d
+#define SSD1307_SEG_REMAP_ON 0xa1
+#define SSD1307_DISPLAY_OFF0xae
+#define SSD1307_SET_MULTIPLEX_RATIO0xa8
+#define SSD1307_DISPLAY_ON 0xaf
+#define SSD1307_START_PAGE_ADDRESS 0xb0
+#define SSD1307_SET_DISPLAY_OFFSET 0xd3
+#define SSD1307_SET_CLOCK_FREQ 0xd5
+#define SSD1307_SET_AREA_COLOR_MODE0xd8
+#define SSD1307_SET_PRECHARGE_PERIOD 0xd9
+#define SSD1307_SET_COM_PINS_CONFIG0xda
+#define SSD1307_SET_VCOMH 0xdb
+
+#define MAX_CONTRAST 255
+
+struct ssd1307_deviceinfo {
+ u32 default_vcomh;
+ u32 default_dclk_div;
+ u32 default_dclk_frq;
+ int need_pwm;
+ int need_chargepump;
+};
+
+struct ssd1307_device {
+ struct drm_device drm;
+ struct drm_simple_display_pipe pipe;
+ struct drm_display_mode mode;
+ struct drm_connector connector;
+ struct i2c_client *client;
+
+ const struct ssd1307_deviceinfo *device_info;
+
+ unsigned area_color_enable : 1;
+ unsigned
Re: [PATCH 0/4] drm/tiny: Add driver for Solomon SSD1307 OLED displays
Hi
Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
Hi Simon,
On Tue, Feb 1, 2022 at 9:34 AM Simon Ser wrote:
On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven
wrote:
What's the story with the Rn formats?
The comments say "n bpp Red", while this is a monochrome (even
inverted) display?
I don't think the color matters that much. "Red" was picked just because it was
an arbitrary color, to make the difference with e.g. C8. Or am I mistaken?
I'd expect 8-bit grayscale to be Y8 instead.
I like this naming, but DRM_FORMAT_R8 is uapi already. :/ If anything,
we could add Yn formats in addition to existing Rn formats.
Best regards
Thomas
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
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c
>> b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> -/*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> +if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> +!(info->flags & FBINFO_HWACCEL_DISABLED))
>> +p->scrollmode = SCROLL_MOVE;
>> +else /* default to something safe */
>> +p->scrollmode = SCROLL_REDRAW;
>> +#else
>> p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> +int cap = info->flags;
>> +u16 t = 0;
>> +int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> +int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> +int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> +divides(ypan, vc->vc_font.height) && vyres > yres;
>> +int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> +divides(ywrap, vc->vc_font.height) &&
>> +divides(vc->vc_font.height, vyres) &&
>> +divides(vc->vc_font.height, yres);
>> +int reading_fast = cap & FBINFO_READS_FAST;
>> +int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>> +int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> +!(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> +if (good_wrap || good_pan) {
>> +if (reading_fast || fast_copyarea)
>> +p->scrollmode = good_wrap ?
>> +SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> +else
>> +p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> +SCROLL_PAN_REDRAW;
>> +} else {
>> +if (reading_fast || (fast_copyarea && !fast_imageblit))
>> +p->scrollmode = SCROLL_MOVE;
>> +else
>> +p->scrollmode = SCROLL_REDRAW;
>> +}
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> +p->scrollmode = SCROLL_REDRAW;
>> +#endif
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>
Re: [PATCH 08/20] drm/i915/buddy: adjust res->start
On Wed, 2022-01-26 at 15:21 +, Matthew Auld wrote: > Differentiate between mappable vs non-mappable resources, also if > this > is an actual range allocation ensure we set res->start as the > starting > pfn. Later when we need to do non-mappable -> mappable moves then we > want TTM to see that the current placement is not compatible, which > should result in an actual move, instead of being turned into a noop. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström Reviewed-by: Thomas Hellström > --- > drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > index 6e5842155898..bc725a92fc5c 100644 > --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > @@ -140,6 +140,13 @@ static int i915_ttm_buddy_man_alloc(struct > ttm_resource_manager *man, > mutex_unlock(>lock); > } > > + if (place->lpfn - place->fpfn == n_pages) > + bman_res->base.start = place->fpfn; > + else if (lpfn <= bman->visible_size) > + bman_res->base.start = 0; > + else > + bman_res->base.start = bman->visible_size; > + > *res = _res->base; > return 0; >
Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
It's only one flag and slightly tidier code.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Claudio Suarez
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbcon.c | 11 +--
drivers/video/fbdev/core/fbcon.h | 4 +---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index affb40658fee..fa30e1909164 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
ops->currcon = fg_console;
- if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, >var, unit);
@@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
* We need to do it in fbcon_init() to prevent screen corruption.
*/
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
- if (info->fbops->fb_set_par &&
- !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
}
ops->graphics = 0;
@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
- ops->flags &= ~FBCON_FLAGS_INIT;
+ ops->initialized = false;
finished:
fbcon_free_font(p, free_font);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index dce5ce41093e..b18d0cbf73b6 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
#include
-#define FBCON_FLAGS_INIT 1
-
/*
*This is the interface between the low-level console driver and the
*low-level frame buffer device
@@ -77,7 +75,7 @@ struct fbcon_ops {
intblank_state;
intgraphics;
intsave_graphics; /* for debug enter/leave */
- intflags;
+ bool initialized;
This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
introtate;
intcur_rotate;
char *cursor_data;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH v5 07/19] drm/i915/migrate: add acceleration support for DG2
From: Matthew Auld
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
v2: Rebased [Ram]
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 179 +++-
1 file changed, 147 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 18b44af56969..cac791155244 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -32,6 +32,38 @@ static bool engine_supports_migration(struct intel_engine_cs
*engine)
return true;
}
+static void xehpsdv_toggle_pdes(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data)
+{
+ struct insert_pte_data *d = data;
+
+ /*
+* Insert a dummy PTE into every PT that will map to LMEM to ensure
+* we have a correctly setup PDE structure for later use.
+*/
+ vm->insert_page(vm, 0, d->offset, I915_CACHE_NONE, PTE_LM);
+ GEM_BUG_ON(!pt->is_compact);
+ d->offset += SZ_2M;
+}
+
+static void xehpsdv_insert_pte(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data)
+{
+ struct insert_pte_data *d = data;
+
+ /*
+* We are playing tricks here, since the actual pt, from the hw
+* pov, is only 256bytes with 32 entries, or 4096bytes with 512
+* entries, but we are still guaranteed that the physical
+* alignment is 64K underneath for the pt, and we are careful
+* not to access the space in the void.
+*/
+ vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE, PTE_LM);
+ d->offset += SZ_64K;
+}
+
static void insert_pte(struct i915_address_space *vm,
struct i915_page_table *pt,
void *data)
@@ -74,7 +106,12 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
* i.e. within the same non-preemptible window so that we do not switch
* to another migration context that overwrites the PTE.
*
-* TODO: Add support for huge LMEM PTEs
+* On platforms with HAS_64K_PAGES support we have three windows, and
+* dedicate two windows just for mapping lmem pages(smem <-> smem is not
+* a thing), since we are forced to use 64K GTT pages underneath which
+* requires also modifying the PDE. An alternative might be to instead
+* map the PD into the GTT, and then on the fly toggle the 4K/64K mode
+* in the PDE from the same batch that also modifies the PTEs.
*/
vm = i915_ppgtt_create(gt, I915_BO_ALLOC_PM_EARLY);
@@ -86,6 +123,9 @@ static struct i915_address_space *migrate_vm(struct intel_gt
*gt)
goto err_vm;
}
+ if (HAS_64K_PAGES(gt->i915))
+ stash.pt_sz = I915_GTT_PAGE_SIZE_64K;
+
/*
* Each engine instance is assigned its own chunk in the VM, so
* that we can run multiple instances concurrently
@@ -105,14 +145,20 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
* We copy in 8MiB chunks. Each PDE covers 2MiB, so we need
* 4x2 page directories for source/destination.
*/
- sz = 2 * CHUNK_SZ;
+ if (HAS_64K_PAGES(gt->i915))
+ sz = 3 * CHUNK_SZ;
+ else
+ sz = 2 * CHUNK_SZ;
d.offset = base + sz;
/*
* We need another page directory setup so that we can write
* the 8x512 PTE in each chunk.
*/
- sz += (sz >> 12) * sizeof(u64);
+ if (HAS_64K_PAGES(gt->i915))
+ sz += (sz / SZ_2M) * SZ_64K;
+ else
+ sz += (sz >> 12) * sizeof(u64);
err = i915_vm_alloc_pt_stash(>vm, , sz);
if (err)
@@ -133,7 +179,18 @@ static struct i915_address_space *migrate_vm(struct
intel_gt *gt)
goto err_vm;
/* Now allow the GPU to rewrite the PTE via its own ppGTT */
- vm->vm.foreach(>vm, base, d.offset - base, insert_pte, );
+ if (HAS_64K_PAGES(gt->i915)) {
+ vm->vm.foreach(>vm, base, d.offset - base,
+ xehpsdv_insert_pte, );
+ d.offset = base + CHUNK_SZ;
+ vm->vm.foreach(>vm,
+ d.offset,
+ 2 * CHUNK_SZ,
+ xehpsdv_toggle_pdes, );
+ } else {
+ vm->vm.foreach(>vm, base,
[PATCH v5 08/19] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Acked-by: Jordan Justen
Reviewed-by: Ramalingam C
Reviewed-by: Thomas Hellström
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE (which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.20.1
