Re: [PATCH v4 07/16] drm/i915/dg2: Tile 4 plane format support
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/display to
> the beginning(Imre Deak)
> - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> checks(Imre Deak)
> - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> (Imre Deak)
>
> v3: - Rebased patch on top of new changes related to plane_caps.
> - Added static assert to check that PLANE_CTL_TILING_YF
> matches PLANE_CTL_TILING_4(Nanley Chery)
> - Fixed naming and layout description for Tile 4 in drm uapi
> header(Nanley Chery)
>
P.S: Actually combined patch seems to be fine as well, according to
Nanley.
Stan
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Stanislav Lisovskiy
> Signed-off-by: Matt Roper
> Signed-off-by: Juha-Pekka Heikkilä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
> drivers/gpu/drm/i915/display/intel_fb.h | 1 +
> drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
> .../drm/i915/display/intel_plane_initial.c| 1 +
> .../drm/i915/display/skl_universal_plane.c| 23 ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> include/uapi/drm/drm_fourcc.h | 11 +
> 12 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 128d4943a43b..83253c62b6d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -,6 +,7 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state, struct int
> case I915_FORMAT_MOD_X_TILED:
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> + case I915_FORMAT_MOD_4_TILED:
> break;
> default:
> drm_dbg_kms(>drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 23cfe2e5ce2a..46505c69fe72 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -135,11 +135,16 @@ struct intel_modifier_desc {
>INTEL_PLANE_CAP_CCS_MC)
> #define INTEL_PLANE_CAP_TILING_MASK (INTEL_PLANE_CAP_TILING_X | \
>INTEL_PLANE_CAP_TILING_Y | \
> - INTEL_PLANE_CAP_TILING_Yf)
> + INTEL_PLANE_CAP_TILING_Yf | \
> + INTEL_PLANE_CAP_TILING_4)
> #define INTEL_PLANE_CAP_TILING_NONE 0
>
> static const struct intel_modifier_desc intel_modifiers[] = {
> {
> + .modifier = I915_FORMAT_MOD_4_TILED,
> + .display_ver = { 13, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4,
> + }, {
> .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> .display_ver = { 12, 13 },
> .plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
> @@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
> int color_plane)
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_4_TILED:
> + /*
> + * Each 4K tile consists of 64B(8*8) subtiles, with
> + * same shape as Y Tile(i.e 4*16B OWords)
> + */
> + return 128;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> return 128;
> @@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> fb_modifier)
> return I915_TILING_Y;
> case INTEL_PLANE_CAP_TILING_X:
> return I915_TILING_X;
> + case INTEL_PLANE_CAP_TILING_4:
> case INTEL_PLANE_CAP_TILING_Yf:
> case INTEL_PLANE_CAP_TILING_NONE:
> return I915_TILING_NONE;
> @@ -737,6 +749,7 @@ unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> case I915_FORMAT_MOD_Y_TILED:
> + case I915_FORMAT_MOD_4_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> return 1 * 1024 * 1024;
> default:
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.h
>
Re: [PATCH v4 07/16] drm/i915/dg2: Tile 4 plane format support
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/display to
> the beginning(Imre Deak)
> - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> checks(Imre Deak)
> - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> (Imre Deak)
>
> v3: - Rebased patch on top of new changes related to plane_caps.
> - Added static assert to check that PLANE_CTL_TILING_YF
> matches PLANE_CTL_TILING_4(Nanley Chery)
> - Fixed naming and layout description for Tile 4 in drm uapi
> header(Nanley Chery)
Hi Ramalingam,
This is probably wrong patch to use as I've sent a newer series,
where drm_fourcc.h changes are separately introducing new tiling
format.
I would be also resending this series today as Nanley Chery
suggested that drm_foucc changes should be introduced after
the kernel support is introduced.
Stan
>
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Signed-off-by: Stanislav Lisovskiy
> Signed-off-by: Matt Roper
> Signed-off-by: Juha-Pekka Heikkilä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
> drivers/gpu/drm/i915/display/intel_fb.h | 1 +
> drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
> .../drm/i915/display/intel_plane_initial.c| 1 +
> .../drm/i915/display/skl_universal_plane.c| 23 ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> include/uapi/drm/drm_fourcc.h | 11 +
> 12 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 128d4943a43b..83253c62b6d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -,6 +,7 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state, struct int
> case I915_FORMAT_MOD_X_TILED:
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> + case I915_FORMAT_MOD_4_TILED:
> break;
> default:
> drm_dbg_kms(>drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 23cfe2e5ce2a..46505c69fe72 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -135,11 +135,16 @@ struct intel_modifier_desc {
>INTEL_PLANE_CAP_CCS_MC)
> #define INTEL_PLANE_CAP_TILING_MASK (INTEL_PLANE_CAP_TILING_X | \
>INTEL_PLANE_CAP_TILING_Y | \
> - INTEL_PLANE_CAP_TILING_Yf)
> + INTEL_PLANE_CAP_TILING_Yf | \
> + INTEL_PLANE_CAP_TILING_4)
> #define INTEL_PLANE_CAP_TILING_NONE 0
>
> static const struct intel_modifier_desc intel_modifiers[] = {
> {
> + .modifier = I915_FORMAT_MOD_4_TILED,
> + .display_ver = { 13, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4,
> + }, {
> .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> .display_ver = { 12, 13 },
> .plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
> @@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
> int color_plane)
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_4_TILED:
> + /*
> + * Each 4K tile consists of 64B(8*8) subtiles, with
> + * same shape as Y Tile(i.e 4*16B OWords)
> + */
> + return 128;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> return 128;
> @@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> fb_modifier)
> return I915_TILING_Y;
> case INTEL_PLANE_CAP_TILING_X:
> return I915_TILING_X;
> + case INTEL_PLANE_CAP_TILING_4:
> case INTEL_PLANE_CAP_TILING_Yf:
> case INTEL_PLANE_CAP_TILING_NONE:
> return I915_TILING_NONE;
> @@ -737,6 +749,7 @@ unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> case
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Hi, > > The drivers are asic and platform specific. E.g., the driver for > > vangogh is different from renoir is different from skylake, etc. The > > display programming interfaces are asic specific. > > Cool, that makes sense! But if you (or anybody here) know some of these > GOP drivers, e.g. for the qemu/qxl device, OvmfPkg/QemuVideoDxe in tianocore source tree. > I'm just curious to see/understand how complex is the FW driver to > just put the device/screen in a usable state. Note that qemu has a paravirtual interface for vesa vga mode programming where you basically program a handful of registers with xres, yres, depth etc. (after resetting the device to put it into vga compatibility mode) and you are done. Initializing physical hardware is an order of magnitude harder than that. With qxl you could also go figure the current state of the hardware and fill screen_info with that to get a working boot framebuffer in the kexec'ed kernel. Problem with this approach is this works only in case the framebuffer happens to be in a format usable by vesafb/efifb. So no modifiers (tiling etc.) and continuous in physical address space. That is true for qxl. With virtio-gpu it wouldn't work though (framebuffer can be scattered), and I expect with most modern physical hardware it wouldn't work either. take care, Gerd
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Am 09.12.21 um 19:28 schrieb Felix Kuehling: Am 2021-12-09 um 10:30 a.m. schrieb Christian König: That still won't work. But I think we could do this change for the amdgpu mmap callback only. If graphics user mode has problems with it, we could even make this specific to KFD BOs in the amdgpu_gem_object_mmap callback. I think it's fine for the whole amdgpu stack, my concern is more about radeon, nouveau and the ARM stacks which are using this as well. That blew up so nicely the last time we tried to change it and I know of at least one case where radeon was/is used with BOs in a child process. Regards, Christian. Regards, Felix Regards, Christian. Am 09.12.21 um 16:29 schrieb Bhardwaj, Rajneesh: Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank you! On 12/9/2021 10:27 AM, Christian König wrote: Hi Rajneesh, yes, separating this from the drm_gem_mmap_obj() change is certainly a good idea. The child cannot access the BOs mapped by the parent anyway with access restrictions applied exactly that is not correct. That behavior is actively used by some userspace stacks as far as I know. Regards, Christian. Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh: Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on the gem objects, it might be reasonable to also create the VMAs with VM_DONTCOPY flag so a user space application doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK) system call to prevent the pages in the mapped range to appear in the address space of the child process. It also prevents the memory leaks due to additional reference counts on the mapped BOs in the child process that prevented freeing the memory in the parent for which we had worked around earlier in the user space inside the thunk library. Additionally, we faced this issue when using CRIU to checkpoint restore an application that had such inherited mappings in the child which confuse CRIU when it mmaps on restore. Having this flag set for the render node VMAs helps. VMAs mapped via KFD already take care of this so this is needed only for the render nodes. Unfortunately that is most likely a NAK. We already tried something similar. While it is illegal by the OpenGL specification and doesn't work for most userspace stacks, we do have some implementations which call fork() with a GL context open and expect it to work. Regards, Christian. Cc: Felix Kuehling Signed-off-by: David Yat Sin Signed-off-by: Rajneesh Bhardwaj --- drivers/gpu/drm/drm_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 09c820045859..d9c4149f36dd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, goto err_drm_gem_object_put; } - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND + | VM_DONTDUMP | VM_DONTCOPY; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 33680c94127c..420a4898fdd2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) vma->vm_private_data = bo; - vma->vm_flags |= VM_PFNMAP; + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; return 0; }
[PATCH 4/4] drm/i915/guc: Don't go bang in GuC log if no GuC
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
index da7dd099fd93..140896bb988b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
@@ -79,7 +79,7 @@ static int guc_log_level_get(void *data, u64 *val)
{
struct intel_guc_log *log = data;
- if (!intel_guc_is_used(log_to_guc(log)))
+ if (!log->vma)
return -ENODEV;
*val = intel_guc_log_get_level(log);
@@ -91,7 +91,7 @@ static int guc_log_level_set(void *data, u64 val)
{
struct intel_guc_log *log = data;
- if (!intel_guc_is_used(log_to_guc(log)))
+ if (!log->vma)
return -ENODEV;
return intel_guc_log_set_level(log, val);
--
2.25.1
[PATCH 0/4] Assorted fixes/tweaks to GuC support
From: John Harrison Fix a potential null pointer dereference, improve debug crash reports, improve code separation, improve GuC log read speed. Signed-off-by: John Harrison John Harrison (4): drm/i915/uc: Allow platforms to have GuC but not HuC drm/i915/guc: Speed up GuC log dumps drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM drm/i915/guc: Don't go bang in GuC log if no GuC drivers/gpu/drm/i915/gt/intel_gt_debugfs.h| 21 - drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 5 +- .../drm/i915/gt/uc/intel_guc_log_debugfs.c| 58 +++- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 93 +-- 4 files changed, 136 insertions(+), 41 deletions(-) -- 2.25.1
[PATCH 3/4] drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM
From: John Harrison Lots of testing is done with the DEBUG_GEM config option enabled but not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs which are not hugely useful. Enabling full DEBUG_GUC also spews lots of other detailed output that is not generally desired. However, bigger GuC logs are extremely useful for almost any regression debug. So enable bigger logs for DEBUG_GEM builds as well. Signed-off-by: John Harrison Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h index ac1ee1d5ce10..fe6ab7550a14 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h @@ -15,9 +15,12 @@ struct intel_guc; -#ifdef CONFIG_DRM_I915_DEBUG_GUC +#if defined(CONFIG_DRM_I915_DEBUG_GUC) #define CRASH_BUFFER_SIZE SZ_2M #define DEBUG_BUFFER_SIZE SZ_16M +#elif defined(CONFIG_DRM_I915_DEBUG_GEM) +#define CRASH_BUFFER_SIZE SZ_1M +#define DEBUG_BUFFER_SIZE SZ_2M #else #define CRASH_BUFFER_SIZE SZ_8K #define DEBUG_BUFFER_SIZE SZ_64K -- 2.25.1
[PATCH 2/4] drm/i915/guc: Speed up GuC log dumps
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times - 16
times with the full 18MB log size.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt_debugfs.h| 21 ++--
.../drm/i915/gt/uc/intel_guc_log_debugfs.c| 54 +--
2 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
index e307ceb99031..1adea367d99b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
@@ -10,11 +10,7 @@
struct intel_gt;
-#define DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(__name)
\
- static int __name ## _open(struct inode *inode, struct file *file) \
-{ \
- return single_open(file, __name ## _show, inode->i_private);\
-} \
+#define __GT_DEBUGFS_ATTRIBUTE_FOPS(__name)\
static const struct file_operations __name ## _fops = {
\
.owner = THIS_MODULE, \
.open = __name ## _open,\
@@ -23,6 +19,21 @@ static const struct file_operations __name ## _fops = {
\
.release = single_release, \
}
+#define DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(__name) \
+static int __name ## _open(struct inode *inode, struct file *file) \
+{ \
+ return single_open(file, __name ## _show, inode->i_private);\
+} \
+__GT_DEBUGFS_ATTRIBUTE_FOPS(__name)
+
+#define DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE_WITH_SIZE(__name, __size_vf) \
+static int __name ## _open(struct inode *inode, struct file *file) \
+{ \
+return single_open_size(file, __name ## _show, inode->i_private, \
+ __size_vf(inode->i_private)); \
+} \
+__GT_DEBUGFS_ATTRIBUTE_FOPS(__name)
+
void intel_gt_debugfs_register(struct intel_gt *gt);
struct intel_gt_debugfs_file {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
index 46026c2c1722..da7dd099fd93 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
@@ -10,14 +10,62 @@
#include "intel_guc.h"
#include "intel_guc_log.h"
#include "intel_guc_log_debugfs.h"
+#include "intel_uc.h"
+
+static u32 obj_to_guc_log_dump_size(struct drm_i915_gem_object *obj)
+{
+ u32 size;
+
+ if (!obj)
+ return -ENODEV;
+
+ /* "0x%08x 0x%08x 0x%08x 0x%08x\n" => 16 bytes -> 44 chars => x2.75 */
+ size = ((obj->base.size * 11) + 3) / 4;
+
+ /* Add padding for final blank line, any extra header info, etc. */
+ size = PAGE_ALIGN(size + PAGE_SIZE);
+
+ return size;
+}
+
+static u32 guc_log_dump_size(struct intel_guc_log *log)
+{
+ struct intel_guc *guc = log_to_guc(log);
+
+ if (!intel_guc_is_supported(guc))
+ return -ENODEV;
+
+ if (!log->vma)
+ return -ENODEV;
+
+ return obj_to_guc_log_dump_size(log->vma->obj);
+}
static int guc_log_dump_show(struct seq_file *m, void *data)
{
struct drm_printer p = drm_seq_file_printer(m);
+ int ret;
+
+ ret = intel_guc_log_dump(m->private, , false);
+
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) && seq_has_overflowed(m))
+ pr_warn_once("preallocated size:%zx for %s exceeded\n",
+m->size, __func__);
+
+ return ret;
+}
+DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE_WITH_SIZE(guc_log_dump, guc_log_dump_size);
+
+static u32 guc_load_err_dump_size(struct intel_guc_log *log)
+{
+ struct intel_guc *guc = log_to_guc(log);
+ struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
+
+ if (!intel_guc_is_supported(guc))
+ return -ENODEV;
- return intel_guc_log_dump(m->private, , false);
+ return obj_to_guc_log_dump_size(uc->load_err_log);
}
-DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(guc_log_dump);
static int guc_load_err_log_dump_show(struct seq_file *m, void *data)
{
@@ -25,7 +73,7 @@ static int guc_load_err_log_dump_show(struct seq_file *m,
void *data)
return intel_guc_log_dump(m->private, , true);
}
[PATCH 1/4] drm/i915/uc: Allow platforms to have GuC but not HuC
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 93
1 file changed, 63 insertions(+), 30 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 3aa87be4f2e4..a7788ce50736 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,22 +48,39 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
* Note that RKL and ADL-S have the same GuC/HuC device ID's and use the same
* firmware as TGL.
*/
-#define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
- fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3), huc_def(tgl, 7, 9, 3)) \
- fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \
- fw_def(DG1, 0, guc_def(dg1, 62, 0, 0), huc_def(dg1, 7, 9, 3)) \
- fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \
- fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 9, 3)) \
- fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
- fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
- fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \
- fw_def(COMETLAKE, 5, guc_def(cml, 62, 0, 0), huc_def(cml, 4, 0, 0)) \
- fw_def(COMETLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
- fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
- fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0), huc_def(glk, 4, 0, 0)) \
- fw_def(KABYLAKE,0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
- fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt, 2, 0, 0)) \
- fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl, 2, 0, 0))
+#define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
+ fw_def(ALDERLAKE_P, 0, guc_def(adlp, 62, 0, 3)) \
+ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0)) \
+ fw_def(DG1, 0, guc_def(dg1, 62, 0, 0)) \
+ fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0)) \
+ fw_def(TIGERLAKE,0, guc_def(tgl, 62, 0, 0)) \
+ fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0)) \
+ fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0)) \
+ fw_def(COMETLAKE,5, guc_def(cml, 62, 0, 0)) \
+ fw_def(COMETLAKE,0, guc_def(kbl, 62, 0, 0)) \
+ fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0)) \
+ fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0)) \
+ fw_def(KABYLAKE, 0, guc_def(kbl, 62, 0, 0)) \
+ fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0)) \
+ fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0))
+
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
+ fw_def(ALDERLAKE_P, 0, huc_def(tgl, 7, 9, 3)) \
+ fw_def(ALDERLAKE_S, 0, huc_def(tgl, 7, 9, 3)) \
+ fw_def(DG1, 0, huc_def(dg1, 7, 9, 3)) \
+ fw_def(ROCKETLAKE, 0, huc_def(tgl, 7, 9, 3)) \
+ fw_def(TIGERLAKE,0, huc_def(tgl, 7, 9, 3)) \
+ fw_def(JASPERLAKE, 0, huc_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, huc_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, huc_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE,5, huc_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE,0, huc_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, huc_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, huc_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, huc_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, huc_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, huc_def(skl, 2, 0, 0))
#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
@@ -79,11 +96,11 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
__MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_)
/* All blobs need to be declared via MODULE_FIRMWARE() */
-#define INTEL_UC_MODULE_FW(platform_, revid_, guc_, huc_) \
- MODULE_FIRMWARE(guc_); \
- MODULE_FIRMWARE(huc_);
+#define INTEL_UC_MODULE_FW(platform_, revid_, uc_) \
+ MODULE_FIRMWARE(uc_);
-INTEL_UC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH, MAKE_HUC_FW_PATH)
+INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
+INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH)
/* The below structs and macros are used to iterate across the list of blobs */
struct __packed uc_fw_blob {
@@ -106,31 +123,47 @@ struct __packed uc_fw_blob {
struct __packed uc_fw_platform_requirement {
enum intel_platform p;
u8 rev; /* first platform rev using
[git pull] drm fixes for 5.16-rc5
Hi Linus, Regular fixes, pretty small overall, couple of core fixes, two i915 and two amdgpu, hopefully it stays this quiet. Regards, Dave. drm-fixes-2021-12-10: drm fixes for 5.16-rc5 ttm: - fix ttm_bo_swapout syncobj: - fix fence find bug with signalled fences i915: - fix error pointer deref in gem execbuffer - fix for GT init with GuC/HuC on ICL amdgpu: - DPIA fix - eDP fix The following changes since commit 0fcfb00b28c0b7884635dacf38e46d60bf3d4eb1: Linux 5.16-rc4 (2021-12-05 14:08:22 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-10 for you to fetch changes up to 675a095789a2663fe02fdebd6023e29d7f1f51ac: Merge tag 'amd-drm-fixes-5.16-2021-12-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-12-10 14:10:55 +1000) drm fixes for 5.16-rc5 ttm: - fix ttm_bo_swapout syncobj: - fix fence find bug with signalled fences i915: - fix error pointer deref in gem execbuffer - fix for GT init with GuC/HuC on ICL amdgpu: - DPIA fix - eDP fix Bas Nieuwenhuizen (1): drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence. Christian König (1): drm/ttm: fix ttm_bo_swapout Dan Carpenter (1): drm/i915: Fix error pointer dereference in i915_gem_do_execbuffer() Dave Airlie (3): Merge tag 'drm-misc-fixes-2021-12-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2021-12-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.16-2021-12-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Mikita Lipski (1): drm/amd/display: prevent reading unitialized links Nicholas Kazlauskas (1): drm/amd/display: Fix DPIA outbox timeout after S3/S4/reset Raviteja Goud Talla (1): drm/i915/gen11: Moving WAs to icl_gt_workarounds_init() drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++- drivers/gpu/drm/amd/display/dc/dc_link.h | 2 ++ drivers/gpu/drm/drm_syncobj.c | 11 ++- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 +- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 6 files changed, 30 insertions(+), 12 deletions(-)
Re: [PATCH v6 10/11] drm/i915: Use to_gt() helper for GGTT accesses
Hi Matt, > > GGTT is currently available both through i915->ggtt and gt->ggtt, and we > > eventually want to get rid of the i915->ggtt one. > > Use to_gt() for all i915->ggtt accesses to help with the future > > refactoring. > > I think we can also convert the two references in i915_drm_suspend() and > i915_drm_resume(), right? With those converted, I think the only > remaining use of i915->ggtt will be the call to intel_gt_init_hw_early() > during startup that assigns the gt->ggtt pointer. Maybe we should just > make that function assign a drmm_kzalloc() and drop the i915->ggtt > completely? I think calling directly drmm_kzalloc() and get rid of i915->ggtt is a good idea. Thanks, Andi
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
On Friday, 10 December 2021 3:54:31 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/9/2021 10:29 AM, Felix Kuehling wrote:
> > Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> >> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro
> >> (Alex) wrote:
> >>> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
> Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
> > Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> >> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
> >>> Avoid long term pinning for Coherent device type pages. This could
> >>> interfere with their own device memory manager.
> >>> If caller tries to get user device coherent pages with PIN_LONGTERM
> >>> flag
> >>> set, those pages will be migrated back to system memory.
> >>>
> >>> Signed-off-by: Alex Sierra
> >>> ---
> >>>mm/gup.c | 32 ++--
> >>>1 file changed, 30 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/mm/gup.c b/mm/gup.c
> >>> index 886d6148d3d0..1572eacf07f4 100644
> >>> --- a/mm/gup.c
> >>> +++ b/mm/gup.c
> >>> @@ -1689,17 +1689,37 @@ struct page *get_dump_page(unsigned long addr)
> >>>#endif /* CONFIG_ELF_CORE */
> >>>
> >>>#ifdef CONFIG_MIGRATION
> >>> +static int migrate_device_page(unsigned long address,
> >>> + struct page *page)
> >>> +{
> >>> + struct vm_area_struct *vma = find_vma(current->mm, address);
> >>> + struct vm_fault vmf = {
> >>> + .vma = vma,
> >>> + .address = address & PAGE_MASK,
> >>> + .flags = FAULT_FLAG_USER,
> >>> + .pgoff = linear_page_index(vma, address),
> >>> + .gfp_mask = GFP_KERNEL,
> >>> + .page = page,
> >>> + };
> >>> + if (page->pgmap && page->pgmap->ops->migrate_to_ram)
> >>> + return page->pgmap->ops->migrate_to_ram();
> >> How does this synchronise against pgmap being released? As I
> >> understand things
> >> at this point we're not holding a reference on either the page or
> >> pgmap, so
> >> the page and therefore the pgmap may have been freed.
> >>
> >> I think a similar problem exists for device private fault handling as
> >> well and
> >> it has been on my list of things to fix for a while. I think the
> >> solution is to
> >> call try_get_page(), except it doesn't work with device pages due to
> >> the whole
> >> refcount thing. That issue is blocking a fair bit of work now so I've
> >> started
> >> looking into it.
> > At least the page should have been pinned by the __get_user_pages_locked
> > call in __gup_longterm_locked. That refcount is dropped in
> > check_and_migrate_movable_pages when it returns 0 or an error.
> Never mind. We unpin the pages first. Alex, would the migration work if
> we unpinned them afterwards? Also, the normal CPU page fault code path
> seems to make sure the page is locked (check in pfn_swap_entry_to_page)
> before calling migrate_to_ram.
> >> I don't think that's true. The check in pfn_swap_entry_to_page() is only
> >> for
> >> migration entries:
> >>
> >>BUG_ON(is_migration_entry(entry) && !PageLocked(p));
> >>
> >> As this is coherent memory though why do we have to call into a device
> >> driver
> >> to do the migration? Couldn't this all be done in the kernel?
> > I think you're right. I hadn't thought of that mainly because I'm even
> > less familiar with the non-device migration code. Alex, can you give
> > that a try? As long as the driver still gets a page-free callback when
> > the device page is freed, it should work.
Yes, you should still get the page-free callback when the migration code drops
the last page reference.
> ACK.Will do
There is currently not really any support for migrating device pages based on
pfn. What I think is needed is something like migrate_pages(), but that API
won't work for a couple of reasons - main one being that it relies on pages
being LRU pages.
I've been working on a series to implement an equivalent of migrate_pages() for
device-private (and by extension device-coherent) pages. It might also be useful
here so I will try and get it posted as an RFC next week.
- Alistair
> Alex Sierra
>
> > Regards,
> >Felix
> >
> >
> >>> No, you can not unpinned after migration. Due to the expected_count VS
> >>> page_count condition at migrate_page_move_mapping, during migrate_page
> >>> call.
> >>>
> >>> Regards,
> >>> Alex Sierra
> >>>
> Regards,
> Felix
>
>
> >>
[PATCH v7 08/11] drm/i915/pxp: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti
---
Hi,
the inline of i915_dev_to_pxp() was accidentally removed in v6.
Thanks Matt.
Andi
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 5d169624ad60..195b2323ec00 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -16,7 +16,9 @@
static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
{
- return _to_i915(i915_kdev)->gt.pxp;
+ struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
+
+ return _gt(i915)->pxp;
}
static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
--
2.34.1
Re: [PATCH v6 08/11] drm/i915/pxp: Use to_gt() helper
On Fri, Dec 10, 2021 at 02:21:53AM +0200, Andi Shyti wrote: > Hi Matt, > > > > -static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev) > > > +static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev) > > > > Was dropping the inline here intentional? It doesn't seem like there's > > any reason to drop it, and if it was intentional the whitespace isn't > > quite right. > > No, it wasn't intentional and it's strange that checkpatch > didn't catch it. I will resend this one. With the 'inline' re-added, you can include Reviewed-by: Matt Roper > > Thanks! > Andi -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795
Re: [PATCH v6 08/11] drm/i915/pxp: Use to_gt() helper
Hi Matt, > > -static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev) > > +static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev) > > Was dropping the inline here intentional? It doesn't seem like there's > any reason to drop it, and if it was intentional the whitespace isn't > quite right. No, it wasn't intentional and it's strange that checkpatch didn't catch it. I will resend this one. Thanks! Andi
Re: [PATCH v6 11/11] drm/i915: Rename i915->gt to i915->gt0
On Thu, Dec 09, 2021 at 03:25:12PM +0200, Andi Shyti wrote:
> In preparation of the multitile support, highlight the root GT by
> calling it gt0 inside the drm i915 private data.
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Lucas De Marchi
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
If you decide to not drop i915->ggtt completely in the previous patch,
we might want to make a simimlar naming change to that field as well.
Matt
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 96e3553838ef..a4084f209097 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1008,7 +1008,7 @@ struct drm_i915_private {
> struct i915_perf perf;
>
> /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> - struct intel_gt gt;
> + struct intel_gt gt0;
>
> struct {
> struct i915_gem_contexts {
> @@ -1082,7 +1082,7 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
>
> static inline struct intel_gt *to_gt(struct drm_i915_private *i915)
> {
> - return >gt;
> + return >gt0;
> }
>
> /* Simple iterator over all initialised engines */
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Freedreno] [PATCH v1 8/8] drm/msm/dpu: move SSPP debugfs support from plane to SSPP code
On 10/12/2021 01:27, Abhinav Kumar wrote:
On 12/9/2021 2:18 PM, Abhinav Kumar wrote:
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 67 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 82 +++--
4 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index d77eb7da5daf..ae3cf2e4d7d9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -8,6 +8,8 @@
#include "dpu_hw_sspp.h"
#include "dpu_kms.h"
+#include
+
#define DPU_FETCH_CONFIG_RESET_VALUE 0x0087
/* DPU_SSPP_SRC */
@@ -686,6 +688,71 @@ static void _setup_layer_ops(struct dpu_hw_pipe *c,
c->ops.setup_cdp = dpu_hw_sspp_setup_cdp;
}
+#ifdef CONFIG_DEBUG_FS
+int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct
dpu_kms *kms, struct dentry *entry)
+{
+ const struct dpu_sspp_cfg *cfg = hw_pipe->cap;
+ const struct dpu_sspp_sub_blks *sblk = cfg->sblk;
+ struct dentry *debugfs_root;
+ char sspp_name[32];
+
+ snprintf(sspp_name, sizeof(sspp_name), "%d", hw_pipe->idx);
+
+ /* create overall sub-directory for the pipe */
+ debugfs_root =
+ debugfs_create_dir(sspp_name, entry);
I would like to take a different approach to this. Let me know what
you think.
Let the directory names still be the drm plane names as someone who
would first get the DRM state and then try to lookup the register
values of that plane would not know where to look now.
Inside the /sys/kernel/debug/***/plane-X/ directory you can expose an
extra entry which tells the sspp_index.
This will also establish the plane to SSPP mapping.
Now when planes go virtual in the future, this will be helpful even more
so that we can know the plane to SSPP mapping.
OR i like rob's suggestion of implementing the atomic_print_state
callback which will printout the drm plane to SSPP mapping along with
this change so that when we look at DRM state, we also know the plane
to SSPP mapping and look in the right SSPP's dir.
I'd add atomic_print_state(), it seems simpler (and more future-proof).
+
+ /* don't error check these */
+ debugfs_create_xul("features", 0600,
+ debugfs_root, (unsigned long *)_pipe->cap->features);
+
+ /* add register dump support */
+ dpu_debugfs_create_regset32("src_blk", 0400,
+ debugfs_root,
+ sblk->src_blk.base + cfg->base,
+ sblk->src_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED3LITE) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED2) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED4))
+ dpu_debugfs_create_regset32("scaler_blk", 0400,
+ debugfs_root,
+ sblk->scaler_blk.base + cfg->base,
+ sblk->scaler_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_CSC) ||
+ cfg->features & BIT(DPU_SSPP_CSC_10BIT))
+ dpu_debugfs_create_regset32("csc_blk", 0400,
+ debugfs_root,
+ sblk->csc_blk.base + cfg->base,
+ sblk->csc_blk.len,
+ kms);
+
+ debugfs_create_u32("xin_id",
+ 0400,
+ debugfs_root,
+ (u32 *) >xin_id);
+ debugfs_create_u32("clk_ctrl",
+ 0400,
+ debugfs_root,
+ (u32 *) >clk_ctrl);
+ debugfs_create_x32("creq_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >creq_vblank);
+ debugfs_create_x32("danger_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >danger_vblank);
+
+ return 0;
+}
+#endif
+
+
static const struct dpu_sspp_cfg *_sspp_offset(enum dpu_sspp sspp,
void __iomem *addr,
struct dpu_mdss_cfg *catalog,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index e8939d7387cb..cef281687bab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -381,6 +381,7 @@ struct dpu_hw_pipe {
struct dpu_hw_sspp_ops ops;
};
+struct dpu_kms;
/**
* dpu_hw_sspp_init - initializes the sspp hw driver object.
* Should be called once before accessing every pipe.
@@ -400,5 +401,8 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum
dpu_sspp idx,
*/
void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
+void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry
*debugfs_root);
+int _dpu_hw_sspp_init_debugfs(struct
Re: [PATCH v6 10/11] drm/i915: Use to_gt() helper for GGTT accesses
On Thu, Dec 09, 2021 at 03:25:11PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
I think we can also convert the two references in i915_drm_suspend() and
i915_drm_resume(), right? With those converted, I think the only
remaining use of i915->ggtt will be the call to intel_gt_init_hw_early()
during startup that assigns the gt->ggtt pointer. Maybe we should just
make that function assign a drmm_kzalloc() and drop the i915->ggtt
completely?
Matt
>
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> .../gpu/drm/i915/display/intel_plane_initial.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 16
> drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c| 2 +-
> .../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 16
> .../gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +++---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> drivers/gpu/drm/i915/i915_driver.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 16
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/i915_getparam.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> drivers/gpu/drm/i915/selftests/i915_gem.c| 8
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 6 +++---
> drivers/gpu/drm/i915/selftests/i915_request.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_vma.c| 2 +-
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
> drivers/gpu/drm/i915/selftests/mock_gtt.c| 2 +-
> 28 files changed, 70 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8be01b93015f..98319c0322d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -595,7 +595,7 @@ static void ivb_fbc_activate(struct intel_fbc *fbc)
> else if (DISPLAY_VER(i915) == 9)
> skl_fbc_program_cfb_stride(fbc);
>
> - if (i915->ggtt.num_fences)
> + if (to_gt(i915)->ggtt->num_fences)
> snb_fbc_program_fence(fbc);
>
> intel_de_write(i915, ILK_DPFC_CONTROL,
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 01ce1d72297f..e4186a0b8edb 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -94,7 +94,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> goto err_obj;
> }
>
> - vma = i915_vma_instance(obj, >ggtt.vm, NULL);
> + vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL);
> if (IS_ERR(vma))
> goto err_obj;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index babfecb17ad1..e5b0f66ea1fe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -174,7 +174,7 @@ i915_gem_context_get_eb_vm(struct i915_gem_context *ctx)
>
> vm = ctx->vm;
> if (!vm)
> - vm = >i915->ggtt.vm;
> + vm = _gt(ctx->i915)->ggtt->vm;
> vm = i915_vm_get(vm);
>
> return vm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index ec7c4a29a720..3078611d5bfe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1106,7 +1106,7 @@ static inline struct i915_ggtt *cache_to_ggtt(struct
> reloc_cache *cache)
> {
> struct drm_i915_private *i915 =
> container_of(cache, struct i915_execbuffer, reloc_cache)->i915;
> - return >ggtt;
> + return to_gt(i915)->ggtt;
> }
>
> static void reloc_cache_reset(struct reloc_cache *cache, struct
> i915_execbuffer *eb)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>
Re: [PATCH v6 09/11] drm/i915: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:10PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 38 +++
> drivers/gpu/drm/i915/i915_debugfs_params.c | 4 +-
> drivers/gpu/drm/i915/i915_driver.c | 32 ++---
> drivers/gpu/drm/i915/i915_drv.h| 2 +-
> drivers/gpu/drm/i915/i915_gem.c| 16 +++
> drivers/gpu/drm/i915/i915_getparam.c | 10 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
> drivers/gpu/drm/i915/i915_irq.c| 56 +++---
> drivers/gpu/drm/i915/i915_perf.c | 2 +-
> drivers/gpu/drm/i915/i915_pmu.c| 14 +++---
> drivers/gpu/drm/i915/i915_query.c | 2 +-
> drivers/gpu/drm/i915/i915_sysfs.c | 22 -
> drivers/gpu/drm/i915/intel_gvt.c | 2 +-
> drivers/gpu/drm/i915/intel_wopcm.c | 2 +-
> 14 files changed, 103 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bafb902269de..93c3d154885b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -65,7 +65,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
> intel_device_info_print_static(INTEL_INFO(i915), );
> intel_device_info_print_runtime(RUNTIME_INFO(i915), );
> i915_print_iommu_status(i915, );
> - intel_gt_info_print(>gt.info, );
> + intel_gt_info_print(_gt(i915)->info, );
> intel_driver_caps_print(>caps, );
>
> kernel_param_lock(THIS_MODULE);
> @@ -293,7 +293,7 @@ static int i915_gpu_info_open(struct inode *inode, struct
> file *file)
>
> gpu = NULL;
> with_intel_runtime_pm(>runtime_pm, wakeref)
> - gpu = i915_gpu_coredump(>gt, ALL_ENGINES);
> + gpu = i915_gpu_coredump(to_gt(i915), ALL_ENGINES);
> if (IS_ERR(gpu))
> return PTR_ERR(gpu);
>
> @@ -351,7 +351,7 @@ static const struct file_operations i915_error_state_fops
> = {
> static int i915_frequency_info(struct seq_file *m, void *unused)
> {
> struct drm_i915_private *i915 = node_to_i915(m->private);
> - struct intel_gt *gt = >gt;
> + struct intel_gt *gt = to_gt(i915);
> struct drm_printer p = drm_seq_file_printer(m);
>
> intel_gt_pm_frequency_dump(gt, );
> @@ -439,11 +439,11 @@ static int i915_swizzle_info(struct seq_file *m, void
> *data)
> static int i915_rps_boost_info(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct intel_rps *rps = _priv->gt.rps;
> + struct intel_rps *rps = _gt(dev_priv)->rps;
>
> seq_printf(m, "RPS enabled? %s\n", yesno(intel_rps_is_enabled(rps)));
> seq_printf(m, "RPS active? %s\n", yesno(intel_rps_is_active(rps)));
> - seq_printf(m, "GPU busy? %s\n", yesno(dev_priv->gt.awake));
> + seq_printf(m, "GPU busy? %s\n", yesno(to_gt(dev_priv)->awake));
> seq_printf(m, "Boosts outstanding? %d\n",
> atomic_read(>num_waiters));
> seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->power.interactive));
> @@ -476,7 +476,7 @@ static int i915_runtime_pm_status(struct seq_file *m,
> void *unused)
> seq_printf(m, "Runtime power status: %s\n",
> enableddisabled(!dev_priv->power_domains.init_wakeref));
>
> - seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
> + seq_printf(m, "GPU idle: %s\n", yesno(!to_gt(dev_priv)->awake));
> seq_printf(m, "IRQs disabled: %s\n",
> yesno(!intel_irqs_enabled(dev_priv)));
> #ifdef CONFIG_PM
> @@ -508,18 +508,18 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
> wakeref = intel_runtime_pm_get(>runtime_pm);
>
> seq_printf(m, "GT awake? %s [%d], %llums\n",
> -yesno(i915->gt.awake),
> -atomic_read(>gt.wakeref.count),
> -ktime_to_ms(intel_gt_get_awake_time(>gt)));
> +yesno(to_gt(i915)->awake),
> +atomic_read(_gt(i915)->wakeref.count),
> +ktime_to_ms(intel_gt_get_awake_time(to_gt(i915;
> seq_printf(m, "CS timestamp frequency: %u Hz, %d ns\n",
> -i915->gt.clock_frequency,
> -i915->gt.clock_period_ns);
> +to_gt(i915)->clock_frequency,
> +to_gt(i915)->clock_period_ns);
>
> p = drm_seq_file_printer(m);
> for_each_uabi_engine(engine, i915)
> intel_engine_dump(engine, , "%s\n", engine->name);
>
> - intel_gt_show_timelines(>gt, , i915_request_show_with_schedule);
> + intel_gt_show_timelines(to_gt(i915), ,
> i915_request_show_with_schedule);
>
>
Re: [PATCH v6 08/11] drm/i915/pxp: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:09PM +0200, Andi Shyti wrote:
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index 5d169624ad60..726c2b5a3fa3 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -14,9 +14,11 @@
> #include "intel_pxp_tee.h"
> #include "intel_pxp_tee_interface.h"
>
> -static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> +static struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
Was dropping the inline here intentional? It doesn't seem like there's
any reason to drop it, and if it was intentional the whitespace isn't
quite right.
Matt
> {
> - return _to_i915(i915_kdev)->gt.pxp;
> + struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
> +
> + return _gt(i915)->pxp;
> }
>
> static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [PATCH v12, 15/19] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192
Reviewed-by: Steve Cho On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote: > > Adds decoder dt-bindings for mt8192. basic question: what is dt-bindings? Is this yaml file supposed to be used for some settings? > > Signed-off-by: Yunfei Dong > --- > .../media/mediatek,vcodec-subdev-decoder.yaml | 266 ++ > 1 file changed, 266 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > > diff --git > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > new file mode 100644 > index ..67cbcf8b3373 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > @@ -0,0 +1,266 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > + > +%YAML 1.2 > +--- > +$id: > "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > + > +title: Mediatek Video Decode Accelerator With Multi Hardware Is Multi Hardware supposed to mean parent & child devices in this context? > + > +maintainers: > + - Yunfei Dong > + > +description: | > + Mediatek Video Decode is the video decode hardware present in Mediatek > + SoCs which supports high resolution decoding functionalities. Required > + parent and child device node. > + > + About the Decoder Hardware Block Diagram, please check below: Great to see this diagram and description! > + > ++-++ > +| || > +| input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | > +||| | || | > ++||---+-||-+ > + lat workqueue | core workqueue > > + > -||-||-- > + || || > > + \/\/ > + +--+ > + |enable/disable| > + | clk powerirqiommu | > + | (lat/lat soc/core0/core1)| > + +--+ > + > + As above, there are parent and child devices, child mean each hardware. > The child device > + controls the information of each hardware independent which include > clk/power/irq. > + > + There are two workqueues in parent device: lat workqueue and core > workqueue. They are used > + to lat and core hardware deocder. Lat workqueue need to get input > bitstream and lat buffer, > + then enable lat to decode, writing the result to lat buffer, dislabe > hardware when lat decode > + done. Core workqueue need to get lat buffer and output buffer, then enable > core to decode, > + writing the result to output buffer, disable hardware when core decode > done. These two > + hardwares will decode each frame cyclically. > + > + For the smi common may not the same for each hardware, can't combine all > hardware in one node, > + or leading to iommu fault when access dram data. > + > +properties: > + compatible: > +const: mediatek,mt8192-vcodec-dec > + > + reg: > +maxItems: 1 > + > + iommus: > +minItems: 1 > +maxItems: 32 > +description: | > + List of the hardware port in respective IOMMU block for current Socs. > + Refer to bindings/iommu/mediatek,iommu.yaml. > + > + mediatek,scp: > +$ref: /schemas/types.yaml#/definitions/phandle > +maxItems: 1 > +description: | > + The node of system control processor (SCP), using > + the remoteproc & rpmsg framework. > + $ref: /schemas/remoteproc/mtk,scp.yaml > + > + dma-ranges: > +maxItems: 1 > +description: | > + Describes the physical address space of IOMMU maps to memory. > + > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 1 > + > + ranges: true > + > +# Required child node: > +patternProperties: > + vcodec-lat: > +type: object > + > +properties: > + compatible: > +const: mediatek,mtk-vcodec-lat > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + iommus: > +minItems: 1 > +maxItems: 32 > +description: | > + List of the hardware port in respective IOMMU block for current > Socs. > + Refer to bindings/iommu/mediatek,iommu.yaml. > + > + clocks: > +maxItems: 5 > + > + clock-names: > +items: > + - const: sel > + -
Re: [PATCH v6 07/11] drm/i915/selftests: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:08PM +0200, Andi Shyti wrote:
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Andi Shyti
> Cc: Michał Winiarski
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +-
> .../gpu/drm/i915/selftests/i915_gem_evict.c | 6 ++--
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +--
> drivers/gpu/drm/i915/selftests/i915_perf.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_request.c | 10 +++
> .../gpu/drm/i915/selftests/i915_selftest.c| 4 +--
> .../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
> .../gpu/drm/i915/selftests/igt_live_test.c| 4 +--
> .../drm/i915/selftests/intel_memory_region.c | 4 +--
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 30 +--
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 6 ++--
> drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
> 14 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
> b/drivers/gpu/drm/i915/selftests/i915_active.c
> index 61bf4560d8af..2dac9be1de58 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> @@ -254,7 +254,7 @@ int i915_active_live_selftests(struct drm_i915_private
> *i915)
> SUBTEST(live_active_barrier),
> };
>
> - if (intel_gt_is_wedged(>gt))
> + if (intel_gt_is_wedged(to_gt(i915)))
> return 0;
>
> return i915_subtests(tests, i915);
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index 152d9ab135b1..b5576888cd78 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -248,7 +248,7 @@ int i915_gem_live_selftests(struct drm_i915_private *i915)
> SUBTEST(igt_gem_ww_ctx),
> };
>
> - if (intel_gt_is_wedged(>gt))
> + if (intel_gt_is_wedged(to_gt(i915)))
> return 0;
>
> return i915_live_subtests(tests, i915);
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> index 7e0658a77659..75b709c26dd3 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
> @@ -545,7 +545,7 @@ int i915_gem_evict_mock_selftests(void)
> return -ENOMEM;
>
> with_intel_runtime_pm(>runtime_pm, wakeref)
> - err = i915_subtests(tests, >gt);
> + err = i915_subtests(tests, to_gt(i915));
>
> mock_destroy_device(i915);
> return err;
> @@ -557,8 +557,8 @@ int i915_gem_evict_live_selftests(struct drm_i915_private
> *i915)
> SUBTEST(igt_evict_contexts),
> };
>
> - if (intel_gt_is_wedged(>gt))
> + if (intel_gt_is_wedged(to_gt(i915)))
> return 0;
>
> - return intel_gt_live_subtests(tests, >gt);
> + return intel_gt_live_subtests(tests, to_gt(i915));
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 46f4236039a9..48123c3e1ff0 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -155,7 +155,7 @@ static int igt_ppgtt_alloc(void *arg)
> if (!HAS_PPGTT(dev_priv))
> return 0;
>
> - ppgtt = i915_ppgtt_create(_priv->gt, 0);
> + ppgtt = i915_ppgtt_create(to_gt(dev_priv), 0);
> if (IS_ERR(ppgtt))
> return PTR_ERR(ppgtt);
>
> @@ -1053,7 +1053,7 @@ static int exercise_ppgtt(struct drm_i915_private
> *dev_priv,
> if (IS_ERR(file))
> return PTR_ERR(file);
>
> - ppgtt = i915_ppgtt_create(_priv->gt, 0);
> + ppgtt = i915_ppgtt_create(to_gt(dev_priv), 0);
> if (IS_ERR(ppgtt)) {
> err = PTR_ERR(ppgtt);
> goto out_free;
> diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
> b/drivers/gpu/drm/i915/selftests/i915_perf.c
> index 9e9a6cb1d9e5..88db2e3d81d0 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_perf.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
> @@ -424,7 +424,7 @@ int i915_perf_live_selftests(struct drm_i915_private
> *i915)
> if (!perf->metrics_kobj || !perf->ops.enable_metric_set)
> return 0;
>
> - if (intel_gt_is_wedged(>gt))
> + if (intel_gt_is_wedged(to_gt(i915)))
> return 0;
>
> err = alloc_empty_config(>perf);
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 9979ef9197cd..92a859b34190 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@
Re: [PATCH v6 06/11] drm/i915/gvt: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:07PM +0200, Andi Shyti wrote: > From: Michał Winiarski > > Use to_gt() helper consistently throughout the codebase. > Pure mechanical s/i915->gt/to_gt(i915). No functional changes. > > Signed-off-by: Michał Winiarski > Signed-off-by: Andi Shyti Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gvt/gvt.c | 2 +- > drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c > index cbac409f6c8a..f0b69e4dcb52 100644 > --- a/drivers/gpu/drm/i915/gvt/gvt.c > +++ b/drivers/gpu/drm/i915/gvt/gvt.c > @@ -205,7 +205,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915) > spin_lock_init(>scheduler.mmio_context_lock); > mutex_init(>lock); > mutex_init(>sched_lock); > - gvt->gt = >gt; > + gvt->gt = to_gt(i915); > i915->gvt = gvt; > > init_device_info(gvt); > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c > b/drivers/gpu/drm/i915/gvt/scheduler.c > index 6c804102528b..42a0c9ae0a73 100644 > --- a/drivers/gpu/drm/i915/gvt/scheduler.c > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c > @@ -1386,7 +1386,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu) > enum intel_engine_id i; > int ret; > > - ppgtt = i915_ppgtt_create(>gt, I915_BO_ALLOC_PM_EARLY); > + ppgtt = i915_ppgtt_create(to_gt(i915), I915_BO_ALLOC_PM_EARLY); > if (IS_ERR(ppgtt)) > return PTR_ERR(ppgtt); > > -- > 2.34.1 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795
Re: [PATCH v6 05/11] drm/i915/gem: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:06PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 22
> drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +--
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++--
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 6 ++---
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 3 ++-
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 12 -
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +--
> .../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 10 +++
> .../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mman.c| 26 ++-
> 15 files changed, 55 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 347dab952e90..cad3f0b2be9e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct
> drm_i915_private *i915,
>* colateral damage, and we should not pretend we can by
>* exposing the interface.
>*/
> - if (!intel_has_reset_engine(>gt))
> + if (!intel_has_reset_engine(to_gt(i915)))
> return -ENODEV;
>
> pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
> @@ -254,7 +254,7 @@ static int proto_context_set_protected(struct
> drm_i915_private *i915,
>
> if (!protected) {
> pc->uses_protected_content = false;
> - } else if (!intel_pxp_is_enabled(>gt.pxp)) {
> + } else if (!intel_pxp_is_enabled(_gt(i915)->pxp)) {
> ret = -ENODEV;
> } else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
> !(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
> @@ -268,8 +268,8 @@ static int proto_context_set_protected(struct
> drm_i915_private *i915,
>*/
> pc->pxp_wakeref = intel_runtime_pm_get(>runtime_pm);
>
> - if (!intel_pxp_is_active(>gt.pxp))
> - ret = intel_pxp_start(>gt.pxp);
> + if (!intel_pxp_is_active(_gt(i915)->pxp))
> + ret = intel_pxp_start(_gt(i915)->pxp);
> }
>
> return ret;
> @@ -571,7 +571,7 @@ set_proto_ctx_engines_parallel_submit(struct
> i915_user_extension __user *base,
> intel_engine_mask_t prev_mask;
>
> /* FIXME: This is NIY for execlists */
> - if (!(intel_uc_uses_guc_submission(>gt.uc)))
> + if (!(intel_uc_uses_guc_submission(_gt(i915)->uc)))
> return -ENODEV;
>
> if (get_user(slot, >engine_index))
> @@ -833,7 +833,7 @@ static int set_proto_ctx_sseu(struct
> drm_i915_file_private *fpriv,
> sseu = >legacy_rcs_sseu;
> }
>
> - ret = i915_gem_user_to_context_sseu(>gt, _sseu, sseu);
> + ret = i915_gem_user_to_context_sseu(to_gt(i915), _sseu, sseu);
> if (ret)
> return ret;
>
> @@ -1044,7 +1044,7 @@ static struct i915_gem_engines *alloc_engines(unsigned
> int count)
> static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
> struct intel_sseu rcs_sseu)
> {
> - const struct intel_gt *gt = >i915->gt;
> + const struct intel_gt *gt = to_gt(ctx->i915);
> struct intel_engine_cs *engine;
> struct i915_gem_engines *e, *err;
> enum intel_engine_id id;
> @@ -1521,7 +1521,7 @@ static int __context_set_persistence(struct
> i915_gem_context *ctx, bool state)
>* colateral damage, and we should not pretend we can by
>* exposing the interface.
>*/
> - if (!intel_has_reset_engine(>i915->gt))
> + if (!intel_has_reset_engine(to_gt(ctx->i915)))
> return -ENODEV;
>
> i915_gem_context_clear_persistence(ctx);
> @@ -1559,7 +1559,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
> } else if (HAS_FULL_PPGTT(i915)) {
> struct i915_ppgtt *ppgtt;
>
> - ppgtt = i915_ppgtt_create(>gt, 0);
> + ppgtt = i915_ppgtt_create(to_gt(i915), 0);
> if (IS_ERR(ppgtt)) {
> drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
> PTR_ERR(ppgtt));
> @@ -1742,7 +1742,7 @@ int
Re: [PATCH v12, 13/19] media: mtk-vcodec: Add work queue for core hardware decode
On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote:
>
> Add work queue to process core hardware information.
> First, get lat_buf from message queue, then call core
> hardware of each codec(H264/VP9/AV1) to decode, finally
> puts lat_buf back to the message.
>
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 16 +++-
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 ++
> .../platform/mtk-vcodec/vdec_msg_queue.c | 41 ---
> .../platform/mtk-vcodec/vdec_msg_queue.h | 8 ++--
> 4 files changed, 57 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> index d460703f335d..4fbff61d2334 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -341,6 +341,17 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> goto err_dec_pm;
> }
>
> + if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
> + vdec_msg_queue_init_ctx(>msg_queue_core_ctx,
> MTK_VDEC_CORE);
> + dev->core_workqueue = alloc_ordered_workqueue("core-decoder",
> + WQ_MEM_RECLAIM | WQ_FREEZABLE);
> + if (!dev->core_workqueue) {
> + mtk_v4l2_err("Failed to create core workqueue");
> + ret = -EINVAL;
> + goto err_res;
> + }
> + }
> +
> for (i = 0; i < MTK_VDEC_HW_MAX; i++)
> mutex_init(>dec_mutex[i]);
> spin_lock_init(>irqlock);
> @@ -351,7 +362,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> ret = v4l2_device_register(>dev, >v4l2_dev);
> if (ret) {
> mtk_v4l2_err("v4l2_device_register err=%d", ret);
> - goto err_res;
> + goto err_core_workq;
> }
>
> init_waitqueue_head(>queue);
> @@ -450,6 +461,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> video_unregister_device(vfd_dec);
> err_dec_alloc:
> v4l2_device_unregister(>v4l2_dev);
> +err_core_workq:
> + if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch))
> + destroy_workqueue(dev->core_workqueue);
> err_res:
> mtk_vcodec_release_dec_pm(>pm);
> err_dec_pm:
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index cbaed96dcfa2..a558cc16026d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -27,6 +27,7 @@
> #define MTK_VCODEC_MAX_PLANES 3
> #define MTK_V4L2_BENCHMARK 0
> #define WAIT_INTR_TIMEOUT_MS 1000
> +#define IS_VDEC_LAT_ARCH(hw_arch) ((hw_arch) >= MTK_VDEC_LAT_SINGLE_CORE)
Basic question: What is practical meaning of this? What architectures
are supported?
>
> /*
> * enum mtk_hw_reg_idx - MTK hw register base index
> @@ -464,6 +465,7 @@ struct mtk_vcodec_enc_pdata {
> * @dec_capability: used to identify decode capability, ex: 4k
> * @enc_capability: used to identify encode capability
> *
> + * @core_workqueue: queue used for core hardware decode
> * @msg_queue_core_ctx: msg queue context used for core workqueue
> *
> * @subdev_dev: subdev hardware device
> @@ -506,6 +508,7 @@ struct mtk_vcodec_dev {
> unsigned int dec_capability;
> unsigned int enc_capability;
>
> + struct workqueue_struct *core_workqueue;
> struct vdec_msg_queue_ctx msg_queue_core_ctx;
>
> void *subdev_dev[MTK_VDEC_HW_MAX];
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> index 913aefa67618..24f1d03df9f1 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> @@ -68,6 +68,9 @@ int vdec_msg_queue_qbuf(struct vdec_msg_queue_ctx *msg_ctx,
> struct vdec_lat_buf
>
> if (msg_ctx->hardware_index != MTK_VDEC_CORE)
> wake_up_all(_ctx->ready_to_use);
> + else
> + queue_work(buf->ctx->dev->core_workqueue,
> + >ctx->msg_queue.core_work);
need {} for else here?
>
> mtk_v4l2_debug(3, "enqueue buf type: %d addr: 0x%p num: %d",
> msg_ctx->hardware_index, buf, msg_ctx->ready_num);
> @@ -169,8 +172,7 @@ bool vdec_msg_queue_wait_lat_buf_full(struct
> vdec_msg_queue *msg_queue)
> return false;
> }
>
> -void vdec_msg_queue_deinit(
> - struct vdec_msg_queue *msg_queue,
> +void vdec_msg_queue_deinit(struct vdec_msg_queue *msg_queue,
> struct mtk_vcodec_ctx *ctx)
> {
> struct vdec_lat_buf *lat_buf;
> @@ -196,10 +198,36 @@ void vdec_msg_queue_deinit(
> }
> }
>
> -int vdec_msg_queue_init(
> - struct vdec_msg_queue *msg_queue,
> - struct
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On Thu, Dec 09, 2021 at 05:20:45PM -0500, Harry Wentland wrote:
>
>
> On 2021-12-09 01:23, Kees Cook wrote:
> > On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
> >> On Fri, 03 Dec 2021, Kees Cook wrote:
> >>> The link_status array was not large enough to read the Adjust Request
> >>> Post Cursor2 register. Adjust the size to include it. Found with a
> >>> -Warray-bounds build:
> >>>
> >>> drivers/gpu/drm/drm_dp_helper.c: In function
> >>> 'drm_dp_get_adjust_request_post_cursor':
> >>> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is
> >>> outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> >>> [-Werror=array-bounds]
> >>>59 | return link_status[r - DP_LANE0_1_STATUS];
> >>> |~~~^~~
> >>> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
> >>> 'link_status'
> >>> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> >>> link_status[DP_LINK_STATUS_SIZE],
> >>> |
> >>> ~^~~~
> >>>
> >>> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> >>> Signed-off-by: Kees Cook
> >>
> >> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
> >> published in 2014, and Tegra is the only user of
> >> drm_dp_get_adjust_request_post_cursor().
> >
> > I see POST_CURSOR2 is used here too:
> >
> > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> >
>
> Looks like we read and parse that in the admgpu driver without
> using drm_dp_get_adjust_request_post_cursor.
Right, and probably that could be switched to use it, but I'm not sure
what the impact of the larger link_status read is.
>
> I don't have a strong feeling but I liked your original
> patch a bit better. I'm not sure what it means when part
> of a spec is deprecated. Once a spec is written display
> vendors might implement it. We should make sure that
> displays like that are always handled in a sane manner.
Jani, Dave, any guidance here? I'm fine with whatever, but the current
code is for sure broken. ;)
-Kees
--
Kees Cook
Re: [PATCH v6 04/11] drm/i915/gt: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:05PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/gt/mock_engine.c | 10 +-
> drivers/gpu/drm/i915/gt/selftest_context.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_engine.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_engine_cs.c| 4 ++--
> drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_execlists.c| 6 +++---
> drivers/gpu/drm/i915/gt/selftest_gt_pm.c| 8
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c| 2 +-
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_migrate.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_reset.c| 2 +-
> drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +++---
> drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +++---
> drivers/gpu/drm/i915/gt/selftest_workarounds.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c | 2 +-
> 23 files changed, 46 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 8f8bea08e734..9ce85a845105 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private
> *i915)
> disabled |= (I915_SCHEDULER_CAP_ENABLED |
>I915_SCHEDULER_CAP_PRIORITY);
>
> - if (intel_uc_uses_guc_submission(>gt.uc))
> + if (intel_uc_uses_guc_submission(_gt(i915)->uc))
> enabled |= I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP;
>
> for (i = 0; i < ARRAY_SIZE(map); i++) {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index cbc6d2b1fd9e..f5c8fd3911b0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -1229,7 +1229,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> {
> int ret;
>
> - ret = ggtt_probe_hw(>ggtt, >gt);
> + ret = ggtt_probe_hw(>ggtt, to_gt(i915));
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 07ff7ba7b2b7..36eb980d757e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
> return 0;
>
> with_intel_runtime_pm(>runtime_pm, wakeref) {
> - struct intel_ips *ips = >gt.rps.ips;
> + struct intel_ips *ips = _gt(i915)->rps.ips;
>
> spin_lock_irq(_lock);
> chipset_val = __ips_chipset_val(ips);
> @@ -2329,7 +2329,7 @@ bool i915_gpu_raise(void)
> if (!i915)
> return false;
>
> - rps = >gt.rps;
> + rps = _gt(i915)->rps;
>
> spin_lock_irq(_lock);
> if (rps->max_freq_softlimit < rps->max_freq)
> @@ -2356,7 +2356,7 @@ bool i915_gpu_lower(void)
> if (!i915)
> return false;
>
> - rps = >gt.rps;
> + rps = _gt(i915)->rps;
>
> spin_lock_irq(_lock);
> if (rps->max_freq_softlimit > rps->min_freq)
> @@ -2382,7 +2382,7 @@ bool i915_gpu_busy(void)
> if (!i915)
> return false;
>
> - ret = i915->gt.awake;
> + ret = to_gt(i915)->awake;
>
> drm_dev_put(>drm);
> return ret;
> @@ -2405,11 +2405,11 @@ bool i915_gpu_turbo_disable(void)
> if (!i915)
> return false;
>
> - rps = >gt.rps;
> + rps = _gt(i915)->rps;
>
> spin_lock_irq(_lock);
> rps->max_freq_softlimit = rps->min_freq;
> - ret = !__gen5_rps_set(>gt.rps, rps->min_freq);
> + ret = !__gen5_rps_set(_gt(i915)->rps, rps->min_freq);
> spin_unlock_irq(_lock);
>
> drm_dev_put(>drm);
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3113266c286e..ab3277a3d593 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++
Re: [PATCH v12, 06/19] media: mtk-vcodec: Add to support multi hardware decode
Few comments and questions.
On Wed, Dec 1, 2021 at 7:46 PM Yunfei Dong wrote:
>
> There are more than two hardwares for decoder: LAT0, LAT1 and CORE. In order
> to
> manage these hardwares, register each hardware as independent platform device
> for the larbs are different.
basic question: what is "larbs"?
>
> Each hardware module controls its own information which includes
> interrupt/power/
> clocks/registers.
>
> Calling of_platform_populate in parent device, and use subdev_bitmap to record
> whether the hardwares are registered done.
nit: s/registered done/registered/ ?
>
> Signed-off-by: Yunfei Dong
> ---
> drivers/media/platform/mtk-vcodec/Makefile| 5 +-
> .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 111 +++
> .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 172 ++
> .../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 51 ++
> .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
> .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 2 +
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 19 ++
> 7 files changed, 329 insertions(+), 32 deletions(-)
> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
>
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile
> b/drivers/media/platform/mtk-vcodec/Makefile
> index ca8e9e7a9c4e..c61bfb179bcc 100644
> --- a/drivers/media/platform/mtk-vcodec/Makefile
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -2,7 +2,8 @@
>
> obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
>mtk-vcodec-enc.o \
> - mtk-vcodec-common.o
> + mtk-vcodec-common.o \
> + mtk-vcodec-dec-hw.o
>
> mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
> vdec/vdec_vp8_if.o \
> @@ -16,6 +17,8 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
> mtk_vcodec_dec_stateless.o \
> mtk_vcodec_dec_pm.o \
>
> +mtk-vcodec-dec-hw-y := mtk_vcodec_dec_hw.o
> +
> mtk-vcodec-enc-y := venc/venc_vp8_if.o \
> venc/venc_h264_if.o \
> mtk_vcodec_enc.o \
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> index b7a51e96d4ba..95fbe9be3f6d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -18,19 +18,40 @@
>
> #include "mtk_vcodec_drv.h"
> #include "mtk_vcodec_dec.h"
> +#include "mtk_vcodec_dec_hw.h"
> #include "mtk_vcodec_dec_pm.h"
> #include "mtk_vcodec_intr.h"
> #include "mtk_vcodec_util.h"
> #include "mtk_vcodec_fw.h"
>
> -#define VDEC_HW_ACTIVE 0x10
> -#define VDEC_IRQ_CFG 0x11
> -#define VDEC_IRQ_CLR 0x10
> -#define VDEC_IRQ_CFG_REG 0xa4
> -
> module_param(mtk_v4l2_dbg_level, int, 0644);
> module_param(mtk_vcodec_dbg, bool, 0644);
>
> +static int mtk_vcodec_subdev_device_check(struct mtk_vcodec_dev *vdec_dev)
> +{
> + struct platform_device *pdev = vdec_dev->plat_dev;
> + struct device_node *subdev_node;
> + enum mtk_vdec_hw_id hw_idx;
> + const struct of_device_id *of_id;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(mtk_vdec_hw_match); i++) {
> + of_id = _vdec_hw_match[i];
> + subdev_node = of_find_compatible_node(NULL, NULL,
> + of_id->compatible);
> + if (!subdev_node)
> + continue;
> +
> + hw_idx = (enum mtk_vdec_hw_id)(uintptr_t)of_id->data;
> + if (!test_bit(hw_idx, vdec_dev->subdev_bitmap)) {
> + dev_err(>dev, "Vdec %d is not ready", hw_idx);
> + return -EAGAIN;
> + }
> + }
> +
> + return 0;
> +}
> +
> static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
> {
> struct mtk_vcodec_dev *dev = priv;
> @@ -95,6 +116,42 @@ static int mtk_vcodec_get_reg_bases(struct mtk_vcodec_dev
> *dev)
> return 0;
> }
>
> +static int mtk_vcodec_init_dec_resources(struct mtk_vcodec_dev *dev)
> +{
> + struct platform_device *pdev = dev->plat_dev;
> + int ret;
> +
> + ret = mtk_vcodec_get_reg_bases(dev);
> + if (ret)
> + return ret;
> +
> + if (dev->vdec_pdata->is_subdev_supported)
> + return 0;
> +
> + dev->dec_irq = platform_get_irq(pdev, 0);
> + if (dev->dec_irq < 0) {
> + dev_err(>dev, "failed to get irq number");
> + return dev->dec_irq;
> + }
> +
> + irq_set_status_flags(dev->dec_irq, IRQ_NOAUTOEN);
> + ret = devm_request_irq(>dev, dev->dec_irq,
> + mtk_vcodec_dec_irq_handler, 0, pdev->name, dev);
> + if (ret) {
> + dev_err(>dev, "failed to install dev->dec_irq %d (%d)",
> +
Re: [PATCH v6 03/11] drm/i915/display: Use to_gt() helper
On Thu, Dec 09, 2021 at 03:25:04PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 18 +-
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
> .../gpu/drm/i915/display/skl_universal_plane.c | 2 +-
> 5 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 89005628cc3a..c2c512cd8ec0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -819,7 +819,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>* maximum clocks following a vblank miss (see do_rps_boost()).
>*/
> if (!state->rps_interactive) {
> - intel_rps_mark_interactive(_priv->gt.rps, true);
> + intel_rps_mark_interactive(_gt(dev_priv)->rps, true);
> state->rps_interactive = true;
> }
>
> @@ -853,7 +853,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> return;
>
> if (state->rps_interactive) {
> - intel_rps_mark_interactive(_priv->gt.rps, false);
> + intel_rps_mark_interactive(_gt(dev_priv)->rps, false);
> state->rps_interactive = false;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 128d4943a43b..b5cab57a26a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -841,7 +841,7 @@ __intel_display_resume(struct drm_device *dev,
> static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
> {
> return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> - intel_has_gpu_reset(_priv->gt));
> + intel_has_gpu_reset(to_gt(dev_priv)));
> }
>
> void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
> @@ -860,14 +860,14 @@ void intel_display_prepare_reset(struct
> drm_i915_private *dev_priv)
> return;
>
> /* We have a modeset vs reset deadlock, defensively unbreak it. */
> - set_bit(I915_RESET_MODESET, _priv->gt.reset.flags);
> + set_bit(I915_RESET_MODESET, _gt(dev_priv)->reset.flags);
> smp_mb__after_atomic();
> - wake_up_bit(_priv->gt.reset.flags, I915_RESET_MODESET);
> + wake_up_bit(_gt(dev_priv)->reset.flags, I915_RESET_MODESET);
>
> if (atomic_read(_priv->gpu_error.pending_fb_pin)) {
> drm_dbg_kms(_priv->drm,
> "Modeset potentially stuck, unbreaking through
> wedging\n");
> - intel_gt_set_wedged(_priv->gt);
> + intel_gt_set_wedged(to_gt(dev_priv));
> }
>
> /*
> @@ -918,7 +918,7 @@ void intel_display_finish_reset(struct drm_i915_private
> *dev_priv)
> return;
>
> /* reset doesn't touch the display */
> - if (!test_bit(I915_RESET_MODESET, _priv->gt.reset.flags))
> + if (!test_bit(I915_RESET_MODESET, _gt(dev_priv)->reset.flags))
> return;
>
> state = fetch_and_zero(_priv->modeset_restore_state);
> @@ -956,7 +956,7 @@ void intel_display_finish_reset(struct drm_i915_private
> *dev_priv)
> drm_modeset_acquire_fini(ctx);
> mutex_unlock(>mode_config.mutex);
>
> - clear_bit_unlock(I915_RESET_MODESET, _priv->gt.reset.flags);
> + clear_bit_unlock(I915_RESET_MODESET, _gt(dev_priv)->reset.flags);
> }
>
> static void icl_set_pipe_chicken(const struct intel_crtc_state *crtc_state)
> @@ -8564,19 +8564,19 @@ static void intel_atomic_commit_fence_wait(struct
> intel_atomic_state *intel_stat
> for (;;) {
> prepare_to_wait(_state->commit_ready.wait,
> _fence, TASK_UNINTERRUPTIBLE);
> - prepare_to_wait(bit_waitqueue(_priv->gt.reset.flags,
> + prepare_to_wait(bit_waitqueue(_gt(dev_priv)->reset.flags,
> I915_RESET_MODESET),
> _reset, TASK_UNINTERRUPTIBLE);
>
>
> if (i915_sw_fence_done(_state->commit_ready) ||
> - test_bit(I915_RESET_MODESET, _priv->gt.reset.flags))
> + test_bit(I915_RESET_MODESET, _gt(dev_priv)->reset.flags))
> break;
>
> schedule();
> }
> finish_wait(_state->commit_ready.wait, _fence);
> - finish_wait(bit_waitqueue(_priv->gt.reset.flags,
> + finish_wait(bit_waitqueue(_gt(dev_priv)->reset.flags,
>
Re: [PATCH v6 02/11] drm/i915: Introduce to_gt() helper
On Thu, Dec 09, 2021 at 03:25:03PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> To allow further refactoring and abstract away the fact that GT is
> stored inside i915 private.
> No functional changes.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 7 +--
> drivers/gpu/drm/i915/i915_drv.h| 5 +
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
> b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
> index acc49c56a9f3..9db3dcbd917f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
> @@ -9,11 +9,6 @@
> #include "intel_engine_pm.h"
> #include "intel_gt_buffer_pool.h"
>
> -static struct intel_gt *to_gt(struct intel_gt_buffer_pool *pool)
> -{
> - return container_of(pool, struct intel_gt, buffer_pool);
> -}
> -
> static struct list_head *
> bucket_for_size(struct intel_gt_buffer_pool *pool, size_t sz)
> {
> @@ -141,7 +136,7 @@ static struct intel_gt_buffer_pool_node *
> node_create(struct intel_gt_buffer_pool *pool, size_t sz,
> enum i915_map_type type)
> {
> - struct intel_gt *gt = to_gt(pool);
> + struct intel_gt *gt = container_of(pool, struct intel_gt, buffer_pool);
> struct intel_gt_buffer_pool_node *node;
> struct drm_i915_gem_object *obj;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ae7dc7862b5d..c6f34ac353ff 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1080,6 +1080,11 @@ static inline struct drm_i915_private
> *pdev_to_i915(struct pci_dev *pdev)
> return pci_get_drvdata(pdev);
> }
>
> +static inline struct intel_gt *to_gt(struct drm_i915_private *i915)
> +{
> + return >gt;
> +}
> +
> /* Simple iterator over all initialised engines */
> #define for_each_engine(engine__, dev_priv__, id__) \
> for ((id__) = 0; \
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Freedreno] [PATCH v1 8/8] drm/msm/dpu: move SSPP debugfs support from plane to SSPP code
On 12/9/2021 2:18 PM, Abhinav Kumar wrote:
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 67 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 82 +++--
4 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index d77eb7da5daf..ae3cf2e4d7d9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -8,6 +8,8 @@
#include "dpu_hw_sspp.h"
#include "dpu_kms.h"
+#include
+
#define DPU_FETCH_CONFIG_RESET_VALUE 0x0087
/* DPU_SSPP_SRC */
@@ -686,6 +688,71 @@ static void _setup_layer_ops(struct dpu_hw_pipe *c,
c->ops.setup_cdp = dpu_hw_sspp_setup_cdp;
}
+#ifdef CONFIG_DEBUG_FS
+int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct
dpu_kms *kms, struct dentry *entry)
+{
+ const struct dpu_sspp_cfg *cfg = hw_pipe->cap;
+ const struct dpu_sspp_sub_blks *sblk = cfg->sblk;
+ struct dentry *debugfs_root;
+ char sspp_name[32];
+
+ snprintf(sspp_name, sizeof(sspp_name), "%d", hw_pipe->idx);
+
+ /* create overall sub-directory for the pipe */
+ debugfs_root =
+ debugfs_create_dir(sspp_name, entry);
I would like to take a different approach to this. Let me know what you
think.
Let the directory names still be the drm plane names as someone who
would first get the DRM state and then try to lookup the register values
of that plane would not know where to look now.
Inside the /sys/kernel/debug/***/plane-X/ directory you can expose an
extra entry which tells the sspp_index.
This will also establish the plane to SSPP mapping.
Now when planes go virtual in the future, this will be helpful even more
so that we can know the plane to SSPP mapping.
OR i like rob's suggestion of implementing the atomic_print_state
callback which will printout the drm plane to SSPP mapping along with
this change so that when we look at DRM state, we also know the plane
to SSPP mapping and look in the right SSPP's dir.
+
+ /* don't error check these */
+ debugfs_create_xul("features", 0600,
+ debugfs_root, (unsigned long *)_pipe->cap->features);
+
+ /* add register dump support */
+ dpu_debugfs_create_regset32("src_blk", 0400,
+ debugfs_root,
+ sblk->src_blk.base + cfg->base,
+ sblk->src_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED3LITE) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED2) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED4))
+ dpu_debugfs_create_regset32("scaler_blk", 0400,
+ debugfs_root,
+ sblk->scaler_blk.base + cfg->base,
+ sblk->scaler_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_CSC) ||
+ cfg->features & BIT(DPU_SSPP_CSC_10BIT))
+ dpu_debugfs_create_regset32("csc_blk", 0400,
+ debugfs_root,
+ sblk->csc_blk.base + cfg->base,
+ sblk->csc_blk.len,
+ kms);
+
+ debugfs_create_u32("xin_id",
+ 0400,
+ debugfs_root,
+ (u32 *) >xin_id);
+ debugfs_create_u32("clk_ctrl",
+ 0400,
+ debugfs_root,
+ (u32 *) >clk_ctrl);
+ debugfs_create_x32("creq_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >creq_vblank);
+ debugfs_create_x32("danger_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >danger_vblank);
+
+ return 0;
+}
+#endif
+
+
static const struct dpu_sspp_cfg *_sspp_offset(enum dpu_sspp sspp,
void __iomem *addr,
struct dpu_mdss_cfg *catalog,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index e8939d7387cb..cef281687bab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -381,6 +381,7 @@ struct dpu_hw_pipe {
struct dpu_hw_sspp_ops ops;
};
+struct dpu_kms;
/**
* dpu_hw_sspp_init - initializes the sspp hw driver object.
* Should be called once before accessing every pipe.
@@ -400,5 +401,8 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp
idx,
*/
void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
+void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry
*debugfs_root);
+int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct
dpu_kms *kms, struct dentry *entry);
+
#endif /*_DPU_HW_SSPP_H */
diff --git
Reuse framebuffer after a kexec (amdgpu / efifb)
Hi all, I have a question about the possibility of reusing a framebuffer after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not a separate GPU hardware), but I guess the question is kinda generic hence I've looped most of the lists / people I think does make sense (apologies for duplicates). The context is: we have a hardware that has an amdgpu-controlled device (Vangogh model) and as soon as the machine boots, efifb is providing graphics - I understand the UEFI/GRUB outputs rely in EFI framebuffer as well. As soon amdgpu module is available, kernel loads it and it takes over the GPU, providing graphics. The kexec_file_load syscall allows to pass a valid screen_info structure, so by kexec'ing a new kernel, we have again efifb taking over on boot time, but this time I see nothing in the screen. I've manually blacklisted amdgpu in this new kexec'ed kernel, I'd like to rely in the simple framebuffer - the goal is to have a tiny kernel kexec'ed. I'm using kernel version 5.16.0-rc4. I've done some other experiments, for exemple: I've forced screen_info model to match VLFB, so vesafb took over after the kexec, with the same result. Also noticed that BusMaster bit was off after kexec, in the AMD APU PCIe device, so I've set it on efifb before probe, and finally tested the same things in qemu, with qxl, all with the same result (blank screen). The most interesting result I got (both with amdgpu and qemu/qxl) is that if I blacklist these drivers and let the machine continue using efifb since the beginning, after kexec the efifb is still able to produce graphics. Which then led me to think that likely there's something fundamentally "blocking" the reuse of the simple framebuffer after kexec, like maybe DRM stack is destroying the old framebuffer somehow? What kind of preparation is required at firmware level to make the simple EFI VGA framebuffer work, and could we perform this in a kexec (or "save it" before the amdgpu/qxl drivers take over and reuse later)? Any advice is greatly appreciated! Thanks in advance, Guilherme
[PATCH] drm/amdgpu: Fix reference leak in psp_xgmi_reflect_topology_info()
In line 1138 (#1), amdgpu_get_xgmi_hive() increases the kobject reference
counter of the hive it returned. The hive returned by
amdgpu_get_xgmi_hive()should be released with the help of
amdgpu_put_xgmi_hive() to balance its kobject reference counter properly.
Forgetting the amdgpu_put_xgmi_hive() operation will result in reference
leak.
We can fix it by calling amdgpu_put_xgmi_hive() before the end of the
function (#2).
1128 static void psp_xgmi_reflect_topology_info(struct psp_context *psp,
1129struct psp_xgmi_node_info node_info)
1130 {
1138hive = amdgpu_get_xgmi_hive(psp->adev);
// #1: kzalloc space reference increment
1139list_for_each_entry(mirror_adev, >device_list, gmc.xgmi.head) {
1140struct psp_xgmi_topology_info *mirror_top_info;
1141int j;
1143if (mirror_adev->gmc.xgmi.node_id != dst_node_id)
1144continue;
1146mirror_top_info = _adev->psp.xgmi_context.top_info;
1147for (j = 0; j < mirror_top_info->num_nodes; j++) {
1148if (mirror_top_info->nodes[j].node_id != src_node_id)
1149continue;
1151mirror_top_info->nodes[j].num_hops = dst_num_hops;
1157if (dst_num_links)
1158mirror_top_info->nodes[j].num_links =
dst_num_links;
1160break;
1161}
1163break;
1164}
// #2: missing reference decrement
1165 }
Signed-off-by: Jianglei Nie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index c641f84649d6..f6362047ed71 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1162,6 +1162,7 @@ static void psp_xgmi_reflect_topology_info(struct
psp_context *psp,
break;
}
+ amdgpu_put_xgmi_hive(hive);
}
int psp_xgmi_get_topology_info(struct psp_context *psp,
--
2.25.1
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On 09/12/2021 14:31, Alex Deucher wrote: > [...] > Once the driver takes over, none of the pre-driver state is retained. > You'll need to load the driver in the new kernel to initialize the > displays. Note the efifb doesn't actually have the ability to program > any hardware, it just takes over the memory region that was used for > the pre-OS framebuffer and whatever display timing was set up by the > GOP driver prior to the OS loading. Once that OS driver has loaded > the area is gone and the display configuration may have changed. > Hi Christian and Alex, thanks for the clarifications! Is there any way to save/retain this state before amdgpu takes over? Would simpledrm be able to program the device again, to a working state? Finally, do you have any example of such a GOP driver (open source) so I can take a look? I tried to find something like that in Tianocore project, but didn't find anything that seemed useful for my issue. Thanks again!
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Thanks again Alex! Some comments inlined below: On 09/12/2021 15:06, Alex Deucher wrote: > Not really in a generic way. It's asic and platform specific. In > addition most modern displays require link training to bring up the > display, so you can't just save and restore registers. Oh sure, I understand that. My question is more like: is there a way, inside amdgpu driver, to save this state before taking over/overwriting/reprogramming the device? So we could (again, from inside the amdgpu driver) dump this pre-saved state in the shutdown handler, for example, having the device in a "pre-OS" state when the new kexec'ed kernel starts. > > The drivers are asic and platform specific. E.g., the driver for > vangogh is different from renoir is different from skylake, etc. The > display programming interfaces are asic specific. Cool, that makes sense! But if you (or anybody here) know some of these GOP drivers, e.g. for the qemu/qxl device, I'm just curious to see/understand how complex is the FW driver to just put the device/screen in a usable state. Cheers, Guilherme
Re: [Mesa-dev] [PATCH v3 13/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color
Ping. I see that a v4 has been sent out without these comments being addressed.
-Nanley
On Tue, Dec 7, 2021 at 6:51 PM Nanley Chery wrote:
>
> Hi Ramalingam,
>
> On Wed, Oct 27, 2021 at 5:22 PM Ramalingam C wrote:
> >
> > From: Matt Roper
> >
> > DG2 unifies render compression and media compression into a single
> > format for the first time. The programming and buffer layout is
> > supposed to match compression on older gen12 platforms, but the
> > actual compression algorithm is different from any previous platform; as
> > such, we need a new framebuffer modifier to represent buffers in this
> > format, but otherwise we can re-use the existing gen12 compression driver
> > logic.
> >
> > DG2 clear color render compression uses Tile4 layout. Therefore, we need
> > to define a new format modifier for uAPI to support clear color rendering.
> >
>
> I left some feedback on the modifier texts below, but I think it also
> applies to this commit message.
>
> > v2: Rebased on new format modifier check [Ram]
> >
> > Signed-off-by: Matt Roper
> > Signed-off-by: Mika Kahola (v2)
> > Signed-off-by: Juha-Pekka Heikkilä
> > Signed-off-by: Ramalingam C
> > cc: Simon Ser
> > Cc: Pekka Paalanen
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: mesa-...@lists.freedesktop.org
> > Cc: Tony Ye
> > Cc: Slawomir Milczarek
> > Acked-by: Simon Ser
> > ---
> > drivers/gpu/drm/i915/display/intel_fb.c | 43 +++
> > .../drm/i915/display/skl_universal_plane.c| 29 -
> > include/uapi/drm/drm_fourcc.h | 30 +
> > 3 files changed, 101 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index 562d5244688d..484ae1fd0e94 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -106,6 +106,21 @@ static const struct drm_format_info
> > gen12_ccs_cc_formats[] = {
> > .hsub = 1, .vsub = 1, .has_alpha = true },
> > };
> >
> > +static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
> > + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1,
> > 1 },
> > + .hsub = 1, .vsub = 1, },
> > + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1,
> > 1 },
> > + .hsub = 1, .vsub = 1, },
> > + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1,
> > 1 },
> > + .hsub = 1, .vsub = 1, .has_alpha = true },
> > + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> > + .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1,
> > 1 },
> > + .hsub = 1, .vsub = 1, .has_alpha = true },
> > +};
> > +
> > struct intel_modifier_desc {
> > u64 modifier;
> > struct {
> > @@ -166,6 +181,27 @@ static const struct intel_modifier_desc
> > intel_modifiers[] = {
> > .ccs.packed_aux_planes = BIT(1),
> >
> > FORMAT_OVERRIDE(gen12_ccs_cc_formats),
> > + }, {
> > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
> > + .display_ver = { 12, 13 },
> > + .tiling = I915_TILING_NONE,
> > +
> > + .ccs.type = INTEL_CCS_RC,
> > + }, {
> > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
> > + .display_ver = { 12, 13 },
> > + .tiling = I915_TILING_NONE,
> > +
> > + .ccs.type = INTEL_CCS_MC,
> > + }, {
> > + .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
> > + .display_ver = { 12, 13 },
> > + .tiling = I915_TILING_NONE,
> > +
> > + .ccs.type = INTEL_CCS_RC_CC,
> > + .ccs.cc_planes = BIT(1),
> > +
> > + FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
> > }, {
> > .modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
> > .display_ver = { 9, 11 },
> > @@ -582,6 +618,9 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int color_plane)
> > return 128;
> > else
> > return 512;
> > + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> > + case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> > + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
> > case I915_FORMAT_MOD_4_TILED:
> > /*
> > * Each 4K tile consists of 64B(8*8) subtiles, with
> > @@ -759,6 +798,10 @@ unsigned int intel_surf_alignment(const struct
> > drm_framebuffer *fb,
> > case I915_FORMAT_MOD_4_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > return 1 * 1024 * 1024;
> > + case
Re: [syzbot] BUG: unable to handle kernel paging request in bitfill_aligned (2)
syzbot has found a reproducer for the following issue on: HEAD commit:2a987e65025e Merge tag 'perf-tools-fixes-for-v5.16-2021-12.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12f8fdc5b0 kernel config: https://syzkaller.appspot.com/x/.config?x=7d5e878e3399b6cc dashboard link: https://syzkaller.appspot.com/bug?extid=a4edd73d589b0b7efbeb compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16671badb0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=122beabdb0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+a4edd73d589b0b7ef...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: 88800130 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 11201067 P4D 11201067 PUD 11202067 PMD 810001e1 Oops: 0003 [#1] PREEMPT SMP KASAN CPU: 0 PID: 6524 Comm: syz-executor260 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__writeq arch/x86/include/asm/io.h:98 [inline] RIP: 0010:bitfill_aligned+0x1d2/0x270 drivers/video/fbdev/core/cfbfillrect.c:75 Code: 39 1b fd eb 09 e8 3e 39 1b fd 48 83 c3 40 31 ff 89 ee e8 41 3d 1b fd 85 ed 74 2c 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 ff cd <4c> 89 33 85 ed 74 0b 48 83 c3 08 e8 0e 39 1b fd eb ec e8 07 39 1b RSP: 0018:c90002b4ee38 EFLAGS: 00010202 RAX: RBX: 88800130 RCX: 888020209d00 RDX: 888020209d00 RSI: 0002 RDI: RBP: 0001 R08: 84695e4f R09: 0040 R10: 0002 R11: 888020209d00 R12: R13: 0080 R14: R15: FS: 55c14300() GS:8880b9a0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 88800130 CR3: 708fb000 CR4: 003506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: cfb_fillrect+0x5d8/0x800 drivers/video/fbdev/core/cfbfillrect.c:327 bit_clear_margins+0x2d7/0x6e0 drivers/video/fbdev/core/bitblit.c:209 fbcon_clear_margins drivers/video/fbdev/core/fbcon.c:1296 [inline] fbcon_switch+0x1569/0x21f0 drivers/video/fbdev/core/fbcon.c:1677 redraw_screen+0x53d/0x1280 drivers/tty/vt/vt.c:1021 vc_do_resize+0x1361/0x1930 drivers/tty/vt/vt.c:1342 fbcon_do_set_font+0x9ef/0x10d0 drivers/video/fbdev/core/fbcon.c:1928 fbcon_set_font+0x9f9/0xc80 drivers/video/fbdev/core/fbcon.c:2014 con_font_set drivers/tty/vt/vt.c:4666 [inline] con_font_op+0xbcd/0x1080 drivers/tty/vt/vt.c:4710 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x1838/0x3860 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0xfb2/0x17d0 drivers/tty/tty_io.c:2805 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f44f1232229 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fffb8c823a8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 7f44f1232229 RDX: 2400 RSI: 4b72 RDI: 0004 RBP: R08: 000d R09: 7fffb8c82548 R10: R11: 0246 R12: 7f44f11f5820 R13: 431bde82d7b634db R14: R15: Modules linked in: CR2: 88800130 ---[ end trace 3cf2fa8eab0f5f7d ]--- RIP: 0010:__writeq arch/x86/include/asm/io.h:98 [inline] RIP: 0010:bitfill_aligned+0x1d2/0x270 drivers/video/fbdev/core/cfbfillrect.c:75 Code: 39 1b fd eb 09 e8 3e 39 1b fd 48 83 c3 40 31 ff 89 ee e8 41 3d 1b fd 85 ed 74 2c 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 ff cd <4c> 89 33 85 ed 74 0b 48 83 c3 08 e8 0e 39 1b fd eb ec e8 07 39 1b RSP: 0018:c90002b4ee38 EFLAGS: 00010202 RAX: RBX: 88800130 RCX: 888020209d00 RDX: 888020209d00 RSI: 0002 RDI: RBP: 0001 R08: 84695e4f R09: 0040 R10: 0002 R11: 888020209d00 R12: R13: 0080 R14: R15: FS: 55c14300() GS:8880b9a0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 88800130 CR3: 708fb000 CR4: 003506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7:
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On 2021-12-09 01:23, Kees Cook wrote:
> On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
>> On Fri, 03 Dec 2021, Kees Cook wrote:
>>> The link_status array was not large enough to read the Adjust Request
>>> Post Cursor2 register. Adjust the size to include it. Found with a
>>> -Warray-bounds build:
>>>
>>> drivers/gpu/drm/drm_dp_helper.c: In function
>>> 'drm_dp_get_adjust_request_post_cursor':
>>> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside
>>> array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
>>> [-Werror=array-bounds]
>>>59 | return link_status[r - DP_LANE0_1_STATUS];
>>> |~~~^~~
>>> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
>>> 'link_status'
>>> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
>>> link_status[DP_LINK_STATUS_SIZE],
>>> |
>>> ~^~~~
>>>
>>> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
>>> Signed-off-by: Kees Cook
>>
>> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
>> published in 2014, and Tegra is the only user of
>> drm_dp_get_adjust_request_post_cursor().
>
> I see POST_CURSOR2 is used here too:
>
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>
Looks like we read and parse that in the admgpu driver without
using drm_dp_get_adjust_request_post_cursor.
I don't have a strong feeling but I liked your original
patch a bit better. I'm not sure what it means when part
of a spec is deprecated. Once a spec is written display
vendors might implement it. We should make sure that
displays like that are always handled in a sane manner.
Harry
> Here's a version of that for tegra (untested):
>
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 23f9073bc473..c9528aa62c9c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8
> link_status[DP_LINK_STATUS_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
>
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane)
> -{
> - unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> - u8 value = dp_link_status(link_status, offset);
> -
> - return (value >> (lane << 1)) & 0x3;
> -}
> -EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> -
> static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8
> rd_interval)
> {
> if (rd_interval > 4)
> diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
> index 70dfb7d1dec5..f5535eb04c6b 100644
> --- a/drivers/gpu/drm/tegra/dp.c
> +++ b/drivers/gpu/drm/tegra/dp.c
> @@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> {
> struct drm_dp_link_train_set *adjust = >train.adjust;
> unsigned int i;
> + u8 post_cursor;
> + int err;
> +
> + err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
> +_cursor, sizeof(post_cursor));
> + if (err < 0) {
> + DRM_ERROR("failed to read post_cursor2: %d\n", err);
> + post_cursor = 0;
> + }
>
> for (i = 0; i < link->lanes; i++) {
> adjust->voltage_swing[i] =
> @@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct
> drm_dp_link *link,
> DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> adjust->post_cursor[i] =
> - drm_dp_get_adjust_request_post_cursor(status, i);
> + (post_cursor >> (i << 1)) & 0x3;
> }
> }
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 30359e434c3f..28378db676c8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> int lane);
> u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane);
> -u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> - unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
>
>
> Is that the right way to go?
>
Re: [PATCH v1 8/8] drm/msm/dpu: move SSPP debugfs support from plane to SSPP code
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to dpu_hw_sspp.c, where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 67 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 82 +++--
4 files changed, 84 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index d77eb7da5daf..ae3cf2e4d7d9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -8,6 +8,8 @@
#include "dpu_hw_sspp.h"
#include "dpu_kms.h"
+#include
+
#define DPU_FETCH_CONFIG_RESET_VALUE 0x0087
/* DPU_SSPP_SRC */
@@ -686,6 +688,71 @@ static void _setup_layer_ops(struct dpu_hw_pipe *c,
c->ops.setup_cdp = dpu_hw_sspp_setup_cdp;
}
+#ifdef CONFIG_DEBUG_FS
+int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct dpu_kms
*kms, struct dentry *entry)
+{
+ const struct dpu_sspp_cfg *cfg = hw_pipe->cap;
+ const struct dpu_sspp_sub_blks *sblk = cfg->sblk;
+ struct dentry *debugfs_root;
+ char sspp_name[32];
+
+ snprintf(sspp_name, sizeof(sspp_name), "%d", hw_pipe->idx);
+
+ /* create overall sub-directory for the pipe */
+ debugfs_root =
+ debugfs_create_dir(sspp_name, entry);
I would like to take a different approach to this. Let me know what you
think.
Let the directory names still be the drm plane names as someone who
would first get the DRM state and then try to lookup the register values
of that plane would not know where to look now.
Inside the /sys/kernel/debug/***/plane-X/ directory you can expose an
extra entry which tells the sspp_index.
This will also establish the plane to SSPP mapping.
Now when planes go virtual in the future, this will be helpful even more
so that we can know the plane to SSPP mapping.
+
+ /* don't error check these */
+ debugfs_create_xul("features", 0600,
+ debugfs_root, (unsigned long *)_pipe->cap->features);
+
+ /* add register dump support */
+ dpu_debugfs_create_regset32("src_blk", 0400,
+ debugfs_root,
+ sblk->src_blk.base + cfg->base,
+ sblk->src_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED3LITE) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED2) ||
+ cfg->features & BIT(DPU_SSPP_SCALER_QSEED4))
+ dpu_debugfs_create_regset32("scaler_blk", 0400,
+ debugfs_root,
+ sblk->scaler_blk.base + cfg->base,
+ sblk->scaler_blk.len,
+ kms);
+
+ if (cfg->features & BIT(DPU_SSPP_CSC) ||
+ cfg->features & BIT(DPU_SSPP_CSC_10BIT))
+ dpu_debugfs_create_regset32("csc_blk", 0400,
+ debugfs_root,
+ sblk->csc_blk.base + cfg->base,
+ sblk->csc_blk.len,
+ kms);
+
+ debugfs_create_u32("xin_id",
+ 0400,
+ debugfs_root,
+ (u32 *) >xin_id);
+ debugfs_create_u32("clk_ctrl",
+ 0400,
+ debugfs_root,
+ (u32 *) >clk_ctrl);
+ debugfs_create_x32("creq_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >creq_vblank);
+ debugfs_create_x32("danger_vblank",
+ 0600,
+ debugfs_root,
+ (u32 *) >danger_vblank);
+
+ return 0;
+}
+#endif
+
+
static const struct dpu_sspp_cfg *_sspp_offset(enum dpu_sspp sspp,
void __iomem *addr,
struct dpu_mdss_cfg *catalog,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index e8939d7387cb..cef281687bab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -381,6 +381,7 @@ struct dpu_hw_pipe {
struct dpu_hw_sspp_ops ops;
};
+struct dpu_kms;
/**
* dpu_hw_sspp_init - initializes the sspp hw driver object.
* Should be called once before accessing every pipe.
@@ -400,5 +401,8 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp idx,
*/
void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
+void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry *debugfs_root);
+int
[PATCH] drm/i915/guc: Request RP0 before loading firmware
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
SLPC will restore the frequency back to RPn after initialization,
but we need to manually do that for the non-SLPC path.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rps.c | 59 +++
drivers/gpu/drm/i915/gt/intel_rps.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9
drivers/gpu/drm/i915/i915_reg.h | 4 ++
4 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 07ff7ba7b2b7..4f7fe079ed4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2226,6 +2226,65 @@ u32 intel_rps_read_state_cap(struct intel_rps *rps)
return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
}
+static void intel_rps_set_manual(struct intel_rps *rps, bool enable)
+{
+ struct intel_uncore *uncore = rps_to_uncore(rps);
+ u32 state = enable ? GEN9_RPSWCTL_ENABLE : GEN9_RPSWCTL_DISABLE;
+
+ if (enable)
+ intel_rps_clear_timer(rps);
+
+ /* Allow punit to process software requests */
+ intel_uncore_write(uncore, GEN6_RP_CONTROL, state);
+
+ if (!enable)
+ intel_rps_set_timer(rps);
+}
+
+void intel_rps_raise_unslice(struct intel_rps *rps)
+{
+ struct intel_uncore *uncore = rps_to_uncore(rps);
+ u32 rp0_unslice_req;
+
+ intel_rps_set_manual(rps, true);
+
+ /* RP limits have not been read yet */
+ if (!rps->rp0_freq)
+ rp0_unslice_req = ((intel_rps_read_state_cap(rps) >> 0)
+ & 0xff) * GEN9_FREQ_SCALER;
+ else
+ rp0_unslice_req = rps->rp0_freq;
+
+ intel_uncore_write(uncore, GEN6_RPNSWREQ,
+ ((rp0_unslice_req <<
+ GEN9_SW_REQ_UNSLICE_RATIO_SHIFT) |
+ GEN9_IGNORE_SLICE_RATIO));
+
+ intel_rps_set_manual(rps, false);
+}
+
+void intel_rps_lower_unslice(struct intel_rps *rps)
+{
+ struct intel_uncore *uncore = rps_to_uncore(rps);
+ u32 rpn_unslice_req;
+
+ intel_rps_set_manual(rps, true);
+
+ /* RP limits have not been read yet */
+ if (!rps->min_freq)
+ rpn_unslice_req = ((intel_rps_read_state_cap(rps) >> 16)
+ & 0xff) * GEN9_FREQ_SCALER;
+ else
+ rpn_unslice_req = rps->min_freq;
+
+ intel_uncore_write(uncore, GEN6_RPNSWREQ,
+ ((rpn_unslice_req <<
+ GEN9_SW_REQ_UNSLICE_RATIO_SHIFT) |
+ GEN9_IGNORE_SLICE_RATIO));
+
+ intel_rps_set_manual(rps, false);
+}
+
/* External interface for intel_ips.ko */
static struct drm_i915_private __rcu *ips_mchdev;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h
b/drivers/gpu/drm/i915/gt/intel_rps.h
index aee12f37d38a..c6d76a3d1331 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -45,6 +45,8 @@ u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
u32 intel_rps_read_punit_req(struct intel_rps *rps);
u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
u32 intel_rps_read_state_cap(struct intel_rps *rps);
+void intel_rps_raise_unslice(struct intel_rps *rps);
+void intel_rps_lower_unslice(struct intel_rps *rps);
void gen5_rps_irq_handler(struct intel_rps *rps);
void gen6_rps_irq_handler(struct intel_rps *rps, u32 pm_iir);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 2fef3b0bbe95..3693c4e7dad0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -8,6 +8,7 @@
#include "intel_guc.h"
#include "intel_guc_ads.h"
#include "intel_guc_submission.h"
+#include "gt/intel_rps.h"
#include "intel_uc.h"
#include "i915_drv.h"
@@ -462,6 +463,8 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
+ intel_rps_raise_unslice(_to_gt(uc)->rps);
+
while (attempts--) {
/*
* Always reset the GuC just before (re)loading, so
@@ -499,6 +502,9 @@ static int __uc_init_hw(struct intel_uc *uc)
ret = intel_guc_slpc_enable(>slpc);
if (ret)
goto err_submission;
+ } else {
+ /* Restore GT back to RPn for non-SLPC path */
+ intel_rps_lower_unslice(_to_gt(uc)->rps);
}
drm_info(>drm, "%s firmware %s version %u.%u %s:%s\n",
@@ -529,6 +535,9 @@ static int __uc_init_hw(struct intel_uc *uc)
err_log_capture:
__uc_capture_load_err_log(uc);
err_out:
+ /* Return GT back to RPn */
+ intel_rps_lower_unslice(_to_gt(uc)->rps);
+
[PATCH] drm: Remove some useless memset
'bufs' is an array embedded in an structure (struct drm_device_dma) which
is kzalloc just a few lines above.
So there is no need to explicitly memset each element on the array. It is
already cleared.
Remove the useless memset.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/drm_dma.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/drm_dma.c
index eb6b741a6f99..df4837dc5030 100644
--- a/drivers/gpu/drm/drm_dma.c
+++ b/drivers/gpu/drm/drm_dma.c
@@ -51,8 +51,6 @@
*/
int drm_legacy_dma_setup(struct drm_device *dev)
{
- int i;
-
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA) ||
!drm_core_check_feature(dev, DRIVER_LEGACY))
return 0;
@@ -64,9 +62,6 @@ int drm_legacy_dma_setup(struct drm_device *dev)
if (!dev->dma)
return -ENOMEM;
- for (i = 0; i <= DRM_MAX_ORDER; i++)
- memset(>dma->bufs[i], 0, sizeof(dev->dma->bufs[0]));
-
return 0;
}
--
2.32.0
Re: [Freedreno] [PATCH v1 7/8] drm/msm/dpu: simplify DPU's regset32 code
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Squash dpu_debugfs_setup_regset32() into dpu_debugfs_create_regset32().
it makes little sense to have separate function to just setup the
structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 32 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 38 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 27 +---
3 files changed, 33 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 4c04982c71b2..7e7a619769a8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -182,6 +182,15 @@ static void dpu_debugfs_danger_init(struct dpu_kms
*dpu_kms,
}
+/*
+ * Companion structure for dpu_debugfs_create_regset32.
+ */
+struct dpu_debugfs_regset32 {
+ uint32_t offset;
+ uint32_t blk_len;
+ struct dpu_kms *dpu_kms;
+};
+
static int _dpu_debugfs_show_regset32(struct seq_file *s, void *data)
{
struct dpu_debugfs_regset32 *regset = s->private;
@@ -229,24 +238,23 @@ static const struct file_operations dpu_fops_regset32 = {
.release = single_release,
};
-void dpu_debugfs_setup_regset32(struct dpu_debugfs_regset32 *regset,
+void dpu_debugfs_create_regset32(const char *name, umode_t mode,
+ void *parent,
uint32_t offset, uint32_t length, struct dpu_kms *dpu_kms)
{
- if (regset) {
- regset->offset = offset;
- regset->blk_len = length;
- regset->dpu_kms = dpu_kms;
- }
-}
+ struct dpu_debugfs_regset32 *regset;
-void dpu_debugfs_create_regset32(const char *name, umode_t mode,
- void *parent, struct dpu_debugfs_regset32 *regset)
-{
- if (!name || !regset || !regset->dpu_kms || !regset->blk_len)
+ if (WARN_ON(!name || !dpu_kms || !length))
+ return;
+
+ regset = devm_kzalloc(_kms->pdev->dev, sizeof(*regset), GFP_KERNEL);
+ if (!regset)
return;
/* make sure offset is a multiple of 4 */
- regset->offset = round_down(regset->offset, 4);
+ regset->offset = round_down(offset, 4);
+ regset->blk_len = length;
+ regset->dpu_kms = dpu_kms;
debugfs_create_file(name, mode, parent, regset, _fops_regset32);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 775bcbda860f..b53cdeb1b5c4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -160,33 +160,9 @@ struct dpu_global_state
*
* Documentation/filesystems/debugfs.rst
*
- * @dpu_debugfs_setup_regset32: Initialize data for dpu_debugfs_create_regset32
* @dpu_debugfs_create_regset32: Create 32-bit register dump file
- * @dpu_debugfs_get_root: Get root dentry for DPU_KMS's debugfs node
*/
-/**
- * Companion structure for dpu_debugfs_create_regset32. Do not initialize the
- * members of this structure explicitly; use dpu_debugfs_setup_regset32
instead.
- */
-struct dpu_debugfs_regset32 {
- uint32_t offset;
- uint32_t blk_len;
- struct dpu_kms *dpu_kms;
-};
-
-/**
- * dpu_debugfs_setup_regset32 - Initialize register block definition for
debugfs
- * This function is meant to initialize dpu_debugfs_regset32 structures for use
- * with dpu_debugfs_create_regset32.
- * @regset: opaque register definition structure
- * @offset: sub-block offset
- * @length: sub-block length, in bytes
- * @dpu_kms: pointer to dpu kms structure
- */
-void dpu_debugfs_setup_regset32(struct dpu_debugfs_regset32 *regset,
- uint32_t offset, uint32_t length, struct dpu_kms *dpu_kms);
-
/**
* dpu_debugfs_create_regset32 - Create register read back file for debugfs
*
@@ -195,20 +171,16 @@ void dpu_debugfs_setup_regset32(struct
dpu_debugfs_regset32 *regset,
* names/offsets do not need to be provided. The 'read' function simply
outputs
* sequential register values over a specified range.
*
- * Similar to the related debugfs_create_regset32 API, the structure pointed to
- * by regset needs to persist for the lifetime of the created file. The calling
- * code is responsible for initialization/management of this structure.
- *
- * The structure pointed to by regset is meant to be opaque. Please use
- * dpu_debugfs_setup_regset32 to initialize it.
- *
* @name: File name within debugfs
* @mode: File mode within debugfs
* @parent: Parent directory entry within debugfs, can be NULL
- * @regset: Pointer to persistent register block definition
+ * @offset: sub-block offset
+ * @length: sub-block length, in bytes
+ * @dpu_kms: pointer to dpu kms structure
*/
void dpu_debugfs_create_regset32(const char *name, umode_t mode,
- void *parent, struct dpu_debugfs_regset32 *regset);
+
[PATCH v4 RESEND 2/2] drm: Add orientation quirk for GPD Win Max
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Signed-off-by: Anisse Astier
Reviewed-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 042bb80383c9..3dc383b1e2ba 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -174,6 +174,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* GPD Win Max */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1619-01"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.31.1
[PATCH v4 RESEND 1/2] drm/i915/opregion: add support for mailbox #5 EDID
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Fixes the GPD Win Max display.
Based on original patch series by: Jani Nikula
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
Changes:
- EDID is copied and validated with drm_edid_is_valid
- EDID is now only used as a fallback.
- squashed the two patches
Cc: Jani Nikula
Cc: Uma Shankar
Cc: Ville Syrjälä
Co-developed-by: Jani Nikula
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++
drivers/gpu/drm/i915/display/intel_opregion.c | 55 ++-
drivers/gpu/drm/i915/display/intel_opregion.h | 10
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a424bf69396..a3c64125405e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4962,6 +4962,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
mutex_lock(>mode_config.mutex);
edid = drm_get_edid(connector, _dp->aux.ddc);
+ if (!edid) {
+ /* Fallback to EDID from ACPI OpRegion, if any */
+ edid = intel_opregion_get_edid(intel_connector);
+ if (edid)
+ drm_dbg_kms(_priv->drm,
+ "[CONNECTOR:%d:%s] Using OpRegion EDID\n",
+ connector->base.id, connector->name);
+ }
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_connector_update_edid_property(connector, edid);
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index 0065111593a6..985790a66a4d 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -195,6 +195,8 @@ struct opregion_asle_ext {
#define ASLE_IUER_WINDOWS_BTN (1 << 1)
#define ASLE_IUER_POWER_BTN(1 << 0)
+#define ASLE_PHED_EDID_VALID_MASK 0x3
+
/* Software System Control Interrupt (SWSCI) */
#define SWSCI_SCIC_INDICATOR (1 << 0)
#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
@@ -908,8 +910,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
}
- if (mboxes & MBOX_ASLE_EXT)
+ if (mboxes & MBOX_ASLE_EXT) {
drm_dbg(_priv->drm, "ASLE extension supported\n");
+ opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
+ }
if (intel_load_vbt_firmware(dev_priv) == 0)
goto out;
@@ -1036,6 +1040,54 @@ intel_opregion_get_panel_type(struct drm_i915_private
*dev_priv)
return ret - 1;
}
+/**
+ * intel_opregion_get_edid - Fetch EDID from ACPI OpRegion mailbox #5
+ * @intel_connector: eDP connector
+ *
+ * This reads the ACPI Opregion mailbox #5 to extract the EDID that is passed
+ * to it.
+ *
+ * Returns:
+ * The EDID in the OpRegion, or NULL if there is none or it's invalid.
+ *
+ */
+struct edid *intel_opregion_get_edid(struct intel_connector *intel_connector)
+{
+ struct drm_connector *connector = _connector->base;
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_opregion *opregion = >opregion;
+ const void *in_edid;
+ const struct edid *edid;
+ struct edid *new_edid;
+ int len;
+
+ if (!opregion->asle_ext)
+ return NULL;
+
+ in_edid = opregion->asle_ext->bddc;
+
+ /* Validity corresponds to number of 128-byte blocks */
+ len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
+ if (!len || !memchr_inv(in_edid, 0, len))
+ return NULL;
+
+ edid = in_edid;
+
+ if (len < EDID_LENGTH * (1 + edid->extensions)) {
+ drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5): too short\n");
+ return NULL;
+ }
+ new_edid = drm_edid_duplicate(edid);
+ if (!new_edid)
+ return NULL;
+ if (!drm_edid_is_valid(new_edid)) {
+ kfree(new_edid);
+ drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5)\n");
+ return NULL;
+ }
+ return new_edid;
+}
+
void intel_opregion_register(struct drm_i915_private *i915)
{
struct intel_opregion *opregion = >opregion;
@@ -1129,6 +1181,7 @@ void intel_opregion_unregister(struct drm_i915_private
*i915)
opregion->acpi = NULL;
opregion->swsci = NULL;
opregion->asle = NULL;
+
[PATCH v4 RESEND 0/2] GPD Win Max display fixes
This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The second patch is just to fix the orientation of the panel. Changes since v1: - rebased on drm-tip - squashed patch 1 & 2 - picked up Reviewed-by from Hans de Goede (thanks for the review) Changes since v2: - rebased on drm-tip - updated commit message When v2 was initially sent [3] Ville Syrjälä suggested that it might be a good idea to use the ACPI _DDC method instead to get the EDID, to cover a wider range of hardware. Unfortunately, it doesn't seem available on GPD Win Max, so I think this work should be done independently, and this patch series considered separately. Change since v3: - edits following Jani's review: - The EDID from the opregion is now only used as a fallback: if we cannot get any edid from the edp connector, then we attempt to get it from the opregion. This works for the GPD Win Max. - all other remarks should have been taken into account - rebased on drm-tip - added Co-developed-by - reordered signed-off-by and reviewed-by in second patch (thanks Maarten!) [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454 [2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/ [3]: https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-ani...@astier.eu/ Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max .../gpu/drm/drm_panel_orientation_quirks.c| 6 ++ drivers/gpu/drm/i915/display/intel_dp.c | 7 +++ drivers/gpu/drm/i915/display/intel_opregion.c | 55 ++- drivers/gpu/drm/i915/display/intel_opregion.h | 10 4 files changed, 77 insertions(+), 1 deletion(-) -- 2.31.1
Re: [PATCH v11 0/8] MIPS: JZ4780 and CI20 HDMI
On Thu, Dec 02, 2021 at 07:39:45PM +0100, H. Nikolaus Schaller wrote: > [..] > This series adds HDMI support for JZ4780 and CI20 board > > > > H. Nikolaus Schaller (3): > drm/ingenic: prepare ingenic drm for later addition of JZ4780 > MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780 > [RFC] MIPS: DTS: Ingenic: adjust register size to available registers > > Paul Boddie (4): > drm/ingenic: Add support for JZ4780 and HDMI output > drm/ingenic: Add dw-hdmi driver for jz4780 > MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD > controllers > MIPS: DTS: CI20: Add DT nodes for HDMI setup > > Sam Ravnborg (1): > dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema > > .../display/bridge/ingenic,jz4780-hdmi.yaml | 78 ++ > .../display/bridge/synopsys,dw-hdmi.yaml | 3 + > arch/mips/boot/dts/ingenic/ci20.dts | 72 +- > arch/mips/boot/dts/ingenic/jz4725b.dtsi | 2 +- > arch/mips/boot/dts/ingenic/jz4740.dtsi| 2 +- > arch/mips/boot/dts/ingenic/jz4770.dtsi| 2 +- > arch/mips/boot/dts/ingenic/jz4780.dtsi| 40 ++ > arch/mips/configs/ci20_defconfig | 6 + > drivers/gpu/drm/ingenic/Kconfig | 9 ++ > drivers/gpu/drm/ingenic/Makefile | 1 + > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 62 +++- > drivers/gpu/drm/ingenic/ingenic-drm.h | 38 + > drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 136 ++ > 13 files changed, 443 insertions(+), 8 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml > create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c applied patches 5-8 to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH v7 2/2] drm/msm/dp: do not initialize phy until plugin interrupt received
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume (including booting up), dongle plugin, dongle unplugged and suspend.
Regulators, core clocks and irq are grouped together and enabled at resume
(or booting up) so that the DP controller is armed and ready to receive HPD
plugin interrupts. HPD plugin interrupt is generated when a dongle plugs
into DUT (device under test). Once HPD plugin interrupt is received, DP
controller will initialize phy so that dpcd read/write will function and
following link training can be proceeded successfully. DP phy will be
disabled after main link is teared down at end of unplugged HPD interrupt
handle triggered by dongle unplugged out of DUT. Finally regulators, code
clocks and irq are disabled at corresponding suspension.
Changes in V2:
-- removed unnecessary dp_ctrl NULL check
-- removed unnecessary phy init_count and power_count DRM_DEBUG_DP logs
-- remove flip parameter out of dp_ctrl_irq_enable()
-- add fixes tag
Changes in V3:
-- call dp_display_host_phy_init() instead of dp_ctrl_phy_init() at
dp_display_host_init() for eDP
Changes in V4:
-- rewording commit text to match this commit changes
Changes in V5:
-- rebase on top of msm-next branch
Changes in V6:
-- delete flip variable
Changes in V7:
-- dp_ctrl_irq_enable/disabe() merged into dp_ctrl_reset_irq_ctrl()
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 77 --
drivers/gpu/drm/msm/dp/dp_ctrl.h| 8 ++--
drivers/gpu/drm/msm/dp/dp_display.c | 84 ++---
3 files changed, 92 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index c724cb0..39558a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1365,60 +1365,44 @@ static int dp_ctrl_enable_stream_clocks(struct
dp_ctrl_private *ctrl)
return ret;
}
-int dp_ctrl_host_init(struct dp_ctrl *dp_ctrl, bool flip, bool reset)
+void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable)
+{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ dp_catalog_ctrl_reset(ctrl->catalog);
+
+ if (enable)
+ dp_catalog_ctrl_enable_irq(ctrl->catalog, enable);
+}
+
+void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return -EINVAL;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = >parser->io;
phy = dp_io->phy;
- ctrl->dp_ctrl.orientation = flip;
-
- if (reset)
- dp_catalog_ctrl_reset(ctrl->catalog);
-
- DRM_DEBUG_DP("flip=%d\n", flip);
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_init(phy);
- dp_catalog_ctrl_enable_irq(ctrl->catalog, true);
-
- return 0;
}
-/**
- * dp_ctrl_host_deinit() - Uninitialize DP controller
- * @dp_ctrl: Display Port Driver data
- *
- * Perform required steps to uninitialize DP controller
- * and its resources.
- */
-void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
+void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
struct dp_io *dp_io;
struct phy *phy;
- if (!dp_ctrl) {
- DRM_ERROR("Invalid input data\n");
- return;
- }
-
ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
dp_io = >parser->io;
phy = dp_io->phy;
- dp_catalog_ctrl_enable_irq(ctrl->catalog, false);
+ dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_exit(phy);
-
- DRM_DEBUG_DP("Host deinitialized successfully\n");
}
static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
@@ -1893,8 +1877,14 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
return ret;
}
+ DRM_DEBUG_DP("Before, phy=%x init_count=%d power_on=%d\n",
+ (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
+
phy_power_off(phy);
+ DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
+ (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
+
/* aux channel down, reinit phy */
phy_exit(phy);
phy_init(phy);
@@ -1903,23 +1893,6 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
return ret;
}
-void dp_ctrl_off_phy(struct dp_ctrl *dp_ctrl)
-{
- struct dp_ctrl_private *ctrl;
- struct dp_io *dp_io;
- struct phy
[PATCH v7 1/2] drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read failed
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged. Also make
sure dp controller had been initialized before start dpcd read and write.
Changes in V4:
-- split this patch as stand alone patch
Changes in v5:
-- rebase on msm-next branch
Changes in v6:
-- add more details commit text
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 12 +---
drivers/gpu/drm/msm/dp/dp_link.c| 19 ++-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3d61459..0766752 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -692,9 +692,15 @@ static int dp_irq_hpd_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
- ret = dp_display_usbpd_attention_cb(>pdev->dev);
- if (ret == -ECONNRESET) { /* cable unplugged */
- dp->core_initialized = false;
+ /*
+* dp core (ahb/aux clks) must be initialized before
+* irq_hpd be handled
+*/
+ if (dp->core_initialized) {
+ ret = dp_display_usbpd_attention_cb(>pdev->dev);
+ if (ret == -ECONNRESET) { /* cable unplugged */
+ dp->core_initialized = false;
+ }
}
DRM_DEBUG_DP("hpd_state=%d\n", state);
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index a5bdfc5..d4d31e5 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct dp_link
*dp_link)
return 0;
}
-static void dp_link_parse_sink_status_field(struct dp_link_private *link)
+static int dp_link_parse_sink_status_field(struct dp_link_private *link)
{
int len = 0;
link->prev_sink_count = link->dp_link.sink_count;
- dp_link_parse_sink_count(>dp_link);
+ len = dp_link_parse_sink_count(>dp_link);
+ if (len < 0) {
+ DRM_ERROR("DP parse sink count failed\n");
+ return len;
+ }
len = drm_dp_dpcd_read_link_status(link->aux,
link->link_status);
- if (len < DP_LINK_STATUS_SIZE)
+ if (len < DP_LINK_STATUS_SIZE) {
DRM_ERROR("DP link status read failed\n");
- dp_link_parse_request(link);
+ return len;
+ }
+
+ return dp_link_parse_request(link);
}
/**
@@ -1023,7 +1030,9 @@ int dp_link_process_request(struct dp_link *dp_link)
dp_link_reset_data(link);
- dp_link_parse_sink_status_field(link);
+ ret = dp_link_parse_sink_status_field(link);
+ if (ret)
+ return ret;
if (link->request.test_requested == DP_TEST_LINK_EDID_READ) {
dp_link->sink_request |= DP_TEST_LINK_EDID_READ;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
Hi On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach wrote: > > Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno > Trimarchi: > > Hi Tim > > > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote: > > > > > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi > > > wrote: > > > > > > > > Hi Tim > > > > > > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey > > > > wrote: > > > > > > > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > > > > > wrote: > > > > > > > > > > > > Hi Sam, > > > > > > > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg > > > > > > wrote: > > > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI > > > > > > > > devices. > > > > > > > > > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > > > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > > > > > >users like i.MX8MM. > > > > > > > > > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > > > > > component_ops and fixing exynos specific code in order to make > > > > > > > > the bridge more mature to use and the same is mentioned in > > > > > > > > drivers TODO. > > > > > > > > > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > > > > > > > > > Anyone interest, please have a look on this repo > > > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > > > > > the exynos platform? > > > > > > > > > > > > > > > > Any inputs? > > > > > > > > > > > > > > I really like where you are headign with this! > > > > > > > No testing - sorry. But I will try to provide a bit of feedback > > > > > > > on the > > > > > > > individual patches. > > > > > > > > > > > > > > I hope you find a way to move forward with this. > > > > > > > > > > > > Thanks for the response. > > > > > > > > > > > > We have found some issues with Bridge conversion on existing exynos > > > > > > drivers. The component based DSI drivers(like exynos) are difficult > > > > > > to > > > > > > attach if it involves kms hotplug. kms hotplug would require drm > > > > > > pointer and that pointer would only available after the bind call > > > > > > finishes. But the bridge attach in bind call will defer till it find > > > > > > the attached bridge. > > > > > > > > > > > > Right now I'm trying to find the proper way to attach the bridges > > > > > > for > > > > > > component based DSI drivers which involves kms hot-plug. > > > > > > > > > > > > If you have any ideas on this, please let me know. > > > > > > > > > > > > > > > > Jagan, > > > > > > > > > > How is your progress on this series? Looking at your repo it looks > > > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > > > > > branch but you've got a lot of things there that are likely not > > > > > related to this series? > > > > > > > > I have a bit of work on those patches and tested on imx8mn. Basically: > > > > > > > > - add the dsi timing calculation > > > > - change few difference with samsung bridge > > > > - fix crashes of my dsi panels > > > > - compare with NXP driver the final results > > > > > > > > I found that I have one problem that gives me some instability. In the > > > > NXP original driver the panel needs to be > > > > enabled in bridge_enable before out the standby. If I understand > > > > correctly, our standby should be done after. > > > > I would like to have some feedback and help and testing on other > > > > boards/devices and some suggestions on how to handle > > > > some of the differences. Another big problem is etnavi that is not > > > > stable > > > > > > > > > > Michael, > > > > > > Where can I find your patches? > > > > > > > I will push on some tree and share > > > > > What do you mean by etnaviv not being stable? > > > > > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi > > > > > > > > > patches on an Ubuntu focal root filesystem by: > > > apt update > > > apt install gnome-session gnome-terminal > > > ^^^ 2D hardware acceleration appears to be working (dragging opaque > > > windows around) > > > apt install mesa-utils glmark2 > > > glxgears > > > ^^^ ~160fps on IMX8MM > > > glmark2 > > > ^^^ score of 39 on IMX8MM > > > > > > I haven't seen any updates from Jagan since Nov 24 > > >
Re: [Freedreno] [PATCH v1 6/8] drm/msm/dpu: stop manually removing debugfs files for the DPU CRTC
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
DRM code handles removing all debugfs recursively. Drop CRTC-specific
code to perform that.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 15 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ---
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d290809d59bd..9899f7424131 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1424,15 +1424,16 @@ DEFINE_SHOW_ATTRIBUTE(dpu_crtc_debugfs_state);
static int _dpu_crtc_init_debugfs(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
+ struct dentry *debugfs_root;
- dpu_crtc->debugfs_root = debugfs_create_dir(dpu_crtc->name,
+ debugfs_root = debugfs_create_dir(dpu_crtc->name,
crtc->dev->primary->debugfs_root);
debugfs_create_file("status", 0400,
- dpu_crtc->debugfs_root,
+ debugfs_root,
dpu_crtc, &_dpu_debugfs_status_fops);
debugfs_create_file("state", 0600,
- dpu_crtc->debugfs_root,
+ debugfs_root,
_crtc->base,
_crtc_debugfs_state_fops);
@@ -1450,13 +1451,6 @@ static int dpu_crtc_late_register(struct drm_crtc *crtc)
return _dpu_crtc_init_debugfs(crtc);
}
-static void dpu_crtc_early_unregister(struct drm_crtc *crtc)
-{
- struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
-
- debugfs_remove_recursive(dpu_crtc->debugfs_root);
-}
-
static const struct drm_crtc_funcs dpu_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = dpu_crtc_destroy,
@@ -1465,7 +1459,6 @@ static const struct drm_crtc_funcs dpu_crtc_funcs = {
.atomic_duplicate_state = dpu_crtc_duplicate_state,
.atomic_destroy_state = dpu_crtc_destroy_state,
.late_register = dpu_crtc_late_register,
- .early_unregister = dpu_crtc_early_unregister,
.verify_crc_source = dpu_crtc_verify_crc_source,
.set_crc_source = dpu_crtc_set_crc_source,
.enable_vblank = msm_crtc_enable_vblank,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 4328e133d71c..b8785c394fcc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -129,7 +129,6 @@ struct dpu_crtc_frame_event {
* @drm_requested_vblank : Whether vblanks have been enabled in the encoder
* @property_info : Opaque structure for generic property support
* @property_defaults : Array of default values for generic property support
- * @debugfs_root : Parent of debugfs node
* @vblank_cb_count : count of vblank callback since last reset
* @play_count: frame count between crtc enable and disable
* @vblank_cb_time : ktime at vblank count reset
@@ -160,8 +159,6 @@ struct dpu_crtc {
struct drm_pending_vblank_event *event;
u32 vsync_count;
- struct dentry *debugfs_root;
-
u32 vblank_cb_count;
u64 play_count;
ktime_t vblank_cb_time;
Re: [PATCH v1 5/8] drm/msm/dpu: stop manually removing debugfs files for the DPU plane
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
DRM code handles removing all debugfs recursively. Drop plane-specific
code to perform that.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 28 ---
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f80ee3ba9a8a..d3176f58708e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -110,7 +110,6 @@ struct dpu_plane {
struct dpu_mdss_cfg *catalog;
/* debugfs related stuff */
- struct dentry *debugfs_root;
struct dpu_debugfs_regset32 debugfs_src;
struct dpu_debugfs_regset32 debugfs_scaler;
struct dpu_debugfs_regset32 debugfs_csc;
@@ -1368,15 +1367,16 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
struct dpu_kms *kms = _dpu_plane_get_kms(plane);
const struct dpu_sspp_cfg *cfg = pdpu->pipe_hw->cap;
const struct dpu_sspp_sub_blks *sblk = cfg->sblk;
+ struct dentry *debugfs_root;
/* create overall sub-directory for the pipe */
- pdpu->debugfs_root =
+ debugfs_root =
debugfs_create_dir(plane->name,
plane->dev->primary->debugfs_root);
/* don't error check these */
debugfs_create_xul("features", 0600,
- pdpu->debugfs_root, (unsigned long
*)>pipe_hw->cap->features);
+ debugfs_root, (unsigned long
*)>pipe_hw->cap->features);
/* add register dump support */
dpu_debugfs_setup_regset32(>debugfs_src,
@@ -1384,7 +1384,7 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
sblk->src_blk.len,
kms);
dpu_debugfs_create_regset32("src_blk", 0400,
- pdpu->debugfs_root, >debugfs_src);
+ debugfs_root, >debugfs_src);
if (cfg->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
cfg->features & BIT(DPU_SSPP_SCALER_QSEED3LITE) ||
@@ -1395,7 +1395,7 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
sblk->scaler_blk.len,
kms);
dpu_debugfs_create_regset32("scaler_blk", 0400,
- pdpu->debugfs_root,
+ debugfs_root,
>debugfs_scaler);
}
@@ -1406,24 +1406,24 @@ static int _dpu_plane_init_debugfs(struct drm_plane *plane)
sblk->csc_blk.len,
kms);
dpu_debugfs_create_regset32("csc_blk", 0400,
- pdpu->debugfs_root, >debugfs_csc);
+ debugfs_root, >debugfs_csc);
}
debugfs_create_u32("xin_id",
0400,
- pdpu->debugfs_root,
+ debugfs_root,
(u32 *) >xin_id);
debugfs_create_u32("clk_ctrl",
0400,
- pdpu->debugfs_root,
+ debugfs_root,
(u32 *) >clk_ctrl);
debugfs_create_x32("creq_vblank",
0600,
- pdpu->debugfs_root,
+ debugfs_root,
(u32 *) >creq_vblank);
debugfs_create_x32("danger_vblank",
0600,
- pdpu->debugfs_root,
+ debugfs_root,
(u32 *) >danger_vblank);
return 0;
@@ -1440,13 +1440,6 @@ static int dpu_plane_late_register(struct drm_plane
*plane)
return _dpu_plane_init_debugfs(plane);
}
-static void dpu_plane_early_unregister(struct drm_plane *plane)
-{
- struct dpu_plane *pdpu = to_dpu_plane(plane);
-
- debugfs_remove_recursive(pdpu->debugfs_root);
-}
-
static bool dpu_plane_format_mod_supported(struct drm_plane *plane,
uint32_t format, uint64_t modifier)
{
@@ -1472,7 +1465,6 @@ static const struct drm_plane_funcs dpu_plane_funcs = {
.atomic_duplicate_state = dpu_plane_duplicate_state,
.atomic_destroy_state = dpu_plane_destroy_state,
.late_register = dpu_plane_late_register,
- .early_unregister = dpu_plane_early_unregister,
.format_mod_supported = dpu_plane_format_mod_supported,
};
Re: [Freedreno] [PATCH v1 4/8] drm/msm/dpu: drop plane's default_scaling debugfs file
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Proper support for the 'default_scaling' debugfs file was removed during
DPU driver pre-merge cleanup. Remove leftover file.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 6ea4db061c9f..f80ee3ba9a8a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -114,7 +114,6 @@ struct dpu_plane {
struct dpu_debugfs_regset32 debugfs_src;
struct dpu_debugfs_regset32 debugfs_scaler;
struct dpu_debugfs_regset32 debugfs_csc;
- bool debugfs_default_scale;
};
static const uint64_t supported_format_modifiers[] = {
@@ -1398,10 +1397,6 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
dpu_debugfs_create_regset32("scaler_blk", 0400,
pdpu->debugfs_root,
>debugfs_scaler);
- debugfs_create_bool("default_scaling",
- 0600,
- pdpu->debugfs_root,
- >debugfs_default_scale);
}
if (cfg->features & BIT(DPU_SSPP_CSC) ||
Re: [PATCH v1 3/8] drm/msm/dpu: make danger_status/safe_status readable
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote: Change \t to \n in the print format to stop putting all SSPP status in a single line. Splitting it to one SSPP per line is much more readable. Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index e7f0cded2c6b..4c04982c71b2 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -82,7 +82,7 @@ static int _dpu_danger_signal_status(struct seq_file *s, seq_printf(s, "MDP : 0x%x\n", status.mdp); for (i = SSPP_VIG0; i < SSPP_MAX; i++) - seq_printf(s, "SSPP%d : 0x%x \t", i - SSPP_VIG0, + seq_printf(s, "SSPP%d : 0x%x \n", i - SSPP_VIG0, status.sspp[i]); seq_puts(s, "\n");
Re: [Freedreno] [PATCH v1 2/8] drm/msm/dpu: fix safe status debugfs file
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
Make safe_status debugfs fs file actually return safe status rather than
danger status data.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 259d438bc6e8..e7f0cded2c6b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -73,8 +73,8 @@ static int _dpu_danger_signal_status(struct seq_file *s,
);
} else {
seq_puts(s, "\nSafe signal status:\n");
- if (kms->hw_mdp->ops.get_danger_status)
- kms->hw_mdp->ops.get_danger_status(kms->hw_mdp,
+ if (kms->hw_mdp->ops.get_safe_status)
+ kms->hw_mdp->ops.get_safe_status(kms->hw_mdp,
);
}
pm_runtime_put_sync(>pdev->dev);
Re: [Freedreno] [PATCH v1 1/8] drm/msm/dpu: move disable_danger out of plane subdir
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
The disable_danger debugfs file is not related to a single plane.
Instead it is used by all registered planes. Move it from plane subtree
to the global subtree next to danger_status and safe_status files,
so that the new file supplements them.
the danger_safe itself is a per-plane feature as each SSPP can be
controlled individually.
In todays code, yes we do it for all the active planes together.
Since this is the same behavior
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 70 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 74 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 ++
3 files changed, 77 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 6c457c419412..259d438bc6e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -101,6 +101,73 @@ static int dpu_debugfs_safe_stats_show(struct seq_file *s,
void *v)
}
DEFINE_SHOW_ATTRIBUTE(dpu_debugfs_safe_stats);
+static ssize_t _dpu_plane_danger_read(struct file *file,
+ char __user *buff, size_t count, loff_t *ppos)
+{
+ struct dpu_kms *kms = file->private_data;
+ int len;
+ char buf[40];
+
+ len = scnprintf(buf, sizeof(buf), "%d\n", !kms->has_danger_ctrl);
+
+ return simple_read_from_buffer(buff, count, ppos, buf, len);
+}
+
+static void _dpu_plane_set_danger_state(struct dpu_kms *kms, bool enable)
+{
+ struct drm_plane *plane;
+
+ drm_for_each_plane(plane, kms->dev) {
+ if (plane->fb && plane->state) {
+ dpu_plane_danger_signal_ctrl(plane, enable);
+ DPU_DEBUG("plane:%d img:%dx%d ",
+ plane->base.id, plane->fb->width,
+ plane->fb->height);
+ DPU_DEBUG("src[%d,%d,%d,%d] dst[%d,%d,%d,%d]\n",
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->crtc_x, plane->state->crtc_y,
+ plane->state->crtc_w, plane->state->crtc_h);
+ } else {
+ DPU_DEBUG("Inactive plane:%d\n", plane->base.id);
+ }
+ }
+}
+
+static ssize_t _dpu_plane_danger_write(struct file *file,
+ const char __user *user_buf, size_t count, loff_t *ppos)
+{
+ struct dpu_kms *kms = file->private_data;
+ int disable_panic;
+ int ret;
+
+ ret = kstrtouint_from_user(user_buf, count, 0, _panic);
+ if (ret)
+ return ret;
+
+ if (disable_panic) {
+ /* Disable panic signal for all active pipes */
+ DPU_DEBUG("Disabling danger:\n");
+ _dpu_plane_set_danger_state(kms, false);
+ kms->has_danger_ctrl = false;
+ } else {
+ /* Enable panic signal for all active pipes */
+ DPU_DEBUG("Enabling danger:\n");
+ kms->has_danger_ctrl = true;
+ _dpu_plane_set_danger_state(kms, true);
+ }
+
+ return count;
+}
+
+static const struct file_operations dpu_plane_danger_enable = {
+ .open = simple_open,
+ .read = _dpu_plane_danger_read,
+ .write = _dpu_plane_danger_write,
+};
+
static void dpu_debugfs_danger_init(struct dpu_kms *dpu_kms,
struct dentry *parent)
{
@@ -110,6 +177,9 @@ static void dpu_debugfs_danger_init(struct dpu_kms *dpu_kms,
dpu_kms, _debugfs_danger_stats_fops);
debugfs_create_file("safe_status", 0600, entry,
dpu_kms, _debugfs_safe_stats_fops);
+ debugfs_create_file("disable_danger", 0600, entry,
+ dpu_kms, _plane_danger_enable);
+
}
static int _dpu_debugfs_show_regset32(struct seq_file *s, void *data)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ca190d92f0d5..6ea4db061c9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1350,7 +1350,7 @@ static void dpu_plane_reset(struct drm_plane *plane)
}
#ifdef CONFIG_DEBUG_FS
-static void dpu_plane_danger_signal_ctrl(struct drm_plane *plane, bool enable)
+void dpu_plane_danger_signal_ctrl(struct drm_plane *plane, bool enable)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
@@ -1363,73 +1363,6 @@ static void dpu_plane_danger_signal_ctrl(struct
drm_plane *plane, bool enable)
pm_runtime_put_sync(_kms->pdev->dev);
}
-static ssize_t
Re: [PATCH v4 0/6] Expand display core documentation
> Thanks for this. It's really good to see this.
>
> Reviewed-by: Harry Wentland
Hearfully seconded, let's get this rolling :)
Reviewed-by: Yann Dirson
>
> Harry
>
> On 2021-12-09 09:20, Rodrigo Siqueira wrote:
> > Display Core (DC) is one of the components under amdgpu, and it has
> > multiple features directly related to the KMS API. Unfortunately,
> > we
> > don't have enough documentation about DC in the upstream, which
> > makes
> > the life of some external contributors a little bit more
> > challenging.
> > For these reasons, this patchset reworks part of the DC
> > documentation
> > and introduces a new set of details on how the display core works
> > on DCN
> > IP. Another improvement that this documentation effort tries to
> > bring is
> > making explicit some of our hardware-specific details to guide
> > user-space developers better.
> >
> > In my view, it is easier to review this series if you apply it in
> > your
> > local kernel and build the HTML version (make htmldocs). I'm
> > suggesting
> > this approach because I added a few SVG diagrams that will be
> > easier to
> > see in the HTML version. If you cannot build the documentation, try
> > to
> > open the SVG images while reviewing the content. In summary, in
> > this
> > series, you will find:
> >
> > 1. Patch 1: Re-arrange of display core documentation. This is
> >preparation work for the other patches, but it is also a way to
> >expand
> >this documentation.
> > 2. Patch 2 to 4: Document some common debug options related to
> > display.
> > 3. Patch 5: This patch provides an overview of how our display core
> > next
> >works and a brief explanation of each component.
> > 4. Patch 6: We use a lot of acronyms in our driver; for this
> > reason, we
> >exposed a glossary with common terms used by display core.
> >
> > Please let us know what you think we can improve this series and
> > what
> > kind of content you want to see for the next series.
> >
> > Changes since V3:
> > - Add new acronyms to amdgpu glossary
> > - Add link between dc and amdgpu glossary
> > Changes since V2:
> > - Add a comment about MMHUBBUB
> > Changes since V1:
> > - Group amdgpu documentation together.
> > - Create index pages.
> > - Mirror display folder in the documentation.
> > - Divide glossary based on driver context.
> > - Make terms more consistent and update CPLIB
> > - Add new acronyms to the glossary
> >
> > Thanks
> > Siqueira
> >
> > Rodrigo Siqueira (6):
> > Documentation/gpu: Reorganize DC documentation
> > Documentation/gpu: Document amdgpu_dm_visual_confirm debugfs
> > entry
> > Documentation/gpu: Document pipe split visual confirmation
> > Documentation/gpu: How to collect DTN log
> > Documentation/gpu: Add basic overview of DC pipeline
> > Documentation/gpu: Add amdgpu and dc glossary
> >
> > Documentation/gpu/amdgpu-dc.rst | 74 --
> > Documentation/gpu/amdgpu/amdgpu-glossary.rst | 87 ++
> > .../gpu/amdgpu/display/config_example.svg | 414 ++
> > Documentation/gpu/amdgpu/display/dc-debug.rst | 77 ++
> > .../gpu/amdgpu/display/dc-glossary.rst| 237
> > .../amdgpu/display/dc_pipeline_overview.svg | 1125
> > +
> > .../gpu/amdgpu/display/dcn-overview.rst | 171 +++
> > .../gpu/amdgpu/display/display-manager.rst| 42 +
> > .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++
> > Documentation/gpu/amdgpu/display/index.rst| 29 +
> > .../gpu/{amdgpu.rst => amdgpu/index.rst} | 25 +-
> > Documentation/gpu/drivers.rst |3 +-
> > 12 files changed, 2690 insertions(+), 79 deletions(-)
> > delete mode 100644 Documentation/gpu/amdgpu-dc.rst
> > create mode 100644 Documentation/gpu/amdgpu/amdgpu-glossary.rst
> > create mode 100644
> > Documentation/gpu/amdgpu/display/config_example.svg
> > create mode 100644 Documentation/gpu/amdgpu/display/dc-debug.rst
> > create mode 100644
> > Documentation/gpu/amdgpu/display/dc-glossary.rst
> > create mode 100644
> > Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg
> > create mode 100644
> > Documentation/gpu/amdgpu/display/dcn-overview.rst
> > create mode 100644
> > Documentation/gpu/amdgpu/display/display-manager.rst
> > create mode 100644
> > Documentation/gpu/amdgpu/display/global_sync_vblank.svg
> > create mode 100644 Documentation/gpu/amdgpu/display/index.rst
> > rename Documentation/gpu/{amdgpu.rst => amdgpu/index.rst} (95%)
> >
>
>
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno Trimarchi: > Hi Tim > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote: > > > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi > > wrote: > > > > > > Hi Tim > > > > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote: > > > > > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > > > > wrote: > > > > > > > > > > Hi Sam, > > > > > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg > > > > > wrote: > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > > > > >users like i.MX8MM. > > > > > > > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > > > > component_ops and fixing exynos specific code in order to make > > > > > > > the bridge more mature to use and the same is mentioned in > > > > > > > drivers TODO. > > > > > > > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > > > > > > > Anyone interest, please have a look on this repo > > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > > > > the exynos platform? > > > > > > > > > > > > > > Any inputs? > > > > > > > > > > > > I really like where you are headign with this! > > > > > > No testing - sorry. But I will try to provide a bit of feedback on > > > > > > the > > > > > > individual patches. > > > > > > > > > > > > I hope you find a way to move forward with this. > > > > > > > > > > Thanks for the response. > > > > > > > > > > We have found some issues with Bridge conversion on existing exynos > > > > > drivers. The component based DSI drivers(like exynos) are difficult to > > > > > attach if it involves kms hotplug. kms hotplug would require drm > > > > > pointer and that pointer would only available after the bind call > > > > > finishes. But the bridge attach in bind call will defer till it find > > > > > the attached bridge. > > > > > > > > > > Right now I'm trying to find the proper way to attach the bridges for > > > > > component based DSI drivers which involves kms hot-plug. > > > > > > > > > > If you have any ideas on this, please let me know. > > > > > > > > > > > > > Jagan, > > > > > > > > How is your progress on this series? Looking at your repo it looks > > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > > > > branch but you've got a lot of things there that are likely not > > > > related to this series? > > > > > > I have a bit of work on those patches and tested on imx8mn. Basically: > > > > > > - add the dsi timing calculation > > > - change few difference with samsung bridge > > > - fix crashes of my dsi panels > > > - compare with NXP driver the final results > > > > > > I found that I have one problem that gives me some instability. In the > > > NXP original driver the panel needs to be > > > enabled in bridge_enable before out the standby. If I understand > > > correctly, our standby should be done after. > > > I would like to have some feedback and help and testing on other > > > boards/devices and some suggestions on how to handle > > > some of the differences. Another big problem is etnavi that is not stable > > > > > > > Michael, > > > > Where can I find your patches? > > > > I will push on some tree and share > > > What do you mean by etnaviv not being stable? > > > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi > > > > > patches on an Ubuntu focal root filesystem by: > > apt update > > apt install gnome-session gnome-terminal > > ^^^ 2D hardware acceleration appears to be working (dragging opaque > > windows around) > > apt install mesa-utils glmark2 > > glxgears > > ^^^ ~160fps on IMX8MM > > glmark2 > > ^^^ score of 39 on IMX8MM > > > > I haven't seen any updates from Jagan since Nov 24 > > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not > > sure if he's been able to work through drm/exynos issues that have > > been blocking his progress. > > I plan to push on github > > [17:07:42.315] Sending ready to systemd > [ 214.052085] etnaviv-gpu 3800.gpu: recover hung GPU! > [ 214.595998] etnaviv-gpu
Re: [PATCH] drm/i915/guc: Remove racey GEM_BUG_ON
On 12/9/2021 11:57 AM, Matthew Brost wrote:
On Thu, Dec 09, 2021 at 11:26:09AM -0800, Daniele Ceraolo Spurio wrote:
On 12/9/2021 10:51 AM, Matthew Brost wrote:
A full GT can race with the last context put resulting in the context
forgot to mention earlier but you're missing "reset" here
ref count being zero but the destroyed bit not yet being set. Remove
GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 --
1 file changed, 2 deletions(-)
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 9b7b4f4e0d91..0f99bb83293a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1040,8 +1040,6 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
spin_unlock(>guc_state.lock);
- GEM_BUG_ON(!do_put && !destroyed);
-
Do we need to re-queue/flush the destroyer work to make sure it runs before
we reset, or is it ok for that to run in parallel?
The code in the put path will either see the reset or that it isn't
registered and destroy the context without any interaction with the GuC.
ok.
Reviewed-by: Daniele Ceraolo Spurio
Daniele
Matt
Daniele
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
if (deregister)
Re: [PATCH] drm/i915/guc: Remove racey GEM_BUG_ON
On Thu, Dec 09, 2021 at 11:26:09AM -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 12/9/2021 10:51 AM, Matthew Brost wrote:
> > A full GT can race with the last context put resulting in the context
> > ref count being zero but the destroyed bit not yet being set. Remove
> > GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
> > destroyed bit must be set in ref count is zero.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > 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 9b7b4f4e0d91..0f99bb83293a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -1040,8 +1040,6 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
> > intel_guc *guc)
> > spin_unlock(>guc_state.lock);
> > - GEM_BUG_ON(!do_put && !destroyed);
> > -
>
> Do we need to re-queue/flush the destroyer work to make sure it runs before
> we reset, or is it ok for that to run in parallel?
>
The code in the put path will either see the reset or that it isn't
registered and destroy the context without any interaction with the GuC.
Matt
> Daniele
>
> > if (pending_enable || destroyed || deregister) {
> > decr_outstanding_submission_g2h(guc);
> > if (deregister)
>
Re: [PATCH] drm/i915/guc: Remove racey GEM_BUG_ON
On 12/9/2021 10:51 AM, Matthew Brost wrote:
A full GT can race with the last context put resulting in the context
ref count being zero but the destroyed bit not yet being set. Remove
GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 --
1 file changed, 2 deletions(-)
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 9b7b4f4e0d91..0f99bb83293a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1040,8 +1040,6 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
spin_unlock(>guc_state.lock);
- GEM_BUG_ON(!do_put && !destroyed);
-
Do we need to re-queue/flush the destroyer work to make sure it runs
before we reset, or is it ok for that to run in parallel?
Daniele
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
if (deregister)
[PATCH] drm/msm/a6xx: Skip crashdumper state if GPU needs_hw_init
From: Rob Clark
I am seeing some crash logs which imply that we are trying to use
crashdumper hw to read back GPU state when the GPU isn't initialized.
This doesn't go well (for example, GPU could be in 32b address mode
and ignoring the upper bits of buffer that it is trying to dump state
to).
I'm not *quite* sure how we get into this state in the first place,
but lets not make a bad situation worse by triggering iova fault
crashes.
While we're at it, also add the information about whether the GPU is
initialized to the devcore dump to make this easier to see in the
logs (which makes the WARN_ON() redundant and even harmful because
it fills up the small bit of dmesg we get with the crash report).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 9 -
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
index bdd0059a81ff..55f443328d8e 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
@@ -49,6 +49,8 @@ struct a6xx_gpu_state {
s32 hfi_queue_history[2][HFI_HISTORY_SZ];
struct list_head objs;
+
+ bool gpu_initialized;
};
static inline int CRASHDUMP_WRITE(u64 *in, u32 reg, u32 val)
@@ -1001,7 +1003,8 @@ struct msm_gpu_state *a6xx_gpu_state_get(struct msm_gpu
*gpu)
* write out GPU state, so we need to skip this when the SMMU is
* stalled in response to an iova fault
*/
- if (!stalled && !a6xx_crashdumper_init(gpu, &_dumper)) {
+ if (!stalled && !gpu->needs_hw_init &&
+ !a6xx_crashdumper_init(gpu, &_dumper)) {
dumper = &_dumper;
}
@@ -1018,6 +1021,8 @@ struct msm_gpu_state *a6xx_gpu_state_get(struct msm_gpu
*gpu)
if (snapshot_debugbus)
a6xx_get_debugbus(gpu, a6xx_state);
+ a6xx_state->gpu_initialized = !gpu->needs_hw_init;
+
return _state->base;
}
@@ -1246,6 +1251,8 @@ void a6xx_show(struct msm_gpu *gpu, struct msm_gpu_state
*state,
if (IS_ERR_OR_NULL(state))
return;
+ drm_printf(p, "gpu-initialized: %d\n", a6xx_state->gpu_initialized);
+
adreno_show(gpu, state, p);
drm_puts(p, "gmu-log:\n");
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 47cb40bdbd43..f33cfa4ef1c8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -504,7 +504,6 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
msm_gpu_state *state)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i, count = 0;
- WARN_ON(gpu->needs_hw_init);
WARN_ON(!mutex_is_locked(>lock));
kref_init(>ref);
--
2.33.1
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Thu, Dec 9, 2021 at 1:18 PM Guilherme G. Piccoli wrote: > > Thanks again Alex! Some comments inlined below: > > On 09/12/2021 15:06, Alex Deucher wrote: > > Not really in a generic way. It's asic and platform specific. In > > addition most modern displays require link training to bring up the > > display, so you can't just save and restore registers. > > Oh sure, I understand that. My question is more like: is there a way, > inside amdgpu driver, to save this state before taking > over/overwriting/reprogramming the device? So we could (again, from > inside the amdgpu driver) dump this pre-saved state in the shutdown > handler, for example, having the device in a "pre-OS" state when the new > kexec'ed kernel starts. Sure, it could be done, it's just a fair amount of work. Things like legacy vga text mode is a bit more of a challenge, but that tends to be less relevant as non-legacy UEFI becomes more pervasive. > > > > > The drivers are asic and platform specific. E.g., the driver for > > vangogh is different from renoir is different from skylake, etc. The > > display programming interfaces are asic specific. > > Cool, that makes sense! But if you (or anybody here) know some of these > GOP drivers, e.g. for the qemu/qxl device, I'm just curious to > see/understand how complex is the FW driver to just put the > device/screen in a usable state. Most of the asic init and display setup on AMD GPUs is handled via atombios command tables (basically little scripted stored in the vbios) which are shared by the driver and the GOP driver for most programming sequences. In our case, the GOP driver is pretty simple. Take a look at the pre-DC display code in amdgpu to see what a basic display driver would look like (e.g., dce_v11_0.c). The GOP driver would call the atombios asic_init table to make sure the chip itself is initialized (e.g., memory controller, etc.), then walk the display data tables in the vbios to determine the display configuration specific to this board, then probe the displays and use the atombios display command tables to light them up. Alex
Re: [PATCH] drm/i915/guc: Use correct context lock when callig clr_context_registered
On 12/9/2021 10:48 AM, Matthew Brost wrote:
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Cc:
Reviewed-by: Daniele Ceraolo Spurio
I'm assuming we didn't see any splat from the lockdep assert in
clr_context_registered in our CI runs because we never hit this case as
it requires 64k+ contexts. Maybe we can add a selftest to purposely
exercise this path? Not a blocker for merging this fix.
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 1f9d4fde421f..9b7b4f4e0d91 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1937,9 +1937,9 @@ static int steal_guc_id(struct intel_guc *guc, struct
intel_context *ce)
list_del_init(>guc_id.link);
ce->guc_id = cn->guc_id;
- spin_lock(>guc_state.lock);
+ spin_lock(>guc_state.lock);
clr_context_registered(cn);
- spin_unlock(>guc_state.lock);
+ spin_unlock(>guc_state.lock);
set_context_guc_id_invalid(cn);
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2021-12-09: A fix to a error pointer dereference in gem_execbuffer and a fix for GT initialization when GuC/HuC are used on ICL. Thanks, Rodrigo. The following changes since commit 0fcfb00b28c0b7884635dacf38e46d60bf3d4eb1: Linux 5.16-rc4 (2021-12-05 14:08:22 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-12-09 for you to fetch changes up to 52255ef662a5d490678fbad64a735f88fcba564d: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init() (2021-12-09 08:30:22 -0500) A fix to a error pointer dereference in gem_execbuffer and a fix for GT initialization when GuC/HuC are used on ICL. Dan Carpenter (1): drm/i915: Fix error pointer dereference in i915_gem_do_execbuffer() Raviteja Goud Talla (1): drm/i915/gen11: Moving WAs to icl_gt_workarounds_init() drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c| 18 +- 2 files changed, 10 insertions(+), 9 deletions(-)
[PATCH] drm/i915/guc: Remove racey GEM_BUG_ON
A full GT can race with the last context put resulting in the context
ref count being zero but the destroyed bit not yet being set. Remove
GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 --
1 file changed, 2 deletions(-)
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 9b7b4f4e0d91..0f99bb83293a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1040,8 +1040,6 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
spin_unlock(>guc_state.lock);
- GEM_BUG_ON(!do_put && !destroyed);
-
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
if (deregister)
--
2.33.1
[PATCH] drm/i915/guc: Use correct context lock when callig clr_context_registered
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 1f9d4fde421f..9b7b4f4e0d91 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1937,9 +1937,9 @@ static int steal_guc_id(struct intel_guc *guc, struct
intel_context *ce)
list_del_init(>guc_id.link);
ce->guc_id = cn->guc_id;
- spin_lock(>guc_state.lock);
+ spin_lock(>guc_state.lock);
clr_context_registered(cn);
- spin_unlock(>guc_state.lock);
+ spin_unlock(>guc_state.lock);
set_context_guc_id_invalid(cn);
--
2.33.1
Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Am 2021-12-09 um 10:30 a.m. schrieb Christian König: > That still won't work. > > But I think we could do this change for the amdgpu mmap callback only. If graphics user mode has problems with it, we could even make this specific to KFD BOs in the amdgpu_gem_object_mmap callback. Regards, Felix > > Regards, > Christian. > > Am 09.12.21 um 16:29 schrieb Bhardwaj, Rajneesh: >> Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank >> you! >> >> On 12/9/2021 10:27 AM, Christian König wrote: >>> Hi Rajneesh, >>> >>> yes, separating this from the drm_gem_mmap_obj() change is certainly >>> a good idea. >>> The child cannot access the BOs mapped by the parent anyway with access restrictions applied >>> >>> exactly that is not correct. That behavior is actively used by some >>> userspace stacks as far as I know. >>> >>> Regards, >>> Christian. >>> >>> Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh: Thanks Christian. Would it make it less intrusive if I just use the flag for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch? For our use case, just the ttm_bo_mmap_obj change should suffice and we don't want to put any more work arounds in the user space (thunk, in our case). The child cannot access the BOs mapped by the parent anyway with access restrictions applied so I wonder why even inherit the vma? On 12/9/2021 2:54 AM, Christian König wrote: > Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: >> When an application having open file access to a node forks, its >> shared >> mappings also get reflected in the address space of child process >> even >> though it cannot access them with the object permissions applied. >> With the >> existing permission checks on the gem objects, it might be >> reasonable to >> also create the VMAs with VM_DONTCOPY flag so a user space >> application >> doesn't need to explicitly call the madvise(addr, len, >> MADV_DONTFORK) >> system call to prevent the pages in the mapped range to appear in >> the >> address space of the child process. It also prevents the memory >> leaks >> due to additional reference counts on the mapped BOs in the child >> process that prevented freeing the memory in the parent for which >> we had >> worked around earlier in the user space inside the thunk library. >> >> Additionally, we faced this issue when using CRIU to checkpoint >> restore >> an application that had such inherited mappings in the child which >> confuse CRIU when it mmaps on restore. Having this flag set for the >> render node VMAs helps. VMAs mapped via KFD already take care of >> this so >> this is needed only for the render nodes. > > Unfortunately that is most likely a NAK. We already tried > something similar. > > While it is illegal by the OpenGL specification and doesn't work > for most userspace stacks, we do have some implementations which > call fork() with a GL context open and expect it to work. > > Regards, > Christian. > >> >> Cc: Felix Kuehling >> >> Signed-off-by: David Yat Sin >> Signed-off-by: Rajneesh Bhardwaj >> --- >> drivers/gpu/drm/drm_gem.c | 3 ++- >> drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >> index 09c820045859..d9c4149f36dd 100644 >> --- a/drivers/gpu/drm/drm_gem.c >> +++ b/drivers/gpu/drm/drm_gem.c >> @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object >> *obj, unsigned long obj_size, >> goto err_drm_gem_object_put; >> } >> - vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | >> VM_DONTDUMP; >> + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND >> + | VM_DONTDUMP | VM_DONTCOPY; >> vma->vm_page_prot = >> pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); >> vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); >> } >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c >> b/drivers/gpu/drm/ttm/ttm_bo_vm.c >> index 33680c94127c..420a4898fdd2 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c >> @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct >> *vma, struct ttm_buffer_object *bo) >> vma->vm_private_data = bo; >> - vma->vm_flags |= VM_PFNMAP; >> + vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY; >> vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; >> return 0; >> } > >>> >
Re: [PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
Hi Dave
On Thu, Dec 9, 2021 at 6:58 PM Dave Stevenson
wrote:
>
> Hi Michael
>
> On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi all
> >
> > On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> > wrote:
> > >
> > > All the panel driver check the fact that their prepare/unprepare
> > > call was already called. It's not an ideal solution but fix
> > > for now the problem on ili9881c
> > >
> > > [ 9862.283296] [ cut here ]
> > > [ 9862.288490] unbalanced disables for vcc3v3_lcd
> > > [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851
> > > _regulator_disable+0xd4/0x190
> > >
> > > from:
> > >
> > > [ 9862.038619] drm_panel_unprepare+0x2c/0x4c
> > > [ 9862.043212] panel_bridge_post_disable+0x18/0x24
> > > [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0
> > > [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > >
> > > and:
> > >
> > > [ 9862.183103] drm_panel_unprepare+0x2c/0x4c
> > > [ 9862.187695] panel_bridge_post_disable+0x18/0x24
> > > [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > > [ 9862.199117] disable_outputs+0x120/0x31c
>
> This is down to the dw-mipi-dsi driver calling the post_disable hook
> explicitly at [1], but then also allowing the framework to call it.
> The explicit call is down to limitations in the DSI support, so we
> can't control the DSI host state to a fine enough degree (an ongoing
> discussion [2] [3]). There shouldn't be a need to handle mismatched
> calling in individual panel drivers.
>
> Dave
>
> [1]
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L894
> [2] https://lists.freedesktop.org/archives/dri-devel/2021-November/332060.html
> [3] https://lists.freedesktop.org/archives/dri-devel/2021-December/334007.html
I'm in the second case. I need to enable HS mode after the panel is
initialized. Time to time I have timeout
on dsi command or I have wrong panel initialization. So I explicit call from
the bridge but I understand that is not correct in the design point of view.
So this patch can not be queued because it's a known problem that
people are discussing
Michael
>
>
> > > Signed-off-by: Michael Trimarchi
> > > ---
> > > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > index 103a16018975..f75eecb0e65c 100644
> > > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > @@ -52,6 +52,8 @@ struct ili9881c {
> > >
> > > struct regulator*power;
> > > struct gpio_desc*reset;
> > > +
> > > + boolprepared;
> > > };
> > >
> >
> > I found that this can be a general problem. Should not mandatory to
> > track panel status
> >
> > DRM_PANEL_PREPARED
> > DRM_PANEL_ENABLED
> >
> > Michael
> > > #define ILI9881C_SWITCH_PAGE_INSTR(_page) \
> > > @@ -707,6 +709,10 @@ static int ili9881c_prepare(struct drm_panel *panel)
> > > unsigned int i;
> > > int ret;
> > >
> > > + /* Preparing when already prepared is a no-op */
> > > + if (ctx->prepared)
> > > + return 0;
> > > +
> > > /* Power the panel */
> > > ret = regulator_enable(ctx->power);
> > > if (ret)
> > > @@ -745,6 +751,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
> > > if (ret)
> > > return ret;
> > >
> > > + ctx->prepared = true;
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -770,10 +778,16 @@ static int ili9881c_unprepare(struct drm_panel
> > > *panel)
> > > {
> > > struct ili9881c *ctx = panel_to_ili9881c(panel);
> > >
> > > + /* Unpreparing when already unprepared is a no-op */
> > > + if (!ctx->prepared)
> > > + return 0;
> > > +
> > > mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> > > regulator_disable(ctx->power);
> > > gpiod_set_value(ctx->reset, 1);
> > >
> > > + ctx->prepared = false;
> > > +
> > > return 0;
> > > }
> > >
> > > --
> > > 2.25.1
> > >
> >
> >
> > --
> > Michael Nazzareno Trimarchi
> > Co-Founder & Chief Executive Officer
> > M. +39 347 913 2170
> > mich...@amarulasolutions.com
> > __
> >
> > Amarula Solutions BV
> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> > T. +31 (0)85 111 9172
> > i...@amarulasolutions.com
> > www.amarulasolutions.com
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli wrote: > > On 09/12/2021 14:31, Alex Deucher wrote: > > [...] > > Once the driver takes over, none of the pre-driver state is retained. > > You'll need to load the driver in the new kernel to initialize the > > displays. Note the efifb doesn't actually have the ability to program > > any hardware, it just takes over the memory region that was used for > > the pre-OS framebuffer and whatever display timing was set up by the > > GOP driver prior to the OS loading. Once that OS driver has loaded > > the area is gone and the display configuration may have changed. > > > > Hi Christian and Alex, thanks for the clarifications! > > Is there any way to save/retain this state before amdgpu takes over? Not really in a generic way. It's asic and platform specific. In addition most modern displays require link training to bring up the display, so you can't just save and restore registers. > Would simpledrm be able to program the device again, to a working state? No. You need an asic specific driver that knows how to program the specific hardware. It's also platform specific in that you need to determine platform specific details such as the number and type of display connectors and encoders that are present on the system. > > Finally, do you have any example of such a GOP driver (open source) so I > can take a look? I tried to find something like that in Tianocore > project, but didn't find anything that seemed useful for my issue. The drivers are asic and platform specific. E.g., the driver for vangogh is different from renoir is different from skylake, etc. The display programming interfaces are asic specific. Alex
Re: [PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
Hi Michael
On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
wrote:
>
> Hi all
>
> On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> wrote:
> >
> > All the panel driver check the fact that their prepare/unprepare
> > call was already called. It's not an ideal solution but fix
> > for now the problem on ili9881c
> >
> > [ 9862.283296] [ cut here ]
> > [ 9862.288490] unbalanced disables for vcc3v3_lcd
> > [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851
> > _regulator_disable+0xd4/0x190
> >
> > from:
> >
> > [ 9862.038619] drm_panel_unprepare+0x2c/0x4c
> > [ 9862.043212] panel_bridge_post_disable+0x18/0x24
> > [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0
> > [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> >
> > and:
> >
> > [ 9862.183103] drm_panel_unprepare+0x2c/0x4c
> > [ 9862.187695] panel_bridge_post_disable+0x18/0x24
> > [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > [ 9862.199117] disable_outputs+0x120/0x31c
This is down to the dw-mipi-dsi driver calling the post_disable hook
explicitly at [1], but then also allowing the framework to call it.
The explicit call is down to limitations in the DSI support, so we
can't control the DSI host state to a fine enough degree (an ongoing
discussion [2] [3]). There shouldn't be a need to handle mismatched
calling in individual panel drivers.
Dave
[1]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L894
[2] https://lists.freedesktop.org/archives/dri-devel/2021-November/332060.html
[3] https://lists.freedesktop.org/archives/dri-devel/2021-December/334007.html
> > Signed-off-by: Michael Trimarchi
> > ---
> > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > index 103a16018975..f75eecb0e65c 100644
> > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > @@ -52,6 +52,8 @@ struct ili9881c {
> >
> > struct regulator*power;
> > struct gpio_desc*reset;
> > +
> > + boolprepared;
> > };
> >
>
> I found that this can be a general problem. Should not mandatory to
> track panel status
>
> DRM_PANEL_PREPARED
> DRM_PANEL_ENABLED
>
> Michael
> > #define ILI9881C_SWITCH_PAGE_INSTR(_page) \
> > @@ -707,6 +709,10 @@ static int ili9881c_prepare(struct drm_panel *panel)
> > unsigned int i;
> > int ret;
> >
> > + /* Preparing when already prepared is a no-op */
> > + if (ctx->prepared)
> > + return 0;
> > +
> > /* Power the panel */
> > ret = regulator_enable(ctx->power);
> > if (ret)
> > @@ -745,6 +751,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
> > if (ret)
> > return ret;
> >
> > + ctx->prepared = true;
> > +
> > return 0;
> > }
> >
> > @@ -770,10 +778,16 @@ static int ili9881c_unprepare(struct drm_panel *panel)
> > {
> > struct ili9881c *ctx = panel_to_ili9881c(panel);
> >
> > + /* Unpreparing when already unprepared is a no-op */
> > + if (!ctx->prepared)
> > + return 0;
> > +
> > mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> > regulator_disable(ctx->power);
> > gpiod_set_value(ctx->reset, 1);
> >
> > + ctx->prepared = false;
> > +
> > return 0;
> > }
> >
> > --
> > 2.25.1
> >
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
On Thu, Dec 9, 2021 at 9:09 AM Michael Nazzareno Trimarchi wrote: > > Hi Tim > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote: > > > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi > > wrote: > > > > > > Hi Tim > > > > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote: > > > > > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > > > > wrote: > > > > > > > > > > Hi Sam, > > > > > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg > > > > > wrote: > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > > > > >users like i.MX8MM. > > > > > > > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > > > > component_ops and fixing exynos specific code in order to make > > > > > > > the bridge more mature to use and the same is mentioned in > > > > > > > drivers TODO. > > > > > > > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > > > > > > > Anyone interest, please have a look on this repo > > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > > > > the exynos platform? > > > > > > > > > > > > > > Any inputs? > > > > > > > > > > > > I really like where you are headign with this! > > > > > > No testing - sorry. But I will try to provide a bit of feedback on > > > > > > the > > > > > > individual patches. > > > > > > > > > > > > I hope you find a way to move forward with this. > > > > > > > > > > Thanks for the response. > > > > > > > > > > We have found some issues with Bridge conversion on existing exynos > > > > > drivers. The component based DSI drivers(like exynos) are difficult to > > > > > attach if it involves kms hotplug. kms hotplug would require drm > > > > > pointer and that pointer would only available after the bind call > > > > > finishes. But the bridge attach in bind call will defer till it find > > > > > the attached bridge. > > > > > > > > > > Right now I'm trying to find the proper way to attach the bridges for > > > > > component based DSI drivers which involves kms hot-plug. > > > > > > > > > > If you have any ideas on this, please let me know. > > > > > > > > > > > > > Jagan, > > > > > > > > How is your progress on this series? Looking at your repo it looks > > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > > > > branch but you've got a lot of things there that are likely not > > > > related to this series? > > > > > > I have a bit of work on those patches and tested on imx8mn. Basically: > > > > > > - add the dsi timing calculation > > > - change few difference with samsung bridge > > > - fix crashes of my dsi panels > > > - compare with NXP driver the final results > > > > > > I found that I have one problem that gives me some instability. In the > > > NXP original driver the panel needs to be > > > enabled in bridge_enable before out the standby. If I understand > > > correctly, our standby should be done after. > > > I would like to have some feedback and help and testing on other > > > boards/devices and some suggestions on how to handle > > > some of the differences. Another big problem is etnavi that is not stable > > > > > > > Michael, > > > > Where can I find your patches? > > > > I will push on some tree and share > > > What do you mean by etnaviv not being stable? > > > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi > > > > > patches on an Ubuntu focal root filesystem by: > > apt update > > apt install gnome-session gnome-terminal > > ^^^ 2D hardware acceleration appears to be working (dragging opaque > > windows around) > > apt install mesa-utils glmark2 > > glxgears > > ^^^ ~160fps on IMX8MM > > glmark2 > > ^^^ score of 39 on IMX8MM > > > > I haven't seen any updates from Jagan since Nov 24 > > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not > > sure if he's been able to work through drm/exynos issues that have > > been blocking his progress. > > I plan to push on github > > [17:07:42.315] Sending ready to systemd > [ 214.052085] etnaviv-gpu 3800.gpu: recover hung GPU! > [ 214.595998] etnaviv-gpu 3800.gpu: recover hung GPU! > > ** (maynard:386): WARNING **:
Re: [PATCH] drm/i915: Fix coredump of perma-pinned vmas
On 08/12/2021 08:22, Thomas Hellström wrote:
When updating the error capture code and introducing vma snapshots,
we introduced code to hold the vma in memory while capturing it,
calling i915_active_acquire_if_busy(). Now that function isn't relevant
for perma-pinned vmas and caused important vmas to be dropped from the
coredump. Like for example the GuC log.
Fix this by instead requiring those vmas to be pinned while capturing.
Tested by running the initial subtests of the gem_exec_capture igt test
with GuC submission enabled and verifying that a GuC log blob appears
in the output.
Fixes: ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the current
vma state")
Cc: Ramalingam C
Cc: Matthew Auld
Cc: Maarten Lankhorst
Cc: John Harrison
Cc: Matthew Brost
Reported-by: John Harrison
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
Re: [PATCH] drm/mediatek: Set the default value of rotation to DRM_MODE_ROTATE_0
On Wed, Dec 8, 2021 at 7:16 PM Chun-Kuang Hu wrote:
>
> Hi Mark:
>
> Mark Yacoub 於 2021年10月28日 週四 上午12:28寫道：
> >
> > From: Mark Yacoub
> >
> > At the reset hook, call __drm_atomic_helper_plane_reset which is
> > called at the initialization of the plane and sets the default value of
> > rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1.
>
> This patch looks good to me, but please fix this checkpatch warning:
Uploaded a new revision. Thanks!
>
> WARNING: From:/Signed-off-by: email address mismatch: 'From: Mark
> Yacoub ' != 'Signed-off-by: Mark Yacoub
> '
>
> total: 0 errors, 1 warnings, 11 lines checked
>
> Regards,
> Chun-Kuang.
>
> >
> > Tested on Jacuzzi (MTK).
> > Resolves IGT@kms_properties@plane-properties-{legacy,atomic}
> >
> > Signed-off-by: Mark Yacoub
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index e6dcb34d30522..accd26481b9fb 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -44,9 +44,10 @@ static void mtk_plane_reset(struct drm_plane *plane)
> > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > if (!state)
> > return;
> > - plane->state = >base;
> > }
> >
> > + __drm_atomic_helper_plane_reset(plane, >base);
> > +
> > state->base.plane = plane;
> > state->pending.format = DRM_FORMAT_RGB565;
> > }
> > --
> > 2.33.0.1079.g6e70778dc9-goog
> >
Re: [PATCH 1/2] of: Add helper to lookup non port child node
Hi Rob and Laurent, On Wed, Dec 8, 2021 at 11:56 AM Jagan Teki wrote: > > On Wed, Dec 8, 2021 at 2:20 AM Rob Herring wrote: > > > > On Mon, Dec 6, 2021 at 11:49 PM Jagan Teki > > wrote: > > > > > > Add of_get_non_port_child() helper that can be used to lookup > > > non port child nodes. > > > > > > Some OF graphs don't require 'ports' to represent the next output > > > instead, it simply adds a child node on a given parent node. This > > > helper lookup that child node, however that child node is not a > > > 'port' on given parent as 'port' based nodes are looked up via > > > of_graph_get_remote_node(). > > > > > > Example OF graph representation of DSI host, which doesn't > > > have 'ports'. > > > > This seems pretty specific to DSI and also can't handle there being > > more than 1 non-port node. That's allowed for DSI too, but I don't > > think I've ever seen a case. Anyways, I'd just move this to DRM rather > > than common DT code. One comment on the implementation that will > > shrink it. > > I think it can be possible to OF graph even for non-DSI, however if > the end-node outputs to a panel or bridge. At the moment, I can one > use case on the non-DSI side is rcar du encoder. > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rcar-du/rcar_du_encoder.c#n68 Do you see any point to make this helper in of/base based on above rcar_du_encoder usage? if not i can directly use this functionality in panel_or_bridge finding code itself. Please let me know. Thanks, Jagan.
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Thu, Dec 9, 2021 at 12:04 PM Guilherme G. Piccoli wrote: > > Hi all, I have a question about the possibility of reusing a framebuffer > after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not > a separate GPU hardware), but I guess the question is kinda generic > hence I've looped most of the lists / people I think does make sense > (apologies for duplicates). > > > The context is: we have a hardware that has an amdgpu-controlled device > (Vangogh model) and as soon as the machine boots, efifb is providing > graphics - I understand the UEFI/GRUB outputs rely in EFI framebuffer as > well. As soon amdgpu module is available, kernel loads it and it takes > over the GPU, providing graphics. The kexec_file_load syscall allows to > pass a valid screen_info structure, so by kexec'ing a new kernel, we > have again efifb taking over on boot time, but this time I see nothing > in the screen. I've manually blacklisted amdgpu in this new kexec'ed > kernel, I'd like to rely in the simple framebuffer - the goal is to have > a tiny kernel kexec'ed. I'm using kernel version 5.16.0-rc4. > > I've done some other experiments, for exemple: I've forced screen_info > model to match VLFB, so vesafb took over after the kexec, with the same > result. Also noticed that BusMaster bit was off after kexec, in the AMD > APU PCIe device, so I've set it on efifb before probe, and finally > tested the same things in qemu, with qxl, all with the same result > (blank screen). > The most interesting result I got (both with amdgpu and qemu/qxl) is > that if I blacklist these drivers and let the machine continue using > efifb since the beginning, after kexec the efifb is still able to > produce graphics. > > Which then led me to think that likely there's something fundamentally > "blocking" the reuse of the simple framebuffer after kexec, like maybe > DRM stack is destroying the old framebuffer somehow? What kind of > preparation is required at firmware level to make the simple EFI VGA > framebuffer work, and could we perform this in a kexec (or "save it" > before the amdgpu/qxl drivers take over and reuse later)? > Once the driver takes over, none of the pre-driver state is retained. You'll need to load the driver in the new kernel to initialize the displays. Note the efifb doesn't actually have the ability to program any hardware, it just takes over the memory region that was used for the pre-OS framebuffer and whatever display timing was set up by the GOP driver prior to the OS loading. Once that OS driver has loaded the area is gone and the display configuration may have changed. Alex > Any advice is greatly appreciated! > Thanks in advance, > > > Guilherme
Re: [PATCH] drm/i915: Don't leak the capture list items
On 09/12/2021 14:13, Thomas Hellström wrote:
When we recently converted the capture code to use vma snapshots,
we forgot to free the struct i915_capture_list list items after use.
Fix that by bringing back a kfree.
Fixes: ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the current
vma state")
Cc: Ramalingam C
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
Re: [Intel-gfx] [PATCH v6 01/11] drm/i915: Store backpointer to GT in uncore
Hi Jani, thanks for looking at it. > > - intel_gt_init_early(_priv->gt, dev_priv); > > + __intel_gt_init_early(_priv->gt, dev_priv); > > Why double underscores here? It looks like it's supposed to be internal > to intel_gt, not to be called by anyone else. I forgot to write two lines in the commit log about this. It's a temporary solution that will go away in the next patch series[*]. The reason for it is because at this point I need to break the early initialization of the gt into two parts. In the specific the '__intel_gt_init_early' assigns the i915 private data and the uncore. It's not pretty, but, knowing what's coming next, it's the change with the smallest impact. > > > > i915_gem_init_early(dev_priv); > > Thank you, Andi [*] https://patchwork.freedesktop.org/patch/464475/?series=97352=1
Re: [Intel-gfx] [PATCH] drm/i915/dg2: make GuC FW a requirement for Gen12 and beyond devices
On 12/9/2021 06:41, Robert Beckett wrote:
On 09/12/2021 00:24, John Harrison wrote:
On 12/8/2021 09:58, Robert Beckett wrote:
On 07/12/2021 23:15, John Harrison wrote:
On 12/7/2021 09:53, Adrian Larumbe wrote:
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error
handling in
the FW init and load functions so that the driver's probe()
function will
fail if GuC could not be loaded.
We still need to load the i915 driver in fall back mode (display
but no engines) if the GuC is missing. Otherwise you may have just
bricked the user's device.
good point, well made.
though this still seems like an issue for gen12+ (excluding rkl and
adl).
maybe a redesign of toplevel driver probe, with
i915_driver_early_probe before i915_driver_create could work. If the
GuC fw is not found, it could then register a new kms only version
of i915_drm_driver.
or something like like that ...
Or we could just leave it all alone?
AFAIK, this is working just fine at the moment. If the platform
default is to use GuC submission and you have the fw then the driver
loads fine. If the platform default is to use GuC submission and you
don't have the firmware then the driver wedges but keeps loading.
That means it returns no engines to userland but the display is
unaffected. Hence the user gets a slow but safe fallback path in
which they can still load their Ubuntu desktop and try to work out
what package they need to install.
What is the problem that this patch is trying to fix?
In dg2 enablement branch, when fw was unavailable, submissions could
still be attempted and it would segfault the kernel due to some
function pointers not being set up.
From what you said, it sounds like this may just be a bug in the dg2
enablement, which we can diagnose and fix if so.
Yeah, that is not supposed to happen. It has definitely been working
correctly in the past. Maybe something is incorrectly thinking it can
unwedge by a reset? That is permissible for a regular wedge but
wedge-on-init is meant to be permanent.
Though I still think it would be a better design to only register kms
capabilities if that is all that will be supported without the fw. It
seems a bit messy to advertise render and create the render node for
userland sw to attempt to use and have it fail, but if that is the
prefered design, then we can make dg2 match that.
Daniel Vetter/Jon Bloomfield may have newer thoughts but last I heard
was the architectural decision was to simply wedge and not return any
engines to userland. Maybe on the grounds that while a cleaner design
maybe possible, it's not worth the extra complexity in the driver for
what is basically only an error path.
John.
John.
Also, we do want to be able to disable the GuC via the enable_guc
module parameter.
John.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7660eba893fa..8b0778b6d9ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -277,14 +277,19 @@ static void guc_disable_communication(struct
intel_guc *guc)
drm_dbg(>drm, "GuC communication disabled\n");
}
-static void __uc_fetch_firmwares(struct intel_uc *uc)
+static int __uc_fetch_firmwares(struct intel_uc *uc)
{
+ struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
GEM_BUG_ON(!intel_uc_wants_guc(uc));
err = intel_uc_fw_fetch(>guc.fw);
if (err) {
+ /* GuC is mandatory on Gen12 and beyond */
+ if (GRAPHICS_VER(i915) >= 12)
+ return err;
+
/* Make sure we transition out of transient "SELECTED"
state */
if (intel_uc_wants_huc(uc)) {
drm_dbg(_to_gt(uc)->i915->drm,
@@ -293,11 +298,13 @@ static void __uc_fetch_firmwares(struct
intel_uc *uc)
INTEL_UC_FIRMWARE_ERROR);
}
- return;
+ return 0;
}
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(>huc.fw);
+
+ return 0;
}
static void __uc_cleanup_firmwares(struct intel_uc *uc)
@@ -308,14 +315,19 @@ static void __uc_cleanup_firmwares(struct
intel_uc *uc)
static int __uc_init(struct intel_uc *uc)
{
+ struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret;
GEM_BUG_ON(!intel_uc_wants_guc(uc));
- if (!intel_uc_uses_guc(uc))
- return 0;
+ if (!intel_uc_uses_guc(uc)) {
+ if (GRAPHICS_VER(i915) >= 12)
+ return -EINVAL;
+ else
+ return 0;
+ }
if (i915_inject_probe_failure(uc_to_gt(uc)->i915))
Re: [Intel-gfx] [PATCH v6 01/11] drm/i915: Store backpointer to GT in uncore
On Thu, 09 Dec 2021, Andi Shyti wrote:
> From: Michał Winiarski
>
> We now support a per-gt uncore, yet we're not able to infer which GT
> we're operating upon. Let's store a backpointer for now.
>
> Signed-off-by: Michał Winiarski
> Signed-off-by: Matt Roper
> Reviewed-by: Andi Shyti
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
> drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
> drivers/gpu/drm/i915/i915_driver.c | 5 +++--
> drivers/gpu/drm/i915/intel_uncore.c | 9 +
> drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
> drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
> 7 files changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f2422d48be32..f98f0fb21efb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -25,11 +25,8 @@
> #include "shmem_utils.h"
> #include "pxp/intel_pxp.h"
>
> -void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
> +void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private
> *i915)
> {
> - gt->i915 = i915;
> - gt->uncore = >uncore;
> -
> spin_lock_init(>irq_lock);
>
> INIT_LIST_HEAD(>closed_vma);
> @@ -48,6 +45,12 @@ void intel_gt_init_early(struct intel_gt *gt, struct
> drm_i915_private *i915)
> intel_rps_init_early(>rps);
> }
>
> +void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
> +{
> + gt->i915 = i915;
> + gt->uncore = >uncore;
> +}
> +
> int intel_gt_probe_lmem(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 74e771871a9b..3ace129eb2af 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -35,6 +35,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
> *huc)
> }
>
> void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
> +void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private
> *i915);
> void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt);
> int intel_gt_probe_lmem(struct intel_gt *gt);
> int intel_gt_init_mmio(struct intel_gt *gt);
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index e9125f14b3d1..42ae5a12040d 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -314,8 +314,9 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> intel_device_info_subplatform_init(dev_priv);
> intel_step_init(dev_priv);
>
> + intel_gt_init_early(_priv->gt, dev_priv);
> intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
> - intel_uncore_init_early(_priv->uncore, dev_priv);
> + intel_uncore_init_early(_priv->uncore, _priv->gt);
>
> spin_lock_init(_priv->irq_lock);
> spin_lock_init(_priv->gpu_error.lock);
> @@ -346,7 +347,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
>
> intel_wopcm_init_early(_priv->wopcm);
>
> - intel_gt_init_early(_priv->gt, dev_priv);
> + __intel_gt_init_early(_priv->gt, dev_priv);
Why double underscores here? It looks like it's supposed to be internal
to intel_gt, not to be called by anyone else.
BR,
Jani.
>
> i915_gem_init_early(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index abdac78d3976..fc25ebf1a593 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2061,12 +2061,13 @@ void intel_uncore_cleanup_mmio(struct intel_uncore
> *uncore)
> }
>
> void intel_uncore_init_early(struct intel_uncore *uncore,
> - struct drm_i915_private *i915)
> + struct intel_gt *gt)
> {
> spin_lock_init(>lock);
> - uncore->i915 = i915;
> - uncore->rpm = >runtime_pm;
> - uncore->debug = >mmio_debug;
> + uncore->i915 = gt->i915;
> + uncore->gt = gt;
> + uncore->rpm = >i915->runtime_pm;
> + uncore->debug = >i915->mmio_debug;
> }
>
> static void uncore_raw_init(struct intel_uncore *uncore)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h
> b/drivers/gpu/drm/i915/intel_uncore.h
> index d1d17b04e29f..210fe2a71612 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -129,6 +129,7 @@ struct intel_uncore {
> void __iomem *regs;
>
> struct drm_i915_private *i915;
> + struct intel_gt *gt;
> struct intel_runtime_pm *rpm;
>
> spinlock_t lock; /** lock is also taken in irq contexts. */
> @@ -217,7 +218,7 @@ u32
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
Hi Tim On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote: > > On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi > wrote: > > > > Hi Tim > > > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote: > > > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > > > wrote: > > > > > > > > Hi Sam, > > > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg wrote: > > > > > > > > > > Hi Jagan, > > > > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > > > >users like i.MX8MM. > > > > > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > > > component_ops and fixing exynos specific code in order to make > > > > > > the bridge more mature to use and the same is mentioned in > > > > > > drivers TODO. > > > > > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > > > > > Anyone interest, please have a look on this repo > > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > > > the exynos platform? > > > > > > > > > > > > Any inputs? > > > > > > > > > > I really like where you are headign with this! > > > > > No testing - sorry. But I will try to provide a bit of feedback on the > > > > > individual patches. > > > > > > > > > > I hope you find a way to move forward with this. > > > > > > > > Thanks for the response. > > > > > > > > We have found some issues with Bridge conversion on existing exynos > > > > drivers. The component based DSI drivers(like exynos) are difficult to > > > > attach if it involves kms hotplug. kms hotplug would require drm > > > > pointer and that pointer would only available after the bind call > > > > finishes. But the bridge attach in bind call will defer till it find > > > > the attached bridge. > > > > > > > > Right now I'm trying to find the proper way to attach the bridges for > > > > component based DSI drivers which involves kms hot-plug. > > > > > > > > If you have any ideas on this, please let me know. > > > > > > > > > > Jagan, > > > > > > How is your progress on this series? Looking at your repo it looks > > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > > > branch but you've got a lot of things there that are likely not > > > related to this series? > > > > I have a bit of work on those patches and tested on imx8mn. Basically: > > > > - add the dsi timing calculation > > - change few difference with samsung bridge > > - fix crashes of my dsi panels > > - compare with NXP driver the final results > > > > I found that I have one problem that gives me some instability. In the > > NXP original driver the panel needs to be > > enabled in bridge_enable before out the standby. If I understand > > correctly, our standby should be done after. > > I would like to have some feedback and help and testing on other > > boards/devices and some suggestions on how to handle > > some of the differences. Another big problem is etnavi that is not stable > > > > Michael, > > Where can I find your patches? > I will push on some tree and share > What do you mean by etnaviv not being stable? > > I did some limited testing with etnaviv on imx8mm with 5.15 + dsi > patches on an Ubuntu focal root filesystem by: > apt update > apt install gnome-session gnome-terminal > ^^^ 2D hardware acceleration appears to be working (dragging opaque > windows around) > apt install mesa-utils glmark2 > glxgears > ^^^ ~160fps on IMX8MM > glmark2 > ^^^ score of 39 on IMX8MM > > I haven't seen any updates from Jagan since Nov 24 > (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not > sure if he's been able to work through drm/exynos issues that have > been blocking his progress. I plan to push on github [17:07:42.315] Sending ready to systemd [ 214.052085] etnaviv-gpu 3800.gpu: recover hung GPU! [ 214.595998] etnaviv-gpu 3800.gpu: recover hung GPU! ** (maynard:386): WARNING **: 17:07:43.874: failed to setup mixer: Success [17:07:44.175] Added surface 0xaaab02630440, app_id (null) to pending list [17:07:44.176] Added surface 0xaaab026172b0, app_id (null) to pending list ** Message: 17:07:44.289: New advertisement app id maynard ** Message: 17:07:44.290: New advertisement app id maynard [17:07:45.171] (background) position
Re: [PATCH 1/2] drm/ bridge: tc358762: move bridge init to enable callback
Hi Dmitry,
(CC'ing Tomi)
On Thu, Dec 09, 2021 at 07:53:43PM +0300, Dmitry Baryshkov wrote:
> On Fri, 26 Nov 2021 at 14:56, Dave Stevenson wrote:
> > On Fri, 26 Nov 2021 at 00:32, Dmitry Baryshkov wrote:
> > >
> > > During the pre_enable time the previous bridge (e.g. DSI host) might be
> > > not initialized yet. Move the regulator enablement and bridge init to
> > > te enable callback (and consequently regulator disblement to disable).
> >
> > Except that in the enable callback the DSI host has video enabled too,
> > so the data lanes may be in HS mode too, and the bridge may not be
> > prepared to accept that during power on / initialisation. That means
> > you've got a race condition over how quickly the composition hardware
> > starts producing pixel data vs when this enable callback is called. I
> > suspect that is why we had [1] for the rare case when the race
> > condition failed.
> > There's also seems to be no guarantee that a host can do LP commands
> > between HS video packets (eg sunxi [2])
>
> I see.
>
> > This is the same issue that was being hacked around in [3], and is one
> > of the questions I'd raised back in July [4].
> > The DSI support is broken when it comes to accommodating
> > initialisation sequences, but in trying to ensure all possible
> > sequences can be accomodated, all currently proposed solutions have
> > been shot down.
> > Some platforms have worked around it by powering up the DSI host in
> > mode_set (dw-mipi-dsi),
>
> Looks like this approach is supported by panel-bridge, so I have
> proposed a similar change to the msm dsi driver. [5]
>
> > others have broken the bridge chain apart so
> > their pre_enable gets called first (exynos and currently vc4) except
> > that approach is broken for the atomic API.
> >
> > There is a need for some form of resolution, even if it is only
> > documenting the correct hack to implement in the DSI host driver.
> > Hacking bridge or panel drivers to try and workaround it seems wrong.
>
> Thank you for this lengthy explanation, background and pointers. This
> helped a lot.
>
> It really looks like we need a separate callback between pre-enable
> and enable (or before pre-enable, but that would break the 'clocks not
> enabled' constraint.
>
> Another option would be to move video mode enablement from bridge ops
> to dsi host interface, making the panel/bridge implicitly tell the
> host to switch from LP to HS mode.
Do you mean explicitly ?
> This way the bridge's enable() callback would start with the DSI host
> powered up, but not sending the video, so the DSI device can send
> setup commands. Then it'd enable the video/cmd mode on the DSI host
> and then make final adjustments (like enabling the backlight/etc, so
> that the video is visible/sent to the next item in a chain. WDYT?
This is how the omapdrm driver originally implemented support for
bridges (as custom omapdrm components, before it was ported to
drm_bridge), with an that allowed downstream components to explicitly
control the enable/disable sequence of upstream components. I'm
beginning to think it's a better model, but switching drm_bridge to that
is likely an impossible task. Keeping it specific to the DSI interface
could be a good middle-ground, although some DSI encoders may need to
propagate any control operation they receive from the downstream
component up to their upstream component (for instance instructing the
CRTC to enable video when the panel requests video to be enabled).
Still, it's probably worth being investigated.
I can't agree more with Dave about the need for documentation, DSI
drivers (both on the TX and RX side) are very creative these days,
causing lots of interoperability issues. This wild west situation really
needs some policing.
If anyone documents rules that can be enforced, I'll be very happy to
buy them a few rounds of drinks in any conference we'll happen to both
attend (even more so because that will mean travel restrictions will be
lifted :-)).
> > [1]
> > https://lists.freedesktop.org/archives/dri-devel/2021-September/322119.html
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n776
> > [3]
> > https://lists.freedesktop.org/archives/dri-devel/2021-November/332003.html
> > [4] https://lists.freedesktop.org/archives/dri-devel/2021-July/313576.html
>
> [5] https://patchwork.freedesktop.org/patch/465764/?series=97688=1
>
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/bridge/tc358762.c | 20 ++--
> > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/tc358762.c
> > > b/drivers/gpu/drm/bridge/tc358762.c
> > > index 7104828024fd..ebdf771a1e49 100644
> > > --- a/drivers/gpu/drm/bridge/tc358762.c
> > > +++ b/drivers/gpu/drm/bridge/tc358762.c
> > > @@ -64,7 +64,7 @@ struct tc358762 {
> > > struct drm_connector connector;
> > > struct regulator
Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels
Il 02/10/21 00:33, Dmitry Baryshkov ha scritto: On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). I've compared this with the MDP5 driver, where we always wait for PP_DONE interrupt. Would it be enough to always wait for it (= always call dpu_encoder_phys_cmd_wait_for_tx_complete())? This sets my delay record to reply to two months. Great achievement! Jokes apart, yes it would make sense to do that, it's something that works at least... but we should verify that such a thing doesn't break new platforms (like sm8150 and newer).
[PATCH v4 15/16] drm/i915/Flat-CCS: Document on Flat-CCS memory compression
Documents the Flat-CCS feature and kernel handling required along with
modifiers used.
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 0fb83d0bec91..2d7ea9b6e8fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -595,6 +595,53 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
}
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ *
+ *
+ * Flat-CCS Modifiers for different compression formats
+ *
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat
CCS
+ * render compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is
+ * used. Render compression uses 128 byte compression blocks
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS
+ * media compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is
+ * used. Media compression uses 256 byte compression blocks.
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat
+ * CCS clear color render compression formats. Unified compression format for
+ * clear color render compression. The genral layout is a tiled layout using
+ * 4Kb tiles i.e Tile4 layout.
+ */
+
static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
{
/* Mask the 3 LSB to use the PPGTT address space */
--
2.20.1
Re: [RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
On Thu, Dec 9, 2021 at 12:36 AM Michael Nazzareno Trimarchi wrote: > > Hi Tim > > On Tue, Oct 5, 2021 at 11:43 PM Tim Harvey wrote: > > > > On Sun, Jul 25, 2021 at 10:14 AM Jagan Teki > > wrote: > > > > > > Hi Sam, > > > > > > On Sun, Jul 25, 2021 at 10:35 PM Sam Ravnborg wrote: > > > > > > > > Hi Jagan, > > > > > > > > On Sun, Jul 04, 2021 at 02:32:13PM +0530, Jagan Teki wrote: > > > > > This series supports common bridge support for Samsung MIPI DSIM > > > > > which is used in Exynos and i.MX8MM SoC's. > > > > > > > > > > The final bridge supports both the Exynos and i.MX8MM DSI devices. > > > > > > > > > > Right now bridge offers two sets of implementations. > > > > > > > > > > A. With component_ops and exynos specific code exclusively for > > > > >exynos dsi drivers and it's legacy bindings. > > > > > > > > > > B. Without componenet_ops for newly implemented bridges and its > > > > >users like i.MX8MM. > > > > > > > > > > The future plan is to fix the implementation A) by dropping > > > > > component_ops and fixing exynos specific code in order to make > > > > > the bridge more mature to use and the same is mentioned in > > > > > drivers TODO. > > > > > > > > > > Patch 0001 - 0006: Bridge conversion > > > > > Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions > > > > > > > > > > Tested in Engicam i.Core MX8M Mini SoM. > > > > > > > > > > Anyone interest, please have a look on this repo > > > > > https://github.com/openedev/linux/tree/070421-imx8mm-dsim > > > > > > > > > > Would appreciate anyone from the exynos team to test it on > > > > > the exynos platform? > > > > > > > > > > Any inputs? > > > > > > > > I really like where you are headign with this! > > > > No testing - sorry. But I will try to provide a bit of feedback on the > > > > individual patches. > > > > > > > > I hope you find a way to move forward with this. > > > > > > Thanks for the response. > > > > > > We have found some issues with Bridge conversion on existing exynos > > > drivers. The component based DSI drivers(like exynos) are difficult to > > > attach if it involves kms hotplug. kms hotplug would require drm > > > pointer and that pointer would only available after the bind call > > > finishes. But the bridge attach in bind call will defer till it find > > > the attached bridge. > > > > > > Right now I'm trying to find the proper way to attach the bridges for > > > component based DSI drivers which involves kms hot-plug. > > > > > > If you have any ideas on this, please let me know. > > > > > > > Jagan, > > > > How is your progress on this series? Looking at your repo it looks > > like you've rebased on top of 5.13-rc3 in your 070121-imx8mm-dsim > > branch but you've got a lot of things there that are likely not > > related to this series? > > I have a bit of work on those patches and tested on imx8mn. Basically: > > - add the dsi timing calculation > - change few difference with samsung bridge > - fix crashes of my dsi panels > - compare with NXP driver the final results > > I found that I have one problem that gives me some instability. In the > NXP original driver the panel needs to be > enabled in bridge_enable before out the standby. If I understand > correctly, our standby should be done after. > I would like to have some feedback and help and testing on other > boards/devices and some suggestions on how to handle > some of the differences. Another big problem is etnavi that is not stable > Michael, Where can I find your patches? What do you mean by etnaviv not being stable? I did some limited testing with etnaviv on imx8mm with 5.15 + dsi patches on an Ubuntu focal root filesystem by: apt update apt install gnome-session gnome-terminal ^^^ 2D hardware acceleration appears to be working (dragging opaque windows around) apt install mesa-utils glmark2 glxgears ^^^ ~160fps on IMX8MM glmark2 ^^^ score of 39 on IMX8MM I haven't seen any updates from Jagan since Nov 24 (https://www.spinics.net/lists/dri-devel/msg324059.html) and am not sure if he's been able to work through drm/exynos issues that have been blocking his progress. Best regards, Tim
Re: [PATCH 0/2] Add SMBus features to Tegra I2C
09.12.2021 18:05, Akhil R пишет: > Add support for SMBus Alert and SMBus block read functions to > i2c-tegra driver > > Akhil R (2): > dt-bindings: i2c: tegra: Add SMBus feature properties > i2c: tegra: Add SMBus block read and SMBus alert functions > > .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++ > drivers/i2c/busses/i2c-tegra.c | 54 > +- > 2 files changed, 57 insertions(+), 1 deletion(-) > How this was tested? This series must include the DT patch. If there is no real user in upstream for this feature, then I don't think that we should bother at all about it.
[PATCH v4 06/16] drm/i915/gt: Clear compress metadata for Xe_HP platforms
From: Ayaz A Siddiqui
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
Flat CCS memory can not be directly accessed by S/W.
Address of CCS buffer associated main BO is automatically calculated
by device itself. KMD/UMD can only access this buffer indirectly using
XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.
v2: Fixed issues with platform naming [Lucas]
Cc: CQ Tang
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 14 +++
drivers/gpu/drm/i915/gt/intel_migrate.c | 120 ++-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..07bf5a1753bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -203,6 +203,20 @@
#define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
#define GFX_OP_DRAWRECT_INFO_I965 ((0x7900<<16)|0x2)
+#define XY_CTRL_SURF_INSTR_SIZE5
+#define MI_FLUSH_DW_SIZE 3
+#define XY_CTRL_SURF_COPY_BLT ((2 << 29) | (0x48 << 22) | 3)
+#define SRC_ACCESS_TYPE_SHIFT21
+#define DST_ACCESS_TYPE_SHIFT20
+#define CCS_SIZE_SHIFT 8
+#define XY_CTRL_SURF_MOCS_SHIFT 25
+#define NUM_CCS_BYTES_PER_BLOCK 256
+#define NUM_CCS_BLKS_PER_XFER1024
+#define INDIRECT_ACCESS 0
+#define DIRECT_ACCESS1
+#define MI_FLUSH_LLC BIT(9)
+#define MI_FLUSH_CCS BIT(16)
+
#define COLOR_BLT_CMD (2 << 29 | 0x40 << 22 | (5 - 2))
#define XY_COLOR_BLT_CMD (2 << 29 | 0x50 << 22)
#define SRC_COPY_BLT_CMD (2 << 29 | 0x43 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 19a01878fee3..64ffaacac1e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -16,6 +16,7 @@ struct insert_pte_data {
};
#define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
+#define GET_CCS_SIZE(i915, size) (HAS_FLAT_CCS(i915) ? (size) >> 8 : 0)
static bool engine_supports_migration(struct intel_engine_cs *engine)
{
@@ -488,15 +489,104 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
}
-static int emit_clear(struct i915_request *rq, int size, u32 value)
+static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
+{
+ /* Mask the 3 LSB to use the PPGTT address space */
+ *cmd++ = MI_FLUSH_DW | flags;
+ *cmd++ = lower_32_bits(dst);
+ *cmd++ = upper_32_bits(dst);
+
+ return cmd;
+}
+
+static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
+{
+ u32 num_cmds, num_blks, total_size;
+
+ if (!GET_CCS_SIZE(i915, size))
+ return 0;
+
+ /*
+* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
+* blocks. one XY_CTRL_SURF_COPY_BLT command can
+* trnasfer upto 1024 blocks.
+*/
+ num_blks = (GET_CCS_SIZE(i915, size) +
+ (NUM_CCS_BYTES_PER_BLOCK - 1)) >> 8;
+ num_cmds = (num_blks + (NUM_CCS_BLKS_PER_XFER - 1)) >> 10;
+ total_size = (XY_CTRL_SURF_INSTR_SIZE) * num_cmds;
+
+ /*
+* We need to add a flush before and after
+* XY_CTRL_SURF_COPY_BLT
+*/
+ total_size += 2 * MI_FLUSH_DW_SIZE;
+ return total_size;
+}
+
+static u32 *_i915_ctrl_surf_copy_blt(u32 *cmd, u64 src_addr, u64 dst_addr,
+u8 src_mem_access, u8 dst_mem_access,
+int src_mocs, int dst_mocs,
+u16 num_ccs_blocks)
+{
+ int i = num_ccs_blocks;
+
+ /*
+* The XY_CTRL_SURF_COPY_BLT instruction is used to copy the CCS
+* data in and out of the CCS region.
+*
+* We can copy at most 1024 blocks of 256 bytes using one
+* XY_CTRL_SURF_COPY_BLT instruction.
+*
+* In case we need to copy more than 1024 blocks, we need to add
+* another instruction to the same batch buffer.
+*
+* 1024 blocks of 256 bytes of CCS represent a total 256KB of CCS.
+*
+* 256 KB of CCS represents 256 * 256 KB = 64 MB of LMEM.
+*/
+ do {
+ /*
+* We use logical AND with 1023 since the size field
+* takes values which is in the range of 0 - 1023
+*/
+ *cmd++ = ((XY_CTRL_SURF_COPY_BLT) |
+ (src_mem_access << SRC_ACCESS_TYPE_SHIFT) |
+ (dst_mem_access << DST_ACCESS_TYPE_SHIFT) |
+
[PATCH v2] i2c: tegra: use i2c_timings for bus clock freq
Use i2c_timings struct and corresponding methods to get bus clock frequency
Signed-off-by: Akhil R
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/i2c-tegra.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
v1->v2: Added temp var for i2c_timings struct in function.
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index a5be8f0..4cbe89b 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -246,7 +246,7 @@ struct tegra_i2c_hw_feature {
* @msg_buf: pointer to current message data
* @msg_buf_remaining: size of unsent data in the message buffer
* @msg_read: indicates that the transfer is a read access
- * @bus_clk_rate: current I2C bus clock rate
+ * @timings: i2c timings information like bus frequency
* @multimaster_mode: indicates that I2C controller is in multi-master mode
* @tx_dma_chan: DMA transmit channel
* @rx_dma_chan: DMA receive channel
@@ -273,7 +273,7 @@ struct tegra_i2c_dev {
unsigned int nclocks;
struct clk *div_clk;
- u32 bus_clk_rate;
+ struct i2c_timings timings;
struct completion msg_complete;
size_t msg_buf_remaining;
@@ -610,6 +610,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
{
u32 val, clk_divisor, clk_multiplier, tsu_thd, tlow, thigh, non_hs_mode;
acpi_handle handle = ACPI_HANDLE(i2c_dev->dev);
+ struct i2c_timings *t = _dev->timings;
int err;
/*
@@ -642,14 +643,14 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
if (i2c_dev->is_vi)
tegra_i2c_vi_init(i2c_dev);
- switch (i2c_dev->bus_clk_rate) {
+ switch (t->bus_freq_hz) {
case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
default:
tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
- if (i2c_dev->bus_clk_rate > I2C_MAX_FAST_MODE_FREQ)
+ if (t->bus_freq_hz > I2C_MAX_FAST_MODE_FREQ)
non_hs_mode = i2c_dev->hw->clk_divisor_fast_plus_mode;
else
non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
@@ -685,7 +686,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
err = clk_set_rate(i2c_dev->div_clk,
- i2c_dev->bus_clk_rate * clk_multiplier);
+ t->bus_freq_hz * clk_multiplier);
if (err) {
dev_err(i2c_dev->dev, "failed to set div-clk rate: %d\n", err);
return err;
@@ -724,7 +725,7 @@ static int tegra_i2c_disable_packet_mode(struct
tegra_i2c_dev *i2c_dev)
* before disabling the controller so that the STOP condition has
* been delivered properly.
*/
- udelay(DIV_ROUND_UP(2 * 100, i2c_dev->bus_clk_rate));
+ udelay(DIV_ROUND_UP(2 * 100, i2c_dev->timings.bus_freq_hz));
cnfg = i2c_readl(i2c_dev, I2C_CNFG);
if (cnfg & I2C_CNFG_PACKET_MODE_EN)
@@ -1254,7 +1255,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
*i2c_dev,
* Total bits = 9 bits per byte (including ACK bit) + Start & stop bits
*/
xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
- i2c_dev->bus_clk_rate);
+ i2c_dev->timings.bus_freq_hz);
int_mask = I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST;
tegra_i2c_unmask_irq(i2c_dev, int_mask);
@@ -1633,10 +1634,7 @@ static void tegra_i2c_parse_dt(struct tegra_i2c_dev
*i2c_dev)
bool multi_mode;
int err;
- err = device_property_read_u32(i2c_dev->dev, "clock-frequency",
- _dev->bus_clk_rate);
- if (err)
- i2c_dev->bus_clk_rate = I2C_MAX_STANDARD_MODE_FREQ;
+ i2c_parse_fw_timings(i2c_dev->dev, _dev->timings, true);
multi_mode = device_property_read_bool(i2c_dev->dev, "multi-master");
i2c_dev->multimaster_mode = multi_mode;
--
2.7.4
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
> wrote:
>> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
>>> Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
>> Avoid long term pinning for Coherent device type pages. This could
>> interfere with their own device memory manager.
>> If caller tries to get user device coherent pages with PIN_LONGTERM flag
>> set, those pages will be migrated back to system memory.
>>
>> Signed-off-by: Alex Sierra
>> ---
>> mm/gup.c | 32 ++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index 886d6148d3d0..1572eacf07f4 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1689,17 +1689,37 @@ struct page *get_dump_page(unsigned long addr)
>> #endif /* CONFIG_ELF_CORE */
>>
>> #ifdef CONFIG_MIGRATION
>> +static int migrate_device_page(unsigned long address,
>> +struct page *page)
>> +{
>> +struct vm_area_struct *vma = find_vma(current->mm, address);
>> +struct vm_fault vmf = {
>> +.vma = vma,
>> +.address = address & PAGE_MASK,
>> +.flags = FAULT_FLAG_USER,
>> +.pgoff = linear_page_index(vma, address),
>> +.gfp_mask = GFP_KERNEL,
>> +.page = page,
>> +};
>> +if (page->pgmap && page->pgmap->ops->migrate_to_ram)
>> +return page->pgmap->ops->migrate_to_ram();
> How does this synchronise against pgmap being released? As I understand
> things
> at this point we're not holding a reference on either the page or pgmap,
> so
> the page and therefore the pgmap may have been freed.
>
> I think a similar problem exists for device private fault handling as
> well and
> it has been on my list of things to fix for a while. I think the solution
> is to
> call try_get_page(), except it doesn't work with device pages due to the
> whole
> refcount thing. That issue is blocking a fair bit of work now so I've
> started
> looking into it.
At least the page should have been pinned by the __get_user_pages_locked
call in __gup_longterm_locked. That refcount is dropped in
check_and_migrate_movable_pages when it returns 0 or an error.
>>> Never mind. We unpin the pages first. Alex, would the migration work if
>>> we unpinned them afterwards? Also, the normal CPU page fault code path
>>> seems to make sure the page is locked (check in pfn_swap_entry_to_page)
>>> before calling migrate_to_ram.
> I don't think that's true. The check in pfn_swap_entry_to_page() is only for
> migration entries:
>
> BUG_ON(is_migration_entry(entry) && !PageLocked(p));
>
> As this is coherent memory though why do we have to call into a device driver
> to do the migration? Couldn't this all be done in the kernel?
I think you're right. I hadn't thought of that mainly because I'm even
less familiar with the non-device migration code. Alex, can you give
that a try? As long as the driver still gets a page-free callback when
the device page is freed, it should work.
Regards,
Felix
>
>> No, you can not unpinned after migration. Due to the expected_count VS
>> page_count condition at migrate_page_move_mapping, during migrate_page call.
>>
>> Regards,
>> Alex Sierra
>>
>>> Regards,
>>>Felix
>>>
>>>
>
>
Re: [PATCH v4 4/4] drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
Hi Jagan,
On Thu, Dec 09, 2021 at 12:34:49PM +0530, Jagan Teki wrote:
> On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein wrote:
> >
> > VCC needs to be enabled before releasing the enable GPIO.
> >
> > Signed-off-by: Alexander Stein
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > index 065610edc37a..54d18e82ed74 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -143,6 +144,7 @@ struct sn65dsi83 {
> > struct mipi_dsi_device *dsi;
> > struct drm_bridge *panel_bridge;
> > struct gpio_desc*enable_gpio;
> > + struct regulator*vcc;
> > int dsi_lanes;
> > boollvds_dual_link;
> > boollvds_dual_link_even_odd_swap;
> > @@ -337,6 +339,12 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
> > *bridge,
> > u16 val;
> > int ret;
> >
> > + ret = regulator_enable(ctx->vcc);
> > + if (ret) {
> > + dev_err(ctx->dev, "Failed to enable vcc\n");
> > + return;
> > + }
>
> Better check the vcc and enable it since it is an optional one.
Won't the regulator core create a dummy regulator if none is specified
in DT ?
--
Regards,
Laurent Pinchart
Re: [PATCH 0/4] drm/i915: Basic enabling of 64k page support
On 2021-12-08 at 19:46:09 +0530, Ramalingam C wrote: > Preparational patches for 64k page support. Thanks for the review. Merged these patches. Ram. > > Matthew Auld (3): > drm/i915/xehpsdv: set min page-size to 64K > drm/i915/gtt/xehpsdv: move scratch page to system memory > drm/i915: enforce min page size for scratch > > Stuart Summers (1): > drm/i915: Add has_64k_pages flag > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 +- > drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 1 + > drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 23 +++-- > drivers/gpu/drm/i915/gt/intel_ggtt.c| 3 +++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 14 - > drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++ > drivers/gpu/drm/i915/gt/intel_region_lmem.c | 5 - > drivers/gpu/drm/i915/i915_drv.h | 8 +++ > drivers/gpu/drm/i915/i915_pci.c | 2 ++ > drivers/gpu/drm/i915/intel_device_info.h| 1 + > drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 ++ > 11 files changed, 62 insertions(+), 5 deletions(-) > > -- > 2.20.1 >
RE: [PATCH v4 2/6] drm: improve drm_buddy_alloc function
[AMD Official Use Only]
Hi Matthew,
Ping on this?
Regards,
Arun
-Original Message-
From: amd-gfx On Behalf Of Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: dan...@ffwll.ch; Paneer Selvam, Arunpravin
; jani.nik...@linux.intel.com;
matthew.a...@intel.com; tzimmerm...@suse.de; Deucher, Alexander
; Koenig, Christian
Subject: [PATCH v4 2/6] drm: improve drm_buddy_alloc function
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 driver to drm buddy
v2:
merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make alloc_range() block allocations as bottom-up
- optimize order computation logic
- replace uint64_t with u64, which is preferred in the kernel
v4(Matthew Auld):
- keep drm_buddy_alloc_range() function implementation for generic
actual range allocations
- keep alloc_range() implementation for end bias allocations
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 316 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 67 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +
include/drm/drm_buddy.h | 22 +-
4 files changed, 285 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index
9340a4b61c5a..7f47632821f4 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -280,23 +280,97 @@ void drm_buddy_free_list(struct drm_buddy_mm *mm, struct
list_head *objects) } EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the _buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order)
+static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2) {
+ return s1 <= e2 && e1 >= s2;
+}
+
+static inline bool contains(u64 s1, u64 e1, u64 s2, u64 e2) {
+ return s1 <= s2 && e1 >= e2;
+}
+
+static struct drm_buddy_block *
+alloc_range_bias(struct drm_buddy_mm *mm,
+u64 start, u64 end,
+unsigned int order)
+{
+ struct drm_buddy_block *block;
+ struct drm_buddy_block *buddy;
+ LIST_HEAD(dfs);
+ int err;
+ int i;
+
+ end = end - 1;
+
+ for (i = 0; i < mm->n_roots; ++i)
+ list_add_tail(>roots[i]->tmp_link, );
+
+ do {
+ u64 block_start;
+ u64 block_end;
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+tmp_link);
+ if (!block)
+ break;
+
+ list_del(>tmp_link);
+
+ if (drm_buddy_block_order(block) < order)
+ continue;
+
+ block_start = drm_buddy_block_offset(block);
+ block_end = block_start + drm_buddy_block_size(mm, block) - 1;
+
+ if (!overlaps(start, end, block_start, block_end))
+ continue;
+
+ if (drm_buddy_block_is_allocated(block))
+ continue;
+
+ if (contains(start, end, block_start, block_end) &&
+ order == drm_buddy_block_order(block)) {
+ /*
+* Find the free block within the range.
+*/
+ if (drm_buddy_block_is_free(block))
+ return block;
+
+ continue;
+ }
+
+ if (!drm_buddy_block_is_split(block)) {
+ err = split_block(mm, block);
+ if (unlikely(err))
+ goto err_undo;
+ }
+
+ list_add(>right->tmp_link, );
+ list_add(>left->tmp_link, );
+ } while (1);
+
+ return ERR_PTR(-ENOSPC);
+
+err_undo:
+ /*
+* We really don't want to leave around a bunch of split blocks, since
+* bigger is better, so make sure we merge everything back before
RE: [PATCH v4 4/6] drm: implement a method to free unused pages
[Public]
Hi Matthew,
Ping?
Regards,
Arun
-Original Message-
From: Paneer Selvam, Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: matthew.a...@intel.com; dan...@ffwll.ch; Koenig, Christian
; Deucher, Alexander ;
tzimmerm...@suse.de; jani.nik...@linux.intel.com; Paneer Selvam, Arunpravin
Subject: [PATCH v4 4/6] drm: implement a method to free unused pages
On contiguous allocation, we round up the size to the *next* power of 2,
implement a function to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input argument name 'actual_size' with 'new_size'
- add more validation checks for input arguments
- add overlaps check to avoid needless searching and splitting
- merged the below patch to see the feature in action
- add free unused pages support to i915 driver
- lock drm_buddy_block_trim() function as it calls mark_free/mark_split
are all globally visible
v3:
- remove drm_buddy_block_trim() error handling and
print a warn message if it fails
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 72 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 +++
include/drm/drm_buddy.h | 4 ++
3 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index
eddc1eeda02e..707efc82216d 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -434,7 +434,8 @@ alloc_from_freelist(struct drm_buddy_mm *mm, static int
__alloc_range(struct drm_buddy_mm *mm,
struct list_head *dfs,
u64 start, u64 size,
-struct list_head *blocks)
+struct list_head *blocks,
+bool trim_path)
{
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
@@ -480,8 +481,20 @@ static int __alloc_range(struct drm_buddy_mm *mm,
if (!drm_buddy_block_is_split(block)) {
err = split_block(mm, block);
- if (unlikely(err))
+ if (unlikely(err)) {
+ if (trim_path)
+ /*
+* Here in case of trim, we return and
dont goto
+* split failure path as it removes
from the
+* original list and potentially also
freeing
+* the block. so we could leave as it
is,
+* worse case we get some internal
fragmentation
+* and leave the decision to the user
+*/
+ return err;
+
goto err_undo;
+ }
}
list_add(>right->tmp_link, dfs); @@ -535,8 +548,61 @@
static int __drm_buddy_alloc_range(struct drm_buddy_mm *mm,
for (i = 0; i < mm->n_roots; ++i)
list_add_tail(>roots[i]->tmp_link, );
- return __alloc_range(mm, , start, size, blocks);
+ return __alloc_range(mm, , start, size, blocks, 0); }
+
+/**
+ * drm_buddy_block_trim - free unused pages
+ *
+ * @mm: DRM buddy manager
+ * @new_size: original size requested
+ * @blocks: output list head to add allocated blocks
+ *
+ * For contiguous allocation, we round up the size to the nearest
+ * power of two value, drivers consume *actual* size, so remaining
+ * portions are unused and it can be freed.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_block_trim(struct drm_buddy_mm *mm,
+u64 new_size,
+struct list_head *blocks)
+{
+ struct drm_buddy_block *block;
+ u64 new_start;
+ LIST_HEAD(dfs);
+
+ if (!list_is_singular(blocks))
+ return -EINVAL;
+
+ block = list_first_entry(blocks,
+struct drm_buddy_block,
+link);
+
+ if (!drm_buddy_block_is_allocated(block))
+ return -EINVAL;
+
+ if (new_size > drm_buddy_block_size(mm, block))
+ return -EINVAL;
+
+ if (!new_size && !IS_ALIGNED(new_size, mm->chunk_size))
+ return -EINVAL;
+
+ if (new_size == drm_buddy_block_size(mm, block))
+ return 0;
+
+ list_del(>link);
+
+ new_start = drm_buddy_block_offset(block);
+
+ mark_free(mm, block);
+
+ list_add(>tmp_link, );
+
+ return __alloc_range(mm, , new_start, new_size, blocks, 1);
}
Re: [PATCH 2/2] i2c: tegra: Add SMBus block read and SMBus alert functions
09.12.2021 18:33, Andy Shevchenko пишет:
> On Thu, Dec 9, 2021 at 5:30 PM Dmitry Osipenko wrote:
>> 09.12.2021 18:05, Akhil R пишет:
>>> +static int tegra_i2c_setup_smbalert(struct tegra_i2c_dev *i2c_dev)
>>> +{
>>> + struct tegra_i2c_smbalert *smbalert = _dev->smbalert;
>>> + struct gpio_desc *alert_gpiod;
>>> + struct i2c_client *ara;
>>> +
>>> + alert_gpiod = devm_gpiod_get(i2c_dev->dev, "smbalert", GPIOD_IN);
>>> + if (IS_ERR(alert_gpiod))
>>> + return PTR_ERR(alert_gpiod);
>>> +
>>> + smbalert->alert_data.irq = gpiod_to_irq(alert_gpiod);
>>> + if (smbalert->alert_data.irq <= 0)
>>> + return smbalert->alert_data.irq;
>>
>> 0 is the error condition.
>
> I'm not sure what you implied here. gpiod_to_irq() returns 0 if and
> only if it goes to the architectures where it might be possible to
> have valid vIRQ 0, but this is not the case (at least I never heard of
> a such) for GPIO controllers on such platforms. So, looking at the
> above code I may tell that the '=' part is redundant.
>
Yes, removal of the '=' should be enough here.
[PATCH v4 02/16] drm/i915/xehpsdv: support 64K GTT pages
From: Matthew Auld
XEHPSDV optimises 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 109 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 170 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c69c7d45aabc..bd8dc1a28022 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1483,6 +1483,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return err;
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1740,6 +1799,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index b012c50f7ce7..8d081497e87e 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
atomic_sub(count, >used);
start += count;
@@ -453,6 +463,96 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
return
[PATCH 1/2] drm/amd/display: Reduce stack size for dml31_ModeSupportAndSystemConfigurationFull
From: Michel Dänzer
Move code using the Pipe struct to a new helper function.
Works around[0] this warning (resulting in failure to build a RHEL debug
kernel with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function ‘dml31_ModeSupportAndSystemConfigurationFull’:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:5740:1:
warning: the frame size of 2144 bytes is larger than 2048 bytes
[-Wframe-larger-than=]
The culprit seems to be the Pipe struct, so pull the relevant block out
into its own sub-function. (This is porting
a62427ef9b55 "drm/amd/display: Reduce stack size for
dml21_ModeSupportAndSystemConfigurationFull"
from dml31 to dml21)
[0] AFAICT this doesn't actually reduce the total amount of stack which
can be used, just moves some of it from
dml31_ModeSupportAndSystemConfigurationFull to the new helper function,
so the former happens to no longer exceed the limit for a single
function.
Signed-off-by: Michel Dänzer
---
.../dc/dml/dcn31/display_mode_vba_31.c| 185 ++
1 file changed, 99 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index 7e937bdcea00..8965f9af9d0a 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -3949,6 +3949,102 @@ static double TruncToValidBPP(
return BPP_INVALID;
}
+static noinline void CalculatePrefetchSchedulePerPlane(
+ struct display_mode_lib *mode_lib,
+ double HostVMInefficiencyFactor,
+ int i,
+ unsigned j,
+ unsigned k)
+{
+ struct vba_vars_st *v = _lib->vba;
+ Pipe myPipe;
+
+ myPipe.DPPCLK = v->RequiredDPPCLK[i][j][k];
+ myPipe.DISPCLK = v->RequiredDISPCLK[i][j];
+ myPipe.PixelClock = v->PixelClock[k];
+ myPipe.DCFCLKDeepSleep = v->ProjectedDCFCLKDeepSleep[i][j];
+ myPipe.DPPPerPlane = v->NoOfDPP[i][j][k];
+ myPipe.ScalerEnabled = v->ScalerEnabled[k];
+ myPipe.SourceScan = v->SourceScan[k];
+ myPipe.BlockWidth256BytesY = v->Read256BlockWidthY[k];
+ myPipe.BlockHeight256BytesY = v->Read256BlockHeightY[k];
+ myPipe.BlockWidth256BytesC = v->Read256BlockWidthC[k];
+ myPipe.BlockHeight256BytesC = v->Read256BlockHeightC[k];
+ myPipe.InterlaceEnable = v->Interlace[k];
+ myPipe.NumberOfCursors = v->NumberOfCursors[k];
+ myPipe.VBlank = v->VTotal[k] - v->VActive[k];
+ myPipe.HTotal = v->HTotal[k];
+ myPipe.DCCEnable = v->DCCEnable[k];
+ myPipe.ODMCombineIsEnabled = v->ODMCombineEnablePerState[i][k] ==
dm_odm_combine_mode_4to1
+ || v->ODMCombineEnablePerState[i][k] ==
dm_odm_combine_mode_2to1;
+ myPipe.SourcePixelFormat = v->SourcePixelFormat[k];
+ myPipe.BytePerPixelY = v->BytePerPixelY[k];
+ myPipe.BytePerPixelC = v->BytePerPixelC[k];
+ myPipe.ProgressiveToInterlaceUnitInOPP =
v->ProgressiveToInterlaceUnitInOPP;
+ v->NoTimeForPrefetch[i][j][k] = CalculatePrefetchSchedule(
+ mode_lib,
+ HostVMInefficiencyFactor,
+ ,
+ v->DSCDelayPerState[i][k],
+ v->DPPCLKDelaySubtotal + v->DPPCLKDelayCNVCFormater,
+ v->DPPCLKDelaySCL,
+ v->DPPCLKDelaySCLLBOnly,
+ v->DPPCLKDelayCNVCCursor,
+ v->DISPCLKDelaySubtotal,
+ v->SwathWidthYThisState[k] / v->HRatio[k],
+ v->OutputFormat[k],
+ v->MaxInterDCNTileRepeaters,
+ dml_min(v->MaxVStartup, v->MaximumVStartup[i][j][k]),
+ v->MaximumVStartup[i][j][k],
+ v->GPUVMMaxPageTableLevels,
+ v->GPUVMEnable,
+ v->HostVMEnable,
+ v->HostVMMaxNonCachedPageTableLevels,
+ v->HostVMMinPageSize,
+ v->DynamicMetadataEnable[k],
+ v->DynamicMetadataVMEnabled,
+ v->DynamicMetadataLinesBeforeActiveRequired[k],
+ v->DynamicMetadataTransmittedBytes[k],
+ v->UrgLatency[i],
+ v->ExtraLatency,
+ v->TimeCalc,
+ v->PDEAndMetaPTEBytesPerFrame[i][j][k],
+ v->MetaRowBytes[i][j][k],
+ v->DPTEBytesPerRow[i][j][k],
+ v->PrefetchLinesY[i][j][k],
+ v->SwathWidthYThisState[k],
+ v->PrefillY[k],
+ v->MaxNumSwY[k],
+ v->PrefetchLinesC[i][j][k],
+ v->SwathWidthCThisState[k],
+ v->PrefillC[k],
+ v->MaxNumSwC[k],
+ v->swath_width_luma_ub_this_state[k],
+ v->swath_width_chroma_ub_this_state[k],
+ v->SwathHeightYThisState[k],
+ v->SwathHeightCThisState[k],
+
[PATCH v4 11/16] drm/i915/dg2: Add DG2 unified compression
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the actual
compression algorithm is different from any previous platform; as such,
we need a new framebuffer modifier to represent buffers in this format,
but otherwise we can re-use the existing gen12 compression driver logic.
Signed-off-by: Matt Roper
cc: Radhakrishna Sripada
Signed-off-by: Mika Kahola (v2)
cc: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_fb.c | 13
.../drm/i915/display/skl_universal_plane.c| 33 +++
include/uapi/drm/drm_fourcc.h | 22 +
3 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 46505c69fe72..e15216f1cb82 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -141,6 +141,14 @@ struct intel_modifier_desc {
static const struct intel_modifier_desc intel_modifiers[] = {
{
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
+ .display_ver = { 13, 14 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
+ .display_ver = { 13, 14 },
+ .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
+ }, {
.modifier = I915_FORMAT_MOD_4_TILED,
.display_ver = { 13, 14 },
.plane_caps = INTEL_PLANE_CAP_TILING_4,
@@ -550,6 +558,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
case I915_FORMAT_MOD_4_TILED:
/*
* Each 4K tile consists of 64B(8*8) subtiles, with
@@ -752,6 +762,9 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ return 16 * 1024;
default:
MISSING_CASE(fb->modifier);
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index f62ba027fcf9..d80424194c75 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -764,6 +764,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_Y;
case I915_FORMAT_MOD_4_TILED:
return PLANE_CTL_TILED_4;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ return PLANE_CTL_TILED_4 |
+ PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ return PLANE_CTL_TILED_4 |
+ PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
+ PLANE_CTL_CLEAR_COLOR_DISABLE;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return PLANE_CTL_TILED_Y |
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
@@ -2073,6 +2081,10 @@ static bool gen12_plane_has_mc_ccs(struct
drm_i915_private *i915,
if (IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
return false;
+ /* Wa_14013215631 */
+ if (IS_DG2_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
+ return false;
+
return plane_id < PLANE_SPRITE4;
}
@@ -2312,18 +2324,25 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
break;
case PLANE_CTL_TILED_Y:
plane_config->tiling = I915_TILING_Y;
- if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
- fb->modifier = DISPLAY_VER(dev_priv) >= 12 ?
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS :
- I915_FORMAT_MOD_Y_TILED_CCS;
- else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
+ if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) {
+ if (DISPLAY_VER(dev_priv) >= 12)
+ fb->modifier =
I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS;
+ else
+ fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
+ } else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE) {
fb->modifier =
[PATCH v4 2/3] drm/i915: Sanitycheck device iomem on probe
From: Chris Wilson
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.
v2: wrapper for memtest [Chris]
v3: Removed the unused ptr i915 [Chris]
v4: used the %pa for the resource_size_t.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/intel_memory_region.c | 116 +
1 file changed, 116 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index b43121609e25..7bfb6df02e72 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -3,6 +3,8 @@
* Copyright © 2019 Intel Corporation
*/
+#include
+
#include "intel_memory_region.h"
#include "i915_drv.h"
#include "i915_ttm_buddy_manager.h"
@@ -29,6 +31,99 @@ static const struct {
},
};
+static int __iopagetest(struct intel_memory_region *mem,
+ u8 __iomem *va, int pagesize,
+ u8 value, resource_size_t offset,
+ const void *caller)
+{
+ int byte = prandom_u32_max(pagesize);
+ u8 result[3];
+
+ memset_io(va, value, pagesize); /* or GPF! */
+ wmb();
+
+ result[0] = ioread8(va);
+ result[1] = ioread8(va + byte);
+ result[2] = ioread8(va + pagesize - 1);
+ if (memchr_inv(result, value, sizeof(result))) {
+ dev_err(mem->i915->drm.dev,
+ "Failed to read back from memory region:%pR at [%pa +
%pa] for %ps; wrote %x, read (%x, %x, %x)\n",
+ >region, >io_start, , caller,
+ value, result[0], result[1], result[2]);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int iopagetest(struct intel_memory_region *mem,
+ resource_size_t offset,
+ const void *caller)
+{
+ const u8 val[] = { 0x0, 0xa5, 0xc3, 0xf0 };
+ void __iomem *va;
+ int err;
+ int i;
+
+ va = ioremap_wc(mem->io_start + offset, PAGE_SIZE);
+ if (!va) {
+ dev_err(mem->i915->drm.dev,
+ "Failed to ioremap memory region [%pa + %pa] for %ps\n",
+ >io_start, , caller);
+ return -EFAULT;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(val); i++) {
+ err = __iopagetest(mem, va, PAGE_SIZE, val[i], offset, caller);
+ if (err)
+ break;
+
+ err = __iopagetest(mem, va, PAGE_SIZE, ~val[i], offset, caller);
+ if (err)
+ break;
+ }
+
+ iounmap(va);
+ return err;
+}
+
+static resource_size_t random_page(resource_size_t last)
+{
+ /* Limited to low 44b (16TiB), but should suffice for a spot check */
+ return prandom_u32_max(last >> PAGE_SHIFT) << PAGE_SHIFT;
+}
+
+static int iomemtest(struct intel_memory_region *mem, const void *caller)
+{
+ resource_size_t last = resource_size(>region) - PAGE_SIZE;
+ int err;
+
+ /*
+* Quick test to check read/write access to the iomap (backing store).
+*
+* Write a byte, read it back. If the iomapping fails, we expect
+* a GPF preventing further execution. If the backing store does not
+* exist, the read back will return garbage. We check a couple of pages,
+* the first and last of the specified region to confirm the backing
+* store + iomap does cover the entire memory region; and we check
+* a random offset within as a quick spot check for bad memory.
+*/
+
+ err = iopagetest(mem, 0, caller);
+ if (err)
+ return err;
+
+ err = iopagetest(mem, last, caller);
+ if (err)
+ return err;
+
+ err = iopagetest(mem, random_page(last), caller);
+ if (err)
+ return err;
+
+ return 0;
+}
+
struct intel_memory_region *
intel_memory_region_lookup(struct drm_i915_private *i915,
u16 class, u16 instance)
@@ -90,6 +185,20 @@ void intel_memory_region_debug(struct intel_memory_region
*mr,
>total, >avail);
}
+static int intel_memory_region_memtest(struct intel_memory_region *mem,
+ void *caller)
+{
+ int err = 0;
+
+ if (!mem->io_start)
+ return 0;
+
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ err = iomemtest(mem, caller);
+
+ return err;
+}
+
struct intel_memory_region *
intel_memory_region_create(struct drm_i915_private *i915,
resource_size_t start,
@@ -126,8 +235,15 @@ intel_memory_region_create(struct
Re: [PATCH 1/2] dt-bindings: i2c: tegra: Add SMBus feature properties
On Thu, Dec 9, 2021 at 5:05 PM Akhil R wrote: > > Tegra I2C can use a gpio as an smbus-alert. Document the usage of > the same. ... > +optional properties: Optional > +- smbalert-gpio: Must contain an entry for the gpio to be used as smbus > alert. -gpios (the suffix in plural form, the singular is a legacy one) > + It will be used only if optional smbus-alert property is present. -- With Best Regards, Andy Shevchenko
RE: [PATCH 1/2] drm/i915: Introduce new Tile 4 format
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Thursday, December 9, 2021 5:47 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Lisovskiy, Stanislav
> ; Saarinen, Jani ; C,
> Ramalingam ; ville.syrj...@linux.intel.com; Deak,
> Imre ; Chery, Nanley G
> Subject: [PATCH 1/2] drm/i915: Introduce new Tile 4 format
>
We want this patch to be 2/2, right? That way, we expose public kernel support
for the format after the kernel gains internal support for it.
With that fixed, this patch is:
Acked-by: Nanley Chery
Alternatively, you could apply the ack to the prior combined patch if you'd
like.
-Nanley
> This tiling layout uses 4KB tiles in a row-major layout. It has the same
> shape as
> Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It only
> differs from
> Tile Y at the 256B granularity in between. At this granularity, Tile Y has a
> shape
> of 16B x 32 rows, but this tiling has a shape of 64B x 8 rows.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> include/uapi/drm/drm_fourcc.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 7f652c96845b..a146c6df1066 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -565,6 +565,17 @@ extern "C" {
> */
> #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC
> fourcc_mod_code(INTEL, 8)
>
> +/*
> + * Intel Tile 4 layout
> + *
> + * This is a tiled layout using 4KB tiles in a row-major layout. It has
> +the same
> + * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x
> +4). It
> + * only differs from Tile Y at the 256B granularity in between. At this
> + * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling
> +has a shape
> + * of 64B x 8 rows.
> + */
> +#define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
> +
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> *
> --
> 2.24.1.485.gad05a3d8e5
[PATCH v4 13/16] drm/i915/dg2: Flat CCS Support
From: Anshuman Gupta
DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displayable surfaces must use tile4 format.
HAS: 1407880786
B.Spec : 7655
B.Spec : 53902
Cc: Mika Kahola
Signed-off-by: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fb.c | 32 +--
.../drm/i915/display/skl_universal_plane.c| 14 +---
3 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 83253c62b6d6..fd84ed0da41c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8628,7 +8628,9 @@ static void
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
/*
* The layout of the fast clear color value expected by HW
-* (the DRM ABI requiring this value to be located in fb at
offset 0 of plane#2):
+* (the DRM ABI requiring this value to be located in fb at
+* offset 0 of cc plane, plane #2 previous generations or
+* plane #1 for flat ccs):
* - 4 x 4 bytes per-channel value
* (in surface type specific float/int format provided by the
fb user)
* - 8 bytes native color value used by the display
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index f10e77cb5b4a..72040f580911 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -107,6 +107,21 @@ static const struct drm_format_info gen12_ccs_cc_formats[]
= {
.hsub = 1, .vsub = 1, .has_alpha = true },
};
+static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+};
+
struct intel_modifier_desc {
u64 modifier;
struct {
@@ -150,6 +165,8 @@ static const struct intel_modifier_desc intel_modifiers[] =
{
.plane_caps = INTEL_PLANE_CAP_TILING_4 |
INTEL_PLANE_CAP_CCS_RC_CC,
.ccs.cc_planes = BIT(1),
+
+ FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
}, {
.modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
.display_ver = { 13, 14 },
@@ -399,17 +416,13 @@ bool intel_fb_plane_supports_modifier(struct intel_plane
*plane, u64 modifier)
static bool format_is_yuv_semiplanar(const struct intel_modifier_desc *md,
const struct drm_format_info *info)
{
- int yuv_planes;
-
if (!info->is_yuv)
return false;
- if (plane_caps_contain_any(md->plane_caps, INTEL_PLANE_CAP_CCS_MASK))
- yuv_planes = 4;
+ if (hweight8(md->ccs.planar_aux_planes) == 2)
+ return info->num_planes == 4;
else
- yuv_planes = 2;
-
- return info->num_planes == yuv_planes;
+ return info->num_planes == 2;
}
/**
@@ -534,12 +547,13 @@ static unsigned int gen12_ccs_aux_stride(struct
intel_framebuffer *fb, int ccs_p
int skl_main_to_aux_plane(const struct drm_framebuffer *fb, int main_plane)
{
+ const struct intel_modifier_desc *md = lookup_modifier(fb->modifier);
struct drm_i915_private *i915 = to_i915(fb->dev);
- if (intel_fb_is_ccs_modifier(fb->modifier))
+ if (md->ccs.packed_aux_planes | md->ccs.planar_aux_planes)
return main_to_ccs_plane(fb, main_plane);
else if (DISPLAY_VER(i915) < 11 &&
-intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
+format_is_yuv_semiplanar(md, fb->format))
return 1;
else
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 9a89df9c0243..ed2883409e91 100644
---
