[linux-next:master] BUILD SUCCESS WITH WARNING d3f2cd24819158bb70701c3549e586f9df9cee67
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: d3f2cd24819158bb70701c3549e586f9df9cee67 Add linux-next specific files for 20230414 Warning reports: https://lore.kernel.org/oe-kbuild-all/202303161521.jbgbafjj-...@intel.com Warning: (recently discovered and may have been fixed) drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable] drivers/net/wireless/legacy/ray_cs.c:628:17: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] Unverified Warning (likely false positive, please contact us if interested): drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'. drivers/gpu/host1x/context.c:82 host1x_memory_context_list_init() warn: missing error code 'err' drivers/gpu/host1x/dev.c:417 host1x_iommu_attach() warn: passing zero to 'ERR_PTR' fs/xfs/scrub/refcount.c: xfs_mount.h is included more than once. fs/xfs/scrub/refcount.c: xfs_trans_resv.h is included more than once. Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-net-wireless-legacy-ray_cs.c:warning:strncpy-specified-bound-equals-destination-size |-- alpha-randconfig-r013-20230409 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-randconfig-c023-20230412 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-randconfig-r022-20230409 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-randconfig-m041-20230413 | |-- drivers-gpu-host1x-context.c-host1x_memory_context_list_init()-warn:missing-error-code-err | `-- drivers-gpu-host1x-dev.c-host1x_iommu_attach()-warn:passing-zero-to-ERR_PTR |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- i386-randconfig-m021 | `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-. |-- ia64-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-net-wireless-legacy-ray_cs.c:warning:strncpy-specified-bound-equals-destination-size |-- loongarch-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_nee
Re: [PATCH 1/7] mm/gup: remove unused vmas parameter from get_user_pages()
On Sat, Apr 15, 2023 at 12:27:13AM +0100, Lorenzo Stoakes wrote: > No invocation of get_user_pages() uses the vmas parameter, so remove > it. > > The GUP API is confusing and caveated. Recent changes have done much to > improve that, however there is more we can do. Exporting vmas is a prime > target as the caller has to be extremely careful to preclude their use > after the mmap_lock has expired or otherwise be left with dangling > pointers. > > Removing the vmas parameter focuses the GUP functions upon their primary > purpose - pinning (and outputting) pages as well as performing the actions > implied by the input flags. > > This is part of a patch series aiming to remove the vmas parameter > altogether. > > Signed-off-by: Lorenzo Stoakes > Suggested-by: Matthew Wilcox (Oracle) Acked-by: Greg Kroah-Hartman
[PATCH v3] drm/nouveau: fix incorrect conversion to dma_resv_wait_timeout()
Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout().
However, dma_resv_wait_timeout() returns greater than zero on
success as opposed to ttm_bo_wait_ctx(). As a result, relocs
will fail and log errors even when it was a success.
Change the return code handling to match that of
nouveau_gem_ioctl_cpu_prep(), which was already using
dma_resv_wait_timeout() correctly.
Fixes: 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
Reported-by: Tanmay Bhushan <0070472...@gmail.com>
Link: https://lore.kernel.org/lkml/20230119225351.71657-1-0070472...@gmail.com
Signed-off-by: John Ogness
---
I just realized that the nouveau driver style prefers to scope
variables used only in loops.
v3: Define @lret within the for-loop.
drivers/gpu/drm/nouveau/nouveau_gem.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f77e44958037..ab9062e50977 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -645,7 +645,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf_reloc *reloc,
struct drm_nouveau_gem_pushbuf_bo *bo)
{
- long ret = 0;
+ int ret = 0;
unsigned i;
for (i = 0; i < req->nr_relocs; i++) {
@@ -653,6 +653,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf_bo *b;
struct nouveau_bo *nvbo;
uint32_t data;
+ long lret;
if (unlikely(r->bo_index >= req->nr_buffers)) {
NV_PRINTK(err, cli, "reloc bo index invalid\n");
@@ -703,13 +704,18 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
data |= r->vor;
}
- ret = dma_resv_wait_timeout(nvbo->bo.base.resv,
- DMA_RESV_USAGE_BOOKKEEP,
- false, 15 * HZ);
- if (ret == 0)
+ lret = dma_resv_wait_timeout(nvbo->bo.base.resv,
+DMA_RESV_USAGE_BOOKKEEP,
+false, 15 * HZ);
+ if (!lret)
ret = -EBUSY;
+ else if (lret > 0)
+ ret = 0;
+ else
+ ret = lret;
+
if (ret) {
- NV_PRINTK(err, cli, "reloc wait_idle failed: %ld\n",
+ NV_PRINTK(err, cli, "reloc wait_idle failed: %d\n",
ret);
break;
}
base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
--
2.30.2
[PATCH v2] drm/nouveau: fix incorrect conversion to dma_resv_wait_timeout()
Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout().
However, dma_resv_wait_timeout() returns greater than zero on
success as opposed to ttm_bo_wait_ctx(). As a result, relocs
will fail and log errors even when it was a success.
Change the return code handling to match that of
nouveau_gem_ioctl_cpu_prep(), which was already using
dma_resv_wait_timeout() correctly.
Fixes: 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
Reported-by: Tanmay Bhushan <0070472...@gmail.com>
Link: https://lore.kernel.org/lkml/20230119225351.71657-1-0070472...@gmail.com
Signed-off-by: John Ogness
---
The original report was actually a patch that needed fixing.
Since nobody has stepped up to fix this regression correctly,
I'm posting the v2.
This is a real regression introduced in 6.3-rc1.
drivers/gpu/drm/nouveau/nouveau_gem.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f77e44958037..346839c24273 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -645,8 +645,9 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf_reloc *reloc,
struct drm_nouveau_gem_pushbuf_bo *bo)
{
- long ret = 0;
+ int ret = 0;
unsigned i;
+ long lret;
for (i = 0; i < req->nr_relocs; i++) {
struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
@@ -703,13 +704,18 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
data |= r->vor;
}
- ret = dma_resv_wait_timeout(nvbo->bo.base.resv,
- DMA_RESV_USAGE_BOOKKEEP,
- false, 15 * HZ);
- if (ret == 0)
+ lret = dma_resv_wait_timeout(nvbo->bo.base.resv,
+DMA_RESV_USAGE_BOOKKEEP,
+false, 15 * HZ);
+ if (!lret)
ret = -EBUSY;
+ else if (lret > 0)
+ ret = 0;
+ else
+ ret = lret;
+
if (ret) {
- NV_PRINTK(err, cli, "reloc wait_idle failed: %ld\n",
+ NV_PRINTK(err, cli, "reloc wait_idle failed: %d\n",
ret);
break;
}
base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
--
2.30.2
[PATCH 2/5] drm/i915/guc: Print status register when waiting for GuC to load
From: John Harrison If the GuC load is taking an excessively long time, the wait loop currently prints the GT frequency. Extend that to include the GuC status as well so we can see if the GuC is actually making progress or not. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c index 0ff088a5e51a8..364d0d546ec82 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c @@ -191,8 +191,10 @@ static int guc_wait_ucode(struct intel_guc *guc) if (!ret || !success) break; - guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz\n", - count, intel_rps_read_actual_frequency(&uncore->gt->rps)); + guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz, status = 0x%08X [0x%02X/%02X]\n", + count, intel_rps_read_actual_frequency(&uncore->gt->rps), status, + REG_FIELD_GET(GS_BOOTROM_MASK, status), + REG_FIELD_GET(GS_UKERNEL_MASK, status)); } after = ktime_get(); delta = ktime_sub(after, before); -- 2.39.1
[PATCH 5/5] drm/i915/uc: Reject doplicate entries in firmware table
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
duplicates.
For full m/m/p files, that can be done by simply tweaking the patch
level check to reject matching values. For reduced version entries,
the filename itself must be compared.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 +---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index c589782467265..44829247ef6bc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -319,7 +319,7 @@ static void validate_fw_table_type(struct drm_i915_private
*i915, enum intel_uc_
{
const struct uc_fw_platform_requirement *fw_blobs;
u32 fw_count;
- int i;
+ int i, j;
if (type >= ARRAY_SIZE(blobs_all)) {
drm_err(&i915->drm, "No blob array for %s\n",
intel_uc_fw_type_repr(type));
@@ -334,6 +334,27 @@ static void validate_fw_table_type(struct drm_i915_private
*i915, enum intel_uc_
/* make sure the list is ordered as expected */
for (i = 1; i < fw_count; i++) {
+ /* Versionless file names must be unique per platform: */
+ for (j = i + 1; j < fw_count; j++) {
+ /* Same platform? */
+ if (fw_blobs[i].p != fw_blobs[j].p)
+ continue;
+
+ if (fw_blobs[i].blob.path != fw_blobs[j].blob.path)
+ continue;
+
+ drm_err(&i915->drm, "Diplicaate %s blobs: %s r%u
%s%d.%d.%d [%s] matches %s r%u %s%d.%d.%d [%s]\n",
+ intel_uc_fw_type_repr(type),
+ intel_platform_name(fw_blobs[j].p),
fw_blobs[j].rev,
+ fw_blobs[j].blob.legacy ? "L" : "v",
+ fw_blobs[j].blob.major, fw_blobs[j].blob.minor,
+ fw_blobs[j].blob.patch, fw_blobs[j].blob.path,
+ intel_platform_name(fw_blobs[i].p),
fw_blobs[i].rev,
+ fw_blobs[i].blob.legacy ? "L" : "v",
+ fw_blobs[i].blob.major, fw_blobs[i].blob.minor,
+ fw_blobs[i].blob.patch, fw_blobs[i].blob.path);
+ }
+
/* Next platform is good: */
if (fw_blobs[i].p < fw_blobs[i - 1].p)
continue;
@@ -377,8 +398,8 @@ static void validate_fw_table_type(struct drm_i915_private
*i915, enum intel_uc_
if (fw_blobs[i].blob.minor != fw_blobs[i - 1].blob.minor)
goto bad;
- /* Patch versions must be in order: */
- if (fw_blobs[i].blob.patch <= fw_blobs[i - 1].blob.patch)
+ /* Patch versions must be in order and unique: */
+ if (fw_blobs[i].blob.patch < fw_blobs[i - 1].blob.patch)
continue;
bad:
--
2.39.1
[PATCH 3/5] drm/i915/uc: Track patch level versions on reduced version firmware files
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The KMD can work without the change but if the effort has
been taken to release a new firmware with the change then there must
be a valid reason for doing so - important bug fix, security fix, etc.
And in that case it would be good to alert the user if they are
missing out on that new fix.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 41 +---
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index a82a53dbbc86d..6bb45d6b8da5f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -80,14 +80,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
*/
#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \
- fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \
- fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \
+ fw_def(DG2, 0, guc_maj(dg2, 70, 5, 4)) \
+ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5, 4)) \
fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \
fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 69, 0, 3)) \
- fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5)) \
+ fw_def(ALDERLAKE_S, 0, guc_maj(tgl, 70, 5, 4)) \
fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(ALDERLAKE_S, 0, guc_mmp(tgl, 69, 0, 3)) \
- fw_def(DG1, 0, guc_maj(dg1, 70, 5)) \
+ fw_def(DG1, 0, guc_maj(dg1, 70, 5, 4)) \
fw_def(ROCKETLAKE, 0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(TIGERLAKE,0, guc_mmp(tgl, 70, 1, 1)) \
fw_def(JASPERLAKE, 0, guc_mmp(ehl, 70, 1, 1)) \
@@ -141,7 +141,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
__stringify(patch_) ".bin"
/* Minor for internal driver use, not part of file name */
-#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
+#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_) \
__MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
#define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
@@ -197,9 +197,9 @@ struct __packed uc_fw_blob {
{ UC_FW_BLOB_BASE(major_, minor_, patch_, path_) \
.legacy = true }
-#define GUC_FW_BLOB(prefix_, major_, minor_) \
- UC_FW_BLOB_NEW(major_, minor_, 0, false, \
- MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_))
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+ UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+ MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))
#define GUC_FW_BLOB_MMP(prefix_, major_, minor_, patch_) \
UC_FW_BLOB_OLD(major_, minor_, patch_, \
@@ -296,6 +296,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
uc_fw->file_wanted.path = blob->path;
uc_fw->file_wanted.ver.major = blob->major;
uc_fw->file_wanted.ver.minor = blob->minor;
+ uc_fw->file_wanted.ver.patch = blob->patch;
uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
found = true;
break;
@@ -776,6 +777,17 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (uc_fw->type == INTEL_UC_FW_TYPE_GUC &&
!guc_check_version_range(uc_fw))
goto fail;
+ gt_info(gt, "%s firmware: wanted = %s / %d.%d.%d, got = %s /
%d.%d.%d\n",
+ intel_uc_fw_type_repr(uc_fw->type),
+ uc_fw->file_wanted.path,
+ uc_fw->file_wanted.ver.major,
+ uc_fw->file_wanted.ver.minor,
+ uc_fw->file_wanted.ver.patch,
+ uc_fw->file_selected.path,
+ uc_fw->file_selected.ver.major,
+ uc_fw->file_selected.ver.minor,
+ uc_fw->file_selected.ver.patch);
+
if (uc_fw->file_wanted.ver.major && uc_fw->file_selected.ver.major) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.ver.major !=
uc_fw->file_wanted.ver.major) {
@@ -790,6 +802,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
} else {
if (uc_fw->file_selected.ver.minor <
uc_fw->file_wanted.ver.minor)
old_ver = true;
+ else if ((uc_fw->file_selected.ver.minor ==
uc_fw->file_wanted.ver.minor) &&
+(uc_fw->file_selected.ver.patch <
uc_fw->file_wanted.ver.patch))
+ old_ver = true;
}
}
@@ -797,12 +812,16 @@ int
[PATCH 1/5] drm/i915/guc: Decode another GuC load failure case
From: John Harrison
Explain another potential firmware failure mode and early exit the
long wait if hit.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index bcb1129b36102..dabeaf4f245f3 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -44,6 +44,7 @@ enum intel_guc_load_status {
enum intel_bootrom_load_status {
INTEL_BOOTROM_STATUS_NO_KEY_FOUND = 0x13,
INTEL_BOOTROM_STATUS_AES_PROD_KEY_FOUND = 0x1A,
+ INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE = 0x2B,
INTEL_BOOTROM_STATUS_RSA_FAILED = 0x50,
INTEL_BOOTROM_STATUS_PAVPC_FAILED = 0x73,
INTEL_BOOTROM_STATUS_WOPCM_FAILED = 0x74,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 6fda3aec5c66a..0ff088a5e51a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -129,6 +129,7 @@ static inline bool guc_load_done(struct intel_uncore
*uncore, u32 *status, bool
case INTEL_BOOTROM_STATUS_RC6CTXCONFIG_FAILED:
case INTEL_BOOTROM_STATUS_MPUMAP_INCORRECT:
case INTEL_BOOTROM_STATUS_EXCEPTION:
+ case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
*success = false;
return true;
}
@@ -219,6 +220,11 @@ static int guc_wait_ucode(struct intel_guc *guc)
guc_info(guc, "firmware signature verification
failed\n");
ret = -ENOEXEC;
break;
+
+ case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
+ guc_info(guc, "firmware production part check
failure\n");
+ ret = -ENOEXEC;
+ break;
}
switch (ukernel) {
--
2.39.1
[PATCH 4/5] drm/i915/uc: Split firmware table validation to a separate function
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. Potentially, it should be a selftest. But either way, the
first step is pulling it out into a separate function that can be
called just once rather than once per blob attempt per blob type.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 164 ++-
1 file changed, 99 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 6bb45d6b8da5f..c589782467265 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -233,20 +233,22 @@ struct fw_blobs_by_type {
u32 count;
};
+static const struct uc_fw_platform_requirement blobs_guc[] = {
+ INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB, GUC_FW_BLOB_MMP)
+};
+
+static const struct uc_fw_platform_requirement blobs_huc[] = {
+ INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB, HUC_FW_BLOB_MMP,
HUC_FW_BLOB_GSC)
+};
+
+static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] = {
+ [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
+ [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
+};
+
static void
__uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
{
- static const struct uc_fw_platform_requirement blobs_guc[] = {
- INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB,
GUC_FW_BLOB_MMP)
- };
- static const struct uc_fw_platform_requirement blobs_huc[] = {
- INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB,
HUC_FW_BLOB_MMP, HUC_FW_BLOB_GSC)
- };
- static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] =
{
- [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
- [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
- };
- static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
enum intel_platform p = INTEL_INFO(i915)->platform;
u32 fw_count;
@@ -286,6 +288,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct
intel_uc_fw *uc_fw)
continue;
if (uc_fw->file_selected.path) {
+ /*
+* Continuing an earlier search after a found blob
failed to load.
+* Once the previously chosen path has been found,
clear it out
+* and let the search continue from there.
+*/
if (uc_fw->file_selected.path == blob->path)
uc_fw->file_selected.path = NULL;
@@ -306,78 +313,103 @@ __uc_fw_auto_select(struct drm_i915_private *i915,
struct intel_uc_fw *uc_fw)
/* Failed to find a match for the last attempt?! */
uc_fw->file_selected.path = NULL;
}
+}
- /* make sure the list is ordered as expected */
- if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified[uc_fw->type]) {
- verified[uc_fw->type] = true;
+static void validate_fw_table_type(struct drm_i915_private *i915, enum
intel_uc_fw_type type)
+{
+ const struct uc_fw_platform_requirement *fw_blobs;
+ u32 fw_count;
+ int i;
- for (i = 1; i < fw_count; i++) {
- /* Next platform is good: */
- if (fw_blobs[i].p < fw_blobs[i - 1].p)
- continue;
+ if (type >= ARRAY_SIZE(blobs_all)) {
+ drm_err(&i915->drm, "No blob array for %s\n",
intel_uc_fw_type_repr(type));
+ return;
+ }
- /* Next platform revision is good: */
- if (fw_blobs[i].p == fw_blobs[i - 1].p &&
- fw_blobs[i].rev < fw_blobs[i - 1].rev)
- continue;
+ fw_blobs = blobs_all[type].blobs;
+ fw_count = blobs_all[type].count;
- /* Platform/revision must be in order: */
- if (fw_blobs[i].p != fw_blobs[i - 1].p ||
- fw_blobs[i].rev != fw_blobs[i - 1].rev)
- goto bad;
+ if (!fw_count)
+ return;
- /* Next major version is good: */
- if (fw_blobs[i].blob.major < fw_blobs[i - 1].blob.major)
- continue;
+ /* make sure the list is ordered as expected */
+ for (i = 1; i < fw_count; i++) {
+ /* Next platform is good: */
+ if (fw_blobs[i].p < fw_blobs[i - 1].p)
+ continue;
- /* New must be before legacy: */
- if (!fw_blobs[i].b
[PATCH 0/5] Improvements to uc firmare management
From: John Harrison Enhance the firmware table verification code to catch more potential errors and to generally improve the code itself. Track patch level version even on reduced version files to allow user notification of missing bug fixes. Detect another immediate failure case when loading GuC firmware. Signed-off-by: John Harrison John Harrison (5): drm/i915/guc: Decode another GuC load failure case drm/i915/guc: Print status register when waiting for GuC to load drm/i915/uc: Track patch level versions on reduced version firmware files drm/i915/uc: Split firmware table validation to a separate function drm/i915/uc: Reject doplicate entries in firmware table .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 12 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 222 -- 3 files changed, 159 insertions(+), 76 deletions(-) -- 2.39.1
[PATCH] drm/i915/guc: Fix error capture for virtual engines
From: John Harrison
GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
[IGT] gem_exec_balancer: starting subtest hang
[drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
[drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D
[drm] GPU HANG: ecode 12:4:, in gem_exec_balanc [6388]
[IGT] gem_exec_balancer: exiting, ret=0
The test causes a hang on both engines of a virtual engine context.
The engine instance zero hang gets a valid error capture but the
non-instance-zero hang does not.
Fix that by scanning through the list of pending register captures
when a hang notification for a virtual engine is received. That way,
the hang can be assigned to the correct physical engine prior to
starting the error capture process. So later on, when the error capture
handler tries to find the engine register list, it looks for one on
the correct engine.
Also, sneak in a missing blank line before a comment in the node
search code.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 31 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 11 +--
4 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index cf49188db6a6e..fc6964abb517e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1593,6 +1593,36 @@ void intel_guc_capture_free_node(struct
intel_engine_coredump *ee)
ee->guc_capture_node = NULL;
}
+bool intel_guc_capture_is_matching_engine(struct intel_gt *gt,
+ struct intel_context *ce,
+ struct intel_engine_cs *engine)
+{
+ struct __guc_capture_parsed_output *n;
+ struct intel_guc *guc;
+
+ if (!gt || !ce || !engine)
+ return false;
+
+ guc = >->uc.guc;
+ if (!guc->capture)
+ return false;
+
+ /*
+* Look for a matching GuC reported error capture node from
+* the internal output link-list based on lrca, guc-id and engine
+* identification.
+*/
+ list_for_each_entry(n, &guc->capture->outlist, link) {
+ if (n->eng_inst == GUC_ID_TO_ENGINE_INSTANCE(engine->guc_id) &&
+ n->eng_class == GUC_ID_TO_ENGINE_CLASS(engine->guc_id) &&
+ n->guc_id == ce->guc_id.id &&
+ (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
CTX_GTT_ADDRESS_MASK))
+ return true;
+ }
+
+ return false;
+}
+
void intel_guc_capture_get_matching_node(struct intel_gt *gt,
struct intel_engine_coredump *ee,
struct intel_context *ce)
@@ -1608,6 +1638,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
return;
GEM_BUG_ON(ee->guc_capture_node);
+
/*
* Look for a matching GuC reported error capture node from
* the internal output link-list based on lrca, guc-id and engine
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
index fbd3713c7832d..302256d45431d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
@@ -11,6 +11,7 @@
struct drm_i915_error_state_buf;
struct guc_gt_system_info;
struct intel_engine_coredump;
+struct intel_engine_cs;
struct intel_context;
struct intel_gt;
struct intel_guc;
@@ -20,6 +21,8 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *m,
const struct intel_engine_coredump *ee);
void intel_guc_capture_get_matching_node(struct intel_gt *gt, struct
intel_engine_coredump *ee,
struct intel_context *ce);
+bool intel_guc_capture_is_matching_engine(struct intel_gt *gt, struct
intel_context *ce,
+ struct intel_engine_cs *engine);
void intel_guc_capture_process(struct intel_guc *guc);
int intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
void **outptr);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf0..86096ffde2190 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4697,13 +4697,37 @@ static void capture_error_state(struct intel_guc *guc,
{
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- stru
Re: [Intel-gfx] [PATCH v3] drm/i915/guc/slpc: Provide sysfs for efficient freq
On Fri, 14 Apr 2023 15:34:15 -0700, Vinay Belgaumkar wrote:
>
> @@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
> *slpc, u32 *val)
> return ret;
> }
>
> +int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
> +{
> + struct drm_i915_private *i915 = slpc_to_i915(slpc);
> + intel_wakeref_t wakeref;
> + int ret = 0;
> +
> + /* Need a lock now since waitboost can be modifying min as well */
Delete comment.
> + mutex_lock(&slpc->lock);
Actually, don't need the lock itself now so delete the lock.
Or, maybe the lock prevents the race if userspace writes to the sysfs when
GuC reset is going on so let's retain the lock. But the comment is wrong.
> + wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> +
> + /* Ignore efficient freq if lower min freq is requested */
Delete comment, it's wrong.
> + ret = slpc_set_param(slpc,
> + SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> + val);
> + if (ret) {
> + guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
> freq(%d): %pe\n",
> + val, ERR_PTR(ret));
> + goto out;
> + }
> +
> + slpc->ignore_eff_freq = val;
> +
This extra line can also be deleted.
> +out:
> + intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> + mutex_unlock(&slpc->lock);
> + return ret;
> +}
> +
> /**
> * intel_guc_slpc_set_min_freq() - Set min frequency limit for SLPC.
> * @slpc: pointer to intel_guc_slpc.
> @@ -482,16 +511,6 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc
> *slpc, u32 val)
> mutex_lock(&slpc->lock);
> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>
> - /* Ignore efficient freq if lower min freq is requested */
> - ret = slpc_set_param(slpc,
> - SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> - val < slpc->rp1_freq);
> - if (ret) {
> - guc_probe_error(slpc_to_guc(slpc), "Failed to toggle efficient
> freq: %pe\n",
> - ERR_PTR(ret));
> - goto out;
> - }
> -
Great, thanks!
After taking care of the above, and seems there are also a couple of
checkpatch errors, this is:
Reviewed-by: Ashutosh Dixit
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 3:52 PM, Marijn Suijten wrote: On 2023-04-14 14:03:23, Abhinav Kumar wrote: [..] Yes, ofcourse git send-email was used to send the patch, not any other mail client. Yes i am also aware that send-email converts rb to CC. But if you keep working on the local branch, then you would have to manually add the r-bs. If you use am of the prev version and develop on that, it will automatically add the r-bs. I don't think git-am is smart enough to fetch additional replies from lore and apply the reviewed-by (and other trailers). This workflow relies on downloading the mbox from a service that extracts and accumulates the trailers such as patchwork, see for example: https://patchwork.freedesktop.org/api/1.0/series/116340/revisions/1/mbox/ Note that it also picked up one sentence starting with Fixes: Fixes: tag below seems extraneous. Yes, I usually use git-pw ap. So perhaps, I should have been more specific to say that. Some form of am is what i wanted to emphasize but just wrote git am by mistake. On the other hand b4 (shaz)am is itself capable of downloading the whole mail thread and appending all trailers, just like patchwork is doing above, in one automated `b4 shazam ` command. And to solve the problem of trailers arriving in your inbox after working on the next revision in a local branch - or without ever even redownloading the series from lore/patchwork¸ b4 has a command to download and apply them to commits in your local branch: b4 trailers -uF Try it out, b4 is amazing :) Yes, i recently started using it to send "applied" emails as suggested by Dmitry , for patch related work was still using git-pw. Perhaps, I will switch completely to it. [..] 2) I synced with kuogee. his git version seems to be quite old which is not adding the folks from r-b to cc. So there was nothing wrong with invocation, just versioning. You are right. The X-Mailer header of Kuogee's patch indicates git 2.7.4, while cc'ing of additional -by trailers (such as r-b's) was only introduced in 2.20.0: https://github.com/git/git/commit/ef0cc1df90f6b6c2987ab2db8e0ccf2cfc421edf Fwiw 2.7.4 is from March 2016. - Marijn
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 3:53 PM, Dmitry Baryshkov wrote:
On Sat, 15 Apr 2023 at 00:03, Abhinav Kumar wrote:
On 4/14/2023 1:58 PM, Dmitry Baryshkov wrote:
On Fri, 14 Apr 2023 at 21:55, Abhinav Kumar wrote:
On 4/14/2023 10:28 AM, Marijn Suijten wrote:
On 2023-04-14 08:41:37, Abhinav Kumar wrote:
On 4/14/2023 12:48 AM, Marijn Suijten wrote:
Capitalize DSC in the title, as discussed in v1.
On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
In current code, the DSC active bits are written only if cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
By default git send-email should pick this up in the CC line... but I
had to download this patch from lore once again.
Yes, I think what happened here is, he didnt git am the prev rev and
make changes on top of that so git send-email didnt pick up. We should
fix that process.
The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file. I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).
Yes, ofcourse git send-email was used to send the patch, not any other
mail client.
Yes i am also aware that send-email converts rb to CC.
But if you keep working on the local branch, then you would have to
manually add the r-bs. If you use am of the prev version and develop on
that, it will automatically add the r-bs.
It looks like there is some misunderstanding here. I think Marijn
doesn't question his R-B (which was present), but tries to point out
that Kuogee might want to adjust his git-send-email invocation. By
default (and that's a good practice, which we should follow),
git-send-email will CC people mentioned in such tags. Marijn didn't
get this email. So, it seems, for some reason this Cc: _mail_ header
was suppressed. Probably git-send-email invocation should be changed
to prevent suppression of adding mentioned people to CC lists.
Yeah I understood that part. There were two issues here:
1) My r-b got dropped and that was because am wasn't used to
automatically retain tags from prev version.
If you dont add the r-bs either manually or by am, then folks wont be
part of CC either
Just as a note: there is nothing wrong with adding tags manually. I do
that for some of my patchsets (and sometimes I miss them too).
Nothing wrong, especially when sometimes its given on IRC or something,
I have to add it manually that time too.
But, just prone to forgetting. Like this case.
Next time, lets say Marijn again gives R-b, but someone else forgets to
manually apply it, the same issue will happen even if proper git
send-email is used.
2) I synced with kuogee. his git version seems to be quite old which is
not adding the folks from r-b to cc. So there was nothing wrong with
invocation, just versioning.
Ack. Thanks for updating it.
I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions. It even
requires a changelog to be edited ;). However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
There's more wrong than just moving (not "fix"ing) this bit of code into
reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
again by reverting this patch. Perhaps that can be explained, or link
to Abhinav's explanation to make it clear to readers what this FIXME
actually means? Let's wait for Abhinav and Dmitry to confirm the
desired communication here.
https://lore.kernel.org/l
Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits
On 4/14/2023 4:11 PM, Marijn Suijten wrote: On 2023-04-14 10:57:45, Abhinav Kumar wrote: On 4/14/2023 10:34 AM, Marijn Suijten wrote: On 2023-04-14 08:48:43, Abhinav Kumar wrote: On 4/14/2023 12:35 AM, Marijn Suijten wrote: On 2023-04-12 10:33:15, Abhinav Kumar wrote: [..] What happens if a device boots without DSC panel connected? Will CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the DSC blocks? Or could this flush uninitialized state to the block? If we bootup without DSC panel connected, the kernel's cfg->dsc will be 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush any DSC blocks. Ack, that makes sense. However, if I connect a DSC panel, then disconnect it (now the register should be non-zero, but cfg->dsc will be zero), and then replug a non-DSC panel multiple times, it'll get flushed every time because we never clear CTL_DSC_FLUSH after that? If we remove it after kernel starts, that issue is there even today without that change because DSI is not a hot-pluggable display so a teardown wont happen when you plug out the panel. How will cfg->dsc be 0 then? In that case, its not a valid test as there was no indication to DRM that display was disconnected so we cannot tear it down. The patch description itself describes hot-pluggable displays, which I believe is the upcoming DSC support for DP? You ask how cfg->dsc can become zero, but this is **exactly** what the patch description describes, and what this patch is removing the `if` for. If we are not allowed to discuss that scenario because it is not currently supported, neither should we allow to apply this patch. With that in mind, can you re-answer the question? I didnt follow what needs to be re-answered. This patch is being sent in preparation of the DSC over DP support. This does not handle non-hotpluggable displays. Good, because my question is specifically about *hotpluggable* displays/panels like the upcoming DSC support for DP. After all there would be no point in me suggesting to connect and disconnect non-hotpluggable displays and expect something sensible to happen, wouldn't it? Allow me to copy-paste the question again for convenience, with some minor wording changes: However, if I connect a DSC DP display, then disconnect it (now the register should be non-zero, but cfg->dsc will be zero), and then connect and reconnect a non-DSC DP display multiple times, it'll get flushed every time because we never clear CTL_DSC_FLUSH after that? And the missing part is: would multiple flushes be harmful in this case? Well, you kept asking about "DSC panel" , that made me think you were asking about a non-hotpluggable MIPI DSI DSC panel and not DP DSC monitor. On many boards, panels can be removed/connected back to their daughter card. The term "panel" confused me a bit. Now answering your question. Yes, it will get flushed once every hotplug thats not too bad but importantly DSC wont be active as CTL_DSC_ACTIVE will be set to 0 so it wont cause any issue. I do not think dynamic switch between DSC and non-DSC of non-hotpluggable displays needs to be discussed here as its not handled at all with or without this patch. We wanted to get early reviews on the patch. If you want this patch to be absorbed when rest of DSC over DP lands, I have no concerns with that. I wont pick this up for fixes and we will land this together with the rest of DP over DSC. I don't mind when and where this lands, just want to have the semantics clear around persisting the value of CTL_DSC_FLUSh in the register. Regardless, this patch doesn't sound like a fix but a workaround until reset_intf_cfg() is fixed to be called at the right point, and extended to clear CTL_DSC_ACTIVE and flush the DSCs. Perhaps it shouldn't have a Fixes: tag for that reason, as you intend to reinstate this if (cfg->dsc) condition when that is done? Its certainly fixing the use-case of DSC to non-DSC switching. So it is a fix. But yes not the best fix possible. We have to improve it by moving this to reset_intf_cfg() as I already committed to. - Marijn
Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits
On 2023-04-14 10:57:45, Abhinav Kumar wrote: > On 4/14/2023 10:34 AM, Marijn Suijten wrote: > > On 2023-04-14 08:48:43, Abhinav Kumar wrote: > >> On 4/14/2023 12:35 AM, Marijn Suijten wrote: > >>> On 2023-04-12 10:33:15, Abhinav Kumar wrote: > >>> [..] > > What happens if a device boots without DSC panel connected? Will > > CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the > > DSC blocks? Or could this flush uninitialized state to the block? > > If we bootup without DSC panel connected, the kernel's cfg->dsc will be > 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush > any DSC blocks. > >>> > >>> Ack, that makes sense. However, if I connect a DSC panel, then > >>> disconnect it (now the register should be non-zero, but cfg->dsc will be > >>> zero), and then replug a non-DSC panel multiple times, it'll get flushed > >>> every time because we never clear CTL_DSC_FLUSH after that? > >> > >> If we remove it after kernel starts, that issue is there even today > >> without that change because DSI is not a hot-pluggable display so a > >> teardown wont happen when you plug out the panel. How will cfg->dsc be 0 > >> then? In that case, its not a valid test as there was no indication to > >> DRM that display was disconnected so we cannot tear it down. > > > > The patch description itself describes hot-pluggable displays, which I > > believe is the upcoming DSC support for DP? You ask how cfg->dsc can > > become zero, but this is **exactly** what the patch description > > describes, and what this patch is removing the `if` for. If we are not > > allowed to discuss that scenario because it is not currently supported, > > neither should we allow to apply this patch. > > > > With that in mind, can you re-answer the question? > > I didnt follow what needs to be re-answered. > > This patch is being sent in preparation of the DSC over DP support. This > does not handle non-hotpluggable displays. Good, because my question is specifically about *hotpluggable* displays/panels like the upcoming DSC support for DP. After all there would be no point in me suggesting to connect and disconnect non-hotpluggable displays and expect something sensible to happen, wouldn't it? Allow me to copy-paste the question again for convenience, with some minor wording changes: However, if I connect a DSC DP display, then disconnect it (now the register should be non-zero, but cfg->dsc will be zero), and then connect and reconnect a non-DSC DP display multiple times, it'll get flushed every time because we never clear CTL_DSC_FLUSH after that? And the missing part is: would multiple flushes be harmful in this case? > I do not think dynamic switch > between DSC and non-DSC of non-hotpluggable displays needs to be > discussed here as its not handled at all with or without this patch. > > We wanted to get early reviews on the patch. If you want this patch to > be absorbed when rest of DSC over DP lands, I have no concerns with > that. I wont pick this up for fixes and we will land this together with > the rest of DP over DSC. I don't mind when and where this lands, just want to have the semantics clear around persisting the value of CTL_DSC_FLUSh in the register. Regardless, this patch doesn't sound like a fix but a workaround until reset_intf_cfg() is fixed to be called at the right point, and extended to clear CTL_DSC_ACTIVE and flush the DSCs. Perhaps it shouldn't have a Fixes: tag for that reason, as you intend to reinstate this if (cfg->dsc) condition when that is done? - Marijn
Re: [PATCH v3] drm/msm/dpu: always program DSC active bits
On 2023-04-14 09:46:17, Kuogee Hsieh wrote:
> In current code, the dsc active bits are set only if the cfg->dsc is set.
This is the old sentence from v1 again, did you accidentally send the
wrong patch as the improvements from v2 are missing?
> However, for displays which are hot-pluggable, there can be a use-case
> of disconnecting a DSC supported sink and connecting a non-DSC sink.
>
> For those cases we need to clear DSC active bits during teardown.
At least teardown is one word again, v2 had "tear down" which is wrong.
> As discuss at [1], clear DSC active bit will handled at reset_intf_cfg()
discussed* as pointed out by Dmitry, and make it clear that this is
about clearing CTL_DSC_ACTIVE (and CTL_DSC_FLUSH?) specifically. Once
that is moved to reset_intf_cfg(), this patch should be reverted as
there is no need to write the registers once again when cfg->dsc equals
0.
- Marijn
> Signed-off-by: Kuogee Hsieh
> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Reviewed-by: Abhinav Kumar
> Reviewed-by: Marijn Suijten
>
> [1]
> https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95c..88e4efe 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl
> *ctx,
> if (cfg->merge_3d)
> DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
> - if (cfg->dsc) {
> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> - }
> +
> + DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> + DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> }
>
> static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On Sat, 15 Apr 2023 at 00:03, Abhinav Kumar wrote:
>
>
>
> On 4/14/2023 1:58 PM, Dmitry Baryshkov wrote:
> > On Fri, 14 Apr 2023 at 21:55, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 4/14/2023 10:28 AM, Marijn Suijten wrote:
> >>> On 2023-04-14 08:41:37, Abhinav Kumar wrote:
>
> On 4/14/2023 12:48 AM, Marijn Suijten wrote:
> > Capitalize DSC in the title, as discussed in v1.
> >
> > On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
> >> In current code, the DSC active bits are written only if cfg->dsc is
> >> set.
> >> However, for displays which are hot-pluggable, there can be a use-case
> >> of disconnecting a DSC supported sink and connecting a non-DSC sink.
> >>
> >> For those cases we need to clear DSC active bits during tear down.
> >>
> >> Changes in V2:
> >> 1) correct commit text as suggested
> >> 2) correct Fixes commit id
> >> 3) add FIXME comment
> >>
> >> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> >> Signed-off-by: Kuogee Hsieh
> >> Reviewed-by: Marijn Suijten
> >
> > By default git send-email should pick this up in the CC line... but I
> > had to download this patch from lore once again.
> >
>
> Yes, I think what happened here is, he didnt git am the prev rev and
> make changes on top of that so git send-email didnt pick up. We should
> fix that process.
> >>>
> >>> The mail was sent so it must have gone through git send-email, unless a
> >>> different mail client was used to send the .patch file. I think you are
> >>> confusing this with git am (which doesn't need to be used if editing a
> >>> commit on a local branch) and subsequently git format-patch, which takes
> >>> a commit from a git repository and turns it into a .patch file: neither
> >>> of these "converts" r-b's (and other tags) to cc, that's happening in
> >>> git send-email (see `--suppress-cc` documentation in `man
> >>> git-send-email`).
> >>>
> >>
> >> Yes, ofcourse git send-email was used to send the patch, not any other
> >> mail client.
> >>
> >> Yes i am also aware that send-email converts rb to CC.
> >>
> >> But if you keep working on the local branch, then you would have to
> >> manually add the r-bs. If you use am of the prev version and develop on
> >> that, it will automatically add the r-bs.
> >
> > It looks like there is some misunderstanding here. I think Marijn
> > doesn't question his R-B (which was present), but tries to point out
> > that Kuogee might want to adjust his git-send-email invocation. By
> > default (and that's a good practice, which we should follow),
> > git-send-email will CC people mentioned in such tags. Marijn didn't
> > get this email. So, it seems, for some reason this Cc: _mail_ header
> > was suppressed. Probably git-send-email invocation should be changed
> > to prevent suppression of adding mentioned people to CC lists.
> >
>
> Yeah I understood that part. There were two issues here:
>
> 1) My r-b got dropped and that was because am wasn't used to
> automatically retain tags from prev version.
>
> If you dont add the r-bs either manually or by am, then folks wont be
> part of CC either
Just as a note: there is nothing wrong with adding tags manually. I do
that for some of my patchsets (and sometimes I miss them too).
>
> 2) I synced with kuogee. his git version seems to be quite old which is
> not adding the folks from r-b to cc. So there was nothing wrong with
> invocation, just versioning.
Ack. Thanks for updating it.
>
>
> >>
> >>
> >>> I can recommend b4: it has lots of useful features including
> >>> automatically picking up reviews and processing revisions. It even
> >>> requires a changelog to be edited ;). However, finding the right flags
> >>> and trusting it'll "do as ordered" is a bit daunting at first.
> >>>
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> index bbdc95c..1651cd7 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> @@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct
> >> dpu_hw_ctl *ctx,
> >> if (cfg->merge_3d)
> >> DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> >> BIT(cfg->merge_3d - MERGE_3D_0));
> >> - if (cfg->dsc) {
> >> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> >> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> >> - }
> >> +
> >> + /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
> >
> > There's more wrong than just moving (not "fix"ing) this bit of code into
> > reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
>
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 2023-04-14 14:03:23, Abhinav Kumar wrote: [..] > >> Yes, ofcourse git send-email was used to send the patch, not any other > >> mail client. > >> > >> Yes i am also aware that send-email converts rb to CC. > >> > >> But if you keep working on the local branch, then you would have to > >> manually add the r-bs. If you use am of the prev version and develop on > >> that, it will automatically add the r-bs. I don't think git-am is smart enough to fetch additional replies from lore and apply the reviewed-by (and other trailers). This workflow relies on downloading the mbox from a service that extracts and accumulates the trailers such as patchwork, see for example: https://patchwork.freedesktop.org/api/1.0/series/116340/revisions/1/mbox/ Note that it also picked up one sentence starting with Fixes: Fixes: tag below seems extraneous. On the other hand b4 (shaz)am is itself capable of downloading the whole mail thread and appending all trailers, just like patchwork is doing above, in one automated `b4 shazam ` command. And to solve the problem of trailers arriving in your inbox after working on the next revision in a local branch - or without ever even redownloading the series from lore/patchwork¸ b4 has a command to download and apply them to commits in your local branch: b4 trailers -uF Try it out, b4 is amazing :) [..] > 2) I synced with kuogee. his git version seems to be quite old which is > not adding the folks from r-b to cc. So there was nothing wrong with > invocation, just versioning. You are right. The X-Mailer header of Kuogee's patch indicates git 2.7.4, while cc'ing of additional -by trailers (such as r-b's) was only introduced in 2.20.0: https://github.com/git/git/commit/ef0cc1df90f6b6c2987ab2db8e0ccf2cfc421edf Fwiw 2.7.4 is from March 2016. - Marijn
Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
On Fri, 2023-04-14 at 13:35 +0300, Jani Nikula wrote:
> On Fri, 14 Apr 2023, Jeff Layton wrote:
> > On Fri, 2023-04-14 at 04:40 +, Lin, Wayne wrote:
> > > [Public]
> > >
> > > Hi Jeff,
> > >
> > > Thanks. I might need more information to understand why we can't retrieve
> > > the drm atomic state. Also , "Failed to create MST payload for port"
> > > indicates
> > > error while configuring DPCD payload ID table. Could you help to provide
> > > log
> > > with KMS + ATOMIC + DP debug on please? Thanks in advance!
> > >
> > > Regards,
> > > Wayne
> > >
> >
> > Possibly. I'm not that familiar with display driver debugging. Can you
> > send me some directions on how to crank up that sort of debug logging?
> >
> > Note that this problem is _very_ intermittent too: I went about 2 weeks
> > between crashes, and then I got 3 in one day. I'd rather not run with a
> > lot of debug logging for a long time if that's what this is going to
> > require, as this is my main workstation.
> >
> > The last time I got this log message, my proposed patch did prevent the
> > box from oopsing, so I'd really like to see it go in unless it's just
> > categorically wrong for the caller to pass down a NULL state pointer to
> > drm_dp_add_payload_part2.
>
> Cc: Lyude.
>
> Looks like the state parameter was added in commit 4d07b0bc4034
> ("drm/display/dp_mst: Move all payload info into the atomic state") and
> its only use is to get at state->dev for debug logging.
>
> What's the plan for the parameter? Surely something more than that! :)
I don't think there was any plan for that, or at least I certainly don't even
remember adding that D:. It must totally have been by mistake and snuck by
review, if that's the only thing that we're using it for I'd say it's
definitely fine to just drop it entirely
>
> Instead of "state ? state->dev : NULL" I guess we could use mgr->dev
> like the other logging calls do. It's papering over the NULL parameter
> too, but perhaps in a slightly cleaner way...
>
>
> BR,
> Jani.
>
>
> >
> > > > -Original Message-
> > > > From: Alex Deucher
> > > > Sent: Thursday, April 13, 2023 8:59 PM
> > > > To: Jani Nikula ; Lin, Wayne
> > > >
> > > > Cc: Jeff Layton ; David Airlie ;
> > > > Daniel Vetter ; Deucher, Alexander
> > > > ; linux-ker...@vger.kernel.org; dri-
> > > > de...@lists.freedesktop.org
> > > > Subject: Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully
> > > > handle NULL state pointer
> > > >
> > > > + Wayne
> > > >
> > > > On Thu, Apr 13, 2023 at 8:31 AM Jani Nikula
> > > >
> > > > wrote:
> > > > >
> > > > > On Thu, 13 Apr 2023, Jeff Layton wrote:
> > > > > > I've been experiencing some intermittent crashes down in the display
> > > > > > driver code. The symptoms are ususally a line like this in dmesg:
> > > > > >
> > > > > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
> > > > > > 6d3a3885: -5
> > > > > >
> > > > > > ...followed by an Oops due to a NULL pointer dereference.
> > > > > >
> > > > > > The real bug is probably in the caller of this function, which is
> > > > > > passing it a NULL state pointer, but this patch at least keeps my
> > > > > > machine from oopsing when this occurs.
> > > > >
> > > > > My fear is that papering over this makes the root cause harder to
> > > > > find.
> > > > >
> > > > > Cc: Harry, Alex
> > > > >
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > >
> > > > > >
> > > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
> > > > > > Signed-off-by: Jeff Layton
> > > > > > ---
> > > > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
> > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > index 38dab76ae69e..87ad406c50f9 100644
> > > > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > > > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
> > > > > > drm_dp_mst_topology_mgr *mgr,
> > > > > >
> > > > > > /* Skip failed payloads */
> > > > > > if (payload->vc_start_slot == -1) {
> > > > > > - drm_dbg_kms(state->dev, "Part 1 of payload creation
> > > > > > for %s
> > > > failed, skipping part 2\n",
> > > > > > + drm_dbg_kms(state ? state->dev : NULL,
> > > > > > + "Part 1 of payload creation for %s failed,
> > > > > > + skipping part 2\n",
> > > > > > payload->port->connector->name);
> > > > > > return -EIO;
> > > > > > }
> > > > >
> > > > > --
> > > > > Jani Nikula, Intel Open Source Graphics Center
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH v2] drm/i915: Fix memory leaks in i915 selftests
From: Cong Liu
This patch fixes memory leaks on error escapes in function fake_get_pages
Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
creation")
Signed-off-by: Cong Liu
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
Hi,
just resending this patch as I don't see it in our patchwork.
Andi
Changelong
==
v1 -> v2
- Add r-b tags
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 5361ce70d3f29..154801f1c4685 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -69,8 +69,10 @@ static int fake_get_pages(struct drm_i915_gem_object *obj)
rem = round_up(obj->base.size, BIT(31)) >> 31;
/* restricted by sg_alloc_table */
- if (overflows_type(rem, unsigned int))
+ if (overflows_type(rem, unsigned int)) {
+ kfree(pages);
return -E2BIG;
+ }
if (sg_alloc_table(pages, rem, GFP)) {
kfree(pages);
--
2.39.2
[PATCH v3] drm/i915/guc/slpc: Provide sysfs for efficient freq
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface.
v2: Keep just one interface to toggle sysfs. With this, user will
be completely responsible for toggling efficient frequency if need
be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)
v3: Fix compile error
Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 35 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 43 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 1 +
4 files changed, 69 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..7496de5be580 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject
*kobj,
return sysfs_emit(buff, "%u\n", preq);
}
+static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+
+ return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
+}
+
+static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+ int err;
+ uint32_t val;
+
+ err = kstrtou32(buff, 0, &val);
+ if (err)
+ return err;
+
+ err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
+ return err ?: count;
+}
+
struct intel_gt_bool_throttle_attr {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
@@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale =
INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
+INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
+
static const struct attribute *media_perf_power_attrs[] = {
&attr_media_freq_factor.attr,
&attr_media_freq_factor_scale.attr,
@@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
if (ret)
gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)",
ERR_PTR(ret));
+ if (intel_uc_uses_guc_slpc(>->uc)) {
+ ret = sysfs_create_file(kobj, &attr_slpc_ignore_eff_freq.attr);
+ if (ret)
+ gt_warn(gt, "failed to create ignore_eff_freq sysfs
(%pe)", ERR_PTR(ret));
+ }
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 026d73855f36..5668f00f02e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
slpc->max_freq_softlimit = 0;
slpc->min_freq_softlimit = 0;
+ slpc->ignore_eff_freq = false;
slpc->min_is_rpmax = false;
slpc->boost_freq = 0;
@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
*slpc, u32 *val)
return ret;
}
+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
+{
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+ int ret = 0;
+
+ /* Need a lock now since waitboost can be modifying min as well */
+ mutex_lock(&slpc->lock);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ /* Ignore efficient freq if lower min freq is requested */
+ ret = slpc_set_param(slpc,
+SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
+val);
+ if (ret) {
+ guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
freq(%d): %pe\n",
+ val, ERR_PTR(ret));
+ goto out;
+ }
+
+ slpc->ignore_eff_freq = val;
+
+out:
+ intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+ mutex_unlock(&slpc->lock);
+
[PATCH v2] drm/i915/guc/slpc: Provide sysfs for efficient freq
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface.
v2: Keep just one interface to toggle sysfs. With this, user will
be completely responsible for toggling efficient frequency if need
be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)
Signed-off-by: Vinay Belgaumkar
Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 35 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 44 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 1 +
4 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..7496de5be580 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject
*kobj,
return sysfs_emit(buff, "%u\n", preq);
}
+static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+
+ return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
+}
+
+static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+ int err;
+ uint32_t val;
+
+ err = kstrtou32(buff, 0, &val);
+ if (err)
+ return err;
+
+ err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
+ return err ?: count;
+}
+
struct intel_gt_bool_throttle_attr {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
@@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale =
INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
+INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
+
static const struct attribute *media_perf_power_attrs[] = {
&attr_media_freq_factor.attr,
&attr_media_freq_factor_scale.attr,
@@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
if (ret)
gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)",
ERR_PTR(ret));
+ if (intel_uc_uses_guc_slpc(>->uc)) {
+ ret = sysfs_create_file(kobj, &attr_slpc_ignore_eff_freq.attr);
+ if (ret)
+ gt_warn(gt, "failed to create ignore_eff_freq sysfs
(%pe)", ERR_PTR(ret));
+ }
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 026d73855f36..f214a9d533f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
slpc->max_freq_softlimit = 0;
slpc->min_freq_softlimit = 0;
+ slpc->ignore_eff_freq = false;
slpc->min_is_rpmax = false;
slpc->boost_freq = 0;
@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
*slpc, u32 *val)
return ret;
}
+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
+{
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+ int ret = 0;
+
+ /* Need a lock now since waitboost can be modifying min as well */
+ mutex_lock(&slpc->lock);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ /* Ignore efficient freq if lower min freq is requested */
+ ret = slpc_set_param(slpc,
+SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
+val);
+ if (ret) {
+ guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
freq(%d): %pe\n",
+ val, ERR_PTR(ret));
+ goto out;
+ }
+
+ slpc->ignore_eff_freq = val;
+
+out:
+ intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+ mutex_unlock(&slpc->lock);
+ return ret;
+}
+
/**
* intel_guc_slpc_set
Re: [PATCH] drm/amd/pm: change pmfw_decoded_link_width, speed variables to globals
Applied. Thanks!
Alex
On Fri, Apr 14, 2023 at 8:04 AM Tom Rix wrote:
>
> gcc with W=1 reports
> In file included from
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0.c:36:
> ./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/inc/smu_v13_0.h:66:18: error:
> ‘pmfw_decoded_link_width’ defined but not used
> [-Werror=unused-const-variable=]
>66 | static const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
> | ^~~
> ./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/inc/smu_v13_0.h:65:18: error:
> ‘pmfw_decoded_link_speed’ defined but not used
> [-Werror=unused-const-variable=]
>65 | static const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
> | ^~~
>
> These variables are defined and used in smu_v13_0_7_ppt.c and
> smu_v13_0_0_ppt.c.
> There should be only one definition. So define the variables as globals
> in smu_v13_0.c
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 4 ++--
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> index 7944ce80e5c3..df3baaab0037 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> @@ -62,8 +62,8 @@
> #define CTF_OFFSET_HOTSPOT 5
> #define CTF_OFFSET_MEM 5
>
> -static const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
> -static const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
> +extern const int pmfw_decoded_link_speed[5];
> +extern const int pmfw_decoded_link_width[7];
>
> #define DECODE_GEN_SPEED(gen_speed_idx)
> (pmfw_decoded_link_speed[gen_speed_idx])
> #define DECODE_LANE_WIDTH(lane_width_idx)
> (pmfw_decoded_link_width[lane_width_idx])
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> index 73175c993da9..393c6a7b9609 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> @@ -85,6 +85,9 @@ MODULE_FIRMWARE("amdgpu/smu_13_0_10.bin");
> static const int link_width[] = {0, 1, 2, 4, 8, 12, 16};
> static const int link_speed[] = {25, 50, 80, 160};
>
> +const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
> +const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
> +
> int smu_v13_0_init_microcode(struct smu_context *smu)
> {
> struct amdgpu_device *adev = smu->adev;
> --
> 2.27.0
>
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 1:58 PM, Dmitry Baryshkov wrote:
On Fri, 14 Apr 2023 at 21:55, Abhinav Kumar wrote:
On 4/14/2023 10:28 AM, Marijn Suijten wrote:
On 2023-04-14 08:41:37, Abhinav Kumar wrote:
On 4/14/2023 12:48 AM, Marijn Suijten wrote:
Capitalize DSC in the title, as discussed in v1.
On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
In current code, the DSC active bits are written only if cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
By default git send-email should pick this up in the CC line... but I
had to download this patch from lore once again.
Yes, I think what happened here is, he didnt git am the prev rev and
make changes on top of that so git send-email didnt pick up. We should
fix that process.
The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file. I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).
Yes, ofcourse git send-email was used to send the patch, not any other
mail client.
Yes i am also aware that send-email converts rb to CC.
But if you keep working on the local branch, then you would have to
manually add the r-bs. If you use am of the prev version and develop on
that, it will automatically add the r-bs.
It looks like there is some misunderstanding here. I think Marijn
doesn't question his R-B (which was present), but tries to point out
that Kuogee might want to adjust his git-send-email invocation. By
default (and that's a good practice, which we should follow),
git-send-email will CC people mentioned in such tags. Marijn didn't
get this email. So, it seems, for some reason this Cc: _mail_ header
was suppressed. Probably git-send-email invocation should be changed
to prevent suppression of adding mentioned people to CC lists.
Yeah I understood that part. There were two issues here:
1) My r-b got dropped and that was because am wasn't used to
automatically retain tags from prev version.
If you dont add the r-bs either manually or by am, then folks wont be
part of CC either
2) I synced with kuogee. his git version seems to be quite old which is
not adding the folks from r-b to cc. So there was nothing wrong with
invocation, just versioning.
I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions. It even
requires a changelog to be edited ;). However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
There's more wrong than just moving (not "fix"ing) this bit of code into
reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
again by reverting this patch. Perhaps that can be explained, or link
to Abhinav's explanation to make it clear to readers what this FIXME
actually means? Let's wait for Abhinav and Dmitry to confirm the
desired communication here.
https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
Yes, I am fine with linking this explanation in the commit text and
mentioning that till thats fixed, we need to go with this solution. The
FIXME itself is fine, I will work on it and I remember this context well.
Looks like it was removed entirely in v3, in favour of only describing
it in the patch body. The wording seems a bit off but that's fine by me
if you're picking this up soon anyway.
- Marijn
Re: [PATCH v3] drm/msm/dpu: always program DSC active bits
On Fri, 14 Apr 2023 at 19:46, Kuogee Hsieh wrote:
>
> In current code, the dsc active bits are set only if the cfg->dsc is set.
> However, for displays which are hot-pluggable, there can be a use-case
> of disconnecting a DSC supported sink and connecting a non-DSC sink.
>
> For those cases we need to clear DSC active bits during teardown.
>
> As discuss at [1], clear DSC active bit will handled at reset_intf_cfg()
nit: discussed
>
> Signed-off-by: Kuogee Hsieh
> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Reviewed-by: Abhinav Kumar
> Reviewed-by: Marijn Suijten
>
> [1]
> https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
> ---
Changelog? This is v3 already, but it has no changes described.
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95c..88e4efe 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl
> *ctx,
> if (cfg->merge_3d)
> DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
> - if (cfg->dsc) {
> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> - }
> +
And the comment got dropped. Please restore it in some form.
> + DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> + DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> }
>
> static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
With best wishes
Dmitry
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On Fri, 14 Apr 2023 at 21:55, Abhinav Kumar wrote:
>
>
>
> On 4/14/2023 10:28 AM, Marijn Suijten wrote:
> > On 2023-04-14 08:41:37, Abhinav Kumar wrote:
> >>
> >> On 4/14/2023 12:48 AM, Marijn Suijten wrote:
> >>> Capitalize DSC in the title, as discussed in v1.
> >>>
> >>> On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
> In current code, the DSC active bits are written only if cfg->dsc is set.
> However, for displays which are hot-pluggable, there can be a use-case
> of disconnecting a DSC supported sink and connecting a non-DSC sink.
>
> For those cases we need to clear DSC active bits during tear down.
>
> Changes in V2:
> 1) correct commit text as suggested
> 2) correct Fixes commit id
> 3) add FIXME comment
>
> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Marijn Suijten
> >>>
> >>> By default git send-email should pick this up in the CC line... but I
> >>> had to download this patch from lore once again.
> >>>
> >>
> >> Yes, I think what happened here is, he didnt git am the prev rev and
> >> make changes on top of that so git send-email didnt pick up. We should
> >> fix that process.
> >
> > The mail was sent so it must have gone through git send-email, unless a
> > different mail client was used to send the .patch file. I think you are
> > confusing this with git am (which doesn't need to be used if editing a
> > commit on a local branch) and subsequently git format-patch, which takes
> > a commit from a git repository and turns it into a .patch file: neither
> > of these "converts" r-b's (and other tags) to cc, that's happening in
> > git send-email (see `--suppress-cc` documentation in `man
> > git-send-email`).
> >
>
> Yes, ofcourse git send-email was used to send the patch, not any other
> mail client.
>
> Yes i am also aware that send-email converts rb to CC.
>
> But if you keep working on the local branch, then you would have to
> manually add the r-bs. If you use am of the prev version and develop on
> that, it will automatically add the r-bs.
It looks like there is some misunderstanding here. I think Marijn
doesn't question his R-B (which was present), but tries to point out
that Kuogee might want to adjust his git-send-email invocation. By
default (and that's a good practice, which we should follow),
git-send-email will CC people mentioned in such tags. Marijn didn't
get this email. So, it seems, for some reason this Cc: _mail_ header
was suppressed. Probably git-send-email invocation should be changed
to prevent suppression of adding mentioned people to CC lists.
>
>
> > I can recommend b4: it has lots of useful features including
> > automatically picking up reviews and processing revisions. It even
> > requires a changelog to be edited ;). However, finding the right flags
> > and trusting it'll "do as ordered" is a bit daunting at first.
> >
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95c..1651cd7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct
> dpu_hw_ctl *ctx,
> if (cfg->merge_3d)
> DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
> - if (cfg->dsc) {
> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> - }
> +
> + /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
> >>>
> >>> There's more wrong than just moving (not "fix"ing) this bit of code into
> >>> reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
> >>> again by reverting this patch. Perhaps that can be explained, or link
> >>> to Abhinav's explanation to make it clear to readers what this FIXME
> >>> actually means? Let's wait for Abhinav and Dmitry to confirm the
> >>> desired communication here.
> >>>
> >>> https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
> >>>
> >>
> >> Yes, I am fine with linking this explanation in the commit text and
> >> mentioning that till thats fixed, we need to go with this solution. The
> >> FIXME itself is fine, I will work on it and I remember this context well.
> >
> > Looks like it was removed entirely in v3, in favour of only describing
> > it in the patch body. The wording seems a bit off but that's fine by me
> > if you're picking this up soon anyway.
> >
> > - Marijn
--
With best wishes
Dmitry
[pull] amdgpu, amdkfd drm-next-6.4
Hi Dave, Daniel, Last few changes for 6.4. The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585: Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next (2023-04-11 12:28:10 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.4-2023-04-14 for you to fetch changes up to 541372bb62f289f4402cf55be51fb9cec7373627: drm/amdgpu: add some basic elements for multiple XCD case (2023-04-14 13:47:49 -0400) amd-drm-next-6.4-2023-04-14: amdgpu: - S4 fixes for APUs - GFX11 fixes - Misc code cleanups - DCN 3.2 fixes - DCN 3.1.4 fixes - FPO/FAMS work to improve display power savings - DP fixes - UMC 8.10 code cleanup - SDMA v4 fix - GPU clock counter fixes - SMU 13 fixes - Sdma v6 invalidation fix for preemption - RAS fixes - S0ix fix - GC 9.4.3 updates amdkfd: - Fix user pointers with IOMMU - Fix coherency flag handling Aaron Liu (1): drm/amdgpu: skip kfd-iommu suspend/resume for S0ix Alex Deucher (1): drm/amdgpu: simplify amdgpu_ras_eeprom.c Alvin Lee (3): drm/amd/display: Clear FAMS flag if FAMS doesn't reduce vlevel drm/amd/display: Add FPO + VActive support drm/amd/display: On clock init, maintain DISPCLK freq Amber Lin (1): drm/amdkfd: Enable HW_UPDATE_RPTR on GC 9.4.3 Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.161.0 Aric Cyr (1): drm/amd/display: 3.2.230 Arvind Yadav (1): drm/amdgpu: add new parameters in v11_struct Charlene Liu (1): drm/amd/display: add dscclk instance offset check Evan Quan (1): drm/amd/pm: correct the pcie link state check for SMU13 Graham Sider (2): drm/amdgpu: Enable GFX11 SDMA context empty interrupt drm/amdkfd: Add gfx_target_version for GC 9.4.3 Guilherme G. Piccoli (1): drm/amd/pm: Fix incorrect comment about Vangogh power cap support Hamza Mahfooz (1): drm/amd/display: prep work for root clock optimization enablement for DCN314 Hawking Zhang (5): drm/amdgpu: drop temp programming for pagefault handling drm/amdgpu: add gc v9_4_3 rlc_funcs implementation drm/amdgpu: switch to v9_4_3 gfx_funcs callbacks for GC 9.4.3 drm/amdgpu: add common early init support for GC 9.4.3 drm/amdgpu: add common ip block for GC 9.4.3 Horatio Zhang (2): drm/amd/pm: correct SMU13.0.7 pstate profiling clock settings drm/amd/pm: correct SMU13.0.7 max shader clock reporting Igor Artemiev (1): drm/amd/display: Fix potential null dereference Jack Xiao (1): drm/amd/amdgpu: introduce gc_*_mes_2.bin v2 Jane Jian (1): Revert "drm/amdgpu: enable ras for mp0 v13_0_10 on SRIOV" Jesse Zhang (2): drm/amdgpu: switch to golden tsc registers for raven/raven2 drm/amdgpu: change the reference clock for raven/raven2 Le Ma (2): drm/amdgpu: move vmhub out of amdgpu_ring_funcs (v4) drm/amdgpu: add some basic elements for multiple XCD case Li Ma (1): drm/amdgpu: reserve the old gc_11_0_*_mes.bin Lijo Lazar (1): drm/amdgpu: Fix warnings Mario Limonciello (1): drm/amd: Fix an out of bounds error in BIOS parser Michael Strauss (1): drm/amd/display: Improve robustness of FIXED_VS link training at DP1 rates Mukul Joshi (2): drm/amdgpu: Enable IH retry CAM on GFX9 drm/amdgpu: Rework retry fault removal Paul Hsieh (1): drm/amd/display: Correct DML calculation to follow HW SPEC Pierre-Eric Pelloux-Prayer (1): drm/amdgpu: use sdma_v6 single packet invalidation Shane Xiao (3): drm/amdgpu: Add userptr bo support for mGPUs when iommu is on amd/amdgpu: Inherit coherence flags base on original BO flags drm/amdgpu: DROP redundant drm_prime_sg_to_dma_addr_array Shashank Sharma (2): drm/amdgpu: rename num_doorbells drm/amdgpu: include protection for doorbell.h Sreekant Somasekharan (1): drm/amdkfd: Check PCIe atomics support on GFX11 to set CP_HQD_HQ_STATUS0[29] Srinivasan Shanmugam (5): drm/amd/amdgpu: Drop the hang limit parameter drm/amd/display : Log DP link training downspread info drm/amd/display: Add logging for DP link traning Test Pattern Seqeunces drm/amd/display: Add logging when setting DP sink power state fails drm/amd/display: Add logging when DP link training Clock recovery is Successful Stanley.Yang (2): drm/amdgpu: fix unexpected block id drm/amdgpu: correct ras enabled flag Tim Huang (1): drm/amdgpu: allow more APUs to do mode2 reset when go to S4 Tom Rix (6): drm/amd/display: remove unused average_render_time_in_us and i variables drm/amd/display: set variable dcn3_14_soc storage-class-specifier to static drm/amd/display: set variables aperture_default_system and context0
Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector
Hi Francesco,
On 14-Apr-23 14:00, Francesco Dolcini wrote:
> Hello Aradhya,
>
> On Fri, Apr 14, 2023 at 01:19:38PM +0530, Aradhya Bhatia wrote:
>> On 30-Mar-23 22:47, Francesco Dolcini wrote:
>>> Hello,
>>> chiming in in this *old* email thread.
>>>
>>> Adding in copy a few more *@ti.com people recently involved in other tidss
>>> changes [1]
>>>
>>>
>>> [1] https://lore.kernel.org/all/20230125113529.13952-1-a-bhat...@ti.com/
>>>
>>>
>>> On Fri, Dec 04, 2020 at 11:50:30AM +0100, Boris Brezillon wrote:
On Tue, 1 Dec 2020 17:48:28 +0530
Nikhil Devshatwar wrote:
> Remove the old code to iterate over the bridge chain, as this is
> already done by the framework.
> The bridge state should have the negotiated bus format and flags.
> Use these from the bridge's state.
> If the bridge does not support format negotiation, error out
> and fail.
That'd be even better if you implement the bridge interface instead of
the encoder one so we can get rid of the encoder_{helper}_funcs and use
drm_simple_encoder_init().
>>>
>>> Did anything happened on this old discussion? I was working on a very
>>> similar change and after a while I realized about this thread.
>>>
>> Nikhil has moved on from TI.
>>
>> I will be taking up this patch series and implement the changes
>> requested.
> Great!
>
> What I was working on is really about having the media bus format taken
> from the closest bridge, this is really required for proper functionality
> when the display is connected through a bridge.
I agree with you there. The current code will not work well when the
media bus format required by the final sink is not same as the one tidss
needs to output.
>
> This [1] is what I was working on before realizing about this specific
> patch here, in case you want to have a look.
>
> Please keep me in CC, I can test/review patches.
Thank you! Will do. =)
Regards
Aradhya
[PATCH 2/2] accel/qaic: Add MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE
AIC100 does not initialize the SOC_HW_VERSION MHI register as expected.
Some instances of AIC100 are observed to have 0x in this register
which makes the controller think that the link is down and return an error
up to MHI. This results in a failed initialization.
Allow these cards to initialize by advertisting
MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE in the MHI controller.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Carl Vanderlip
---
drivers/accel/qaic/mhi_controller.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/accel/qaic/mhi_controller.c
b/drivers/accel/qaic/mhi_controller.c
index 5036e58..2c85063 100644
--- a/drivers/accel/qaic/mhi_controller.c
+++ b/drivers/accel/qaic/mhi_controller.c
@@ -400,6 +400,7 @@ static struct mhi_controller_config aic100_config = {
.event_cfg = aic100_events,
.use_bounce_buf = false,
.m2_no_db = false,
+ .quirks = MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE,
};
static int mhi_read_reg(struct mhi_controller *mhi_cntrl, void __iomem *addr,
u32 *out)
--
2.7.4
[PATCH 1/2] bus: mhi: host: Add quirk framework and initial quirk
Some devices might require special handling due to flawed implementations
or other reasons. Implement a quirk framework to handle these situations.
Implement the first quirk in this framework -
MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE
The MHI spec indicates that the MHI device must initialize the
SOC_HW_VERSION register before the link to the MHI device is initialized.
The MHI host implementation uses this register as a quick check to see if
the device can be accessed early in the init process.
If an implementation is flawed, and does not properly initialize this
register, it may contain garbage data. In the case of PCIe, the value
0x has special meaning and can indicate that the link is down.
Such an implementation may cause MHI to believe the device cannot be
initialized.
Allow such controller to indicate that the host implementation should not
access this register, and handle the access accordingly during MHI init.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Carl Vanderlip
---
drivers/bus/mhi/host/init.c | 13 +
include/linux/mhi.h | 18 ++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f72fcb6..2731b78 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -891,6 +891,8 @@ static int parse_config(struct mhi_controller *mhi_cntrl,
if (config->m2_no_db)
mhi_cntrl->db_access &= ~MHI_PM_M2;
+ mhi_cntrl->quirks = config->quirks;
+
return 0;
error_ev_cfg:
@@ -982,10 +984,13 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
}
/* Read the MHI device info */
- ret = mhi_read_reg(mhi_cntrl, mhi_cntrl->regs,
- SOC_HW_VERSION_OFFS, &soc_info);
- if (ret)
- goto err_destroy_wq;
+ if (mhi_cntrl->quirks & MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE) {
+ soc_info = 0;
+ else {
+ ret = mhi_read_reg(mhi_cntrl, mhi_cntrl->regs,
SOC_HW_VERSION_OFFS, &soc_info);
+ if (ret)
+ goto err_destroy_wq;
+ }
mhi_cntrl->family_number = FIELD_GET(SOC_HW_VERSION_FAM_NUM_BMSK,
soc_info);
mhi_cntrl->device_number = FIELD_GET(SOC_HW_VERSION_DEV_NUM_BMSK,
soc_info);
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index f6de4b6..830df51 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -17,6 +17,20 @@
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
+/*
+ * List of workarounds for devices that require behavior not specified in
+ * the standard.
+ */
+enum mhi_quirks {
+ /*
+* Some devices do not properly initialize the SOC_HW_VERSION register
+* in the BHI space. In some instances, the value is 0x which
+* may hold special meaning. In the case of such devices, do not read
+* the register.
+*/
+ MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE = BIT(0),
+};
+
struct mhi_chan;
struct mhi_event;
struct mhi_ctxt;
@@ -273,6 +287,7 @@ struct mhi_event_config {
* @event_cfg: Array of defined event rings
* @use_bounce_buf: Use a bounce buffer pool due to limited DDR access
* @m2_no_db: Host is not allowed to ring DB in M2 state
+ * @quirks: Workarounds for devices that require non-standard behavior
*/
struct mhi_controller_config {
u32 max_channels;
@@ -284,6 +299,7 @@ struct mhi_controller_config {
struct mhi_event_config *event_cfg;
bool use_bounce_buf;
bool m2_no_db;
+ u32 quirks;
};
/**
@@ -358,6 +374,7 @@ struct mhi_controller_config {
* @wake_set: Device wakeup set flag
* @irq_flags: irq flags passed to request_irq (optional)
* @mru: the default MRU for the MHI device
+ * @quirks: Workarounds for devices that require non-standard behavior
*
* Fields marked as (required) need to be populated by the controller driver
* before calling mhi_register_controller(). For the fields marked as
(optional)
@@ -452,6 +469,7 @@ struct mhi_controller {
bool wake_set;
unsigned long irq_flags;
u32 mru;
+ u32 quirks;
};
/**
--
2.7.4
[PATCH 0/2] Add MHI quirk for QAIC
With the QAIC driver in -next, I'd like to suggest some MHI changes that specific to AIC100 devices, but perhaps provide a framework for other device oddities. AIC100 devices technically violate the MHI spec in two ways. Sadly, these issues comes from the device hardware, so host SW needs to work around them. Thie first issue, presented in this series, has to do with the SOC_HW_VERSION register. This register is suposed to be initialized by the hardware prior to the MHI being accessable by the host to contain a version string for the SoC of the device. This could be used by the host MHI controller software to identify and handle version to version changes. The AIC100 hardware does not initialize this register, and thus it contains garbage. This would not be much of a problem normally - the QAIC driver would just never use it. However the MHI stack uses this register as part of the init sequence and if the controller reports that the register is inaccessable then the init sequence fails. On some AIC100 cards, the garbage value ends up being 0x which is PCIe spec defined to be a special value indicating the access failed. The MHI controller cannot tell if that value is a PCIe link issue, or just garbage. QAIC needs a way to tell MHI not to use this register. Other buses have a quirk mechanism - a way to describe oddities in a particular implementation that have some kind of workaround. Since this seems to be the first need for such a thing in MHI, introduce a quirk framework. The second issue AIC100 has involves the PK Hash registers. A solution for this is expected to be proposed in the near future and is anticipated to make use of the quirk framework proposed here. With PK Hash, there are two oddities to handle. AIC100 does not initialize these registers until the SBL is running, which is later than the spec indicates, and in practice is after MHI reads/caches them. Also, AIC100 does not have enough registers defined to fully report the 5 PK Hash slots, so a custom reporting format is defined by the device. Jeffrey Hugo (2): bus: mhi: host: Add quirk framework and initial quirk accel/qaic: Add MHI_QUIRK_SOC_HW_VERSION_UNRELIABLE drivers/accel/qaic/mhi_controller.c | 1 + drivers/bus/mhi/host/init.c | 13 + include/linux/mhi.h | 18 ++ 3 files changed, 28 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH] drm/amd/display: fix flickering caused by S/G mode
Currently, we allow the framebuffer for a given plane to move between
memory domains, however when that happens it causes the screen to
flicker, it is even possible for the framebuffer to change memory
domains on every plane update (causing a continuous flicker effect). So,
to fix this, don't perform an immediate flip in the aforementioned case.
Cc: sta...@vger.kernel.org
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 ++-
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index da3045fdcb6d..9a4e7408384a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7897,6 +7897,34 @@ static void amdgpu_dm_commit_cursors(struct
drm_atomic_state *state)
amdgpu_dm_plane_handle_cursor_update(plane,
old_plane_state);
}
+static inline uint32_t get_mem_type(struct amdgpu_device *adev,
+ struct drm_gem_object *obj,
+ bool check_domain)
+{
+ struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
+ uint32_t mem_type;
+
+ if (unlikely(amdgpu_bo_reserve(abo, true)))
+ return 0;
+
+ if (unlikely(dma_resv_reserve_fences(abo->tbo.base.resv, 1)))
+ goto err;
+
+ if (check_domain &&
+ amdgpu_display_supported_domains(adev, abo->flags) !=
+ (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT))
+ goto err;
+
+ mem_type = abo->tbo.resource->mem_type;
+ amdgpu_bo_unreserve(abo);
+
+ return mem_type;
+
+err:
+ amdgpu_bo_unreserve(abo);
+ return 0;
+}
+
static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
struct dc_state *dc_state,
struct drm_device *dev,
@@ -7916,6 +7944,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state,
pcrtc));
int planes_count = 0, vpos, hpos;
unsigned long flags;
+ uint32_t mem_type;
u32 target_vblank, last_flip_vblank;
bool vrr_active = amdgpu_dm_crtc_vrr_active(acrtc_state);
bool cursor_update = false;
@@ -8035,13 +8064,21 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
}
}
+ mem_type = get_mem_type(dm->adev, old_plane_state->fb->obj[0],
+ true);
+
/*
* Only allow immediate flips for fast updates that don't
-* change FB pitch, DCC state, rotation or mirroing.
+* change memory domain, FB pitch, DCC state, rotation or
+* mirroring.
*/
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
- acrtc_state->update_type == UPDATE_TYPE_FAST;
+ acrtc_state->update_type == UPDATE_TYPE_FAST &&
+ (!mem_type || (mem_type && get_mem_type(dm->adev,
+ fb->obj[0],
+ false) ==
+ mem_type));
timestamp_ns = ktime_get_ns();
bundle->flip_addrs[planes_count].flip_timestamp_in_us =
div_u64(timestamp_ns, 1000);
--
2.40.0
[PATCH 1/2] drm/vkms: allow full alpha blending on all planes
Before commit bc0d7fdefec6 ("drm: vkms: Supports to the case where
primary plane doesn't match the CRTC"), the composition was executed on
top of the primary plane. Therefore, the primary plane was not able to
support the alpha channel. After commit bc0d7fdefec6, this is possible,
as the composition is now executed on top of the CRTC.
So, allow all planes to support the alpha channel, making full alpha
blending possible in vkms.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_plane.c | 32 ++-
1 file changed, 2 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index c41cec7dcb70..70474c74b681 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -12,12 +12,6 @@
#include "vkms_formats.h"
static const u32 vkms_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_XRGB16161616,
- DRM_FORMAT_RGB565
-};
-
-static const u32 vkms_plane_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_XRGB16161616,
@@ -196,38 +190,16 @@ struct vkms_plane *vkms_plane_init(struct vkms_device
*vkmsdev,
enum drm_plane_type type, int index)
{
struct drm_device *dev = &vkmsdev->drm;
- const struct drm_plane_helper_funcs *funcs;
struct vkms_plane *plane;
- const u32 *formats;
- int nformats;
-
- switch (type) {
- case DRM_PLANE_TYPE_PRIMARY:
- formats = vkms_formats;
- nformats = ARRAY_SIZE(vkms_formats);
- funcs = &vkms_primary_helper_funcs;
- break;
- case DRM_PLANE_TYPE_CURSOR:
- case DRM_PLANE_TYPE_OVERLAY:
- formats = vkms_plane_formats;
- nformats = ARRAY_SIZE(vkms_plane_formats);
- funcs = &vkms_primary_helper_funcs;
- break;
- default:
- formats = vkms_formats;
- nformats = ARRAY_SIZE(vkms_formats);
- funcs = &vkms_primary_helper_funcs;
- break;
- }
plane = drmm_universal_plane_alloc(dev, struct vkms_plane, base, 1 <<
index,
&vkms_plane_funcs,
- formats, nformats,
+ vkms_formats,
ARRAY_SIZE(vkms_formats),
NULL, type, NULL);
if (IS_ERR(plane))
return plane;
- drm_plane_helper_add(&plane->base, funcs);
+ drm_plane_helper_add(&plane->base, &vkms_primary_helper_funcs);
return plane;
}
--
2.39.2
[PATCH 2/2] drm/vkms: Drop full alpha blending TODO
Now that VKMS supports full alpha blending on all planes, drop the "ARGB format on primary plane" and "Full alpha blending on all planes" tasks from the TODO list. Signed-off-by: Maíra Canal --- Documentation/gpu/vkms.rst | 5 - 1 file changed, 5 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 49db221c0f52..0f599c897614 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -118,13 +118,8 @@ Add Plane Features There's lots of plane features we could add support for: -- ARGB format on primary plane: blend the primary plane into background with - translucent alpha. - - Add background color KMS property[Good to get started]. -- Full alpha blending on all planes. - - Rotation, scaling. - Additional buffer formats, especially YUV formats for video like NV12. -- 2.39.2
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 11:55 AM, Abhinav Kumar wrote:
On 4/14/2023 10:28 AM, Marijn Suijten wrote:
On 2023-04-14 08:41:37, Abhinav Kumar wrote:
On 4/14/2023 12:48 AM, Marijn Suijten wrote:
Capitalize DSC in the title, as discussed in v1.
On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
In current code, the DSC active bits are written only if cfg->dsc
is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
By default git send-email should pick this up in the CC line... but I
had to download this patch from lore once again.
Yes, I think what happened here is, he didnt git am the prev rev and
make changes on top of that so git send-email didnt pick up. We should
fix that process.
The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file. I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).
Yes, ofcourse git send-email was used to send the patch, not any other
mail client.
Yes i am also aware that send-email converts rb to CC.
But if you keep working on the local branch, then you would have to
manually add the r-bs. If you use am of the prev version and develop on
that, it will automatically add the r-bs.
just a minor point, in case you didnt notice, my r-b was dropped too :)
due to manual propagation.
I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions. It even
requires a changelog to be edited ;). However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.
Ack.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct
dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
There's more wrong than just moving (not "fix"ing) this bit of code
into
reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
again by reverting this patch. Perhaps that can be explained, or link
to Abhinav's explanation to make it clear to readers what this FIXME
actually means? Let's wait for Abhinav and Dmitry to confirm the
desired communication here.
https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
Yes, I am fine with linking this explanation in the commit text and
mentioning that till thats fixed, we need to go with this solution. The
FIXME itself is fine, I will work on it and I remember this context
well.
Looks like it was removed entirely in v3, in favour of only describing
it in the patch body. The wording seems a bit off but that's fine by me
if you're picking this up soon anyway.
- Marijn
Re: [PATCH v2 1/7] drm/vkms: isolate pixel conversion functionality
On 14/04/23 10:51, Maíra Canal wrote:
> Currently, the pixel conversion functions repeat the same loop to
> iterate the rows. Instead of repeating the same code for each pixel
> format, create a function to wrap the loop and isolate the pixel
> conversion functionality.
>
> Suggested-by: Arthur Grillo
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 4 +-
> drivers/gpu/drm/vkms/vkms_drv.h | 4 +-
> drivers/gpu/drm/vkms/vkms_formats.c | 136 ---
> drivers/gpu/drm/vkms/vkms_formats.h | 2 +-
> drivers/gpu/drm/vkms/vkms_plane.c| 2 +-
> 5 files changed, 65 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 8e53fa80742b..80164e79af00 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -99,7 +99,7 @@ static void blend(struct vkms_writeback_job *wb,
> if (!check_y_limit(plane[i]->frame_info, y))
> continue;
>
> - plane[i]->plane_read(stage_buffer,
> plane[i]->frame_info, y);
> + vkms_compose_row(stage_buffer, plane[i], y);
> pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
> output_buffer);
> }
> @@ -118,7 +118,7 @@ static int check_format_funcs(struct vkms_crtc_state
> *crtc_state,
> u32 n_active_planes = crtc_state->num_active_planes;
>
> for (size_t i = 0; i < n_active_planes; i++)
> - if (!planes[i]->plane_read)
> + if (!planes[i]->pixel_read)
> return -1;
>
> if (active_wb && !active_wb->wb_write)
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 4a248567efb2..d7ad813d7ae7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -56,8 +56,7 @@ struct vkms_writeback_job { struct vkms_plane_state {
> struct drm_shadow_plane_state base;
> struct vkms_frame_info *frame_info;
> - void (*plane_read)(struct line_buffer *buffer,
> -const struct vkms_frame_info *frame_info, int y);
> + void (*pixel_read)(u16 *src_buffer, struct pixel_argb_u16 *out_pixels,
> int x);
> };
>
> struct vkms_plane {
> @@ -155,6 +154,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> /* Composer Support */
> void vkms_composer_worker(struct work_struct *work);
> void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_compose_row(struct line_buffer *stage_buffer, struct
> vkms_plane_state *plane, int y);
>
> /* Writeback */
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
> b/drivers/gpu/drm/vkms/vkms_formats.c
> index d4950688b3f1..02b0fc5a0839 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> @@ -42,100 +42,82 @@ static void *get_packed_src_addr(const struct
> vkms_frame_info *frame_info, int y
> return packed_pixels_addr(frame_info, x_src, y_src);
> }
>
> -static void ARGB_to_argb_u16(struct line_buffer *stage_buffer,
> - const struct vkms_frame_info *frame_info, int
> y)
> +static void ARGB_to_argb_u16(u16 *src_pixels, struct pixel_argb_u16
> *out_pixels, int x)
Do you need to pass the x coordinate? You don't change it on those
functions. By not passing it, the conversion function would be even more
isolated.
> {
> - struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
> - u8 *src_pixels = get_packed_src_addr(frame_info, y);
> - int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
> - stage_buffer->n_pixels);
> -
> - for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
> - /*
> - * The 257 is the "conversion ratio". This number is obtained
> by the
> - * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries
> to get
> - * the best color value in a pixel format with more
> possibilities.
> - * A similar idea applies to others RGB color conversions.
> - */
> - out_pixels[x].a = (u16)src_pixels[3] * 257;
> - out_pixels[x].r = (u16)src_pixels[2] * 257;
> - out_pixels[x].g = (u16)src_pixels[1] * 257;
> - out_pixels[x].b = (u16)src_pixels[0] * 257;
> - }
> + u8 *pixels = (u8 *)src_pixels;
> +
> + /*
> + * The 257 is the "conversion ratio". This number is obtained by the
> + * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
> + * the best color value in a pixel format with more possibilities.
> + * A similar idea applies to others RGB color conversions.
> + */
> + out_pixels[x].a = (u16)pixels[3] * 257
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 10:28 AM, Marijn Suijten wrote:
On 2023-04-14 08:41:37, Abhinav Kumar wrote:
On 4/14/2023 12:48 AM, Marijn Suijten wrote:
Capitalize DSC in the title, as discussed in v1.
On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
In current code, the DSC active bits are written only if cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
By default git send-email should pick this up in the CC line... but I
had to download this patch from lore once again.
Yes, I think what happened here is, he didnt git am the prev rev and
make changes on top of that so git send-email didnt pick up. We should
fix that process.
The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file. I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).
Yes, ofcourse git send-email was used to send the patch, not any other
mail client.
Yes i am also aware that send-email converts rb to CC.
But if you keep working on the local branch, then you would have to
manually add the r-bs. If you use am of the prev version and develop on
that, it will automatically add the r-bs.
I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions. It even
requires a changelog to be edited ;). However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
There's more wrong than just moving (not "fix"ing) this bit of code into
reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
again by reverting this patch. Perhaps that can be explained, or link
to Abhinav's explanation to make it clear to readers what this FIXME
actually means? Let's wait for Abhinav and Dmitry to confirm the
desired communication here.
https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
Yes, I am fine with linking this explanation in the commit text and
mentioning that till thats fixed, we need to go with this solution. The
FIXME itself is fine, I will work on it and I remember this context well.
Looks like it was removed entirely in v3, in favour of only describing
it in the patch body. The wording seems a bit off but that's fine by me
if you're picking this up soon anyway.
- Marijn
Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits
On 4/14/2023 10:34 AM, Marijn Suijten wrote: On 2023-04-14 08:48:43, Abhinav Kumar wrote: On 4/14/2023 12:35 AM, Marijn Suijten wrote: On 2023-04-12 10:33:15, Abhinav Kumar wrote: [..] What happens if a device boots without DSC panel connected? Will CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the DSC blocks? Or could this flush uninitialized state to the block? If we bootup without DSC panel connected, the kernel's cfg->dsc will be 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush any DSC blocks. Ack, that makes sense. However, if I connect a DSC panel, then disconnect it (now the register should be non-zero, but cfg->dsc will be zero), and then replug a non-DSC panel multiple times, it'll get flushed every time because we never clear CTL_DSC_FLUSH after that? If we remove it after kernel starts, that issue is there even today without that change because DSI is not a hot-pluggable display so a teardown wont happen when you plug out the panel. How will cfg->dsc be 0 then? In that case, its not a valid test as there was no indication to DRM that display was disconnected so we cannot tear it down. The patch description itself describes hot-pluggable displays, which I believe is the upcoming DSC support for DP? You ask how cfg->dsc can become zero, but this is **exactly** what the patch description describes, and what this patch is removing the `if` for. If we are not allowed to discuss that scenario because it is not currently supported, neither should we allow to apply this patch. With that in mind, can you re-answer the question? I didnt follow what needs to be re-answered. This patch is being sent in preparation of the DSC over DP support. This does not handle non-hotpluggable displays. I do not think dynamic switch between DSC and non-DSC of non-hotpluggable displays needs to be discussed here as its not handled at all with or without this patch. We wanted to get early reviews on the patch. If you want this patch to be absorbed when rest of DSC over DP lands, I have no concerns with that. I wont pick this up for fixes and we will land this together with the rest of DP over DSC. - Marijn
Re: [PATCH] drm/i915/gt: Mask media GuC interrupts
Hi Daniele, > > MTL features a dedicated media engine that operates on its > > independent GT, requiring activation of its specific interrupt > > set. > > > > Enable the necessary interrupts in a single action when the media > > engine is present, bypassing the need to iterate through all the > > GTs. > > > > Signed-off-by: Andi Shyti > > --- > > Hi, > > > > I'm starting with v0 as this patch is very different from the > > ones proposed recently. > > > > After all the discussions on this patch, I took Matt's suggestion > > since it seemed the most immediate. > > > > However, in the long run, I agree that we should have a > > specific mtl_ function for enabling interrupts. > > > > Thank you Matt and Daniele for your input. > > > > If this patch hasn't missed anything, is it too optimistic to > > expect MTL to boot? :-) > > The GSC engine also has interrupts tied to the media GT and those are > conditional, so that engine won't work with just this patch. The system > might boot because the GSC engine gets disabled if the FW is not there, but > IMO if we want a single function to handle both GTs we need to do it proper > support for the engines and not hack around just the GuC. yeah... we are already having too many things to handle and at this point I don't see any better way to handle this other than using for_each_gt() as it was first sent. Besides, they are different GT's, why not using for_each_gt? Thank you, Daniele, Andi
Re: [PATCH v2 6/7] drm/vkms: add reflect-y property
On 4/14/23 11:46, Ville Syrjälä wrote: On Fri, Apr 14, 2023 at 11:37:17AM -0300, Maíra Canal wrote: On 4/14/23 11:24, Ville Syrjälä wrote: On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra Canal wrote: Currently, vkms only support the reflect-x property. Therefore, add the reflect-y property to vkms through a software implementation of the operation. This is possible by reverse reading the y axis during the blending. Now, vkms support all possible rotation values. Tested with igt@kms_rotation_crc@primary-reflect-y and igt@kms_rotation_crc@sprite-reflect-y [1]. [1] https://patchwork.freedesktop.org/series/116025/ Signed-off-by: Maíra Canal --- drivers/gpu/drm/vkms/vkms_composer.c | 7 ++- drivers/gpu/drm/vkms/vkms_plane.c| 16 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index b05bd008aeab..19d1078e9d34 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -92,8 +92,13 @@ static int get_y_pos(struct vkms_frame_info *frame_info, int y) return -1; return y + frame_info->dst.x1; default: - return y; + break; } + + if (frame_info->rotation & DRM_MODE_REFLECT_Y) + return drm_rect_height(&frame_info->dst) - y - 1; + + return y; } static bool check_limit(struct vkms_frame_info *frame_info, int pos) diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 11662afa9fe4..d08bda869a24 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -121,12 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info->fb = fb; memcpy(&frame_info->map, &shadow_plane_state->data, sizeof(frame_info->map)); drm_framebuffer_get(frame_info->fb); - frame_info->rotation = drm_rotation_simplify(new_state->rotation, -DRM_MODE_ROTATE_0 | -DRM_MODE_ROTATE_90 | -DRM_MODE_ROTATE_180 | -DRM_MODE_ROTATE_270 | -DRM_MODE_REFLECT_X); + frame_info->rotation = drm_rotation_simplify(new_state->rotation, DRM_MODE_ROTATE_MASK | +DRM_MODE_REFLECT_MASK); What are you trying to achieve with that? Yeah, seeing it right now I can see that this is not achieving anything. I will remove it in the next version. I think using it might still make sense to eg. remove the 180/270 cases from your actual rendering code. I will remove it on the next version. I'm also a bit uneasy about all that hand rolled coordinate calculation stuff. Ideally drm_rect_rotate*() should handle all that for you, and make sure the rotate vs. reflect actually get applied in the correct order. At first, I had a similar idea that drm_rect_rotate() would handle all the rotation. But, this turn out to be untrue. From what I can see, although the drm_rect_rotate() helps by performing the coordinates rotation, we also need to change the way the blending occurs. Although the coordinates have changed, the vmap stays the same and we will still start reading the vmap by the first line (y = 0). That's why we need to change the iteration boundaries in the blending loops. So, drm_rect_rotate() is a part of the solution, but it is not able to handle it completely. If you have any suggestions on how to perform the rotation without changing the way the blending occurs, I would be glad to hear. Unfortunately, just performing drm_rect_rotate() doesn't seem to be a solution. Best Regards, - Maíra Canal
Re: [PATCH] drm/msm/dpu: always program dsc active bits
On 2023-04-14 08:48:43, Abhinav Kumar wrote: > > On 4/14/2023 12:35 AM, Marijn Suijten wrote: > > On 2023-04-12 10:33:15, Abhinav Kumar wrote: > > [..] > >>> What happens if a device boots without DSC panel connected? Will > >>> CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the > >>> DSC blocks? Or could this flush uninitialized state to the block? > >>> > >> > >> If we bootup without DSC panel connected, the kernel's cfg->dsc will be > >> 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush > >> any DSC blocks. > > > > Ack, that makes sense. However, if I connect a DSC panel, then > > disconnect it (now the register should be non-zero, but cfg->dsc will be > > zero), and then replug a non-DSC panel multiple times, it'll get flushed > > every time because we never clear CTL_DSC_FLUSH after that? > > > > If we remove it after kernel starts, that issue is there even today > without that change because DSI is not a hot-pluggable display so a > teardown wont happen when you plug out the panel. How will cfg->dsc be 0 > then? In that case, its not a valid test as there was no indication to > DRM that display was disconnected so we cannot tear it down. The patch description itself describes hot-pluggable displays, which I believe is the upcoming DSC support for DP? You ask how cfg->dsc can become zero, but this is **exactly** what the patch description describes, and what this patch is removing the `if` for. If we are not allowed to discuss that scenario because it is not currently supported, neither should we allow to apply this patch. With that in mind, can you re-answer the question? - Marijn
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 2023-04-14 08:41:37, Abhinav Kumar wrote:
>
> On 4/14/2023 12:48 AM, Marijn Suijten wrote:
> > Capitalize DSC in the title, as discussed in v1.
> >
> > On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
> >> In current code, the DSC active bits are written only if cfg->dsc is set.
> >> However, for displays which are hot-pluggable, there can be a use-case
> >> of disconnecting a DSC supported sink and connecting a non-DSC sink.
> >>
> >> For those cases we need to clear DSC active bits during tear down.
> >>
> >> Changes in V2:
> >> 1) correct commit text as suggested
> >> 2) correct Fixes commit id
> >> 3) add FIXME comment
> >>
> >> Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
> >> Signed-off-by: Kuogee Hsieh
> >> Reviewed-by: Marijn Suijten
> >
> > By default git send-email should pick this up in the CC line... but I
> > had to download this patch from lore once again.
> >
>
> Yes, I think what happened here is, he didnt git am the prev rev and
> make changes on top of that so git send-email didnt pick up. We should
> fix that process.
The mail was sent so it must have gone through git send-email, unless a
different mail client was used to send the .patch file. I think you are
confusing this with git am (which doesn't need to be used if editing a
commit on a local branch) and subsequently git format-patch, which takes
a commit from a git repository and turns it into a .patch file: neither
of these "converts" r-b's (and other tags) to cc, that's happening in
git send-email (see `--suppress-cc` documentation in `man
git-send-email`).
I can recommend b4: it has lots of useful features including
automatically picking up reviews and processing revisions. It even
requires a changelog to be edited ;). However, finding the right flags
and trusting it'll "do as ordered" is a bit daunting at first.
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> index bbdc95c..1651cd7 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> >> @@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl
> >> *ctx,
> >>if (cfg->merge_3d)
> >>DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> >> BIT(cfg->merge_3d - MERGE_3D_0));
> >> - if (cfg->dsc) {
> >> - DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
> >> - DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> >> - }
> >> +
> >> + /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
> >
> > There's more wrong than just moving (not "fix"ing) this bit of code into
> > reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
> > again by reverting this patch. Perhaps that can be explained, or link
> > to Abhinav's explanation to make it clear to readers what this FIXME
> > actually means? Let's wait for Abhinav and Dmitry to confirm the
> > desired communication here.
> >
> > https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
> >
>
> Yes, I am fine with linking this explanation in the commit text and
> mentioning that till thats fixed, we need to go with this solution. The
> FIXME itself is fine, I will work on it and I remember this context well.
Looks like it was removed entirely in v3, in favour of only describing
it in the patch body. The wording seems a bit off but that's fine by me
if you're picking this up soon anyway.
- Marijn
Re: [PATCH] drm/i915/gt: Mask media GuC interrupts
On 4/14/2023 9:25 AM, Andi Shyti wrote:
MTL features a dedicated media engine that operates on its
independent GT, requiring activation of its specific interrupt
set.
Enable the necessary interrupts in a single action when the media
engine is present, bypassing the need to iterate through all the
GTs.
Signed-off-by: Andi Shyti
---
Hi,
I'm starting with v0 as this patch is very different from the
ones proposed recently.
After all the discussions on this patch, I took Matt's suggestion
since it seemed the most immediate.
However, in the long run, I agree that we should have a
specific mtl_ function for enabling interrupts.
Thank you Matt and Daniele for your input.
If this patch hasn't missed anything, is it too optimistic to
expect MTL to boot? :-)
The GSC engine also has interrupts tied to the media GT and those are
conditional, so that engine won't work with just this patch. The system
might boot because the GSC engine gets disabled if the FW is not there,
but IMO if we want a single function to handle both GTs we need to do it
proper support for the engines and not hack around just the GuC.
Daniele
Andi
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a60391522..162a27b4c4095 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -254,7 +254,6 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
u32 irqs = GT_RENDER_USER_INTERRUPT;
- u32 guc_mask = intel_uc_wants_guc(>->uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
u32 dmask;
u32 smask;
@@ -309,17 +308,20 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (gsc_mask)
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK,
~gsc_mask);
- if (guc_mask) {
+ if (intel_uc_wants_guc(>->uc)) {
+ u32 guc_mask = GUC_INTR_GUC2HOST;
/* the enable bit is common for both GTs but the masks are
separate */
- u32 mask = gt->type == GT_MEDIA ?
- REG_FIELD_PREP(ENGINE0_MASK, guc_mask) :
- REG_FIELD_PREP(ENGINE1_MASK, guc_mask);
+ u32 mask = REG_FIELD_PREP(ENGINE1_MASK, guc_mask);
+
+ /* Mask the GuC interrupts of media engine if present */
+ if (MEDIA_VER(gt->i915) >= 13)
+ mask |= REG_FIELD_PREP(ENGINE0_MASK, guc_mask);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE,
REG_FIELD_PREP(ENGINE1_MASK, guc_mask));
/* we might not be the first GT to write this reg */
- intel_uncore_rmw(uncore, MTL_GUC_MGUC_INTR_MASK, mask, 0);
+ intel_uncore_write(uncore, MTL_GUC_MGUC_INTR_MASK, mask);
}
/*
[RFC PATCH v2 2/2] drm/xe: switch to using drm_exec
Replace the use of ttm_execbuf_util helpers with the new drm_exec
helpers. They are only used when locking multiple objects.
Signed-off-by: Francois Dugast
---
drivers/gpu/drm/xe/xe_bo.c | 22 ++-
drivers/gpu/drm/xe/xe_bo_types.h | 1 -
drivers/gpu/drm/xe/xe_exec.c | 32 ++--
drivers/gpu/drm/xe/xe_gt_pagefault.c | 67 +
drivers/gpu/drm/xe/xe_vm.c | 217 +++
drivers/gpu/drm/xe/xe_vm.h | 19 +--
6 files changed, 159 insertions(+), 199 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 3ab404e33fae..ff707eadb96b 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1723,17 +1724,24 @@ int xe_gem_mmap_offset_ioctl(struct drm_device *dev,
void *data,
int xe_bo_lock(struct xe_bo *bo, struct ww_acquire_ctx *ww,
int num_resv, bool intr)
{
- struct ttm_validate_buffer tv_bo;
- LIST_HEAD(objs);
- LIST_HEAD(dups);
+ struct dma_resv *obj;
+ int ret;
XE_BUG_ON(!ww);
- tv_bo.num_shared = num_resv;
- tv_bo.bo = &bo->ttm;;
- list_add_tail(&tv_bo.head, &objs);
+ obj = bo->ttm.base.resv;
+ ww_acquire_init(ww, &reservation_ww_class);
+
+ if (intr)
+ ret = dma_resv_lock_interruptible(obj, ww);
+ else
+ ret = dma_resv_lock(obj, ww);
+
+ if (unlikely(ret))
+ return ret;
- return ttm_eu_reserve_buffers(ww, &objs, intr, &dups);
+ num_resv = max(num_resv, 1);
+ return dma_resv_reserve_fences(obj, num_resv);
}
void xe_bo_unlock(struct xe_bo *bo, struct ww_acquire_ctx *ww)
diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
index 06de3330211d..2ba34a8c9b66 100644
--- a/drivers/gpu/drm/xe/xe_bo_types.h
+++ b/drivers/gpu/drm/xe/xe_bo_types.h
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
struct xe_device;
diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c
index ea869f2452ef..ff41fa828c1c 100644
--- a/drivers/gpu/drm/xe/xe_exec.c
+++ b/drivers/gpu/drm/xe/xe_exec.c
@@ -6,6 +6,7 @@
#include "xe_exec.h"
#include
+#include
#include
#include
@@ -91,21 +92,16 @@
* Unlock all
*/
-static int xe_exec_begin(struct xe_engine *e, struct ww_acquire_ctx *ww,
-struct ttm_validate_buffer tv_onstack[],
-struct ttm_validate_buffer **tv,
-struct list_head *objs)
+static int xe_exec_begin(struct xe_engine *e, struct drm_exec *exec)
{
struct xe_vm *vm = e->vm;
struct xe_vma *vma;
- LIST_HEAD(dups);
int err;
- *tv = NULL;
if (xe_vm_no_dma_fences(e->vm))
return 0;
- err = xe_vm_lock_dma_resv(vm, ww, tv_onstack, tv, objs, true, 1);
+ err = xe_vm_lock_dma_resv(vm, exec, 1);
if (err)
return err;
@@ -120,8 +116,7 @@ static int xe_exec_begin(struct xe_engine *e, struct
ww_acquire_ctx *ww,
err = xe_bo_validate(vma->bo, vm, false);
if (err) {
- xe_vm_unlock_dma_resv(vm, tv_onstack, *tv, ww, objs);
- *tv = NULL;
+ xe_vm_unlock_dma_resv(vm);
return err;
}
}
@@ -129,14 +124,10 @@ static int xe_exec_begin(struct xe_engine *e, struct
ww_acquire_ctx *ww,
return 0;
}
-static void xe_exec_end(struct xe_engine *e,
- struct ttm_validate_buffer *tv_onstack,
- struct ttm_validate_buffer *tv,
- struct ww_acquire_ctx *ww,
- struct list_head *objs)
+static void xe_exec_end(struct xe_engine *e)
{
if (!xe_vm_no_dma_fences(e->vm))
- xe_vm_unlock_dma_resv(e->vm, tv_onstack, tv, ww, objs);
+ xe_vm_unlock_dma_resv(e->vm);
}
int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
@@ -149,14 +140,11 @@ int xe_exec_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
struct xe_engine *engine;
struct xe_sync_entry *syncs = NULL;
u64 addresses[XE_HW_ENGINE_MAX_INSTANCE];
- struct ttm_validate_buffer tv_onstack[XE_ONSTACK_TV];
- struct ttm_validate_buffer *tv = NULL;
u32 i, num_syncs = 0;
struct xe_sched_job *job;
struct dma_fence *rebind_fence;
struct xe_vm *vm;
- struct ww_acquire_ctx ww;
- struct list_head objs;
+ struct drm_exec exec;
bool write_locked;
int err = 0;
@@ -267,7 +255,8 @@ int xe_exec_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
goto err_unlock_list;
}
- err = xe_exec_begin(engine, &ww, tv_onstack, &tv, &objs);
+ drm_exec_i
[RFC PATCH v2 1/2] drm/xe: dependencies for next commit
This commit only here for others to test and for CI to build. It
is a squash of work by Christian König and Danilo Krummrich:
https://patchwork.freedesktop.org/series/114464/
https://patchwork.freedesktop.org/patch/530670/?series=112994&rev=4
---
Documentation/gpu/drm-mm.rst | 12 +
drivers/gpu/drm/Kconfig | 7 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 5 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 302 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 71 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 210 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 42 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 77 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 86 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 20 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 6 +-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 32 +-
drivers/gpu/drm/drm_exec.c| 248 ++
drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
drivers/gpu/drm/qxl/qxl_release.c | 67 ++--
drivers/gpu/drm/radeon/radeon.h | 7 +-
drivers/gpu/drm/radeon/radeon_cs.c| 45 +--
drivers/gpu/drm/radeon/radeon_gem.c | 40 ++-
drivers/gpu/drm/radeon/radeon_object.c| 25 +-
drivers/gpu/drm/radeon/radeon_object.h| 2 +-
drivers/gpu/drm/radeon/radeon_vm.c| 10 +-
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_exec_test.c | 73 +
drivers/gpu/drm/ttm/Makefile | 4 +-
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
.../drm/{ttm => vmwgfx}/ttm_execbuf_util.c| 7 +-
.../gpu/drm/vmwgfx}/ttm_execbuf_util.h| 0
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 2 +-
include/drm/drm_exec.h| 115 +++
34 files changed, 924 insertions(+), 620 deletions(-)
create mode 100644 drivers/gpu/drm/drm_exec.c
create mode 100644 drivers/gpu/drm/tests/drm_exec_test.c
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_execbuf_util.c (97%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_execbuf_util.h (100%)
create mode 100644 include/drm/drm_exec.h
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..a52e6f4117d6 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -493,6 +493,18 @@ DRM Sync Objects
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
+DRM Execution context
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :export:
+
GPU Scheduler
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e928284b4357..c15e9aaa0eca 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -80,6 +80,7 @@ config DRM_KUNIT_TEST
select DRM_BUDDY
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
+ select DRM_EXEC
default KUNIT_ALL_TESTS
help
This builds unit tests for DRM. This option is not useful for
@@ -201,6 +202,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_EXEC
+ tristate
+ depends on DRM
+ help
+ Execution context for command submissions
+
config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 66dd2c48944a..9c4461f0a665 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -79,6 +79,8 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) +=
drm_panel_orientation_quirks.o
#
# Memory-management helpers
#
+#
+obj-$(CONFIG_DRM_EXEC) += drm_exec.o
obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8cf2cc50b3de..ef1994798f89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -53,7 +53,6 @@
#include
#include
-#include
#include
#include
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 01ba3589b60a..dfb41d56d236 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -25,13 +25,13 @@
#ifndef AMDGPU_AMDKFD_H_INCLUDED
#define AMDGPU_AMDKFD_H_INCLUDED
+#include
#include
#include
#include
#include
#include
#include
-#include
#include "amdgpu_sync.h"
#include "amdgpu_vm.h"
[RFC PATCH v2 0/2] drm/xe: switch to using drm_exec
This makes Xe use the new drm_exec helpers provided
by this series, which is not merged yet:
https://patchwork.freedesktop.org/series/114464/
v2: add a first patch with squashed dependencies
Francois Dugast (2):
drm/xe: dependencies for next commit
drm/xe: switch to using drm_exec
Documentation/gpu/drm-mm.rst | 12 +
drivers/gpu/drm/Kconfig | 7 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 5 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 302 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 71 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 210 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 42 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 77 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 86 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 20 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 6 +-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 32 +-
drivers/gpu/drm/drm_exec.c| 248 ++
drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
drivers/gpu/drm/qxl/qxl_release.c | 67 ++--
drivers/gpu/drm/radeon/radeon.h | 7 +-
drivers/gpu/drm/radeon/radeon_cs.c| 45 +--
drivers/gpu/drm/radeon/radeon_gem.c | 40 ++-
drivers/gpu/drm/radeon/radeon_object.c| 25 +-
drivers/gpu/drm/radeon/radeon_object.h| 2 +-
drivers/gpu/drm/radeon/radeon_vm.c| 10 +-
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_exec_test.c | 73 +
drivers/gpu/drm/ttm/Makefile | 4 +-
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
.../drm/{ttm => vmwgfx}/ttm_execbuf_util.c| 7 +-
.../gpu/drm/vmwgfx}/ttm_execbuf_util.h| 0
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 2 +-
drivers/gpu/drm/xe/xe_bo.c| 22 +-
drivers/gpu/drm/xe/xe_bo_types.h | 1 -
drivers/gpu/drm/xe/xe_exec.c | 32 +-
drivers/gpu/drm/xe/xe_gt_pagefault.c | 67 ++--
drivers/gpu/drm/xe/xe_vm.c| 217 ++---
drivers/gpu/drm/xe/xe_vm.h| 19 +-
include/drm/drm_exec.h| 115 +++
40 files changed, 1083 insertions(+), 819 deletions(-)
create mode 100644 drivers/gpu/drm/drm_exec.c
create mode 100644 drivers/gpu/drm/tests/drm_exec_test.c
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_execbuf_util.c (97%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_execbuf_util.h (100%)
create mode 100644 include/drm/drm_exec.h
--
2.25.1
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Thu, Apr 13, 2023 at 11:47:25AM -0700, Nathan Chancellor wrote: > On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote: > select SND_HDA_COMPONENT if SND_HDA_CORE > # !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752 > - select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > KERNEL_MODE_NEON && !CC_IS_CLANG)) > + select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > KERNEL_MODE_NEON && !CC_IS_CLANG)) > help > Choose this option if you want to use the new display engine > support for AMDGPU. This adds required support for Vega and > Please consider resolving this in a future -next update, I was rather > surprised that my AMD test machine's graphical output was not working > until I noticed the configuration difference :) Done. signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: display: mediatek: simplify compatibles syntax
On 14/04/2023 10:33, Krzysztof Kozlowski wrote: Lists (items) with one item should be just enum because it is shorter, simpler and does not confuse, if one wants to add new entry with a fallback. Convert all of them to enums. OTOH, leave unused "oneOf" entries in anticipation of further growth of the entire binding. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Matthias Brugger --- Cc: angelogioacchino.delre...@collabora.com --- .../bindings/display/mediatek/mediatek,ccorr.yaml | 7 +++ .../bindings/display/mediatek/mediatek,color.yaml | 10 -- .../bindings/display/mediatek/mediatek,dither.yaml | 4 ++-- .../bindings/display/mediatek/mediatek,dsc.yaml | 4 ++-- .../bindings/display/mediatek/mediatek,gamma.yaml | 7 +++ .../bindings/display/mediatek/mediatek,merge.yaml | 7 +++ .../bindings/display/mediatek/mediatek,od.yaml | 7 +++ .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 7 +++ .../bindings/display/mediatek/mediatek,ovl.yaml | 13 + .../display/mediatek/mediatek,postmask.yaml | 4 ++-- .../bindings/display/mediatek/mediatek,rdma.yaml| 13 + .../bindings/display/mediatek/mediatek,split.yaml | 4 ++-- .../bindings/display/mediatek/mediatek,ufoe.yaml| 4 ++-- .../bindings/display/mediatek/mediatek,wdma.yaml| 4 ++-- 14 files changed, 41 insertions(+), 54 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..dc22bd522523 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr - items: - enum: - mediatek,mt8188-disp-ccorr diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..1588b3f7cec7 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - enum: + - mediatek,mt8183-disp-dither - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..2cbdd9ee449d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -20,8 +20,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8195-disp-dsc + - enum: + - mediatek,mt8195-disp-dsc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index a5c6a91fac71..6c2be9d6840b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-gamma - - items: - - const: mediatek,mt8183-disp-gamma + - enum: + - mediatek,mt8173-disp-gamma + - mediatek,mt8183-disp-gamma - items: - enum: - mediatek,mt8186-disp-gamma diff --git a/Documentation/devicetree/bindings/displ
[PATCH v3] drm/msm/dpu: always program DSC active bits
In current code, the dsc active bits are set only if the cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during teardown.
As discuss at [1], clear DSC active bit will handled at reset_intf_cfg()
Signed-off-by: Kuogee Hsieh
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Reviewed-by: Abhinav Kumar
Reviewed-by: Marijn Suijten
[1]
https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..88e4efe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
On 14/04/2023 18:07, Guillaume Ranquet wrote:
The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
by the kernel test robot.
Fix the issue by removing the variable altogether and testing out the
return value of mtk_hdmi_pll_set_hw()
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reported-by: kernel test robot
Signed-off-by: Guillaume Ranquet
Looks good, but got unfortunately already fixed 4 hours ago with
20230414122253.3171524-1-t...@redhat.com
:)
Regards,
Matthias
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..054b73cb31ee 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
u8 txpredivs[4] = { 2, 4, 6, 12 };
u32 fbkdiv_low;
- int i, ret;
+ int i;
pixel_clk = rate;
tmds_clk = pixel_clk;
@@ -292,13 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
*hdmi_phy, struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ return mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
txposdiv, digital_div);
- if (ret)
- return -EINVAL;
-
- return 0;
}
static int mtk_hdmi_pll_drv_setting(struct clk_hw *hw)
[PATCH PING] drm/arc: disambiguate Synopsys ARC in Kconfig labels
There's Intel Arc now which is what most folks will be looking for. Signed-off-by: Adam Borowski Acked-by: Alexey Brodkin --- drivers/gpu/drm/tiny/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) v2: added Alexey's ACK. diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig index f6889f649bc1..efeead65030a 100644 --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -1,12 +1,12 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_ARCPGU - tristate "ARC PGU" + tristate "Synopsys ARC PGU" depends on DRM && OF select DRM_GEM_DMA_HELPER select DRM_KMS_HELPER help - Choose this option if you have an ARC PGU controller. + Choose this option if you have a Synopsys ARC PGU controller. If M is selected the module will be called arcpgu. -- 2.40.0
[PATCH] drm/i915/gt: Mask media GuC interrupts
MTL features a dedicated media engine that operates on its
independent GT, requiring activation of its specific interrupt
set.
Enable the necessary interrupts in a single action when the media
engine is present, bypassing the need to iterate through all the
GTs.
Signed-off-by: Andi Shyti
---
Hi,
I'm starting with v0 as this patch is very different from the
ones proposed recently.
After all the discussions on this patch, I took Matt's suggestion
since it seemed the most immediate.
However, in the long run, I agree that we should have a
specific mtl_ function for enabling interrupts.
Thank you Matt and Daniele for your input.
If this patch hasn't missed anything, is it too optimistic to
expect MTL to boot? :-)
Andi
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a60391522..162a27b4c4095 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -254,7 +254,6 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
u32 irqs = GT_RENDER_USER_INTERRUPT;
- u32 guc_mask = intel_uc_wants_guc(>->uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
u32 dmask;
u32 smask;
@@ -309,17 +308,20 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (gsc_mask)
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK,
~gsc_mask);
- if (guc_mask) {
+ if (intel_uc_wants_guc(>->uc)) {
+ u32 guc_mask = GUC_INTR_GUC2HOST;
/* the enable bit is common for both GTs but the masks are
separate */
- u32 mask = gt->type == GT_MEDIA ?
- REG_FIELD_PREP(ENGINE0_MASK, guc_mask) :
- REG_FIELD_PREP(ENGINE1_MASK, guc_mask);
+ u32 mask = REG_FIELD_PREP(ENGINE1_MASK, guc_mask);
+
+ /* Mask the GuC interrupts of media engine if present */
+ if (MEDIA_VER(gt->i915) >= 13)
+ mask |= REG_FIELD_PREP(ENGINE0_MASK, guc_mask);
intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE,
REG_FIELD_PREP(ENGINE1_MASK, guc_mask));
/* we might not be the first GT to write this reg */
- intel_uncore_rmw(uncore, MTL_GUC_MGUC_INTR_MASK, mask, 0);
+ intel_uncore_write(uncore, MTL_GUC_MGUC_INTR_MASK, mask);
}
/*
--
2.39.2
[PATCH v2 2/2] phy: mediatek: hdmi: mt8195: fix wrong pll calculus
The clock rate calculus in mtk_hdmi_pll_calc() was wrong when it has
been replaced by 'div_u64'.
Fix the issue by multiplying the values in the denominator instead of
dividing them.
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index 054b73cb31ee..caa953780bee 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -271,7 +271,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
* [32,24] 9bit integer, [23,0]:24bit fraction
*/
pcw = div_u64(((u64)ns_hdmipll_ck) << PCW_DECIMAL_WIDTH,
- da_hdmitx21_ref_ck / PLL_FBKDIV_HS3);
+ da_hdmitx21_ref_ck * PLL_FBKDIV_HS3);
if (pcw > GENMASK_ULL(32, 0))
return -EINVAL;
@@ -288,7 +288,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
posdiv2 = 1;
/* Digital clk divider, max /32 */
- digital_div = div_u64((u64)ns_hdmipll_ck, posdiv1 / posdiv2 /
pixel_clk);
+ digital_div = div_u64(ns_hdmipll_ck, posdiv1 * posdiv2 * pixel_clk);
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
--
2.40.0
[PATCH v2 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
by the kernel test robot.
Fix the issue by removing the variable altogether and testing out the
return value of mtk_hdmi_pll_set_hw()
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reported-by: kernel test robot
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..054b73cb31ee 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
u8 txpredivs[4] = { 2, 4, 6, 12 };
u32 fbkdiv_low;
- int i, ret;
+ int i;
pixel_clk = rate;
tmds_clk = pixel_clk;
@@ -292,13 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
*hdmi_phy, struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ return mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
txposdiv, digital_div);
- if (ret)
- return -EINVAL;
-
- return 0;
}
static int mtk_hdmi_pll_drv_setting(struct clk_hw *hw)
--
2.40.0
[PATCH v2 0/2] Fix mtk-hdmi-mt8195 unitialized variable usage and clock rate calculation
I've received a report from kernel test report [1] that a variable was used unitialized in the mtk8195 hdmi phy code. I've upon fixing that issue found out that the clock rate calculation was erroneous since the calculus was moved to div_u64. I'm providing those two fixes on top of 45810d486bb44 from the linux-phy repository [2]. [1] https://lore.kernel.org/oe-kbuild-all/202304130304.gmtrudbd-...@intel.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git Signed-off-by: Guillaume Ranquet --- Changes in v2: - Propagate return value of mtk_hdmi_pll_set_hw() as suggested by Angelo --- Guillaume Ranquet (2): phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc phy: mediatek: hdmi: mt8195: fix wrong pll calculus drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) --- base-commit: 45810d486bb44bd60213d5f09a713df81b987972 change-id: 20230413-fixes-for-mt8195-hdmi-phy-9e1513b5baad Best regards, -- Guillaume Ranquet
Re: [PATCH v5 14/20] staging: media: tegra-video: move MIPI calibration calls from VI to CSI
Hi Luca,
I just encountered an error in this patch, so I have rejected the PR I made.
See below for the details:
On 07/04/2023 15:38, Luca Ceresoli wrote:
> The CSI module does not handle all the MIPI lane calibration procedure,
> leaving a small part of it to the VI module. In doing this,
> tegra_channel_enable_stream() (vi.c) manipulates the private data of the
> upstream subdev casting it to struct 'tegra_csi_channel', which will be
> wrong after introducing a VIP (parallel video input) channel.
>
> This prevents adding support for the VIP module. It also breaks the
> logical isolation between modules.
>
> Since the lane calibration requirement does not exist in the parallel input
> module, moving the calibration function to a per-module op is not
> optimal. Instead move the calibration procedure in the CSI module, together
> with the rest of the calibration procedures. After this change,
> tegra_channel_enable_stream() just calls v4l2_subdev_call() to ask for a
> stream start/stop to the CSI module, which in turn knows all the
> CSI-specific details to implement it.
>
> Signed-off-by: Luca Ceresoli
> Reviewed-by: Dmitry Osipenko
>
> ---
>
> No changes in v5
>
> Changed in v4:
> - Added review tags
>
> No changes in v3
> No changes in v2
> ---
> drivers/staging/media/tegra-video/csi.c | 44
> drivers/staging/media/tegra-video/vi.c | 54 ++---
> 2 files changed, 48 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-video/csi.c
> b/drivers/staging/media/tegra-video/csi.c
> index 9a03d5ccdf3c..b93fc879ef3a 100644
> --- a/drivers/staging/media/tegra-video/csi.c
> +++ b/drivers/staging/media/tegra-video/csi.c
> @@ -328,12 +328,42 @@ static int tegra_csi_enable_stream(struct v4l2_subdev
> *subdev)
> }
>
> csi_chan->pg_mode = chan->pg_mode;
> +
> + /*
> + * Tegra CSI receiver can detect the first LP to HS transition.
> + * So, start the CSI stream-on prior to sensor stream-on and
> + * vice-versa for stream-off.
> + */
> ret = csi->ops->csi_start_streaming(csi_chan);
> if (ret < 0)
> goto finish_calibration;
>
> + if (csi_chan->mipi) {
> + struct v4l2_subdev *src_subdev;
> + /*
> + * TRM has incorrectly documented to wait for done status from
> + * calibration logic after CSI interface power on.
> + * As per the design, calibration results are latched and
> applied
> + * to the pads only when the link is in LP11 state which will
> happen
> + * during the sensor stream-on.
> + * CSI subdev stream-on triggers start of MIPI pads calibration.
> + * Wait for calibration to finish here after sensor subdev
> stream-on.
> + */
> + src_subdev = tegra_channel_get_remote_source_subdev(chan);
> + ret = v4l2_subdev_call(src_subdev, video, s_stream, true);
> + err = tegra_mipi_finish_calibration(csi_chan->mipi);
> +
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + goto disable_csi_stream;
If there was an error from s_stream, then tegra_mipi_finish_calibration is
called
and it goes to disable_csi_stream...
> +
> + if (err < 0)
> + dev_warn(csi->dev, "MIPI calibration failed: %d\n",
> err);
> + }
> +
> return 0;
>
> +disable_csi_stream:
> + csi->ops->csi_stop_streaming(csi_chan);
> finish_calibration:
> if (csi_chan->mipi)
> tegra_mipi_finish_calibration(csi_chan->mipi);
...but here tegra_mipi_finish_calibration() is called again, leading to an
unlock
imbalance.
This is the callstack:
[ 109.894502] IMX274 5-001a: s_stream failed
[ 109.900203] =
[ 109.904898] WARNING: bad unlock balance detected!
[ 109.909594] 6.3.0-rc2-tegra #16 Not tainted
[ 109.913774] -
[ 109.918470] v4l2-ctl/2000 is trying to release lock (&mipi->lock) at:
[ 109.924911] [] tegra_mipi_finish_calibration+0x84/0xb0
[ 109.931621] but there are no more locks to release!
[ 109.936489]
other info that might help us debug this:
[ 109.943004] 1 lock held by v4l2-ctl/2000:
[ 109.947009] #0: 83bcf6a8 (&chan->video_lock){}-{3:3}, at:
__video_do_ioctl+0xdc/0x3c8
[ 109.955987]
stack backtrace:
[ 109.960336] CPU: 2 PID: 2000 Comm: v4l2-ctl Not tainted 6.3.0-rc2-tegra #16
[ 109.967290] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
[ 109.973200] Call trace:
[ 109.975642] dump_backtrace+0xa0/0xfc
[ 109.979308] show_stack+0x18/0x24
[ 109.982622] dump_stack_lvl+0x48/0x60
[ 109.986285] dump_stack+0x18/0x24
[ 109.989598] print_unlock_imbalance_bug+0x130/0x148
[ 109.994472] lock_release+0x1bc/0x248
[ 109.998131] __mutex_unlock_slowpath+0x48/0x2cc
[ 110.002657] mutex_unlock+0x20/0x2c
[ 110.006141] tegra_mipi
Re: [PATCH] phy: mediatek: fix returning garbage
On Fri, Apr 14, 2023 at 08:22:53AM -0400, Tom Rix wrote:
> clang reports
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable
> 'ret' is uninitialized when used here [-Werror,-Wuninitialized]
> if (ret)
> ^~~
> ret should have been set by the preceding call to mtk_hdmi_pll_set_hw.
>
> Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
> Signed-off-by: Tom Rix
Reviewed-by: Nathan Chancellor
Angelo brought up a good point on another patch to fix this issue that
we should probably be returning ret instead of unconditionally returning
-EINVAL but it sounds like it does not really matter at the moment since
mtk_hdmi_pll_set_hw() can only return -EINVAL or 0.
https://lore.kernel.org/ada769e0-0141-634f-3753-eb3a50f0e...@collabora.com/
> ---
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> index abfc077fb0a8..c63294e451d6 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> @@ -292,9 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
> *hdmi_phy, struct clk_hw *hw,
> if (!(digital_div <= 32 && digital_div >= 1))
> return -EINVAL;
>
> - mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
> - PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
> - txposdiv, digital_div);
> + ret = mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
> + PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
> + txposdiv, digital_div);
> if (ret)
> return -EINVAL;
>
> --
> 2.27.0
>
Re: [PATCH] drm/msm/dpu: always program dsc active bits
On 4/14/2023 12:35 AM, Marijn Suijten wrote: On 2023-04-12 10:33:15, Abhinav Kumar wrote: [..] What happens if a device boots without DSC panel connected? Will CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the DSC blocks? Or could this flush uninitialized state to the block? If we bootup without DSC panel connected, the kernel's cfg->dsc will be 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush any DSC blocks. Ack, that makes sense. However, if I connect a DSC panel, then disconnect it (now the register should be non-zero, but cfg->dsc will be zero), and then replug a non-DSC panel multiple times, it'll get flushed every time because we never clear CTL_DSC_FLUSH after that? If we remove it after kernel starts, that issue is there even today without that change because DSI is not a hot-pluggable display so a teardown wont happen when you plug out the panel. How will cfg->dsc be 0 then? In that case, its not a valid test as there was no indication to DRM that display was disconnected so we cannot tear it down. Sure, as I wrote in the other response, we can move this to reset_intf_cfg later when the other pieces are fixed. And leave a FIXME here. Kuogee forgot to CC me on this patchs so I did not read/receive that side of the email thread. Will catch up before reviewing v2. - Marijn
Re: [PATCH] phy: mediatek: fix returning garbage
On 14/04/2023 17:43, Matthias Brugger wrote:
On 14/04/2023 14:22, Tom Rix wrote:
clang reports
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable
'ret' is uninitialized when used here [-Werror,-Wuninitialized]
if (ret)
^~~
ret should have been set by the preceding call to mtk_hdmi_pll_set_hw.
Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Signed-off-by: Tom Rix
Reviewed-by: Matthias Brugger
Please also add
Reported-by: Linux Kernel Functional Testing
see CA+G9fYu4o0-ZKSthi7kdCjz_kFazZS-rn17Z2NPz3=1oayr...@mail.gmail.com
Regards,
Matthias
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..c63294e451d6 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -292,9 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
*hdmi_phy, struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
- PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
- txposdiv, digital_div);
+ ret = mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
+ txposdiv, digital_div);
if (ret)
return -EINVAL;
Re: [PATCH] phy: mediatek: fix returning garbage
On 14/04/2023 14:22, Tom Rix wrote:
clang reports
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable
'ret' is uninitialized when used here [-Werror,-Wuninitialized]
if (ret)
^~~
ret should have been set by the preceding call to mtk_hdmi_pll_set_hw.
Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Signed-off-by: Tom Rix
Reviewed-by: Matthias Brugger
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..c63294e451d6 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -292,9 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
- PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
- txposdiv, digital_div);
+ ret = mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
+ txposdiv, digital_div);
if (ret)
return -EINVAL;
Re: [PATCH v2] drm/msm/dpu: always program dsc active bits
On 4/14/2023 12:48 AM, Marijn Suijten wrote:
Capitalize DSC in the title, as discussed in v1.
On 2023-04-13 08:56:41, Kuogee Hsieh wrote:
In current code, the DSC active bits are written only if cfg->dsc is set.
However, for displays which are hot-pluggable, there can be a use-case
of disconnecting a DSC supported sink and connecting a non-DSC sink.
For those cases we need to clear DSC active bits during tear down.
Changes in V2:
1) correct commit text as suggested
2) correct Fixes commit id
3) add FIXME comment
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Marijn Suijten
By default git send-email should pick this up in the CC line... but I
had to download this patch from lore once again.
Yes, I think what happened here is, he didnt git am the prev rev and
make changes on top of that so git send-email didnt pick up. We should
fix that process.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95c..1651cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -541,10 +541,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc) {
- DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
- }
+
+ /* FIXME: fix reset_intf_cfg to handle teardown of dsc */
There's more wrong than just moving (not "fix"ing) this bit of code into
reset_intf_cfg. And this will have to be re-wrapped in `if (cfg->dsc)`
again by reverting this patch. Perhaps that can be explained, or link
to Abhinav's explanation to make it clear to readers what this FIXME
actually means? Let's wait for Abhinav and Dmitry to confirm the
desired communication here.
https://lore.kernel.org/linux-arm-msm/ec045d6b-4ffd-0f8c-4011-8db45edc6...@quicinc.com/
Yes, I am fine with linking this explanation in the commit text and
mentioning that till thats fixed, we need to go with this solution. The
FIXME itself is fine, I will work on it and I remember this context well.
- Marijn
+ DPU_REG_WRITE(&ctx->hw, CTL_FLUSH, DSC_IDX);
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v7 6/8] drm/i915/uapi/pxp: Fix UAPI spec comments and add GET_PARAM for PXP
Hi Lionel, does this patch work for you? On Mon, 2023-04-10 at 10:22 -0700, Ceraolo Spurio, Daniele wrote: > On 4/6/2023 10:44 AM, Alan Previn wrote: alan:snip > > +/* > > + * Query the status of PXP support in i915. > > + * > > + * The query can fail in the following scenarios with the listed error > > codes: > > + * -ENODEV = PXP support is not available on the GPU device or in the > > kernel > > + *due to missing component drivers or kernel configs. > > + * If the IOCTL is successful, the returned parameter will be set to one > > of the > > + * following values: > > + * 0 = PXP support maybe available but underlying SOC fusing, BIOS or > > firmware > > + * configuration is unknown and a PXP-context-creation would be > > required > > + * for final verification of feature availibility. > > Would it be useful to add: > > 1 = PXP support is available > > And start returning that after we've successfully created our first > session? Not sure if userspace would use this though, since they still > need to handle the 0 case anyway. > I'm also ok with this patch as-is, as long as you get an ack from the > userspace drivers for this interface behavior: > > Reviewed-by: Daniele Ceraolo Spurio > > Daniele alan:snip
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: Add no-hpd property
On 11/04/23 11:36, Krzysztof Kozlowski wrote: On 05/04/2023 16:24, Jayesh Choudhary wrote: From: Rahul T R The mhdp bridge can work without its HPD pin hooked up to the connector, but the current bridge driver throws an error when hpd line is not connected to the connector. For such cases, we need an indication for no-hpd, using which we can bypass the hpd detection and instead use the auxiliary channels connected to the DP connector to confirm the connection. So add no-hpd property to the bindings, to disable hpd when not connected or unusable. Your subject prefixes miss device specific part. You do not add no-hpd to all bridges. It's also not drm. It is a display directory. Sorry messed the commit heading. Will fix it. Signed-off-by: Rahul T R Signed-off-by: Jayesh Choudhary --- .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index c2b369456e4e..3a6c6d837593 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -57,6 +57,12 @@ properties: interrupts: maxItems: 1 + cdns,no-hpd: No improvements - use existing no-hpd name. Okay will change it to "no-hpd" Best regards, Krzysztof
Re: [PATCH v2 2/2] drm: bridge: cdns-mhdp8546: Add support for no-hpd
On 06/04/23 07:22, Laurent Pinchart wrote:
Hi Jayesh,
Thank you for the patch.
On Wed, Apr 05, 2023 at 07:54:40PM +0530, Jayesh Choudhary wrote:
From: Rahul T R
In J721S2 EVMs DP0 hpd is not connected to correct
hpd pin on SOC, to handle such cases, Add support for
"no-hpd" property in the device tree node to disable
hpd
s/hpd/hpd./
You can also reflow the commit message to 72 columns.
Okay. Thanks for the suggestion. Will do.
Also change the log level for dpcd read failuers to
debug, since framework retries 32 times for each read
s/read/read./
Doesn't this apply to writes as well ?
Based on message request, we went into the conditional that uses
read. So just changing the log-level for dpcd read was enough to
get rid of the debug logs.
Signed-off-by: Rahul T R
Signed-off-by: Jayesh Choudhary
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 37 ---
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 1 +
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index f6822dfa3805..e177794b069d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -54,6 +54,8 @@
#include "cdns-mhdp8546-hdcp.h"
#include "cdns-mhdp8546-j721e.h"
+static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp);
+
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
int ret, empty;
@@ -749,7 +751,7 @@ static int cdns_mhdp_fw_activate(const struct firmware *fw,
* MHDP_HW_STOPPED happens only due to driver removal when
* bridge should already be detached.
*/
- if (mhdp->bridge_attached)
+ if (mhdp->bridge_attached && !mhdp->no_hpd)
writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
mhdp->regs + CDNS_APB_INT_MASK);
@@ -845,7 +847,7 @@ static ssize_t cdns_mhdp_transfer(struct drm_dp_aux *aux,
ret = cdns_mhdp_dpcd_read(mhdp, msg->address,
msg->buffer, msg->size);
if (ret) {
- dev_err(mhdp->dev,
+ dev_dbg(mhdp->dev,
"Failed to read DPCD addr %u\n",
msg->address);
@@ -1738,6 +1740,19 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
spin_unlock(&mhdp->start_lock);
+ if (mhdp->no_hpd) {
+ ret = wait_event_timeout(mhdp->fw_load_wq,
+mhdp->hw_state == MHDP_HW_READY,
+msecs_to_jiffies(100));
+ if (ret == 0) {
+ dev_err(mhdp->dev, "%s: Timeout waiting for fw
loading\n",
+ __func__);
+ return -ETIMEDOUT;
+ }
+
+ cdns_mhdp_update_link_status(mhdp);
+ return 0;
+ }
Missing blank line.
It's not clear to me while you need to wait for the state to change to
MHDP_HW_READY in the no_hpd case. This should be explained in the commit
message.
/* Enable SW event interrupts */
if (hw_ready)
writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
@@ -2256,7 +2271,16 @@ static int cdns_mhdp_update_link_status(struct
cdns_mhdp_device *mhdp)
mutex_lock(&mhdp->link_mutex);
- mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+ if (mhdp->no_hpd) {
+ ret = drm_dp_dpcd_read_link_status(&mhdp->aux, status);
+ hpd_pulse = false;
+ if (ret < 0)
+ mhdp->plugged = false;
+ else
+ mhdp->plugged = true;
I think there's an issue with how the driver uses mhdp->plugged. In the
no_hpd case, you try to detect if a display is connected by reading the
link status at attach time, and then never update mhdp->plugged. This
means that if no display is connected at that point, functions like
cdns_mhdp_get_edid() will always fail, even if a display gets plugged
later. As the goal of this series is (as far as I understand) support
systems where the HPD signal could be connected to a SoC GPIO instead of
the bridge, I don't think this is good enough.
In the driver, I see that this is the only call which changes
mhdp->plugged. Do you have any suggestions on how to work on this?
Polling the value of drm_dp_dpdc_read_link_status does not seem like a
clean way.
Here by doing this, we are settling for few functionalities of display.
Thanks,
-Jayesh
+ } else {
+ mhdp->plugged = cdns_mhdp_detect_hpd(mhdp, &hpd_pulse);
+ }
if (!mhdp->plugged) {
cdns_mhdp_link_down(mhdp);
@@ -2451,6 +2475,8 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->aux.dev = dev;
mhdp->aux.transfer = cdns_mhdp_t
[PATCH] drm/amd/display: remove unused variable oldest_index
cpp_check reports
drivers/gpu/drm/amd/display/modules/freesync/freesync.c:1143:17: style: Variable
'oldest_index' is assigned a value that is never used. [unreadVariable]
oldest_index = 0;
^
This variable is not used so remove.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 5c41a4751db4..5798c0eafa1f 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -1137,10 +1137,6 @@ void mod_freesync_handle_preflip(struct mod_freesync
*mod_freesync,
if (in_out_vrr->supported &&
in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE) {
- unsigned int oldest_index = plane->time.index + 1;
-
- if (oldest_index >= DC_PLANE_UPDATE_TIMES_MAX)
- oldest_index = 0;
last_render_time_in_us = curr_time_stamp_in_us -
plane->time.prev_update_time_in_us;
--
2.27.0
Re: BUG: KASAN: null-ptr-deref in drm_sched_job_cleanup+0x96/0x290 [gpu_sched]
On Tue, Apr 11, 2023 at 10:40 PM Mikhail Gavrilov wrote: > > Hi, > KASAN continues to find problems in the drm_sched_job_cleanup code at 6.3rc6. > I not got any feedback in the thread > https://lore.kernel.org/lkml/cabxgcsmvub2ra4d+k5cna0_2521tox++d4nmoukki4x2-q_...@mail.gmail.com/ > Therefore, I decided to start a separate thread. Since the problems > are different, the symptoms are also different. > > Reproduction scenario. > After launching one of the listed games: > - Cyberpunk 2077 > - Forza Horizon 4 > - Forza Horizon 5 > - Sackboy: A Big Adventure > > Firstly after some time (may be after several attempts) appears bug > message from KASAN: > == > BUG: KASAN: null-ptr-deref in drm_sched_job_cleanup+0x96/0x290 [gpu_sched] > Read of size 4 at addr 0078 by task ForzaHorizon4.e/31587 > > CPU: 15 PID: 31587 Comm: ForzaHorizon4.e Tainted: GWL > --- --- 6.3.0-0.rc6.49.fc39.x86_64+debug #1 > Hardware name: System manufacturer System Product Name/ROG STRIX > X570-I GAMING, BIOS 4601 02/02/2023 > Call Trace: > > dump_stack_lvl+0x72/0xc0 > kasan_report+0xa4/0xe0 > ? drm_sched_job_cleanup+0x96/0x290 [gpu_sched] > kasan_check_range+0x104/0x1b0 > drm_sched_job_cleanup+0x96/0x290 [gpu_sched] > ? __pfx_drm_sched_job_cleanup+0x10/0x10 [gpu_sched] > ? slab_free_freelist_hook+0x11e/0x1d0 > ? amdgpu_cs_parser_fini+0x363/0x5a0 [amdgpu] > amdgpu_job_free+0x40/0x1b0 [amdgpu] > amdgpu_cs_parser_fini+0x3c9/0x5a0 [amdgpu] > ? __pfx_amdgpu_cs_parser_fini+0x10/0x10 [amdgpu] > amdgpu_cs_ioctl+0x3d9/0x5630 [amdgpu] > ? __pfx_amdgpu_cs_ioctl+0x10/0x10 [amdgpu] > ? __kmem_cache_free+0xbc/0x2e0 > ? mark_lock+0x101/0x16e0 > ? __lock_acquire+0xe54/0x59f0 > ? kasan_save_stack+0x3f/0x50 > ? __pfx_lock_release+0x10/0x10 > ? __pfx_amdgpu_cs_ioctl+0x10/0x10 [amdgpu] > drm_ioctl_kernel+0x1f8/0x3d0 > ? __pfx_drm_ioctl_kernel+0x10/0x10 > drm_ioctl+0x4c1/0xaa0 > ? __pfx_amdgpu_cs_ioctl+0x10/0x10 [amdgpu] > ? __pfx_drm_ioctl+0x10/0x10 > ? _raw_spin_unlock_irqrestore+0x62/0x80 > ? lockdep_hardirqs_on+0x7d/0x100 > ? _raw_spin_unlock_irqrestore+0x4b/0x80 > amdgpu_drm_ioctl+0xce/0x1b0 [amdgpu] > __x64_sys_ioctl+0x12d/0x1a0 > do_syscall_64+0x5c/0x90 > ? do_syscall_64+0x68/0x90 > ? lockdep_hardirqs_on+0x7d/0x100 > ? do_syscall_64+0x68/0x90 > ? do_syscall_64+0x68/0x90 > ? lockdep_hardirqs_on+0x7d/0x100 > ? do_syscall_64+0x68/0x90 > ? asm_exc_page_fault+0x22/0x30 > ? lockdep_hardirqs_on+0x7d/0x100 > entry_SYSCALL_64_after_hwframe+0x72/0xdc > RIP: 0033:0x7fb8a270881d > Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 > 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 > 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 > RSP: 002b:467ad060 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 467ad358 RCX: 7fb8a270881d > RDX: 467ad140 RSI: c0186444 RDI: 005a > RBP: 467ad0b0 R08: 7fb7f00d3eb0 R09: 467ad100 > R10: 7fb88c68fb20 R11: 0246 R12: 467ad140 > R13: c0186444 R14: 005a R15: 7fb7f00d3e50 > > == > > Finally it ends up with the games listed above stopping working they > stuck after a kernel warning: > general protection fault, probably for non-canonical address > 0xdc0f: [#1] PREEMPT SMP KASAN NOPTI > KASAN: null-ptr-deref in range [0x0078-0x007f] > CPU: 15 PID: 31587 Comm: ForzaHorizon4.e Tainted: GB WL > --- --- 6.3.0-0.rc6.49.fc39.x86_64+debug #1 > Hardware name: System manufacturer System Product Name/ROG STRIX > X570-I GAMING, BIOS 4601 02/02/2023 > RIP: 0010:drm_sched_job_cleanup+0xa7/0x290 [gpu_sched] > Code: d6 01 00 00 4c 8b 75 20 be 04 00 00 00 4d 8d 66 78 4c 89 e7 e8 > ba 4d 4e c9 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 > 14 02 4c 89 e0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 8a > RSP: 0018:c9003676f5a8 EFLAGS: 00010216 > RAX: dc00 RBX: 88816f81f020 RCX: 0001 > RDX: 000f RSI: 0008 RDI: 9053e5e0 > RBP: 88816f81f000 R08: 0001 R09: 9053e5e7 > R10: fbfff20a7cbc R11: 6e696c6261736944 R12: 0078 > R13: 192006cedeb5 R14: R15: c9003676f870 > FS: 4680f6c0() GS:888fa5c0() knlGS:2991 > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7fb854d6f010 CR3: 00017b2d6000 CR4: 00350ee0 > Call Trace: > > ? __pfx_drm_sched_job_cleanup+0x10/0x10 [gpu_sched] > ? slab_free_freelist_hook+0x11e/0x1d0 > ? amdgpu_cs_parser_fini+0x363/0x5a0 [amdgpu] > amdgpu_job_free+0x40/0x1b0 [amdgpu] > amdgpu_cs_parser_fini+0x3c9/0x5a0 [amdgpu] > ? __pfx_amdgpu_cs_parser_fini+0x10/0x10 [amdgpu] > amdgpu_cs_ioctl+0x3d9/0x5630 [amdgp
Re: [PATCH v2 6/7] drm/vkms: add reflect-y property
On Fri, Apr 14, 2023 at 11:37:17AM -0300, Maíra Canal wrote: > On 4/14/23 11:24, Ville Syrjälä wrote: > > On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra Canal wrote: > >> Currently, vkms only support the reflect-x property. Therefore, add the > >> reflect-y property to vkms through a software implementation of the > >> operation. This is possible by reverse reading the y axis during the > >> blending. > >> > >> Now, vkms support all possible rotation values. > >> > >> Tested with igt@kms_rotation_crc@primary-reflect-y and > >> igt@kms_rotation_crc@sprite-reflect-y [1]. > >> > >> [1] https://patchwork.freedesktop.org/series/116025/ > >> > >> Signed-off-by: Maíra Canal > >> --- > >> drivers/gpu/drm/vkms/vkms_composer.c | 7 ++- > >> drivers/gpu/drm/vkms/vkms_plane.c| 16 > >> 2 files changed, 10 insertions(+), 13 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c > >> b/drivers/gpu/drm/vkms/vkms_composer.c > >> index b05bd008aeab..19d1078e9d34 100644 > >> --- a/drivers/gpu/drm/vkms/vkms_composer.c > >> +++ b/drivers/gpu/drm/vkms/vkms_composer.c > >> @@ -92,8 +92,13 @@ static int get_y_pos(struct vkms_frame_info > >> *frame_info, int y) > >>return -1; > >>return y + frame_info->dst.x1; > >>default: > >> - return y; > >> + break; > >>} > >> + > >> + if (frame_info->rotation & DRM_MODE_REFLECT_Y) > >> + return drm_rect_height(&frame_info->dst) - y - 1; > >> + > >> + return y; > >> } > >> > >> static bool check_limit(struct vkms_frame_info *frame_info, int pos) > >> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c > >> b/drivers/gpu/drm/vkms/vkms_plane.c > >> index 11662afa9fe4..d08bda869a24 100644 > >> --- a/drivers/gpu/drm/vkms/vkms_plane.c > >> +++ b/drivers/gpu/drm/vkms/vkms_plane.c > >> @@ -121,12 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane > >> *plane, > >>frame_info->fb = fb; > >>memcpy(&frame_info->map, &shadow_plane_state->data, > >> sizeof(frame_info->map)); > >>drm_framebuffer_get(frame_info->fb); > >> - frame_info->rotation = drm_rotation_simplify(new_state->rotation, > >> - DRM_MODE_ROTATE_0 | > >> - DRM_MODE_ROTATE_90 | > >> - DRM_MODE_ROTATE_180 | > >> - DRM_MODE_ROTATE_270 | > >> - DRM_MODE_REFLECT_X); > >> + frame_info->rotation = drm_rotation_simplify(new_state->rotation, > >> DRM_MODE_ROTATE_MASK | > >> + DRM_MODE_REFLECT_MASK); > > > > What are you trying to achieve with that? > > Yeah, seeing it right now I can see that this is not achieving anything. > I will remove it in the next version. I think using it might still make sense to eg. remove the 180/270 cases from your actual rendering code. I'm also a bit uneasy about all that hand rolled coordinate calculation stuff. Ideally drm_rect_rotate*() should handle all that for you, and make sure the rotate vs. reflect actually get applied in the correct order. -- Ville Syrjälä Intel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: Add no-hpd property
On 06/04/23 07:10, Laurent Pinchart wrote: Hi Jayesh, Thank you for the patch. On Wed, Apr 05, 2023 at 07:54:39PM +0530, Jayesh Choudhary wrote: From: Rahul T R The mhdp bridge can work without its HPD pin hooked up to the connector, but the current bridge driver throws an error when hpd line is not connected to the connector. For such cases, we need an indication for no-hpd, using which we can bypass the hpd detection and instead use the auxiliary channels connected to the DP connector to confirm the connection. So add no-hpd property to the bindings, to disable hpd when not connected or unusable. Signed-off-by: Rahul T R Signed-off-by: Jayesh Choudhary --- .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index c2b369456e4e..3a6c6d837593 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -57,6 +57,12 @@ properties: interrupts: maxItems: 1 + cdns,no-hpd: +type: boolean +description: + Set if the HPD line on the bridge isn't hooked up to anything or is + otherwise unusable. I'm fine with the non connected part, but concerned with "otherwise unusable". It's very vague and could thus be abused. Do you have particular use cases in mind for this ? If so, restricting this to those use cases, or at least giving examples, would help. Okay. Will do that in next version. Thanks. + ports: $ref: /schemas/graph.yaml#/properties/ports
[PATCH] drm/etnaviv: fix dumping of active MMU context
gpu->mmu_context is the MMU context of the last job in the HW queue, which
isn't necessarily the same as the context from the bad job. Dump the MMU
context from the scheduler determined bad submit to make it work as intended.
Fixes: 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on
MMUv2")
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 44b5f3c35aab..898f84a0fc30 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -130,9 +130,9 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
return;
etnaviv_dump_core = false;
- mutex_lock(&gpu->mmu_context->lock);
+ mutex_lock(&submit->mmu_context->lock);
- mmu_size = etnaviv_iommu_dump_size(gpu->mmu_context);
+ mmu_size = etnaviv_iommu_dump_size(submit->mmu_context);
/* We always dump registers, mmu, ring, hanging cmdbuf and end marker */
n_obj = 5;
@@ -162,7 +162,7 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
__GFP_NORETRY);
if (!iter.start) {
- mutex_unlock(&gpu->mmu_context->lock);
+ mutex_unlock(&submit->mmu_context->lock);
dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
return;
}
@@ -174,18 +174,18 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
memset(iter.hdr, 0, iter.data - iter.start);
etnaviv_core_dump_registers(&iter, gpu);
- etnaviv_core_dump_mmu(&iter, gpu->mmu_context, mmu_size);
+ etnaviv_core_dump_mmu(&iter, submit->mmu_context, mmu_size);
etnaviv_core_dump_mem(&iter, ETDUMP_BUF_RING, gpu->buffer.vaddr,
gpu->buffer.size,
etnaviv_cmdbuf_get_va(&gpu->buffer,
- &gpu->mmu_context->cmdbuf_mapping));
+ &submit->mmu_context->cmdbuf_mapping));
etnaviv_core_dump_mem(&iter, ETDUMP_BUF_CMD,
submit->cmdbuf.vaddr, submit->cmdbuf.size,
etnaviv_cmdbuf_get_va(&submit->cmdbuf,
- &gpu->mmu_context->cmdbuf_mapping));
+ &submit->mmu_context->cmdbuf_mapping));
- mutex_unlock(&gpu->mmu_context->lock);
+ mutex_unlock(&submit->mmu_context->lock);
/* Reserve space for the bomap */
if (n_bomap_pages) {
--
2.39.2
Re: [PATCH v2 6/7] drm/vkms: add reflect-y property
On 4/14/23 11:24, Ville Syrjälä wrote: On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra Canal wrote: Currently, vkms only support the reflect-x property. Therefore, add the reflect-y property to vkms through a software implementation of the operation. This is possible by reverse reading the y axis during the blending. Now, vkms support all possible rotation values. Tested with igt@kms_rotation_crc@primary-reflect-y and igt@kms_rotation_crc@sprite-reflect-y [1]. [1] https://patchwork.freedesktop.org/series/116025/ Signed-off-by: Maíra Canal --- drivers/gpu/drm/vkms/vkms_composer.c | 7 ++- drivers/gpu/drm/vkms/vkms_plane.c| 16 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index b05bd008aeab..19d1078e9d34 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -92,8 +92,13 @@ static int get_y_pos(struct vkms_frame_info *frame_info, int y) return -1; return y + frame_info->dst.x1; default: - return y; + break; } + + if (frame_info->rotation & DRM_MODE_REFLECT_Y) + return drm_rect_height(&frame_info->dst) - y - 1; + + return y; } static bool check_limit(struct vkms_frame_info *frame_info, int pos) diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 11662afa9fe4..d08bda869a24 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -121,12 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info->fb = fb; memcpy(&frame_info->map, &shadow_plane_state->data, sizeof(frame_info->map)); drm_framebuffer_get(frame_info->fb); - frame_info->rotation = drm_rotation_simplify(new_state->rotation, -DRM_MODE_ROTATE_0 | -DRM_MODE_ROTATE_90 | -DRM_MODE_ROTATE_180 | -DRM_MODE_ROTATE_270 | -DRM_MODE_REFLECT_X); + frame_info->rotation = drm_rotation_simplify(new_state->rotation, DRM_MODE_ROTATE_MASK | +DRM_MODE_REFLECT_MASK); What are you trying to achieve with that? Yeah, seeing it right now I can see that this is not achieving anything. I will remove it in the next version. Best Regards, - Maíra Canal
Re: [PATCH] drm/rockchip: vop2: fix suspend/resume
Hi,
On Thu 13 Apr 23, 10:27, Chris Morgan wrote:
> On Thu, Apr 13, 2023 at 04:43:47PM +0200, Sascha Hauer wrote:
> > During a suspend/resume cycle the VO power domain will be disabled and
> > the VOP2 registers will reset to their default values. After that the
> > cached register values will be out of sync and the read/modify/write
> > operations we do on the window registers will result in bogus values
> > written. Fix this by re-initializing the register cache each time we
> > enable the VOP2. With this the VOP2 will show a picture after a
> > suspend/resume cycle whereas without this the screen stays dark.
I was actually tracking the very same bug this week!
Thanks a lot for fixing this, it would certainly have taken me a while to
think about regmap cache maintenance. Good thinking :)
Your patch fixes the issue on my side but I have a suggestion below:
> > Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sascha Hauer
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index ba3b817895091..d9daa686b014d 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -215,6 +215,8 @@ struct vop2 {
> > struct vop2_win win[];
> > };
> >
> > +static const struct regmap_config vop2_regmap_config;
> > +
> > static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> > {
> > return container_of(crtc, struct vop2_video_port, crtc);
> > @@ -839,6 +841,12 @@ static void vop2_enable(struct vop2 *vop2)
> > return;
> > }
> >
> > + ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
> > + if (ret) {
> > + drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
> > + return;
> > + }
It seems that regmap has regcache_mark_dirty() for this purpose, which is
perhaps more adapted than reinitializing cache (unless I'm missing something).
Note that I haven't tested it at this point.
Cheers,
Paul
> > if (vop2->data->soc_id == 3566)
> > vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
> >
> > --
> > 2.39.2
> >
>
> I confirmed this works on my Anbernic RG353P which uses the rk3566 SOC.
> Before applying the patch I displayed a color pattern with modetest
> before suspend and it appeared correctly. Then I suspended and resumed
> the device, attempted to display the same color pattern, and only got
> a single pixel on an otherwise blank display. After applying the patch
> I performed the same test and the color pattern appeared correctly
> both before and after suspend (and the display was no longer blank
> after resume from suspend).
>
> Tested-by: Chris Morgan
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH 1/9] drm: execution context for GEM buffers v3
Hi Christian, hi Thomas, On Fri, Mar 10, 2023 at 11:42:56AM +0100, Thomas Hellström (Intel) wrote: > Nice. This seems to have all we need for now for Xe as well, although not > for i915 ATM. A series to use drm_exec in Xe has been sent for review: https://patchwork.freedesktop.org/series/116477/ Thanks, Francois
Re: [PATCH v2 6/7] drm/vkms: add reflect-y property
On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra Canal wrote: > Currently, vkms only support the reflect-x property. Therefore, add the > reflect-y property to vkms through a software implementation of the > operation. This is possible by reverse reading the y axis during the > blending. > > Now, vkms support all possible rotation values. > > Tested with igt@kms_rotation_crc@primary-reflect-y and > igt@kms_rotation_crc@sprite-reflect-y [1]. > > [1] https://patchwork.freedesktop.org/series/116025/ > > Signed-off-by: Maíra Canal > --- > drivers/gpu/drm/vkms/vkms_composer.c | 7 ++- > drivers/gpu/drm/vkms/vkms_plane.c| 16 > 2 files changed, 10 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c > b/drivers/gpu/drm/vkms/vkms_composer.c > index b05bd008aeab..19d1078e9d34 100644 > --- a/drivers/gpu/drm/vkms/vkms_composer.c > +++ b/drivers/gpu/drm/vkms/vkms_composer.c > @@ -92,8 +92,13 @@ static int get_y_pos(struct vkms_frame_info *frame_info, > int y) > return -1; > return y + frame_info->dst.x1; > default: > - return y; > + break; > } > + > + if (frame_info->rotation & DRM_MODE_REFLECT_Y) > + return drm_rect_height(&frame_info->dst) - y - 1; > + > + return y; > } > > static bool check_limit(struct vkms_frame_info *frame_info, int pos) > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c > b/drivers/gpu/drm/vkms/vkms_plane.c > index 11662afa9fe4..d08bda869a24 100644 > --- a/drivers/gpu/drm/vkms/vkms_plane.c > +++ b/drivers/gpu/drm/vkms/vkms_plane.c > @@ -121,12 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane > *plane, > frame_info->fb = fb; > memcpy(&frame_info->map, &shadow_plane_state->data, > sizeof(frame_info->map)); > drm_framebuffer_get(frame_info->fb); > - frame_info->rotation = drm_rotation_simplify(new_state->rotation, > - DRM_MODE_ROTATE_0 | > - DRM_MODE_ROTATE_90 | > - DRM_MODE_ROTATE_180 | > - DRM_MODE_ROTATE_270 | > - DRM_MODE_REFLECT_X); > + frame_info->rotation = drm_rotation_simplify(new_state->rotation, > DRM_MODE_ROTATE_MASK | > + DRM_MODE_REFLECT_MASK); What are you trying to achieve with that? -- Ville Syrjälä Intel
Re: [PATCH] misc: sram: Add dma-heap-export reserved SRAM area type
On 4/14/23 12:44 AM, Christian Gmeiner wrote: Hi Andrew Am Di., 4. Apr. 2023 um 17:02 Uhr schrieb Christian Gmeiner : Hi Andrew Okay, will split for v2. Was there a follow-up v2 of this patchset? AFAICT this series did not make it into the mainline kernel. Do you have any plans to work on it? If not I would like to help out as we have a use case where we want to use a dma-buf sram exporter. Sure, I've been keeping it alive in our evil vendor tree, but if there is interest upstream now I'll post a v2 and CC you. That would be great! Did you find time to prepare a v2? If not, can you point me to the evil vendor tree? I did find some time and CC'd you on v2, the patch's subject was slightly renamed, so maybe your emailer missed it? https://patchwork.kernel.org/project/linux-media/patch/20230403192433.26648-1-...@ti.com/ Our evil vendor trees are here either way: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/ Andrew
[PATCH v2 7/7] drm/vkms: drop "Rotation" TODO
Now that VKMS supports all values of rotation and reflection, drop the "Rotation" task from the TODO list. Signed-off-by: Maíra Canal --- Documentation/gpu/vkms.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 49db221c0f52..413e6815b9bc 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -125,7 +125,7 @@ There's lots of plane features we could add support for: - Full alpha blending on all planes. -- Rotation, scaling. +- Scaling. - Additional buffer formats, especially YUV formats for video like NV12. Low/high bpp RGB formats would also be interesting. -- 2.39.2
[PATCH v2 6/7] drm/vkms: add reflect-y property
Currently, vkms only support the reflect-x property. Therefore, add the reflect-y property to vkms through a software implementation of the operation. This is possible by reverse reading the y axis during the blending. Now, vkms support all possible rotation values. Tested with igt@kms_rotation_crc@primary-reflect-y and igt@kms_rotation_crc@sprite-reflect-y [1]. [1] https://patchwork.freedesktop.org/series/116025/ Signed-off-by: Maíra Canal --- drivers/gpu/drm/vkms/vkms_composer.c | 7 ++- drivers/gpu/drm/vkms/vkms_plane.c| 16 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index b05bd008aeab..19d1078e9d34 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -92,8 +92,13 @@ static int get_y_pos(struct vkms_frame_info *frame_info, int y) return -1; return y + frame_info->dst.x1; default: - return y; + break; } + + if (frame_info->rotation & DRM_MODE_REFLECT_Y) + return drm_rect_height(&frame_info->dst) - y - 1; + + return y; } static bool check_limit(struct vkms_frame_info *frame_info, int pos) diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 11662afa9fe4..d08bda869a24 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -121,12 +121,8 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info->fb = fb; memcpy(&frame_info->map, &shadow_plane_state->data, sizeof(frame_info->map)); drm_framebuffer_get(frame_info->fb); - frame_info->rotation = drm_rotation_simplify(new_state->rotation, -DRM_MODE_ROTATE_0 | -DRM_MODE_ROTATE_90 | -DRM_MODE_ROTATE_180 | -DRM_MODE_ROTATE_270 | -DRM_MODE_REFLECT_X); + frame_info->rotation = drm_rotation_simplify(new_state->rotation, DRM_MODE_ROTATE_MASK | +DRM_MODE_REFLECT_MASK); drm_rect_rotate(&frame_info->dst, drm_rect_width(&frame_info->dst), drm_rect_height(&frame_info->dst), frame_info->rotation); @@ -240,12 +236,8 @@ struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev, drm_plane_helper_add(&plane->base, funcs); - drm_plane_create_rotation_property(&plane->base, DRM_MODE_ROTATE_0, - DRM_MODE_ROTATE_0 | - DRM_MODE_ROTATE_90 | - DRM_MODE_ROTATE_180 | - DRM_MODE_ROTATE_270 | - DRM_MODE_REFLECT_X); + drm_plane_create_rotation_property(&plane->base, DRM_MODE_ROTATE_0, DRM_MODE_ROTATE_MASK | + DRM_MODE_REFLECT_MASK); return plane; } -- 2.39.2
[PATCH v2 5/7] drm/vkms: add reflect-x property
Currently, vkms doesn't support any reflection property. Therefore, add
the reflect-x property to vkms through a software implementation of the
operation. This is possible by reverse reading the x axis during the
blending.
Tested with igt@kms_rotation_crc@primary-reflect-x and
igt@kms_rotation_crc@sprite-reflect-x [1].
[1] https://patchwork.freedesktop.org/series/116025/
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_formats.c | 2 +-
drivers/gpu/drm/vkms/vkms_plane.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index c4513f3d6876..2f8b41bf9ff9 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -45,7 +45,7 @@ static void *get_packed_src_addr(const struct vkms_frame_info
*frame_info, int y
static int get_x_position(const struct vkms_frame_info *frame_info, int
x_limit, int x)
{
- if (frame_info->rotation & (DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270))
+ if (frame_info->rotation & (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_180 |
DRM_MODE_ROTATE_270))
return x_limit - x - 1;
return x;
}
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index 5f69e0efd85f..11662afa9fe4 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -125,7 +125,8 @@ static void vkms_plane_atomic_update(struct drm_plane
*plane,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_90 |
DRM_MODE_ROTATE_180 |
-DRM_MODE_ROTATE_270);
+DRM_MODE_ROTATE_270 |
+DRM_MODE_REFLECT_X);
drm_rect_rotate(&frame_info->dst, drm_rect_width(&frame_info->dst),
drm_rect_height(&frame_info->dst),
frame_info->rotation);
@@ -243,7 +244,8 @@ struct vkms_plane *vkms_plane_init(struct vkms_device
*vkmsdev,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_90 |
DRM_MODE_ROTATE_180 |
- DRM_MODE_ROTATE_270);
+ DRM_MODE_ROTATE_270 |
+ DRM_MODE_REFLECT_X);
return plane;
}
--
2.39.2
[PATCH v2 4/7] drm/vkms: add rotate-270 property
Currently, vkms only supports the rotate-90 and rotate-180 properties.
Therefore, improve the vkms IGT test coverage by adding the rotate-270
property to vkms. The rotation was implement by software: rotate the way
the blending occurs by making the source x axis be the destination y axis
and the source y axis be the destination x axis and reverse-read the axis.
Tested with igt@kms_rotation_crc@primary-rotation-270, and
igt@kms_rotation_crc@sprite-rotation-270.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_composer.c | 12 ++--
drivers/gpu/drm/vkms/vkms_formats.c | 7 ---
drivers/gpu/drm/vkms/vkms_plane.c| 6 --
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 824bb65badb7..b05bd008aeab 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,9 @@ static struct pixel_argb_u16 *get_out_buffer(const struct
vkms_frame_info *frame
case DRM_MODE_ROTATE_180:
out -= frame_info->dst.x1;
break;
+ case DRM_MODE_ROTATE_270:
+ out += frame_info->dst.y1;
+ break;
default:
out += frame_info->dst.x1;
break;
@@ -63,7 +67,7 @@ static void pre_mul_alpha_blend(struct vkms_frame_info
*frame_info,
struct pixel_argb_u16 *in = stage_buffer->pixels;
int limit = min_t(size_t, drm_rect_width(&frame_info->dst),
stage_buffer->n_pixels);
- if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ if (drm_rotation_90_or_270(frame_info->rotation))
limit = min_t(size_t, drm_rect_height(&frame_info->dst),
stage_buffer->n_pixels);
for (int x = 0; x < limit; x++) {
@@ -83,6 +87,10 @@ static int get_y_pos(struct vkms_frame_info *frame_info, int
y)
return frame_info->dst.x2 - y - 1;
case DRM_MODE_ROTATE_180:
return drm_rect_height(&frame_info->dst) - y - 1;
+ case DRM_MODE_ROTATE_270:
+ if (y + frame_info->dst.x1 < 0)
+ return -1;
+ return y + frame_info->dst.x1;
default:
return y;
}
@@ -90,7 +98,7 @@ static int get_y_pos(struct vkms_frame_info *frame_info, int
y)
static bool check_limit(struct vkms_frame_info *frame_info, int pos)
{
- if (frame_info->rotation & DRM_MODE_ROTATE_90) {
+ if (drm_rotation_90_or_270(frame_info->rotation)) {
if (pos >= 0 && pos < drm_rect_width(&frame_info->dst))
return true;
} else {
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 90b72b0ff8c9..c4513f3d6876 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
@@ -44,21 +45,21 @@ static void *get_packed_src_addr(const struct
vkms_frame_info *frame_info, int y
static int get_x_position(const struct vkms_frame_info *frame_info, int
x_limit, int x)
{
- if (frame_info->rotation & DRM_MODE_ROTATE_180)
+ if (frame_info->rotation & (DRM_MODE_ROTATE_180 | DRM_MODE_ROTATE_270))
return x_limit - x - 1;
return x;
}
static int get_limit(const struct vkms_frame_info *frame_info, struct
line_buffer *stage_buffer)
{
- if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ if (drm_rotation_90_or_270(frame_info->rotation))
return min_t(size_t, drm_rect_height(&frame_info->dst),
stage_buffer->n_pixels);
return min_t(size_t, drm_rect_width(&frame_info->dst),
stage_buffer->n_pixels);
}
static void *get_src_pixels(const struct vkms_frame_info *frame_info, int x,
int y, int pixel_size)
{
- if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ if (drm_rotation_90_or_270(frame_info->rotation))
return get_packed_src_addr(frame_info, x + frame_info->dst.y1)
+ pixel_size * y;
return get_packed_src_addr(frame_info, y) + pixel_size * x;
}
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index ce2ebe56f6e4..5f69e0efd85f 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -124,7 +124,8 @@ static void vkms_plane_atomic_update(struct drm_plane
*plane,
frame_info->rotation = drm_rotation_simplify(new_state->rotation,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_90 |
-DRM_MODE_ROTATE_180);
+DRM_MODE_ROTATE_180 |
+DRM_MODE_ROTATE_270);
drm_rect_rotate(&frame_info->dst, drm_
[PATCH v2 3/7] drm/vkms: add rotate-90 property
Currently, vkms only supports the rotate-180 property. Therefore,
improve the vkms IGT test coverage by adding the rotate-90 property to
vkms. The rotation was implement by software: rotate the way the
blending occurs by making the source x axis be the destination y axis and
the source y axis be the destination x axis.
Tested with igt@kms_rotation_crc@primary-rotation-90,
igt@kms_rotation_crc@sprite-rotation-90, and
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_composer.c | 29
drivers/gpu/drm/vkms/vkms_formats.c | 28 ---
drivers/gpu/drm/vkms/vkms_plane.c| 2 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 914d85ac1654..824bb65badb7 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -17,6 +17,9 @@ static struct pixel_argb_u16 *get_out_buffer(const struct
vkms_frame_info *frame
struct pixel_argb_u16 *out = output_buffer->pixels;
switch (frame_info->rotation & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_90:
+ out -= frame_info->dst.y1;
+ break;
case DRM_MODE_ROTATE_180:
out -= frame_info->dst.x1;
break;
@@ -58,10 +61,12 @@ static void pre_mul_alpha_blend(struct vkms_frame_info
*frame_info,
{
struct pixel_argb_u16 *out = get_out_buffer(frame_info, output_buffer);
struct pixel_argb_u16 *in = stage_buffer->pixels;
- int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
- stage_buffer->n_pixels);
+ int limit = min_t(size_t, drm_rect_width(&frame_info->dst),
stage_buffer->n_pixels);
+
+ if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ limit = min_t(size_t, drm_rect_height(&frame_info->dst),
stage_buffer->n_pixels);
- for (int x = 0; x < x_limit; x++) {
+ for (int x = 0; x < limit; x++) {
out[x].a = (u16)0x;
out[x].r = pre_mul_blend_channel(in[x].r, out[x].r, in[x].a);
out[x].g = pre_mul_blend_channel(in[x].g, out[x].g, in[x].a);
@@ -72,6 +77,10 @@ static void pre_mul_alpha_blend(struct vkms_frame_info
*frame_info,
static int get_y_pos(struct vkms_frame_info *frame_info, int y)
{
switch (frame_info->rotation & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_90:
+ if (y - frame_info->dst.x1 < 0)
+ return -1;
+ return frame_info->dst.x2 - y - 1;
case DRM_MODE_ROTATE_180:
return drm_rect_height(&frame_info->dst) - y - 1;
default:
@@ -79,11 +88,15 @@ static int get_y_pos(struct vkms_frame_info *frame_info,
int y)
}
}
-static bool check_y_limit(struct vkms_frame_info *frame_info, int y)
+static bool check_limit(struct vkms_frame_info *frame_info, int pos)
{
- if (y >= frame_info->dst.y1 && y < frame_info->dst.y2)
- return true;
-
+ if (frame_info->rotation & DRM_MODE_ROTATE_90) {
+ if (pos >= 0 && pos < drm_rect_width(&frame_info->dst))
+ return true;
+ } else {
+ if (pos >= frame_info->dst.y1 && pos < frame_info->dst.y2)
+ return true;
+ }
return false;
}
@@ -125,7 +138,7 @@ static void blend(struct vkms_writeback_job *wb,
for (size_t i = 0; i < n_active_planes; i++) {
y_pos = get_y_pos(plane[i]->frame_info, y);
- if (!check_y_limit(plane[i]->frame_info, y_pos))
+ if (!check_limit(plane[i]->frame_info, y_pos))
continue;
vkms_compose_row(stage_buffer, plane[i], y_pos);
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 7a98d4d75f17..90b72b0ff8c9 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -49,6 +49,20 @@ static int get_x_position(const struct vkms_frame_info
*frame_info, int x_limit,
return x;
}
+static int get_limit(const struct vkms_frame_info *frame_info, struct
line_buffer *stage_buffer)
+{
+ if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ return min_t(size_t, drm_rect_height(&frame_info->dst),
stage_buffer->n_pixels);
+ return min_t(size_t, drm_rect_width(&frame_info->dst),
stage_buffer->n_pixels);
+}
+
+static void *get_src_pixels(const struct vkms_frame_info *frame_info, int x,
int y, int pixel_size)
+{
+ if (frame_info->rotation & DRM_MODE_ROTATE_90)
+ return get_packed_src_addr(frame_info, x + frame_info->dst.y1)
+ pixel_size * y;
+ return get_packed_src_addr(frame_info, y) + pixel_size * x;
+}
+
static void ARGB_to_argb_u16(u16 *src_pixels, struct pixel_argb_u16
[PATCH v2 2/7] drm/vkms: add rotate-0 and rotate-180 properties
Currently, vkms doesn't support any rotation property. Therefore,
improve the vkms IGT test coverage by adding the rotate-0 and rotate-180
properties to vkms. The rotation was implemented by software: invert the
way the blending occurs by reverse reading the x and y axis.
Tested with igt@kms_rotation_crc@primary-rotation-180,
igt@kms_rotation_crc@sprite-rotation-180, and
igt@kms_rotation_crc@cursor-rotation-180.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_composer.c | 39
drivers/gpu/drm/vkms/vkms_drv.h | 1 +
drivers/gpu/drm/vkms/vkms_formats.c | 16 +---
drivers/gpu/drm/vkms/vkms_plane.c| 12 +
4 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 80164e79af00..914d85ac1654 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -11,6 +11,23 @@
#include "vkms_drv.h"
+static struct pixel_argb_u16 *get_out_buffer(const struct vkms_frame_info
*frame_info,
+struct line_buffer *output_buffer)
+{
+ struct pixel_argb_u16 *out = output_buffer->pixels;
+
+ switch (frame_info->rotation & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_180:
+ out -= frame_info->dst.x1;
+ break;
+ default:
+ out += frame_info->dst.x1;
+ break;
+ }
+
+ return out;
+}
+
static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
u32 new_color;
@@ -39,8 +56,7 @@ static void pre_mul_alpha_blend(struct vkms_frame_info
*frame_info,
struct line_buffer *stage_buffer,
struct line_buffer *output_buffer)
{
- int x_dst = frame_info->dst.x1;
- struct pixel_argb_u16 *out = output_buffer->pixels + x_dst;
+ struct pixel_argb_u16 *out = get_out_buffer(frame_info, output_buffer);
struct pixel_argb_u16 *in = stage_buffer->pixels;
int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
stage_buffer->n_pixels);
@@ -53,6 +69,16 @@ static void pre_mul_alpha_blend(struct vkms_frame_info
*frame_info,
}
}
+static int get_y_pos(struct vkms_frame_info *frame_info, int y)
+{
+ switch (frame_info->rotation & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_180:
+ return drm_rect_height(&frame_info->dst) - y - 1;
+ default:
+ return y;
+ }
+}
+
static bool check_y_limit(struct vkms_frame_info *frame_info, int y)
{
if (y >= frame_info->dst.y1 && y < frame_info->dst.y2)
@@ -86,6 +112,7 @@ static void blend(struct vkms_writeback_job *wb,
{
struct vkms_plane_state **plane = crtc_state->active_planes;
u32 n_active_planes = crtc_state->num_active_planes;
+ int y_pos;
const struct pixel_argb_u16 background_color = { .a = 0x };
@@ -96,10 +123,12 @@ static void blend(struct vkms_writeback_job *wb,
/* The active planes are composed associatively in z-order. */
for (size_t i = 0; i < n_active_planes; i++) {
- if (!check_y_limit(plane[i]->frame_info, y))
+ y_pos = get_y_pos(plane[i]->frame_info, y);
+
+ if (!check_y_limit(plane[i]->frame_info, y_pos))
continue;
- vkms_compose_row(stage_buffer, plane[i], y);
+ vkms_compose_row(stage_buffer, plane[i], y_pos);
pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
output_buffer);
}
@@ -107,7 +136,7 @@ static void blend(struct vkms_writeback_job *wb,
*crc32 = crc32_le(*crc32, (void *)output_buffer->pixels,
row_size);
if (wb)
- wb->wb_write(&wb->wb_frame_info, output_buffer, y);
+ wb->wb_write(&wb->wb_frame_info, output_buffer, y_pos);
}
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index d7ad813d7ae7..8344395d7745 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -27,6 +27,7 @@ struct vkms_frame_info {
struct drm_framebuffer *fb;
struct drm_rect src, dst;
struct iosys_map map[DRM_FORMAT_MAX_PLANES];
+ unsigned int rotation;
unsigned int offset;
unsigned int pitch;
unsigned int cpp;
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 02b0fc5a0839..7a98d4d75f17 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -42,6 +42,13 @@ static void *get_packed_src_addr(const struct
vkms_frame_info *frame_info, int y
return packed_pixels_addr(frame_info, x_src, y_src);
}
+static int
[PATCH v2 0/7] drm/vkms: introduce plane rotation property
This patchset implements all possible rotation value in vkms. All operations were implemented by software by changing the way the pixels are read. The way the blending is performed can be depicted as: - rotate-0: (x) > -- (y) || | || | || ˇ || -- - rotate-90: < (y) -- (x) || | || | || ˇ || -- - rotate-180: < (x) -- (y) || ^ || | || | || -- - rotate-270: (y) > -- (x) || ^ || | || | || -- - reflect-x: < (x) -- (y) || | || | || ˇ || -- - reflect-y: (x) > -- (y) || ^ || | || | || -- The patchset was tested with IGT's kms_rotation_crc tests and also with some additional tests [1] for the reflection operations. In order to avoid code duplication, I introduced a patch that isolates the pixel format convertion and wraps it in a single loop. v1 -> v2: * Add patch to isolate pixel format convertion (Arthur Grillo). [1] https://patchwork.freedesktop.org/series/116025/ Best Regards, - Maíra Canal Maíra Canal (7): drm/vkms: isolate pixel conversion functionality drm/vkms: add rotate-0 and rotate-180 properties drm/vkms: add rotate-90 property drm/vkms: add rotate-270 property drm/vkms: add reflect-x property drm/vkms: add reflect-y property drm/vkms: drop "Rotation" TODO Documentation/gpu/vkms.rst | 2 +- drivers/gpu/drm/vkms/vkms_composer.c | 79 +++--- drivers/gpu/drm/vkms/vkms_drv.h | 5 +- drivers/gpu/drm/vkms/vkms_formats.c | 153 ++- drivers/gpu/drm/vkms/vkms_formats.h | 2 +- drivers/gpu/drm/vkms/vkms_plane.c| 12 ++- 6 files changed, 163 insertions(+), 90 deletions(-) -- 2.39.2
[PATCH v2 1/7] drm/vkms: isolate pixel conversion functionality
Currently, the pixel conversion functions repeat the same loop to
iterate the rows. Instead of repeating the same code for each pixel
format, create a function to wrap the loop and isolate the pixel
conversion functionality.
Suggested-by: Arthur Grillo
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 +-
drivers/gpu/drm/vkms/vkms_drv.h | 4 +-
drivers/gpu/drm/vkms/vkms_formats.c | 136 ---
drivers/gpu/drm/vkms/vkms_formats.h | 2 +-
drivers/gpu/drm/vkms/vkms_plane.c| 2 +-
5 files changed, 65 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 8e53fa80742b..80164e79af00 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -99,7 +99,7 @@ static void blend(struct vkms_writeback_job *wb,
if (!check_y_limit(plane[i]->frame_info, y))
continue;
- plane[i]->plane_read(stage_buffer,
plane[i]->frame_info, y);
+ vkms_compose_row(stage_buffer, plane[i], y);
pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
output_buffer);
}
@@ -118,7 +118,7 @@ static int check_format_funcs(struct vkms_crtc_state
*crtc_state,
u32 n_active_planes = crtc_state->num_active_planes;
for (size_t i = 0; i < n_active_planes; i++)
- if (!planes[i]->plane_read)
+ if (!planes[i]->pixel_read)
return -1;
if (active_wb && !active_wb->wb_write)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 4a248567efb2..d7ad813d7ae7 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -56,8 +56,7 @@ struct vkms_writeback_job {
struct vkms_plane_state {
struct drm_shadow_plane_state base;
struct vkms_frame_info *frame_info;
- void (*plane_read)(struct line_buffer *buffer,
- const struct vkms_frame_info *frame_info, int y);
+ void (*pixel_read)(u16 *src_buffer, struct pixel_argb_u16 *out_pixels,
int x);
};
struct vkms_plane {
@@ -155,6 +154,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
/* Composer Support */
void vkms_composer_worker(struct work_struct *work);
void vkms_set_composer(struct vkms_output *out, bool enabled);
+void vkms_compose_row(struct line_buffer *stage_buffer, struct
vkms_plane_state *plane, int y);
/* Writeback */
int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index d4950688b3f1..02b0fc5a0839 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -42,100 +42,82 @@ static void *get_packed_src_addr(const struct
vkms_frame_info *frame_info, int y
return packed_pixels_addr(frame_info, x_src, y_src);
}
-static void ARGB_to_argb_u16(struct line_buffer *stage_buffer,
-const struct vkms_frame_info *frame_info, int
y)
+static void ARGB_to_argb_u16(u16 *src_pixels, struct pixel_argb_u16
*out_pixels, int x)
{
- struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
- u8 *src_pixels = get_packed_src_addr(frame_info, y);
- int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
- stage_buffer->n_pixels);
-
- for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
- /*
-* The 257 is the "conversion ratio". This number is obtained
by the
-* (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries
to get
-* the best color value in a pixel format with more
possibilities.
-* A similar idea applies to others RGB color conversions.
-*/
- out_pixels[x].a = (u16)src_pixels[3] * 257;
- out_pixels[x].r = (u16)src_pixels[2] * 257;
- out_pixels[x].g = (u16)src_pixels[1] * 257;
- out_pixels[x].b = (u16)src_pixels[0] * 257;
- }
+ u8 *pixels = (u8 *)src_pixels;
+
+ /*
+* The 257 is the "conversion ratio". This number is obtained by the
+* (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
+* the best color value in a pixel format with more possibilities.
+* A similar idea applies to others RGB color conversions.
+*/
+ out_pixels[x].a = (u16)pixels[3] * 257;
+ out_pixels[x].r = (u16)pixels[2] * 257;
+ out_pixels[x].g = (u16)pixels[1] * 257;
+ out_pixels[x].b = (u16)pixels[0] * 257;
}
-static void XRGB_to_argb_u16(struct line_buffer *stage_buffer,
-const struct vkms_frame_info *frame_info, int
y)
+static void XR
Re: [PATCH v3 6/7] drm: Add fdinfo memory stats
On Fri, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
wrote:
>
>
> On 13/04/2023 21:05, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 13/04/2023 14:27, Daniel Vetter wrote:
> >>> On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 20:18, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> >> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >>>
> >>> On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 11/04/2023 23:56, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> v2: Fix typos, change size units to match docs, use div_u64
> >> v3: Do it in core
> >>
> >> Signed-off-by: Rob Clark
> >> Reviewed-by: Emil Velikov
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 21
> >> drivers/gpu/drm/drm_file.c| 76
> >> +++
> >> include/drm/drm_file.h| 1 +
> >> include/drm/drm_gem.h | 19 +++
> >> 4 files changed, 117 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index b46327356e80..b5e7802532ed 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -105,6 +105,27 @@ object belong to this client, in the
> >> respective memory region.
> >> Default unit shall be bytes with optional unit specifiers of
> >> 'KiB' or 'MiB'
> >> indicating kibi- or mebi-bytes.
> >>
> >> +- drm-shared-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are shared with another file (ie.
> >> have more
> >> +than a single handle).
> >> +
> >> +- drm-private-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are not shared with another file.
> >> +
> >> +- drm-resident-memory: [KiB|MiB]
> >> +
> >> +The total size of buffers that are resident in system memory.
> >
> > I think this naming maybe does not work best with the existing
> > drm-memory- keys.
>
> Actually, it was very deliberate not to conflict with the existing
> drm-memory- keys ;-)
>
> I wouldn't have preferred drm-memory-{active,resident,...} but it
> could be mis-parsed by existing userspace so my hands were a bit
> tied.
>
> > How about introduce the concept of a memory region from the start
> > and
> > use naming similar like we do for engines?
> >
> > drm-memory-$CATEGORY-$REGION: ...
> >
> > Then we document a bunch of categories and their semantics, for
> > instance:
> >
> > 'size' - All reachable objects
> > 'shared' - Subset of 'size' with handle_count > 1
> > 'resident' - Objects with backing store
> > 'active' - Objects in use, subset of resident
> > 'purgeable' - Or inactive? Subset of resident.
> >
> > We keep the same semantics as with process memory accounting (if I
> > got
> > it right) which could be desirable for a simplified mental model.
> >
> > (AMD needs to remind me of their 'drm-memory-...' keys semantics.
> > If we
> > correctly captured this in the first round it should be equivalent
> > to
> > 'resident' above. In any case we can document no category is equal
> > to
> > which category, and at most one of the two must be output.)
> >
> > Region names we at most partially standardize. Like we could say
> > 'system' is to be used where backing store is system RAM and others
> > are
> > driver defined.
> >
> > Then discrete GPUs could emit N sets of key-values, one for each
> > memory
> > region they support.
> >
> > I think this all also works for objects which can be migrated
> > between
> > memory regions. 'Size' accounts them against all regions while for
> > 'resident' they only appear in the region of their current
> > placement, etc.
>
> I'm not too sure how to rectify different memory regions with this,
> since drm core doesn't really know about the driver's memory regions.
> Perhaps we can go back to this being a helper and drivers with vram
> just don't use the he
linux-next: manual merge of the drm-misc tree with the mm-stable tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/ttm/ttm_pool.c
between commit:
23baf831a32c0 ("mm, treewide: redefine MAX_ORDER sanely")
from the mm-stable tree and commit:
56e51681246e5 ("drm/ttm: revert "Reduce the number of used allocation orders
for TTM pages"")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/gpu/drm/ttm/ttm_pool.c
index 4db3982057be8,dfce896c4baeb..0
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
[Just the version in mm]
Re: [PATCH 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
On Fri, 14 Apr 2023 12:31, AngeloGioacchino Del Regno
wrote:
>Il 13/04/23 14:46, Guillaume Ranquet ha scritto:
>> The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
>> by the kernel test robot.
>>
>> Fix the issue by removing the variable altogether and testing out the
>> return value of mtk_hdmi_pll_set_hw()
>>
>> Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
>> Reported-by: kernel test robot
>> Signed-off-by: Guillaume Ranquet
>> ---
>> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>> index abfc077fb0a8..e10da6c4147e 100644
>> --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
>> @@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
>> *hdmi_phy, struct clk_hw *hw,
>> u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
>> u8 txpredivs[4] = { 2, 4, 6, 12 };
>> u32 fbkdiv_low;
>> -int i, ret;
>> +int i;
>>
>> pixel_clk = rate;
>> tmds_clk = pixel_clk;
>> @@ -292,10 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
>> *hdmi_phy, struct clk_hw *hw,
>> if (!(digital_div <= 32 && digital_div >= 1))
>> return -EINVAL;
>>
>> -mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
>> +if (mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
>> PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
>> -txposdiv, digital_div);
>> -if (ret)
>> +txposdiv, digital_div))
>> return -EINVAL;
>>
>
>I don't get why we're returning -EINVAL unconditionally in the first place,
>here.
>
>Function mtk_hdmi_pll_set_hw() should return zero or a negative error number:
>in
>that case, the previous *intention* was fine, so this should be
>
Hi Angelo,
I was maybe a bit too quick on fixing this that way.
Anyway it doesn't change a thing as mtk_hdmi_pll_set_hw() eitheir
returns 0 or -EINVAL.
But I agree that the logic is dubious and propagating the return value
is the right thing
to do.
I see that Arnd and Tom posted versions that you might prefer:
https://lore.kernel.org/linux-phy/20230414075842.4006164-1-a...@kernel.org/
https://lore.kernel.org/linux-phy/20230414122253.3171524-1-t...@redhat.com/
Thx,
Guillaume.
> ret = mtk_hdmi_pll_set_hw()
> if (ret)
> return ret;
>
> return 0;
>
>
>Regards,
>Angelo
[PATCH] phy: mediatek: fix returning garbage
clang reports
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable
'ret' is uninitialized when used here [-Werror,-Wuninitialized]
if (ret)
^~~
ret should have been set by the preceding call to mtk_hdmi_pll_set_hw.
Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Signed-off-by: Tom Rix
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..c63294e451d6 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -292,9 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
- PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
- txposdiv, digital_div);
+ ret = mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
+ txposdiv, digital_div);
if (ret)
return -EINVAL;
--
2.27.0
[PATCH] drm/amd/pm: change pmfw_decoded_link_width, speed variables to globals
gcc with W=1 reports
In file included from
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0.c:36:
./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/inc/smu_v13_0.h:66:18: error:
‘pmfw_decoded_link_width’ defined but not used
[-Werror=unused-const-variable=]
66 | static const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
| ^~~
./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/inc/smu_v13_0.h:65:18: error:
‘pmfw_decoded_link_speed’ defined but not used
[-Werror=unused-const-variable=]
65 | static const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
| ^~~
These variables are defined and used in smu_v13_0_7_ppt.c and smu_v13_0_0_ppt.c.
There should be only one definition. So define the variables as globals
in smu_v13_0.c
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 4 ++--
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index 7944ce80e5c3..df3baaab0037 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -62,8 +62,8 @@
#define CTF_OFFSET_HOTSPOT 5
#define CTF_OFFSET_MEM 5
-static const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
-static const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
+extern const int pmfw_decoded_link_speed[5];
+extern const int pmfw_decoded_link_width[7];
#define DECODE_GEN_SPEED(gen_speed_idx)
(pmfw_decoded_link_speed[gen_speed_idx])
#define DECODE_LANE_WIDTH(lane_width_idx)
(pmfw_decoded_link_width[lane_width_idx])
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 73175c993da9..393c6a7b9609 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -85,6 +85,9 @@ MODULE_FIRMWARE("amdgpu/smu_13_0_10.bin");
static const int link_width[] = {0, 1, 2, 4, 8, 12, 16};
static const int link_speed[] = {25, 50, 80, 160};
+const int pmfw_decoded_link_speed[5] = {1, 2, 3, 4, 5};
+const int pmfw_decoded_link_width[7] = {0, 1, 2, 4, 8, 12, 16};
+
int smu_v13_0_init_microcode(struct smu_context *smu)
{
struct amdgpu_device *adev = smu->adev;
--
2.27.0
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
Hi,
On 2023/4/14 15:56, Daniel Vetter wrote:
On Fri, 14 Apr 2023 at 09:34, Thomas Zimmermann wrote:
Hi
Am 14.04.23 um 07:36 schrieb Daniel Vetter:
On Fri, 14 Apr 2023 at 06:24, Sui Jingfeng <15330273...@189.cn> wrote:
Hi,
On 2023/4/14 04:01, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.04.23 um 20:56 schrieb Daniel Vetter:
[...]
This should switch the existing code over to using drm_framebuffer instead
of fbdev:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ef4eb8b12766..99ca69dd432f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -647,22 +647,26 @@ static void drm_fb_helper_damage(struct drm_fb_helper
*helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t
off, size_t len,
struct drm_rect *clip)
{
+ struct drm_fb_helper *helper = info->par;
+
off_t end = off + len;
u32 x1 = 0;
u32 y1 = off / info->fix.line_length;
- u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 x2 = helper->fb->height;
+ unsigned stride = helper->fb->pitches[0];
+ u32 y2 = DIV_ROUND_UP(end, stride);
+ int bpp = drm_format_info_bpp(helper->fb->format, 0);
Please DONT do that. The code here is fbdev code and shouldn't bother about
DRM data structures. Actually, it shouldn't be here: a number of fbdev
drivers with deferred I/O contain similar code and the fbdev module should
provide us with a helper. (I think I even had some patches somewhere.)
Well my thinking is that it's a drm driver,
Yes, I actually agree with this, and the code looks quite good. And I
really want to adopt it.
Because here is DRM, we should emulate the fbdev in the DRM's way.
The DRM is really the big brother on the behind of emulated fbdev,
who provide the real displayable backing memory and scant out engine to
display such a buffer.
But currently, the fact is, drm_fb_helper.c still initializes lots of
data structure come from fbdev world.
For example, the drm_fb_helper_fill_fix() and drm_fb_helper_fill_var()
in drm_fb_helper_fill_info() function.
This saying implicitly that the fbdev-generic is a glue layer which copy
damage frame buffer data
from the front end(fbdev layer) to its drm backend. It's not a 100%
replacement its fbdev front end,
rather, it relay on it.
so if we have issue with limit
checks blowing up it makes more sense to check them against drm limits.
Plus a lot more people understand those than fbdev. They should all match
anyway, or if they dont, we have a bug.
Yes, this is really what I'm worry about.
I see that members of struct fb_var_screeninfo can be changed by
user-space. For example, xoffset and yoffset.
There is no change about 'info->var.xres' and 'info->var.yres' from the
userspace,
therefore, they should all match in practice.
User-space can choose a use a smaller dispaly area than 'var.xres x
var.yres',
but that is implemented with 'var.xoffset' and 'var.xoffset'.
But consider that the name 'var', which may stand for 'variation' or
'vary'. This is terrifying.
I imagine, with a shadow buffer, the front end can do any modeset on the
runtime freely,
including change the format of frame buffer on the runtime. Just do not
out-of-bound.
The middle do the conversion on the fly.
We might also create double shadow buffer size to allow the front end to
pan?
Yeah so the front should be able to pan. And the front-end can
actually make xres/yres smalle than drm_fb->height/width, so we _have_
to use the fb side of things. Otherwise it's a bug I just realized.
What are you talking about? The GEM buffer is a full fbdev framebuffer,
which is screen resolution multiplied by the overall factor. The shadow
buffer is exactly the same size. You can already easily pan within these
buffers.
There's also no need/way to change video modes or formats in the shadow
buffer. If we'd ever support that, it would be implemented in the DRM
driver's modesetting. The relationship between GEM buffer and shadow
buffer remains unaffected by this.
Try it and be amazed :-) I've seen enough syzkaller bugs and screamed
at them that yes we do this. Also xres/yres is the wrong thing even if
you don't use fb ioctl to change things up in multi-monitor cases (we
allocate the drm_fb/fbdev virtual size to match the biggest
resolution, but then set fbinfo->var.x/yres to match the smallest to
make sure fbcon is fully visible everywhere).
I think you're confusion is the perfect case for why we really should
use fb->height/width/pitches[0] here.
-Daniel
Exactly,
This what I'm worry about, if someone add code with changing xres/yres
from userspace
via fb ioctl implemented. Then, xres/yres and
fb->height/width/pitches[0] may not match.
so fetch data from fbinfo->var.x/yres still more safe.
Yet, on our platform with drm/loongson driver wi
Re: [PATCH v2] drm/fbdev-generic: prohibit potential out-of-bounds access
Hi,
On 2023/4/14 03:16, Thomas Zimmermann wrote:
Hi,
thanks for the patch. This is effectively a revert of commit
8fbc9af55de0 ("drm/fbdev-generic: Set screen size to size of GEM
buffer"). Please add a Fixes tag.
Am 13.04.23 um 20:06 schrieb Sui Jingfeng:
From: Sui Jingfeng
The crazy fbdev test of IGT may write after EOF, which lead to
out-of-bound
Please drop 'crazy'. :)
This is OK.
By using the world 'crazy',
I meant that the test is very good and maybe it is written by
professional peoples
with the guidance by experienced engineer. So that even the corner get
tested.
access for the drm drivers using fbdev-generic. For example, run
fbdev test
on a x86-64+ast2400 platform with 1680x1050 resolution will cause the
linux
kernel hang with following call trace:
Oops: [#1] PREEMPT SMP PTI
[IGT] fbdev: starting subtest eof
Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
[IGT] fbdev: starting subtest nullptr
RIP: 0010:memcpy_erms+0xa/0x20
RSP: 0018:a17d40167d98 EFLAGS: 00010246
RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
RBP: a17d40167e20 R08: R09: 89522ecff8c0
R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
R13: 1a40 R14: 041a R15: a17d40167e30
FS: () GS:89525738()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
Call Trace:
? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
process_one_work+0x21f/0x430
worker_thread+0x4e/0x3c0
? __pfx_worker_thread+0x10/0x10
kthread+0xf4/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
CR2: a17d40e0b000
---[ end trace ]---
The indirect reason is drm_fb_helper_memory_range_to_clip() generate
damage
rectangles which partially or completely go out of the active display
area.
The second of argument 'off' is passing from the user-space, this
will lead
to the out-of-bound if it is large than (fb_height + 1) * fb_pitches;
while
DIV_ROUND_UP() may also controbute to error by 1.
This patch will add code to restrict the damage rect computed go
beyond of
the last line of the framebuffer.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 16
drivers/gpu/drm/drm_fbdev_generic.c | 2 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 64458982be40..6bb1b8b27d7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -641,19 +641,27 @@ static void drm_fb_helper_damage(struct
drm_fb_helper *helper, u32 x, u32 y,
static void drm_fb_helper_memory_range_to_clip(struct fb_info
*info, off_t off, size_t len,
struct drm_rect *clip)
{
+ u32 line_length = info->fix.line_length;
+ u32 fb_height = info->var.yres;
off_t end = off + len;
u32 x1 = 0;
- u32 y1 = off / info->fix.line_length;
+ u32 y1 = off / line_length;
u32 x2 = info->var.xres;
- u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+ u32 y2 = DIV_ROUND_UP(end, line_length);
+
+ /* Don't allow any of them beyond the bottom bound of display
area */
+ if (y1 > fb_height)
+ y1 = fb_height;
+ if (y2 > fb_height)
+ y2 = fb_height;
if ((y2 - y1) == 1) {
/*
* We've only written to a single scanline. Try to reduce
* the number of horizontal pixels that need an update.
*/
- off_t bit_off = (off % info->fix.line_length) * 8;
- off_t bit_end = (end % info->fix.line_length) * 8;
+ off_t bit_off = (off % line_length) * 8;
+ off_t bit_end = (end % line_length) * 8;
Please scratch all these changes. The current code should work as
intended. Only the generic fbdev emulation uses this code and it
should really be moved there at some point.
Are you meant that we should remove all these changes in
drivers/gpu/drm/drm_fb_helper.c ?
But this changes are helps to prevent the damage box computed go out of
bound,
the bound of the displayable shadow buffer on multiple display case.
It is the minimum width x height which could be fit in for all
display/minotor.
For example, one is 1920x1080 monitor, another is 1280x800 monitor.
connected to the motherboard simultaneously.
Then, 1920x1080x4 (suppose we are using the XRGB) scanout buffer will be
allocate by the GEM backend. But the the actual display area is 1280x800.
This is true at least for my driver on my platform, In this case,
```
info->var.xres ==1280;
info->var.yres == 800;
```
If don't restrict this, the damage box
Re: [Intel-gfx] [PATCH v2] drm/i915: avoid flush_scheduled_work() usage
On 2023/04/14 19:13, Jani Nikula wrote:
> On Fri, 14 Apr 2023, Tetsuo Handa wrote:
>> On 2023/03/15 19:47, Luca Coelho wrote:
>>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
Now that i915 is the last flush_scheduled_work() user, for now let's
start with blind conversion inside the whole drivers/gpu/drm/i915/
directory. Jani Nikula wants to use two workqueues in order to avoid
adding new module globals, but I'm not familiar enough to audit and
split into two workqueues.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
---
Changes in v2:
Add missing alloc_workqueue() failure check.
>>>
>>> Hi,
>>>
>>> Thanks for your patch! But it seems that you only fixed that failure
>>> check, without making the other change Jani proposed, namely, move the
>>> work to the i915 struct instead of making it a global.
>>>
>>> I'm working on that now.
>>
>> What is estimated time of arrival on this?
>> Can we expect your work in Linux 6.4 ?
>
> I'm afraid that ship has sailed. Sorry. :(
Well, then, can we temporarily apply "[PATCH v2] drm/i915: avoid
flush_scheduled_work() usage" ?
This patch is a mechanical conversion which unlikely causes regressions. This
patch eliminates
interference from work items outside of i915, which is small but an improvement
for i915 users.
[PATCH] dt-bindings: display: simplify compatibles syntax
Lists (items) with one item should be just const or enum because it is shorter and simpler. Signed-off-by: Krzysztof Kozlowski --- Rebased on next-20230406. I hope it applies cleanly... --- .../display/bridge/analogix,anx7625.yaml | 3 +-- .../display/panel/sharp,lq101r1sx01.yaml | 4 ++-- .../bindings/display/solomon,ssd1307fb.yaml | 24 +-- 3 files changed, 14 insertions(+), 17 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 7960745a8dbe..a1ed1004651b 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -16,8 +16,7 @@ description: | properties: compatible: -items: - - const: analogix,anx7625 +const: analogix,anx7625 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml index 9ec0e8aae4c6..57b44a0e763d 100644 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml @@ -34,8 +34,8 @@ properties: - items: - const: sharp,lq101r1sx03 - const: sharp,lq101r1sx01 - - items: - - const: sharp,lq101r1sx01 + - enum: + - sharp,lq101r1sx01 reg: true power-supply: true diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 8bd58913804a..94bb5ef567c6 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -14,20 +14,18 @@ properties: compatible: oneOf: # Deprecated compatible strings - - items: - - enum: - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c deprecated: true - - items: - - enum: - - sinowealth,sh1106 - - solomon,ssd1305 - - solomon,ssd1306 - - solomon,ssd1307 - - solomon,ssd1309 + - enum: + - sinowealth,sh1106 + - solomon,ssd1305 + - solomon,ssd1306 + - solomon,ssd1307 + - solomon,ssd1309 reg: maxItems: 1 -- 2.34.1
Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
Hi Tvrtko,
On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
[snip]
> >
> > [snip]
> > > However I am unsure if disabling pagefaulting is needed or not. Thomas,
> > > Matt, being the last to touch this area, perhaps you could have a look?
> > > Because I notice we have a fallback iomap path which still uses
> > > io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is
> > > safe, does the iomap side also needs converting to
> > > io_mapping_map_local_wc? Or they have separate requirements?
> >
> > AFAIK, the requirements for io_mapping_map_local_wc() are the same as for
> > kmap_local_page(): the kernel virtual address is _only_ valid in the caller
> > context, and map/unmap nesting must be done in stack-based ordering (LIFO).
> >
> > I think a follow up patch could safely switch to io_mapping_map_local_wc() /
> > io_mapping_unmap_local_wc since the address is local to context.
> >
> > However, not being an expert, reading your note now I suspect that I'm
> > missing
> > something. Can I ask why you think that page-faults disabling might be
> > necessary?
>
> I am not saying it is, was just unsure and wanted some people who worked on
> this code most recently to take a look and confirm.
>
> I guess it will work since the copying is done like this anyway:
>
> /*
>* This is the fast path and we cannot handle a pagefault
>* whilst holding the struct mutex lest the user pass in the
>* relocations contained within a mmaped bo. For in such a case
>* we, the page fault handler would call i915_gem_fault() and
>* we would try to acquire the struct mutex again. Obviously
>* this is bad and so lockdep complains vehemently.
>*/
> pagefault_disable();
> copied = __copy_from_user_inatomic(r, urelocs, count *
> sizeof(r[0]));
> pagefault_enable();
> if (unlikely(copied)) {
> remain = -EFAULT;
> goto out;
> }
>
> Comment is a bit outdated since we don't use that global "struct mutex" any
> longer, but in any case, if there is a page fault on the mapping where we
> need to recurse into i915 again to satisfy if, we seem to have code already
> to handle it. So kmap_local conversion I *think* can't regress anything.
Thanks for your explanation!
>
> Patch to convert the io_mapping_map_atomic_wc can indeed come later.
Okay, I will also look at this.
>
> In terms of logistics - if we landed this series to out branch it would be
> queued only for 6.5. Would that work for you?
Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
Thanks,
Zhao
>
> Regards,
>
> Tvrtko
Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully handle NULL state pointer
On Fri, 14 Apr 2023, Jeff Layton wrote:
> On Fri, 2023-04-14 at 04:40 +, Lin, Wayne wrote:
>> [Public]
>>
>> Hi Jeff,
>>
>> Thanks. I might need more information to understand why we can't retrieve
>> the drm atomic state. Also , "Failed to create MST payload for port"
>> indicates
>> error while configuring DPCD payload ID table. Could you help to provide log
>> with KMS + ATOMIC + DP debug on please? Thanks in advance!
>>
>> Regards,
>> Wayne
>>
>
> Possibly. I'm not that familiar with display driver debugging. Can you
> send me some directions on how to crank up that sort of debug logging?
>
> Note that this problem is _very_ intermittent too: I went about 2 weeks
> between crashes, and then I got 3 in one day. I'd rather not run with a
> lot of debug logging for a long time if that's what this is going to
> require, as this is my main workstation.
>
> The last time I got this log message, my proposed patch did prevent the
> box from oopsing, so I'd really like to see it go in unless it's just
> categorically wrong for the caller to pass down a NULL state pointer to
> drm_dp_add_payload_part2.
Cc: Lyude.
Looks like the state parameter was added in commit 4d07b0bc4034
("drm/display/dp_mst: Move all payload info into the atomic state") and
its only use is to get at state->dev for debug logging.
What's the plan for the parameter? Surely something more than that! :)
Instead of "state ? state->dev : NULL" I guess we could use mgr->dev
like the other logging calls do. It's papering over the NULL parameter
too, but perhaps in a slightly cleaner way...
BR,
Jani.
>
>> > -Original Message-
>> > From: Alex Deucher
>> > Sent: Thursday, April 13, 2023 8:59 PM
>> > To: Jani Nikula ; Lin, Wayne
>> >
>> > Cc: Jeff Layton ; David Airlie ;
>> > Daniel Vetter ; Deucher, Alexander
>> > ; linux-ker...@vger.kernel.org; dri-
>> > de...@lists.freedesktop.org
>> > Subject: Re: [PATCH] drm: make drm_dp_add_payload_part2 gracefully
>> > handle NULL state pointer
>> >
>> > + Wayne
>> >
>> > On Thu, Apr 13, 2023 at 8:31 AM Jani Nikula
>> > wrote:
>> > >
>> > > On Thu, 13 Apr 2023, Jeff Layton wrote:
>> > > > I've been experiencing some intermittent crashes down in the display
>> > > > driver code. The symptoms are ususally a line like this in dmesg:
>> > > >
>> > > > amdgpu :30:00.0: [drm] Failed to create MST payload for port
>> > > > 6d3a3885: -5
>> > > >
>> > > > ...followed by an Oops due to a NULL pointer dereference.
>> > > >
>> > > > The real bug is probably in the caller of this function, which is
>> > > > passing it a NULL state pointer, but this patch at least keeps my
>> > > > machine from oopsing when this occurs.
>> > >
>> > > My fear is that papering over this makes the root cause harder to find.
>> > >
>> > > Cc: Harry, Alex
>> > >
>> > >
>> > > BR,
>> > > Jani.
>> > >
>> > >
>> > > >
>> > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
>> > > > Signed-off-by: Jeff Layton
>> > > > ---
>> > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
>> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > > > index 38dab76ae69e..87ad406c50f9 100644
>> > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
>> > > > @@ -3404,7 +3404,8 @@ int drm_dp_add_payload_part2(struct
>> > > > drm_dp_mst_topology_mgr *mgr,
>> > > >
>> > > > /* Skip failed payloads */
>> > > > if (payload->vc_start_slot == -1) {
>> > > > - drm_dbg_kms(state->dev, "Part 1 of payload creation for
>> > > > %s
>> > failed, skipping part 2\n",
>> > > > + drm_dbg_kms(state ? state->dev : NULL,
>> > > > + "Part 1 of payload creation for %s failed,
>> > > > + skipping part 2\n",
>> > > > payload->port->connector->name);
>> > > > return -EIO;
>> > > > }
>> > >
>> > > --
>> > > Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 2/2] phy: mediatek: hdmi: mt8195: fix wrong pll calculus
Il 13/04/23 14:46, Guillaume Ranquet ha scritto:
The clock rate calculus in mtk_hdmi_pll_calc() was wrong when it has
been replaced by 'div_u64'.
Fix the issue by multiplying the values in the denominator instead of
dividing them.
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index e10da6c4147e..5e84b294a43e 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -271,7 +271,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
* [32,24] 9bit integer, [23,0]:24bit fraction
*/
pcw = div_u64(((u64)ns_hdmipll_ck) << PCW_DECIMAL_WIDTH,
- da_hdmitx21_ref_ck / PLL_FBKDIV_HS3);
+ da_hdmitx21_ref_ck * PLL_FBKDIV_HS3);
How did that even work?!?!?!? Because ... it worked, I did test it. Bah!
Luck was on your side :-P
Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
Il 13/04/23 14:46, Guillaume Ranquet ha scritto:
The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
by the kernel test robot.
Fix the issue by removing the variable altogether and testing out the
return value of mtk_hdmi_pll_set_hw()
Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
Reported-by: kernel test robot
Signed-off-by: Guillaume Ranquet
---
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
index abfc077fb0a8..e10da6c4147e 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
@@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy *hdmi_phy,
struct clk_hw *hw,
u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
u8 txpredivs[4] = { 2, 4, 6, 12 };
u32 fbkdiv_low;
- int i, ret;
+ int i;
pixel_clk = rate;
tmds_clk = pixel_clk;
@@ -292,10 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
*hdmi_phy, struct clk_hw *hw,
if (!(digital_div <= 32 && digital_div >= 1))
return -EINVAL;
- mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
+ if (mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
- txposdiv, digital_div);
- if (ret)
+ txposdiv, digital_div))
return -EINVAL;
I don't get why we're returning -EINVAL unconditionally in the first place,
here.
Function mtk_hdmi_pll_set_hw() should return zero or a negative error number: in
that case, the previous *intention* was fine, so this should be
ret = mtk_hdmi_pll_set_hw()
if (ret)
return ret;
return 0;
Regards,
Angelo
Re: [PATCH 01/27] dt-bindings: pwm: Add compatible for MediaTek MT6795
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote: > Add a compatible string for MediaTek Helio X10 MT6795's display PWM > block: this is the same as MT8173. > > Signed-off-by: AngeloGioacchino Del Regno > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 01/27] dt-bindings: pwm: Add compatible for MediaTek MT6795
On 14/04/2023 12:25, AngeloGioacchino Del Regno wrote: > Il 14/04/23 10:34, Krzysztof Kozlowski ha scritto: >> On 14/04/2023 10:30, Uwe Kleine-König wrote: >>> On Fri, Apr 14, 2023 at 10:21:05AM +0200, Krzysztof Kozlowski wrote: On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote: > Add a compatible string for MediaTek Helio X10 MT6795's display PWM > block: this is the same as MT8173. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml > b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml > index 0088bc8e7c54..153e146df7d4 100644 > --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml > +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml > @@ -22,7 +22,9 @@ properties: > - mediatek,mt8173-disp-pwm > - mediatek,mt8183-disp-pwm > - items: > - - const: mediatek,mt8167-disp-pwm > + - enum: > + - mediatek,mt6795-disp-pwm > + - mediatek,mt8167-disp-pwm This does not look correct. You do not add compatible, you replace breaking all mt8167-disp-pwm. At least it looks like this from context. >>> >>> I thought the old semantic to be: >>> >>> "mediatek,mt8167-disp-pwm" >>> >>> and the new >>> >>> "mediatek,mt6795-disp-pwm" or "mediatek,mt8167-disp-pwm" >>> >>> . What am I missing? >> >> The new is ok for mt6795 but it is not valid for mt8167. >> > > Sorry, why is it not valid for MT8167? Eh, above example did not help me, because it missed mt8173, but I see now the context I missed. It's already a list of two compatibles, so the patch is fine. Best regards, Krzysztof
Re: [PATCH 22/27] arm64: dts: mediatek: mt6795: Copyright header additions
Il 14/04/23 10:46, Krzysztof Kozlowski ha scritto: On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote: I have added more than 800 lines to this devicetree: adding myself to the copyright header. Signed-off-by: AngeloGioacchino Del Regno --- arch/arm64/boot/dts/mediatek/mt6795.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi b/arch/arm64/boot/dts/mediatek/mt6795.dtsi index 29ca9a7bf0b3..a4c950b65006 100644 --- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi @@ -2,6 +2,9 @@ /* * Copyright (c) 2015 MediaTek Inc. * Author: Mars.C + * + * Copyright (C) 2023 Collabora Ltd. + *AngeloGioacchino Del Regno Copyright is a result of significant changes, thus it is a part of commit(s) making these changes. Adding copyrights in separate commits looks like you are spreading them unjustified. Squash it. Ok, I'll squash it in one of the commits of this series. Regards, Angelo
Re: [PATCH 01/27] dt-bindings: pwm: Add compatible for MediaTek MT6795
Il 14/04/23 10:34, Krzysztof Kozlowski ha scritto: On 14/04/2023 10:30, Uwe Kleine-König wrote: On Fri, Apr 14, 2023 at 10:21:05AM +0200, Krzysztof Kozlowski wrote: On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote: Add a compatible string for MediaTek Helio X10 MT6795's display PWM block: this is the same as MT8173. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index 0088bc8e7c54..153e146df7d4 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -22,7 +22,9 @@ properties: - mediatek,mt8173-disp-pwm - mediatek,mt8183-disp-pwm - items: - - const: mediatek,mt8167-disp-pwm + - enum: + - mediatek,mt6795-disp-pwm + - mediatek,mt8167-disp-pwm This does not look correct. You do not add compatible, you replace breaking all mt8167-disp-pwm. At least it looks like this from context. I thought the old semantic to be: "mediatek,mt8167-disp-pwm" and the new "mediatek,mt6795-disp-pwm" or "mediatek,mt8167-disp-pwm" . What am I missing? The new is ok for mt6795 but it is not valid for mt8167. Sorry, why is it not valid for MT8167? This is changing the doc from: OLD: - items: - const: mediatek,mt8167-disp-pwm - const: mediatek,mt8173-disp-pwm NEW: - items: - enum: - mediatek,mt6795-disp-pwm - mediatek,mt8167-disp-pwm - const: mediatek,mt8173-disp-pwm For me, that's totally valid, as the old semantic was: compatible = "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm"; ...and the new semantic is .. the same; this commit only *adds* the possibility to get a compatible = "mediatek,mt6795-disp-pwm", "mediatek,mt8173-disp-pwm"; without breaking anything. Regards, Angelo
