Re: [PATCH] drm/atomic-helper: Validate pointer before dereference
Hi,
> - if (funcs->atomic_enable)
> - funcs->atomic_enable(crtc, old_crtc_state);
> - else
> - funcs->commit(crtc);
> + if (funcs) {
> + if (funcs->atomic_enable)
> + funcs->atomic_enable(crtc,
> + old_crtc_state);
> + else if (funcs->atomic_enable)
"if (funcs->commit)" I guess?
> + funcs->commit(crtc);
> + }
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: don't block fb changes for async plane updates
On Mon, 11 Mar 2019 23:22:03 -0300
Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are performed in the old_state.
>
> In the case of async updates, the preparation is also done in the
> new_state but the cleanups are done in the new_state (because updates
> are performed in place, i.e. in the current state).
>
> The current code blocks async udpates when the fb is changed, turning
> async updates into sync updates, slowing down cursor updates and
> introducing regressions in igt tests with errors of type:
>
> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> expect to complete approximately 15360 updates, with the threshold set
> at 7680"
>
> Fb changes in async updates were prevented to avoid the following scenario:
>
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
> Where we have a single call to prepare fb2 but double cleanup call to fb2.
>
> To solve the above problems, instead of blocking async fb changes, we
> place the old framebuffer in the new_state object, so when the code
> performs cleanups in the new_state it will cleanup the old_fb and we
> will have the following scenario instead:
>
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>
> Where calls to prepare/cleanup are balanced.
>
> Cc: # v4.14+
> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> Suggested-by: Boris Brezillon
> Signed-off-by: Helen Koike
Reviewed-by: Boris Brezillon
>
> ---
> Hello,
>
> As mentioned in the cover letter, I tested in almost all platforms with
> igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
> regressions. But I couldn't test on MSM and AMD because I don't have
> the hardware I would appreciate if anyone could help me testing those.
>
> Thanks!
> Helen
>
> Changes in v2:
> - Change the order of the patch in the series, add this as the last one.
> - Add documentation
> - s/ballanced/balanced
>
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> include/drm/drm_modeset_helper_vtables.h | 5 +
> 2 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..e7eb96f1efc2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device
> *dev,
> old_plane_state->crtc != new_plane_state->crtc)
> return -EINVAL;
>
> - /*
> - * FIXME: Since prepare_fb and cleanup_fb are always called on
> - * the new_plane_state for async updates we need to block framebuffer
> - * changes. This prevents use of a fb that's been cleaned up and
> - * double cleanups from occuring.
> - */
> - if (old_plane_state->fb != new_plane_state->fb)
> - return -EINVAL;
> -
> funcs = plane->helper_private;
> if (!funcs->atomic_async_update)
> return -EINVAL;
> @@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device
> *dev,
> int i;
>
> for_each_new_plane_in_state(state, plane, plane_state, i) {
> + struct drm_framebuffer *new_fb = plane_state->fb;
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
> funcs = plane->helper_private;
> funcs->atomic_async_update(plane, plane_state);
>
> @@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct drm_device
> *dev,
>* plane->state in-place, make sure at least common
>* properties have been properly updated.
>*/
> - WARN_ON_ONCE(plane->state->fb != plane_state->fb);
> + WARN_ON_ONCE(plane->state->fb != new_fb);
> WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
> WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
> WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
> WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
> +
> + /*
> + * Make sure the FBs have been swapped so that cleanups in the
> + * new_state performs a cleanup in the old FB.
> + */
> + WARN_ON_ONCE(plane_state->fb != old_fb);
> }
> }
> EXPORT_SYMBOL(drm_atomic_helper_async_commit);
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vta
Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update
On Mon, 11 Mar 2019 23:21:59 -0300
Helen Koike wrote:
> In the case of async update, modifications are done in place, i.e. in the
> current plane state, so the new_state is prepared and the new_state is
> cleanup up (instead of the old_state, diferrently on what happen in a
^ cleaned up ^ differently (but maybe
"unlike what happens" is more appropriate here).
> normal sync update).
> To cleanup the old_fb properly, it needs to be placed in the new_state
> in the end of async_update, so cleanup call will unreference the old_fb
> correctly.
>
> Also, the previous code had a:
>
> plane_state = plane->funcs->atomic_duplicate_state(plane);
> ...
> swap(plane_state, plane->state);
>
> if (plane->state->fb && plane->state->fb != new_state->fb) {
> ...
> }
>
> Which was wrong, as the fb were just assigned to be equal, so this if
> statement nevers evaluates to true.
>
> Another details is that the function drm_crtc_vblank_get() can only be
> called when vop->is_enabled is true, otherwise it has no effect and
> trows a WARN_ON().
>
> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> fb and pus the old fb) is not required, as it is taken care by
> drm_mode_cursor_universal() when calling
> drm_atomic_helper_update_plane().
>
> Signed-off-by: Helen Koike
>
> ---
> Hello,
>
> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> kms_cursor_legacy and I didn't see any regressions.
>
> Changes in v2: None
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> 1 file changed, 24 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c7d4c6073ea5..a1ee8c156a7b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
> drm_plane *plane,
> struct drm_plane_state *new_state)
> {
> struct vop *vop = to_vop(plane->state->crtc);
> - struct drm_plane_state *plane_state;
> + struct drm_framebuffer *old_fb = plane->state->fb;
>
> - plane_state = plane->funcs->atomic_duplicate_state(plane);
> - plane_state->crtc_x = new_state->crtc_x;
> - plane_state->crtc_y = new_state->crtc_y;
> - plane_state->crtc_h = new_state->crtc_h;
> - plane_state->crtc_w = new_state->crtc_w;
> - plane_state->src_x = new_state->src_x;
> - plane_state->src_y = new_state->src_y;
> - plane_state->src_h = new_state->src_h;
> - plane_state->src_w = new_state->src_w;
> -
> - if (plane_state->fb != new_state->fb)
> - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> -
> - swap(plane_state, plane->state);
> -
> - if (plane->state->fb && plane->state->fb != new_state->fb) {
> + /*
> + * A scanout can still be occurring, so we can't drop the reference to
> + * the old framebuffer. To solve this we get a reference to old_fb and
> + * set a worker to release it later.
Hm, doesn't look like an async update to me if we have to wait for the
next VBLANK to happen to get the new content on the screen. Maybe we
should reject async updates when old_fb != new_fb in the rk
->async_check() hook.
> + */
> + if (vop->is_enabled &&
> + plane->state->fb && plane->state->fb != new_state->fb) {
> drm_framebuffer_get(plane->state->fb);
> WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
> drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
> set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
> }
In any case, I think this should be called after
vop_plane_atomic_update() to prevent the situation where the VBLANK
event happens between this point and the following
vop_plane_atomic_update() call.
>
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + plane->state->crtc_h = new_state->crtc_h;
> + plane->state->crtc_w = new_state->crtc_w;
> + plane->state->src_x = new_state->src_x;
> + plane->state->src_y = new_state->src_y;
> + plane->state->src_h = new_state->src_h;
> + plane->state->src_w = new_state->src_w;
> + plane->state->fb = new_state->fb;
Any reason not to use swap() here and reference plane->state->fb
instead of new_state->fb after this point?
> +
> if (vop->is_enabled) {
> rockchip_drm_psr_inhibit_get_state(new_state->state);
> vop_plane_atomic_update(plane, plane->state);
> @@ -945,7 +946,12 @@ static void vop_plane_atomic_async_update(struct
> drm_plane *plane,
> rockchip_drm_psr_inhibit_put_state(new_state->state);
> }
>
> - plane->funcs->atomic_destroy_state(plane, plane_state);
> + /*
> + * In async update we perform inplace modifica
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #26 from Tim Carr --- Edit to my above statement about the amd-staging-drm-next kernel working. Either, I had forgotten to return the raven_dmcu.bin file to it's appropriate folder when I tested it, or upgrading my bios to F.20 messed it up again. I'm now back at the point I was before (Same as comment #24). If Magic SysReq is enabled on the system it can be used to reboot the system safely rather than a hard powerdown. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109970] Personal Banking Button Is Not available
https://bugs.freedesktop.org/show_bug.cgi?id=109970 Bug ID: 109970 Summary: Personal Banking Button Is Not available Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Windows (All) Status: NEW Severity: critical Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: vijaya.so...@gmail.com Created attachment 143630 --> https://bugs.freedesktop.org/attachment.cgi?id=143630&action=edit login page Enter Valid URL Click on GO Click on VisitorFlow Functionlity as Per Table -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v3
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 103 +
include/uapi/drm/drm.h | 1 +
4 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index dd11ae5f1eef..d9a483a5fce0 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 92b3b7b2fd81..d337f161909c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL,
drm_syncobj_timeline_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index f1d18d10d1f2..78fc1c029339 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1174,6 +1174,109 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+int
+drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_array *args = data;
+ struct drm_syncobj **syncobjs;
+ struct dma_fence_chain **chains;
+ uint64_t *points;
+ uint32_t i, j, timeline_count = 0;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -EOPNOTSUPP;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < args->count_handles; i++) {
+ struct dma_fence_chain *chain;
+struct dma_fence *fence;
+
+fence = drm_syncobj_fence_get(syncobjs[i]);
+chain = to_dma_fence_chain(fence);
+if (chain) {
+struct dma_fence *iter;
+
+dma_fence_chain_for_each(iter, fence) {
+if (!iter)
+break;
+ if (!dma_fence_is_signaled(iter)) {
+ dma_fence_put(iter);
+ DRM_ERROR("Client must guarantee all
existing timeline points signaled before performing host signal operation!");
+ ret = -EPERM;
+ goto out;
+ }
+}
+}
+}
+
+ points = kmalloc_array(args->count_handles, sizeof(*points),
+ GFP_KERNEL);
+ if (!points) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ if (!u64_to_user_ptr(args->points)) {
+ memset(points, 0, args->count_handles * sizeof(uint64_t));
+ } else if (copy_from_user(points, u64_to_user_ptr(args->points),
+ sizeof(uint64_t) * args->count_handles)) {
+ ret = -EFAULT;
+ goto err_points;
+ }
+
+
+ for (i = 0; i < args->count_handles; i++) {
+ if (points[i])
+ timeline_count++;
+ }
+ chains = kmalloc_array(timeline_count, sizeof(void *), GFP_KERNEL);
+ if (!chains) {
+ ret = -ENOMEM;
+ goto err_poi
[PATCH 6/9] drm/amdgpu: add timeline support in amdgpu CS v3
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Christian König
Cc: Chris Wilson
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 152 +
include/uapi/drm/amdgpu_drm.h | 8 ++
3 files changed, 144 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8d0d7f3dd5fb..deec2c796253 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -433,6 +433,12 @@ struct amdgpu_cs_chunk {
void*kdata;
};
+struct amdgpu_cs_post_dep {
+ struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
+ u64 point;
+};
+
struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -462,8 +468,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
- unsigned num_post_dep_syncobjs;
- struct drm_syncobj **post_dep_syncobjs;
+ unsignednum_post_deps;
+ struct amdgpu_cs_post_dep *post_deps;
};
static inline u32 amdgpu_get_ib_value(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 52a5e4fdc95b..2f6239b6be6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -215,6 +215,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
case AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
default:
@@ -804,9 +806,11 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser
*parser, int error,
ttm_eu_backoff_reservation(&parser->ticket,
&parser->validated);
- for (i = 0; i < parser->num_post_dep_syncobjs; i++)
- drm_syncobj_put(parser->post_dep_syncobjs[i]);
- kfree(parser->post_dep_syncobjs);
+ for (i = 0; i < parser->num_post_deps; i++) {
+ drm_syncobj_put(parser->post_deps[i].syncobj);
+ kfree(parser->post_deps[i].chain);
+ }
+ kfree(parser->post_deps);
dma_fence_put(parser->fence);
@@ -1117,13 +1121,18 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
}
static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
-uint32_t handle)
+uint32_t handle, u64 point,
+u64 flags)
{
- int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, 0, &fence);
- if (r)
+ int r;
+
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags, &fence);
+ if (r) {
+ DRM_ERROR("syncobj %u failed to find fence @ %llu (%d)!\n",
+ handle, point, r);
return r;
+ }
r = amdgpu_sync_fence(p->adev, &p->job->sync, fence, true);
dma_fence_put(fence);
@@ -1134,46 +1143,118 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
struct amdgpu_cs_chunk *chunk)
{
+ struct drm_amdgpu_cs_chunk_sem *deps;
unsigned num_deps;
int i, r;
- struct drm_amdgpu_cs_chunk_sem *deps;
deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
num_deps = chunk->length_dw * 4 /
sizeof(struct drm_amdgpu_cs_chunk_sem);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle,
+ 0, 0);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+static int amdgpu_cs_process_syncobj_timeline_in_dep(struct amdgpu_cs_parser
*p,
+struct amdgpu_cs_chunk
*chunk)
+{
+ struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+ unsigned num_deps;
+ int i, r;
+
+ syncobj_deps = (struct drm_amdgpu_cs_chunk_syncobj *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_syncobj);
for (i = 0; i < num_deps; ++i) {
- r = amdgpu_s
[PATCH 9/9] drm/amdgpu: update version for timeline syncobj support in amdgpu
Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 8a0732088640..4d8db87048d3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -74,9 +74,10 @@ * - 3.28.0 - Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES * - 3.29.0 - Add AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID * - 3.30.0 - Add AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE. + * - 3.31.0 - Add syncobj timeline support to AMDGPU_CS. */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 30 +#define KMS_DRIVER_MINOR 31 #define KMS_DRIVER_PATCHLEVEL 0 int amdgpu_vram_limit = 0; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/syncobj: add transition iotcls between binary and timeline v2
we need to import/export timeline point.
v2: unify to one transfer ioctl
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 74 ++
include/uapi/drm/drm.h | 10 +
4 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 695179bb88dc..dd11ae5f1eef 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -180,6 +180,8 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7a534c184e52..92b3b7b2fd81 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -686,6 +686,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
drm_syncobj_fd_to_handle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TRANSFER, drm_syncobj_transfer_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 673b805ab2e8..f1d18d10d1f2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -670,6 +670,80 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
&args->handle);
}
+static int drm_syncobj_transfer_to_timeline(struct drm_file *file_private,
+ struct drm_syncobj_transfer *args)
+{
+ struct drm_syncobj *timeline_syncobj = NULL;
+ struct dma_fence *fence;
+ struct dma_fence_chain *chain;
+ int ret;
+
+ timeline_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+ if (!timeline_syncobj) {
+ return -ENOENT;
+ }
+ ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags,
+&fence);
+ if (ret)
+ goto err;
+ chain = kzalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
+ if (!chain) {
+ ret = -ENOMEM;
+ goto err1;
+ }
+ drm_syncobj_add_point(timeline_syncobj, chain, fence, args->dst_point);
+err1:
+ dma_fence_put(fence);
+err:
+ drm_syncobj_put(timeline_syncobj);
+
+ return ret;
+}
+
+static int
+drm_syncobj_transfer_to_binary(struct drm_file *file_private,
+ struct drm_syncobj_transfer *args)
+{
+ struct drm_syncobj *binary_syncobj = NULL;
+ struct dma_fence *fence;
+ int ret;
+
+ binary_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+ if (!binary_syncobj)
+ return -ENOENT;
+ ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags, &fence);
+ if (ret)
+ goto err;
+ drm_syncobj_replace_fence(binary_syncobj, fence);
+ dma_fence_put(fence);
+err:
+ drm_syncobj_put(binary_syncobj);
+
+ return ret;
+}
+int
+drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_transfer *args = data;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad)
+ return -EINVAL;
+
+ if (args->dst_point)
+ ret = drm_syncobj_transfer_to_timeline(file_private, args);
+ else
+ ret = drm_syncobj_transfer_to_binary(file_private, args);
+
+ return ret;
+}
+
static void syncobj_wait_fence_func(struct dma_fence *fence,
struct dma_fence_cb *cb)
{
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b2c36f2b2599..4c1e2e6579fa 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -735,6 +735,15 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer
[PATCH 5/9] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index a5adc7c06caa..673b805ab2e8 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
struct dma_fence **fence)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
- int ret = 0;
+ struct syncobj_wait_entry wait;
+ int ret;
if (!syncobj)
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
+ drm_syncobj_put(syncobj);
+
+ if (*fence) {
+ ret = dma_fence_chain_find_seqno(fence, point);
+ if (!ret)
+ return 0;
+ dma_fence_put(*fence);
+ } else {
ret = -EINVAL;
}
- drm_syncobj_put(syncobj);
+
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ return ret;
+
+ memset(&wait, 0, sizeof(wait));
+ wait.task = current;
+ wait.point = point;
+ drm_syncobj_fence_add_wait(syncobj, &wait);
+
+ do {
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (wait.fence) {
+ ret = 0;
+ break;
+ }
+
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+
+ schedule();
+ } while (1);
+
+ __set_current_state(TASK_RUNNING);
+ *fence = wait.fence;
+
+ if (wait.node.next)
+ drm_syncobj_remove_wait(syncobj, &wait);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/syncobj: add timeline payload query ioctl v5
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Christian König
Cc: Chris Wilson
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 58 ++
include/uapi/drm/drm.h | 10 ++
4 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 331ac6225b58..695179bb88dc 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -188,6 +188,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index c984654646fa..7a534c184e52 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -694,6 +694,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 25eb2176d8c7..a5adc7c06caa 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1062,3 +1062,61 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_array *args = data;
+ struct drm_syncobj **syncobjs;
+ uint64_t __user *points = u64_to_user_ptr(args->points);
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < args->count_handles; i++) {
+ struct dma_fence_chain *chain;
+ struct dma_fence *fence;
+ uint64_t point;
+
+ fence = drm_syncobj_fence_get(syncobjs[i]);
+ chain = to_dma_fence_chain(fence);
+ if (chain) {
+ struct dma_fence *iter, *last_signaled = NULL;
+
+ dma_fence_chain_for_each(iter, fence) {
+ if (!iter)
+ break;
+ dma_fence_put(last_signaled);
+ last_signaled = dma_fence_get(iter);
+ }
+ point = dma_fence_is_signaled(last_signaled) ?
+ last_signaled->seqno :
+ to_dma_fence_chain(last_signaled)->prev_seqno;
+ dma_fence_put(last_signaled);
+ } else {
+ point = 0;
+ }
+ ret = copy_to_user(&points[i], &point, sizeof(uint64_t));
+ ret = ret ? -EFAULT : 0;
+ if (ret)
+ break;
+ }
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 0092111d002c..b2c36f2b2599 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -767,6 +767,14 @@ struct drm_syncobj_array {
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence n
[PATCH 3/9] drm/syncobj: add support for timeline point wait v8
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Chris Wilson
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 153 ++---
include/uapi/drm/drm.h | 15
4 files changed, 143 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 251d67e04c2d..331ac6225b58 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,6 +182,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 687943df58e1..c984654646fa 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -688,6 +688,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 933225fde9a9..25eb2176d8c7 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -61,6 +61,7 @@ struct syncobj_wait_entry {
struct task_struct *task;
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
+ u64point;
};
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
@@ -95,6 +96,8 @@ EXPORT_SYMBOL(drm_syncobj_find);
static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait)
{
+ struct dma_fence *fence;
+
if (wait->fence)
return;
@@ -103,11 +106,15 @@ static void drm_syncobj_fence_add_wait(struct drm_syncobj
*syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence)
- wait->fence = dma_fence_get(
- rcu_dereference_protected(syncobj->fence, 1));
- else
+ fence = dma_fence_get(rcu_dereference_protected(syncobj->fence, 1));
+ if (!fence || dma_fence_chain_find_seqno(&fence, wait->point)) {
+ dma_fence_put(fence);
list_add_tail(&wait->node, &syncobj->cb_list);
+ } else if (!fence) {
+ wait->fence = dma_fence_get_stub();
+ } else {
+ wait->fence = fence;
+ }
spin_unlock(&syncobj->lock);
}
@@ -147,10 +154,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
dma_fence_chain_init(chain, prev, fence, point);
rcu_assign_pointer(syncobj->fence, &chain->base);
- list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
- list_del_init(&cur->node);
+ list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
spin_unlock(&syncobj->lock);
/* Walk the chain once to trigger garbage collection */
@@ -182,10 +187,8 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
rcu_assign_pointer(syncobj->fence, fence);
if (fence != old_fence) {
- list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
- list_del_init(&cur->node);
+ list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
}
spin_
[PATCH 1/9] dma-buf: add new dma_fence_chain container v5
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/dma-fence-chain.c | 241 ++
include/linux/dma-fence-chain.h | 81 ++
3 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dma-fence-chain.c
create mode 100644 include/linux/dma-fence-chain.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..0c5e3c902fa0
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,241 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct dma_fence_chain
*chain)
+{
+ struct dma_fence *prev;
+
+ rcu_read_lock();
+ prev = dma_fence_get_rcu_safe(&chain->prev);
+ rcu_read_unlock();
+ return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL if we are at
+ * the end of the chain. Garbage collects chain nodes which are already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain, *prev_chain;
+ struct dma_fence *prev, *replacement, *tmp;
+
+ chain = to_dma_fence_chain(fence);
+ if (!chain) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ while ((prev = dma_fence_chain_get_prev(chain))) {
+
+ prev_chain = to_dma_fence_chain(prev);
+ if (prev_chain) {
+ if (!dma_fence_is_signaled(prev_chain->fence))
+ break;
+
+ replacement = dma_fence_chain_get_prev(prev_chain);
+ } else {
+ if (!dma_fence_is_signaled(prev))
+ break;
+
+ replacement = NULL;
+ }
+
+ tmp = cmpxchg(&chain->prev, prev, replacement);
+ if (tmp == prev)
+ dma_fence_put(tmp);
+ else
+ dma_fence_put(replacement);
+ dma_fence_put(prev);
+ }
+
+ dma_fence_put(fence);
+ return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno)
+{
+ struct dma_fence_chain *chain;
+
+ if (!seqno)
+ return 0;
+
+ chain = to_dma_fence_chain(*pfence);
+ if (!chain || chain->base.seqno < seqno)
+ return -EINVAL;
+
+ dma_fence_chain_for_each(*p
[PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v3
From: Christian König
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
v3: fix garbage collection parameters
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 37 +++
include/drm/drm_syncobj.h | 5 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 5329e66598c6..933225fde9a9 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -122,6 +122,43 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
*syncobj,
spin_unlock(&syncobj->lock);
}
+/**
+ * drm_syncobj_add_point - add new timeline point to the syncobj
+ * @syncobj: sync object to add timeline point do
+ * @chain: chain node to use to add the point
+ * @fence: fence to encapsulate in the chain node
+ * @point: sequence number to use for the point
+ *
+ * Add the chain node as new timeline point to the syncobj.
+ */
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+ struct dma_fence_chain *chain,
+ struct dma_fence *fence,
+ uint64_t point)
+{
+ struct syncobj_wait_entry *cur, *tmp;
+ struct dma_fence *prev;
+
+ dma_fence_get(fence);
+
+ spin_lock(&syncobj->lock);
+
+ prev = drm_syncobj_fence_get(syncobj);
+ dma_fence_chain_init(chain, prev, fence, point);
+ rcu_assign_pointer(syncobj->fence, &chain->base);
+
+ list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
+ list_del_init(&cur->node);
+ syncobj_wait_syncobj_func(syncobj, cur);
+ }
+ spin_unlock(&syncobj->lock);
+
+ /* Walk the chain once to trigger garbage collection */
+ dma_fence_chain_for_each(fence, prev);
+ dma_fence_put(prev);
+}
+EXPORT_SYMBOL(drm_syncobj_add_point);
+
/**
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 0311c9fdbd2f..6cf7243a1dc5 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -27,6 +27,7 @@
#define __DRM_SYNCOBJ_H__
#include
+#include
struct drm_file;
@@ -112,6 +113,10 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
u32 handle);
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+ struct dma_fence_chain *chain,
+ struct dma_fence *fence,
+ uint64_t point);
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-5.2-wip 283/333] dc_stream.c:undefined reference to `get_vupdate_offset_from_vsync'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip head: b06eb75427559e372346c53cf579064d3bac6d12 commit: 7155d155d70353b3369a1494fff39ec701699389 [283/333] drm/amd/display: Fix plane address updates for video surface formats config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 7155d155d70353b3369a1494fff39ec701699389 # save the attached .config to linux build tree GCC_VERSION=8.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): aarch64-linux-gnu-ld: drivers/gpu/drm/amd/display/dc/core/dc_stream.o: in function `delay_cursor_until_vupdate': >> dc_stream.c:(.text+0x108): undefined reference to >> `get_vupdate_offset_from_vsync' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm: don't block fb changes for async plane updates
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the preparation is also done in the
new_state but the cleanups are done in the new_state (because updates
are performed in place, i.e. in the current state).
The current code blocks async udpates when the fb is changed, turning
async updates into sync updates, slowing down cursor updates and
introducing regressions in igt tests with errors of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"
Fb changes in async updates were prevented to avoid the following scenario:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
Where we have a single call to prepare fb2 but double cleanup call to fb2.
To solve the above problems, instead of blocking async fb changes, we
place the old framebuffer in the new_state object, so when the code
performs cleanups in the new_state it will cleanup the old_fb and we
will have the following scenario instead:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
Where calls to prepare/cleanup are balanced.
Cc: # v4.14+
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Hello,
As mentioned in the cover letter, I tested in almost all platforms with
igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
regressions. But I couldn't test on MSM and AMD because I don't have
the hardware I would appreciate if anyone could help me testing those.
Thanks!
Helen
Changes in v2:
- Change the order of the patch in the series, add this as the last one.
- Add documentation
- s/ballanced/balanced
drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
include/drm/drm_modeset_helper_vtables.h | 5 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 540a77a2ade9..e7eb96f1efc2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
- /*
-* FIXME: Since prepare_fb and cleanup_fb are always called on
-* the new_plane_state for async updates we need to block framebuffer
-* changes. This prevents use of a fb that's been cleaned up and
-* double cleanups from occuring.
-*/
- if (old_plane_state->fb != new_plane_state->fb)
- return -EINVAL;
-
funcs = plane->helper_private;
if (!funcs->atomic_async_update)
return -EINVAL;
@@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device
*dev,
int i;
for_each_new_plane_in_state(state, plane, plane_state, i) {
+ struct drm_framebuffer *new_fb = plane_state->fb;
+ struct drm_framebuffer *old_fb = plane->state->fb;
+
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
@@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct drm_device
*dev,
* plane->state in-place, make sure at least common
* properties have been properly updated.
*/
- WARN_ON_ONCE(plane->state->fb != plane_state->fb);
+ WARN_ON_ONCE(plane->state->fb != new_fb);
WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
+
+ /*
+* Make sure the FBs have been swapped so that cleanups in the
+* new_state performs a cleanup in the old FB.
+*/
+ WARN_ON_ONCE(plane_state->fb != old_fb);
}
}
EXPORT_SYMBOL(drm_atomic_helper_async_commit);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index cfb7be40bed7..ce582e8e8f2f 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1174,6 +1174,11 @@ struct drm_plane_helper_funcs {
* current one with the new plane configuration
[PATCH v2 4/5] drm/vc4: fix fb references in async update
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
Cc: # v4.19+
Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
Reviewed-by: Boris Brezillon
---
Hello,
I tested on a Raspberry Pi model B rev2 with igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
Changes in v2:
- Added reviewed-by tag
- updated CC stable and Fixes tag
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 1babfeca0c92..1235e53b22a3 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -968,7 +968,7 @@ static void vc4_plane_atomic_async_update(struct drm_plane
*plane,
{
struct vc4_plane_state *vc4_state, *new_vc4_state;
- drm_atomic_set_fb_for_plane(plane->state, state->fb);
+ swap(plane->state->fb, state->fb);
plane->state->crtc_x = state->crtc_x;
plane->state->crtc_y = state->crtc_y;
plane->state->crtc_w = state->crtc_w;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/msm: fix fb references in async update
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Cc: # v4.14+
Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Hello,
As mentioned in the cover letter,
But I couldn't test on MSM because I don't have the hardware and I would
appreciate if anyone could test it.
In other platforms (VC4, AMD, Rockchip), there is a hidden
drm_framebuffer_get(new_fb)/drm_framebuffer_put(old_fb) in async_update
that is wrong, but I couldn't identify those here, not sure if it is hidden
somewhere else, but if tests fail this is probably the cause.
Thanks!
Helen
Changes in v2:
- update CC stable and Fixes tag
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index be13140967b4..b854f471e9e5 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check(struct drm_plane
*plane,
static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
+ struct drm_framebuffer *old_fb = plane->state->fb;
+
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
plane->state->crtc_x = new_state->crtc_x;
@@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_update(struct drm_plane
*plane,
*to_mdp5_plane_state(plane->state) =
*to_mdp5_plane_state(new_state);
+
+ new_state->fb = old_fb;
}
static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/rockchip: fix fb references in async update
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleanup up (instead of the old_state, diferrently on what happen in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
in the end of async_update, so cleanup call will unreference the old_fb
correctly.
Also, the previous code had a:
plane_state = plane->funcs->atomic_duplicate_state(plane);
...
swap(plane_state, plane->state);
if (plane->state->fb && plane->state->fb != new_state->fb) {
...
}
Which was wrong, as the fb were just assigned to be equal, so this if
statement nevers evaluates to true.
Another details is that the function drm_crtc_vblank_get() can only be
called when vop->is_enabled is true, otherwise it has no effect and
trows a WARN_ON().
Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
fb and pus the old fb) is not required, as it is taken care by
drm_mode_cursor_universal() when calling
drm_atomic_helper_update_plane().
Signed-off-by: Helen Koike
---
Hello,
I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7d4c6073ea5..a1ee8c156a7b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
drm_plane *plane,
struct drm_plane_state *new_state)
{
struct vop *vop = to_vop(plane->state->crtc);
- struct drm_plane_state *plane_state;
+ struct drm_framebuffer *old_fb = plane->state->fb;
- plane_state = plane->funcs->atomic_duplicate_state(plane);
- plane_state->crtc_x = new_state->crtc_x;
- plane_state->crtc_y = new_state->crtc_y;
- plane_state->crtc_h = new_state->crtc_h;
- plane_state->crtc_w = new_state->crtc_w;
- plane_state->src_x = new_state->src_x;
- plane_state->src_y = new_state->src_y;
- plane_state->src_h = new_state->src_h;
- plane_state->src_w = new_state->src_w;
-
- if (plane_state->fb != new_state->fb)
- drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
-
- swap(plane_state, plane->state);
-
- if (plane->state->fb && plane->state->fb != new_state->fb) {
+ /*
+* A scanout can still be occurring, so we can't drop the reference to
+* the old framebuffer. To solve this we get a reference to old_fb and
+* set a worker to release it later.
+*/
+ if (vop->is_enabled &&
+ plane->state->fb && plane->state->fb != new_state->fb) {
drm_framebuffer_get(plane->state->fb);
WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
}
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+ plane->state->crtc_h = new_state->crtc_h;
+ plane->state->crtc_w = new_state->crtc_w;
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->src_h = new_state->src_h;
+ plane->state->src_w = new_state->src_w;
+ plane->state->fb = new_state->fb;
+
if (vop->is_enabled) {
rockchip_drm_psr_inhibit_get_state(new_state->state);
vop_plane_atomic_update(plane, plane->state);
@@ -945,7 +946,12 @@ static void vop_plane_atomic_async_update(struct drm_plane
*plane,
rockchip_drm_psr_inhibit_put_state(new_state->state);
}
- plane->funcs->atomic_destroy_state(plane, plane_state);
+ /*
+* In async update we perform inplace modifications and release the
+* new_state. The following is required so we release the reference of
+* the old framebuffer.
+*/
+ new_state->fb = old_fb;
}
static const struct drm_plane_helper_funcs plane_helper_funcs = {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/amd: fix fb references in async update
Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Suggested-by: Boris Brezillon Signed-off-by: Helen Koike Reviewed-by: Nicholas Kazlauskas --- Changes in v2: - added reviewed-by tag drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3a6f595f295e..bc02800254bf 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3760,8 +3760,7 @@ static void dm_plane_atomic_async_update(struct drm_plane *plane, struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(new_state->state, plane); - if (plane->state->fb != new_state->fb) - drm_atomic_set_fb_for_plane(plane->state, new_state->fb); + swap(plane->state->fb, new_state->fb); plane->state->src_x = new_state->src_x; plane->state->src_y = new_state->src_y; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] drm: Fix fb changes for async updates
Hello, This series fixes the slow down in performance introduced by "[PATCH v2] drm: Block fb changes for async plane updates" where async update falls back to a sync update, causing igt failures of type: "CRITICAL: completed 97 cursor updated in a period of 30 flips, we expect to complete approximately 15360 updates, with the threshold set at 7680" Please read the commit message of "drm: don't block fb changes for async plane updates" to understand how it works. I tested on the rockchip, on i915 and on vc4 with igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any regressions. I couldn't test on MSM and AMD because I don't have the hardware I would appreciate if anyone could help me testing those. v1 link: https://patchwork.kernel.org/cover/10837847/ Thanks! Helen Changes in v2: - added reviewed-by tag - update CC stable and Fixes tag - Added reviewed-by tag - updated CC stable and Fixes tag - Change the order of the patch in the series, add this as the last one. - Add documentation - s/ballanced/balanced Helen Koike (5): drm/rockchip: fix fb references in async update drm/amd: fix fb references in async update drm/msm: fix fb references in async update drm/vc4: fix fb references in async update drm: don't block fb changes for async plane updates .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 20 - drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 4 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +++ drivers/gpu/drm/vc4/vc4_plane.c | 2 +- include/drm/drm_modeset_helper_vtables.h | 5 +++ 6 files changed, 45 insertions(+), 31 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8] drm/lima: driver for ARM Mali4xx GPUs
On Mon, Mar 11, 2019 at 11:37 PM Rob Herring wrote:
>
> On Sat, Mar 9, 2019 at 6:21 AM Qiang Yu wrote:
> >
> > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> > OpenGL vertex shader processing and PP is for fragment shader
> > processing. Each processor has its own MMU so prcessors work in
> > virtual address space.
> > - There's only one GP but multiple PP (max 4 for mali 400 and 8
> > for mali 450) in the same mali 4xx GPU. All PPs are grouped
> > togather to handle a single fragment shader task divided by
> > FB output tiled pixels. Mali 400 user space driver is
> > responsible for assign target tiled pixels to each PP, but mali
> > 450 has a HW module called DLBU to dynamically balance each
> > PP's load.
> > - User space driver allocate buffer object and map into GPU
> > virtual address space, upload command stream and draw data with
> > CPU mmap of the buffer object, then submit task to GP/PP with
> > a register frame indicating where is the command stream and misc
> > settings.
> > - There's no command stream validation/relocation due to each user
> > process has its own GPU virtual address space. GP/PP's MMU switch
> > virtual address space before running two tasks from different
> > user process. Error or evil user space code just get MMU fault
> > or GP/PP error IRQ, then the HW/SW will be recovered.
> > - Use GEM+shmem for MM. Currently just alloc and pin memory when
> > gem object creation. GPU vm map of the buffer is also done in
> > the alloc stage in kernel space. We may delay the memory
> > allocation and real GPU vm map to command submission stage in the
> > furture as improvement.
> > - Use drm_sched for GPU task schedule. Each OpenGL context should
> > have a lima context object in the kernel to distinguish tasks
> > from different user. drm_sched gets task from each lima context
> > in a fair way.
> >
> > mesa driver can be found here before upstreamed:
> > https://gitlab.freedesktop.org/lima/mesa
> >
> > v8:
> > - add comments for in_sync
> > - fix ctx free miss mutex unlock
> >
> > v7:
> > - remove lima_fence_ops with default value
> > - move fence slab create to device probe
> > - check pad ioctl args to be zero
> > - add comments for user/kernel interface
> >
> > v6:
> > - fix comments by checkpatch.pl
> >
> > v5:
> > - export gp/pp version to userspace
> > - rebase on drm-misc-next
> >
> > v4:
> > - use get param interface to get info
> > - separate context create/free ioctl
> > - remove unused max sched task param
> > - update copyright time
> > - use xarray instead of idr
> > - stop using drmP.h
> >
> > v3:
> > - fix comments from kbuild robot
> > - restrict supported arch to tested ones
> >
> > v2:
> > - fix syscall argument check
> > - fix job finish fence leak since kernel 5.0
> > - use drm syncobj to replace native fence
> > - move buffer object GPU va map into kernel
> > - reserve syscall argument space for future info
> > - remove kernel gem modifier
> > - switch TTM back to GEM+shmem MM
> > - use time based io poll
> > - use whole register name
> > - adopt gem reservation obj integration
> > - use drm_timeout_abs_to_jiffies
> >
> > Cc: Eric Anholt
> > Cc: Rob Herring
> > Cc: Christian König
> > Cc: Daniel Vetter
> > Cc: Alex Deucher
> > Cc: Sam Ravnborg
> > Cc: Rob Clark
> > Cc: Dave Airlie
> > Signed-off-by: Andreas Baierl
> > Signed-off-by: Erico Nunes
> > Signed-off-by: Heiko Stuebner
> > Signed-off-by: Marek Vasut
> > Signed-off-by: Neil Armstrong
> > Signed-off-by: Simon Shields
> > Signed-off-by: Vasily Khoruzhick
> > Signed-off-by: Qiang Yu
> > Reviewed-by: Eric Anholt
> > Reviewed-by: Rob Herring
> > ---
>
> [...]
I thought get your RB last time, should I remove it?
>
> > +static int lima_gem_lock_bos(struct lima_bo **bos, u32 nr_bos,
> > +struct ww_acquire_ctx *ctx)
> > +{
> > + int i, ret = 0, contended, slow_locked = -1;
> > +
> > + ww_acquire_init(ctx, &reservation_ww_class);
> > +
> > +retry:
> > + for (i = 0; i < nr_bos; i++) {
> > + if (i == slow_locked) {
> > + slow_locked = -1;
> > + continue;
> > + }
> > +
> > + ret = ww_mutex_lock_interruptible(&bos[i]->gem.resv->lock,
> > ctx);
> > + if (ret < 0) {
> > + contended = i;
> > + goto err;
> > + }
> > + }
> > +
> > + ww_acquire_done(ctx);
> > + return 0;
> > +
> > +err:
> > + for (i--; i >= 0; i--)
> > + ww_mutex_unlock(&bos[i]->gem.resv->lock);
> > +
> > + if (slow_locked >= 0)
> > + ww_mutex_unlock(&bos[slow_locked]->gem.resv->lock);
> > +
> > + if (ret == -EDEADLK) {
> > + /* we lost out in a seqno race, lock and retry.. */
> > + ret = ww_mutex_lock_slow_interruptible(
> > + &bos[contended]->gem.resv->lo
Re: [PATCH v2] drm/fourcc: add ARM GPU tile format
Alyssa did a very good description of our needs. Since I can't open the cgit mesa link and give you a clear view of this format: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/panfrost/pan_swizzle.c https://gitlab.freedesktop.org/lima/mesa/blob/lima-18.3/src/gallium/drivers/lima/lima_tiling.c#L29 Thanks, Qiang On Tue, Mar 12, 2019 at 12:39 AM Alyssa Rosenzweig wrote: > > > You might want to re-use the exisiting modifier > > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16. > > > > I would suggest you to have a look at the exisiting AFBC modifiers > > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is > > something you cannot reuse. > > So, the "tiled" format in question (that Qiang needs to import/export > BOs in) is *uncompressed* but tiled with an Arm-internal format (for the > GPUs). Here's a software implementation for encoding this format: > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c > > For Midgard/Bifrost, we use this tiling internally for uploading bitmap > textures, but we only render to AFBC (or linear). So for Panfrost, we'll > always be importing/exporting AFBC buffers, never uncompressed tiled. > But Utgard does not seem to support AFBC (?), so Qiang needs the > uncompressed tiled for the same purpose Panfrost uses AFBC. > > Is it possible that this is the same tiling used internally by > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is > blackbox for us, so this isn't something we can figure out ourselves, > but that influences whether it's appropriate to reuse the modifier. If > this is the same tiling scheme, perhaps that's the answer. If it's not > (I don't know how AFBC tiling works), we probably do need a separate > modifier to avoid confusion. > > Thanks, > > Alyssa > -BEGIN PGP SIGNATURE- > > iQIzBAABCgAdFiEEQ17gm7CvANAdqvY4/v5QWgr1WA0FAlyGjz8ACgkQ/v5QWgr1 > WA1JHA/+MKO3rf6htnd48EVnXtEhsSqoDatDVb2c13k5/oxutrAQqR29K1Tl/Wkp > 6HebJD4sBafutBroyGenIz5cLnY3AG3zy1zxzOgdvkXpNuVcXgtpL4HXjEaInueD > ZtssXso4gjRZyD6kuW5fe97TvvRTPknEsMXpWwBgcgP+FxUrrwVqEPo6il3rhMvN > E4NBHkqoX8GtLWB9p/YUcUWMHJ2YhEIo04Vi3tWw7t2TniHrJw7wZDVPXoKhoX9/ > wsu0iZ4XEoL3FPtK1v/S6gWkDq0xDTzHeZOBJKYC94RiH93S+Q7maLzH5fTB9lXt > DsF2zJkEj6tHZJCi0f0JzEcuXiAzZKKVLbKD1KoL6ORKZePRraJRzoTHFU1XknyR > e9Uv3JuO2RwZxicfdgdArgzR9wrM2PL9kPzGsLtaYISQ6hs/vNbu2lgNPUzaX0Az > xvMu/ZW9cbO+XKeilGoOYR8ON0Zyw9zmUSrnd5aRwwk07rvQElz7csFBGeH7QTg5 > p5GTF5QcipZ6JpB3VSYxbJPJx2rEmg8/lTGUuWCB553sdbStPk/rKFAKszgqp6Cw > 8AUktXmPv1Unwsnk46VF8WXJFtIldRjm8ErFRzbSDqyEO1kxPR+wH+6XBrS1iiYS > 3Y7KoRUHLsQk6pk7q4RgVRYe2MCJe3jVeQNL1gZ6Qha3Dzbxymc= > =Prus > -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu: drm: atomic_helper: Fix spelling errors
Trivial fixes identified while working on the DRM code. s/artifically/artificially/ s/achive/achieve/ Signed-off-by: Kieran Bingham --- v2: - Actually spell achieve correctly! drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 540a77a2ade9..2453678d1186 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, * * NOTE: Commit work has multiple phases, first hardware commit, then * cleanup. We want them to overlap, hence need system_unbound_wq to -* make sure work items don't artifically stall on each another. +* make sure work items don't artificially stall on each another. */ drm_atomic_state_get(state); @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); * * Asynchronous workers need to have sufficient parallelism to be able to run * different atomic commits on different CRTCs in parallel. The simplest way to - * achive this is by running them on the &system_unbound_wq work queue. Note + * achieve this is by running them on the &system_unbound_wq work queue. Note * that drivers are not required to split up atomic commits and run an * individual commit in parallel - userspace is supposed to do that if it cares. * But it might be beneficial to do that for modesets, since those necessarily -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
2019 X.Org Foundation Election Candidates
To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 14 March 2019. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Arkadiusz Hiler Manasi Navare Lyude Paul Daniel Vetter Trevor Woerner Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. Harry, on behalf of the X.Org elections committee # Nominees ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa for 5 years, specifically to the Intel drivers for OpenGL and Vulkan. I was one of the organizers of XDC 2018 in A Coruña, Spain. If I am elected, I will use my experience on XDC 2018 to improve the organization of future XDC, help to spread X.Org technologies and help X.org project as much as possible. ## Arkadiusz Hiler __Current Affiliation:__ Intel __Personal Statement:__ My main interest is in quality and automated testing throughout the graphics stack. Especially helping the areas that are lagging behind: testing the kernel and KMS plumbing. I would like to focus on building open source testing toolbox so that anyone can mix and match bits of it to build their testing infrastructure. There are a lot of exotic setups and edge cases that are hard to exercise locally by developers due to lack of hardware. Automating those cases by software faking it or by granting access to the testing infrastructures benefits the whole community. It also a good way of lowering the bar for new contributors and enables refactoring with confidence. ## Manasi Navare __Current Affiliation:__ Intel __Statement of Contribution:__ I am a lead contributor to Intel's Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. Most recently I have been involved in upstreaming Display Stream Compression feature across DRM i915 to enable high resolutions like 5K@120. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. __Personal Statement:__ I have been Linux Open Source contributor for last 4 years since I joined Intel's Open source technology center. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression. I have been already actively involved in IRC discussions with DRM and i915 maintainers to constantly provide any solution on display port questions and work on improving the kernel documentation and code quality. I have proactively started attending X.org board meetings on IRC to better understand working of X.org and at XDC 2018, I also volunteered in the Code of Conduct committee during the conference and I was the point of contact for this. I am also currently a mentor for the KMS project in Outreachy winter program and committed to mentor the Google summer of code program as well. If I get elected, I would like to contribute by helping organize the X.org foundation conferences, screening the papers and any help needed in terms of public relations, working with the sponsors or code of conduct on the day of the conference to make the events a huge success. I would also like to leverage my open source working knowledge on any technical help required for the X.org events. ## Lyude Paul __Current Affiliation:__ Red Hat __Personal Statement:__ One of the people who helped start Panfrost! Also a contributor to nouveau, i915, amdgpu, radeon, weston, Xorg, multiple X DDXs, libinput, the wayland protocol, various other non-graphics related bits in the kernel, and probably more! __Statement of Contribution:__ I originally found out about Linux through a rather unexpected place: an Ubuntu booth at an Anime convention. I was in awe of the beauty of the all-mighty Compiz workspace switching cube and ended up deciding to give it a shot on my own computer. I ended up loving Linux, and quickly found I couldn't go back to other operating systems. I also wanted to become involved, but didn't really know how to at first. After years of being a user throughout high school and the start of my college career, I ended up taking on the challenge of trying t
Re: [PATCH 5/5] drm/vc4: fix fb references in async update
On 3/11/19 6:56 AM, Boris Brezillon wrote:
> +Eric (the VC4 driver maintainer)
>
> Hello Helen,
>
> On Mon, 4 Mar 2019 11:49:09 -0300
> Helen Koike wrote:
>
>> Async update callbacks are expected to set the old_fb in the new_state
>> so prepare/cleanup framebuffers are balanced.
>>
>> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
>> fb and put the old fb) is not required, as it's taken care by
>> drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
>>
>> Cc: # v4.19+: 25dc194b34dd: drm: Block fb changes
>> for async plane updates
>> Cc: # v4.19+: 8105bbaf9afd: drm: don't block fb
>> changes for async plane updates
>
> Hm, the commit hash you give here will change when applied to the DRM
> tree. I think there's a standard way to express dependencies between
> patches that needs to be applied to stable, but I'm not sure you need
> to describe that since Greg picks patches in the order they appear in
> Linus' tree and those patches will be applied in the right order.
right
>
> Another option if you want to keep things simple is to squash all
> changes in a single patch ;).
I was thinking about that, but some of them don't need to be picked by
Greg (rockchip changes won't apply to stable for example), and I think
it's easier to get tested-by/reviewed-by tags if I separate them and
send them to the proper mailing list for the respective architecture.
>
>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
>
> Nitpicking: this Fixes tag is a bit of lie since you're actually fixing a
> mistake that was introduced when async update support was added to VC4.
> Commit 25dc194b34dd only added a new constraint to fix the initial
> problem.
>
> So I'd suggest:
>
> Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
>
> BTW, the same applies to other patches in this series.
>
>> Suggested-by: Boris Brezillon
>
> Other than that,
>
> Reviewed-by: Boris Brezillon
Thanks!
Helen
>
> Regards,
>
> Boris
>
>> Signed-off-by: Helen Koike
>>
>> ---
>> Hello,
>>
>> As mentioned in the cover letter,
>> I tested on the rockchip and on i915 using igt plane_cursor_legacy and
>> kms_cursor_legacy and I didn't see any regressions.
>> But I couldn't test on VC4. I have a Raspberry pi model B rev2, when
>> FB_SIMPLE is running I can see output on the screen, but when vc4 is
>> loaded my hdmi display is not detected anymore, I am still debugging
>> this, probably some config in the firmware, but I would appreciate if
>> anyone could help me testing it.
>>
>> Also the Cc statble commit hash dependency needs to be updated once the
>> refered commit is merged.
>>
>> Thanks!
>> Helen
>>
>> drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c
>> b/drivers/gpu/drm/vc4/vc4_plane.c
>> index 1babfeca0c92..1235e53b22a3 100644
>> --- a/drivers/gpu/drm/vc4/vc4_plane.c
>> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
>> @@ -968,7 +968,7 @@ static void vc4_plane_atomic_async_update(struct
>> drm_plane *plane,
>> {
>> struct vc4_plane_state *vc4_state, *new_vc4_state;
>>
>> -drm_atomic_set_fb_for_plane(plane->state, state->fb);
>> +swap(plane->state->fb, state->fb);
>> plane->state->crtc_x = state->crtc_x;
>> plane->state->crtc_y = state->crtc_y;
>> plane->state->crtc_w = state->crtc_w;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 17/19] drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure
Hi Laurent,
On 21/02/2019 10:32, Laurent Pinchart wrote:
> The mapping between DRM and V4L2 fourcc's is stored in two separate
> tables in rcar_du_vsp.c. In order to make it reusable to implement
> writeback support, move it to the rcar_du_format_info structure.
It's a shame there isn't some core framework conversion helpers that do
these mappings (presumably in both directions). But even if we had one
of those, having a table entry here is a fast conversion.
Reviewed-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 +++
> drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 +
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 44 ---
> 3 files changed, 32 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index b0c80dffd8b8..999440c7b258 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -32,60 +32,70 @@
> static const struct rcar_du_format_info rcar_du_format_infos[] = {
> {
> .fourcc = DRM_FORMAT_RGB565,
> + .v4l2 = V4L2_PIX_FMT_RGB565,
> .bpp = 16,
> .planes = 1,
> .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_ARGB1555,
> + .v4l2 = V4L2_PIX_FMT_ARGB555,
> .bpp = 16,
> .planes = 1,
> .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_XRGB1555,
> + .v4l2 = V4L2_PIX_FMT_XRGB555,
> .bpp = 16,
> .planes = 1,
> .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_XRGB,
> + .v4l2 = V4L2_PIX_FMT_XBGR32,
> .bpp = 32,
> .planes = 1,
> .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
> .edf = PnDDCR4_EDF_RGB888,
> }, {
> .fourcc = DRM_FORMAT_ARGB,
> + .v4l2 = V4L2_PIX_FMT_ABGR32,
> .bpp = 32,
> .planes = 1,
> .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
> .edf = PnDDCR4_EDF_ARGB,
> }, {
> .fourcc = DRM_FORMAT_UYVY,
> + .v4l2 = V4L2_PIX_FMT_UYVY,
> .bpp = 16,
> .planes = 1,
> .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_YUYV,
> + .v4l2 = V4L2_PIX_FMT_YUYV,
> .bpp = 16,
> .planes = 1,
> .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_NV12,
> + .v4l2 = V4L2_PIX_FMT_NV12M,
> .bpp = 12,
> .planes = 2,
> .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_NV21,
> + .v4l2 = V4L2_PIX_FMT_NV21M,
> .bpp = 12,
> .planes = 2,
> .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> .edf = PnDDCR4_EDF_NONE,
> }, {
> .fourcc = DRM_FORMAT_NV16,
> + .v4l2 = V4L2_PIX_FMT_NV16M,
> .bpp = 16,
> .planes = 2,
> .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> @@ -97,62 +107,77 @@ static const struct rcar_du_format_info
> rcar_du_format_infos[] = {
>*/
> {
> .fourcc = DRM_FORMAT_RGB332,
> + .v4l2 = V4L2_PIX_FMT_RGB332,
> .bpp = 8,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_ARGB,
> + .v4l2 = V4L2_PIX_FMT_ARGB444,
> .bpp = 16,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_XRGB,
> + .v4l2 = V4L2_PIX_FMT_XRGB444,
> .bpp = 16,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_BGR888,
> + .v4l2 = V4L2_PIX_FMT_RGB24,
> .bpp = 24,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_RGB888,
> + .v4l2 = V4L2_PIX_FMT_BGR24,
> .bpp = 24,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_BGRA,
> + .v4l2 = V4L2_PIX_FMT_ARGB32,
> .bpp = 32,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_BGRX,
> + .v4l2 = V4L2_PIX_FMT_XRGB32,
> .bpp = 32,
> .planes = 1,
> }, {
> .fourcc = DRM_FORMAT_YVYU,
> + .v4l2 = V4L2_PIX_FMT_YVYU,
> .bpp = 16,
> .planes =
Re: [PATCH v5 16/19] drm: rcar-du: Fix rcar_du_crtc structure documentation
Hi Laurent,
On 21/02/2019 10:32, Laurent Pinchart wrote:
> The rcar_du_crtc structure index field contains the CRTC hardware index,
> not the hardware and software index. Update the documentation
> accordingly.
Should this have a fixes tag? It's only trivial - but if so:
Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support
hardware indexing")
Either way,
Reviewed-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index bcb35b0b7612..c478953be092 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -27,7 +27,7 @@ struct rcar_du_vsp;
> * @clock: the CRTC functional clock
> * @extclock: external pixel dot clock (optional)
> * @mmio_offset: offset of the CRTC registers in the DU MMIO block
> - * @index: CRTC software and hardware index
> + * @index: CRTC hardware index
> * @initialized: whether the CRTC has been initialized and clocks enabled
> * @dsysr: cached value of the DSYSR register
> * @vblank_enable: whether vblank events are enabled on this CRTC
>
--
Regards
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/4] dt-bindings: display: rockchip: add document for rk3066 hdmi
On Wed, 6 Mar 2019 23:41:13 +0100, Johan Jonker wrote: > This patch adds a binding that describes the HDMI controller for > rk3066. > > Signed-off-by: Johan Jonker > --- > .../display/rockchip/rockchip,rk3066-hdmi.txt | 72 > ++ > 1 file changed, 72 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
Den 11.03.2019 20.29, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
>>> This adds support for outputting kernel messages on panic().
>>> A kernel message dumper is used to dump the log. The dumper iterates
>>> over each DRM device and it's crtc's to find suitable framebuffers.
>>>
>>> All the other dumpers are run before this one except mtdoops.
>>> Only atomic drivers are supported.
>>>
>>> Signed-off-by: Noralf Trønnes
>>> +static void drm_panic_try_dev(struct drm_device *dev, struct kmsg_dumper
>>> *dumper)
>>> +{
>>> + struct drm_framebuffer *fb;
>>> + struct drm_plane *plane;
>>> + struct drm_crtc *crtc;
>>> +
>>> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
>>> + return;
>>> +
>>> + if (dumper->max_reason == KMSG_DUMP_OOPS)
>>> + pr_info("%s: %s on minor %d\n", __func__, dev->driver->name,
>>> + dev->primary->index);
>>> +
>>> + drm_for_each_crtc(crtc, dev) {
>>> + if (!ww_mutex_trylock(&crtc->mutex.mutex))
>>> + continue;
>>> +
>>> + if (!crtc->enabled || !crtc->primary)
>>> + goto crtc_unlock;
>>> +
>>> + if (!crtc->state || !crtc->state->active)
>>> + goto crtc_unlock;
>>> +
>>> + plane = crtc->primary;
>>> + if (!ww_mutex_trylock(&plane->mutex.mutex))
>>> + goto crtc_unlock;
>>> +
>>> + /*
>>> +* TODO: Should we check plane_state->visible?
>>> +* It is not set on vc4
>>
>> I think we should. We should also check whether that primary is connected
>> to the crtc (some hw you can reassign planes freely between crtc, and the
>> crtc->primary pointer is only used for compat with legacy ioctl).
>>
>>> + if (!plane->state || !plane->state->visible)
>>> +*/
>>> + if (!plane->state)
>>> + goto plane_unlock;
>>> +
>>> + fb = plane->state->fb;
>>> + if (!fb || !fb->funcs->panic_vmap)
>>
>> Docs says this is optional, doesn't seem to be all that optional. I'd
>> check for this or a driver-specific ->panic_draw_xy instead.
>>> + goto plane_unlock;
>>> +
>>> + /*
>>> +* fbcon puts out panic messages so stay away to avoid jumbled
>>> +* output. If vc->vc_mode != KD_TEXT fbcon won't put out
>>> +* messages (see vt_console_print).
>>> +*/
>>> + if (dev->fb_helper && dev->fb_helper->fb == fb)
>
> This is a bit a layering violation. Could we instead tell fbcon that it
> shouldn't do panic handling for drm drivers? I think that would resolve
> this overlap here in a much cleaner way. drm fbdev helpers already have
> lots of oops_in_progress checks all over to make sure fbcon doesn't do
> anything bad. That only leaves the actual rendering, which I think we can
> stop too with a simple flag.
>
> Ofc only for atomic drivers which have this panic handling mode here
> implemented.
There used to be a fbdev flag FBINFO_CAN_FORCE_OUTPUT that controlled
vc->vc_panic_force_write, but it's gone now I see.
Noralf.
> -Daniel
>
>>> + goto plane_unlock;
>>> +
>>> + drm_panic_kmsg_render_screen(plane, dumper);
>>> +plane_unlock:
>>> + ww_mutex_unlock(&plane->mutex.mutex);
>>> +crtc_unlock:
>>> + ww_mutex_unlock(&crtc->mutex.mutex);
>>> + }
>>> +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
Den 11.03.2019 20.23, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
>> This adds support for outputting kernel messages on panic().
>> A kernel message dumper is used to dump the log. The dumper iterates
>> over each DRM device and it's crtc's to find suitable framebuffers.
>>
>> All the other dumpers are run before this one except mtdoops.
>> Only atomic drivers are supported.
>>
>> Signed-off-by: Noralf Trønnes
>
> Bunch of comments/ideas for you or Darwish below, whoever picks this up.
Actually it would ne nice if Darwish could pick it up since he will do
it on i915 which will be useful to a much broader audience.
If not I'll respin when I'm done with the drm_fb_helper refactoring.
>> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
>> new file mode 100644
>> index ..4bca7f0bc369
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_panic.c
>> @@ -0,0 +1,363 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright 2018 Noralf Trønnes
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "drm_internal.h"
>> +
>> +/*
>> + * The log lines in an ARM stack dump are 92 characters long
>> + * and 120 is a nice multiple for HD and 4K.
>> + */
>> +#define DRM_PANIC_COLUMN_WIDTH 120
>
> I think we should compute this dynamically from the actual fb width and
> font witdth.
The font is picked based on whether it can fit 50 lines of text.
The next rule is to decide when to add another column. I decided to use
a number that gets most log lines in one line on the screen. If most
lines get broken into two lines, there's not much use in an extra column.
Do you have another idea on how to do this?
(There's even a 16x32 font now that wasn't available when I did this.)
>
>> +
>> +struct drm_panic_ctx {
>> +struct drm_framebuffer *fb;
>> +unsigned int width;
>> +unsigned int height;
>> +void *vmap;
>> +
>> +const struct font_desc *font;
>> +unsigned int col_width;
>> +unsigned int bottom_y;
>> +size_t max_line_length;
>> +
>> +unsigned int x;
>> +unsigned int y;
>> +};
>> +
>> +static const struct font_desc *drm_panic_font8x8, *drm_panic_font8x16;
>> +
>> +static void drm_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
>> + int x, int y, bool fg)
>> +{
>> +if (fb->funcs->panic_draw_xy)
>> +fb->funcs->panic_draw_xy(fb, vmap, x, y, fg);
>> +else
>> +drm_framebuffer_panic_draw_xy(fb, vmap, x, y, fg);
>> +}
>> +
>> +static void drm_panic_render_char(struct drm_panic_ctx *ctx,
>> + unsigned int offset, char c)
>> +{
>> +unsigned int h, w, x, y;
>> +u8 fontline;
>> +
>> +for (h = 0; h < ctx->font->height; h++) {
>> +fontline = *(u8 *)(ctx->font->data + c * ctx->font->height + h);
>> +
>> +for (w = 0; w < ctx->font->width; w++) {
>> +x = ctx->x + (offset * ctx->font->width) + w;
>> +y = ctx->y + h;
>> +drm_panic_draw_xy(ctx->fb, ctx->vmap, x, y,
>> + fontline & BIT(7 - w));
>> +}
>> +}
>> +}
>> +
>> +static void drm_panic_render_line(struct drm_panic_ctx *ctx,
>> + const char *line, size_t len)
>> +{
>> +unsigned int i;
>> +
>> +for (i = 0; i < len; i++)
>> +drm_panic_render_char(ctx, i, line[i]);
>> +
>> +/* Clear out the rest of the line */
>> +for (i = len; i < ctx->max_line_length; i++)
>> +drm_panic_render_char(ctx, i, ' ');
>> +}
>> +
>> +static bool drm_panic_newline(struct drm_panic_ctx *ctx)
>> +{
>> +if (ctx->x == 0 && ctx->y == 0)
>> +return false;
>> +if (ctx->y == 0) {
>> +ctx->x -= ctx->col_width;
>> +ctx->y = ctx->bottom_y;
>> +} else {
>> +ctx->y -= ctx->font->height;
>> +}
>> +
>> +return true;
>> +}
>> +
>> +/* Render from bottom right most column */
>> +static bool drm_panic_render_lines(struct drm_panic_ctx *ctx,
>> + const char *str, size_t len)
>> +{
>> +size_t l, line_length;
>> +const char *pos;
>> +int i;
>> +
>> +while (len) {
>> +pos = str + len - 1;
>> +
>> +if (*pos == '\n') {
>> +len--;
>> +if (!drm_panic_newline(ctx))
>> +return false;
>> +continue;
>> +}
>> +
>> +while (pos > str && *(pos - 1) != '\n')
>> +pos--;
>> +
>> +line_length = len - (pos - str);
>> +
>> +if (!line_length || len < line_length) {
>> +pr_err("%s: Bug! line_length=%zu len=%zu\n",
>> +
Re: [PATCH] drm/atomic-helper: Validate pointer before dereference
Hi Rodrigo
On Mon, Mar 11, 2019 at 06:01:20PM -0300, Rodrigo Siqueira wrote:
> The function disable_outputs() and
> drm_atomic_helper_commit_modeset_enables() tries to retrieve
> helper_private from the target CRTC, for dereferencing some operations.
> However, the current implementation does not check whether
> helper_private is null and, if not, if it has a valid pointer to a dpms
> and commit functions. This commit adds pointer validations before
> trying to dereference the dpms and commit function.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 30 -
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> @@ -1277,11 +1279,13 @@ void drm_atomic_helper_commit_modeset_enables(struct
> drm_device *dev,
> if (new_crtc_state->enable) {
> DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
>crtc->base.id, crtc->name);
This DEBUG_ print is only relevant if the code actually
do something in the following.
So it seems more correct to fix the upper if () to:
> if (new_crtc_state->enable && funcs != NULL) {
> DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
...
The you also loose one indent and the calls are nicer.
(If used "funcs != NULL", but this is a matter of taste).
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
On Mon, 11 Mar 2019 at 18:40, Sam Ravnborg wrote: > > Hi Eze > > > > Why is this driver still here? I thought we migrated everyhing to > > tinydrm already. > Some have been ported, some are waiting for a user to do the port. > If you looks at tinydrm you will see: > ili9225.c ili9341.c > > And we also have under panel: > panel-ilitek-ili9881c.c > panel-ilitek-ili9322.c > > But in staging there are more panels than just these. > > So we have not yet ported all. > And there is today no list of what is missing. > Right. Perhaps the TODO file on fbtft should be updated stating clearly that we don't care about cleaning this one. This is important given staging is used for Outreachy and other introductory programs. We can also add some big fat warning message (in case there isn't one already) asking users of staging/fbtft to help porting/testing the port to tinydrm. Thanks, Eze ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Dante. > Hello Sam, thank you very much for your comments, > As I told Dan (my email did not reach the mailing list) this is my > first attempt to contribute, > So I'm learning a lot from your advice and corrections. > > I will look for TODO lists to see if there are more useful > contributions to make, all suggestions are also welcome. Keep the good spirit, and find some other driver to look into. You must realise than experienced developers sometimes goes through several version before a patch is ready. So expect it to be a bumpy ride the first few times. Good luck! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Eze > > Why is this driver still here? I thought we migrated everyhing to > tinydrm already. Some have been ported, some are waiting for a user to do the port. If you looks at tinydrm you will see: ili9225.c ili9341.c And we also have under panel: panel-ilitek-ili9881c.c panel-ilitek-ili9322.c But in staging there are more panels than just these. So we have not yet ported all. And there is today no list of what is missing. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi everyone, Dante: please avoid top-posting. In other words, put your replies in-line, like I'm gonna do now. See below (and see how discussion goes on other threads). On Mon, 11 Mar 2019 at 17:34, DANTE JAVIER PAZ wrote: > > Hello Sam, thank you very much for your comments, > As I told Dan (my email did not reach the mailing list) this is my > first attempt to contribute, > So I'm learning a lot from your advice and corrections. > > I will look for TODO lists to see if there are more useful > contributions to make, all suggestions are also welcome. > > Thanks again for the patience of all of you. > Best, > Dante > > > El lun., 11 mar. 2019 a las 13:25, Sam Ravnborg () > escribió: > > > > Hi Dante > > > > Thanks for the patch. > > On Sat, Mar 09, 2019 at 06:48:52PM -0300, Dante Paz wrote: > > > From: Dante Paz > > > > > > Style and coding function issues were corrected, by avoiding macro > > > functions with a conflicting coding style. > > > Signed-off-by: Dante Paz > > > > But it raised a few comments. > > > > The staging/fbtft is a dumping of a set of drivers that > > in the end will be migrated to DRM. > > And there is not much gained trying to do coding style changes to these > > drivers. > > So please conmsider finding a drver where this is more relevant. > > Sam, Why is this driver still here? I thought we migrated everyhing to tinydrm already. Maybe there's a list of panels still not migrated? Thanks, Eze ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic-helper: Validate pointer before dereference
The function disable_outputs() and
drm_atomic_helper_commit_modeset_enables() tries to retrieve
helper_private from the target CRTC, for dereferencing some operations.
However, the current implementation does not check whether
helper_private is null and, if not, if it has a valid pointer to a dpms
and commit functions. This commit adds pointer validations before
trying to dereference the dpms and commit function.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/drm_atomic_helper.c | 30 -
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 540a77a2ade9..fbeef7c461fc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1028,14 +1028,16 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
/* Right function depends upon target state. */
- if (new_crtc_state->enable && funcs->prepare)
- funcs->prepare(crtc);
- else if (funcs->atomic_disable)
- funcs->atomic_disable(crtc, old_crtc_state);
- else if (funcs->disable)
- funcs->disable(crtc);
- else
- funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
+ if (funcs) {
+ if (new_crtc_state->enable && funcs->prepare)
+ funcs->prepare(crtc);
+ else if (funcs->atomic_disable)
+ funcs->atomic_disable(crtc, old_crtc_state);
+ else if (funcs->disable)
+ funcs->disable(crtc);
+ else if (funcs->dpms)
+ funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
+ }
if (!(dev->irq_enabled && dev->num_crtcs))
continue;
@@ -1277,11 +1279,13 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
if (new_crtc_state->enable) {
DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
crtc->base.id, crtc->name);
-
- if (funcs->atomic_enable)
- funcs->atomic_enable(crtc, old_crtc_state);
- else
- funcs->commit(crtc);
+ if (funcs) {
+ if (funcs->atomic_enable)
+ funcs->atomic_enable(crtc,
+old_crtc_state);
+ else if (funcs->atomic_enable)
+ funcs->commit(crtc);
+ }
}
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add an entry for the vboxvideo driver
On Mon, Mar 11, 2019 at 12:35 PM Hans de Goede wrote: > > Add a MAINTAINERS entry for the vboxvideo driver, now that it has been > moved out of staging. > > Acked-by: Daniel Vetter > Signed-off-by: Hans de Goede Acked-by: Alex Deucher > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 81d484891b53..36577f5db872 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4932,6 +4932,13 @@ S: Odd Fixes > F: drivers/gpu/drm/udl/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > +DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU > +M: Hans de Goede > +L: dri-devel@lists.freedesktop.org > +S: Maintained > +F: drivers/gpu/drm/vboxvideo/ > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > DRM DRIVER FOR VMWARE VIRTUAL GPU > M: "VMware Graphics" > M: Thomas Hellstrom > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 1/8] gpu: ipu-v3: Fix i.MX51 CSI control registers offset
From: Alexander Shiyan
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]
The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Alexander Shiyan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5030cba4a581..0c51b1dde494 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -746,8 +746,8 @@ static struct ipu_devtype ipu_type_imx51 = {
.cpmem_ofs = 0x1f00,
.srm_ofs = 0x1f04,
.tpm_ofs = 0x1f06,
- .csi0_ofs = 0x1f03,
- .csi1_ofs = 0x1f038000,
+ .csi0_ofs = 0x1e03,
+ .csi1_ofs = 0x1e038000,
.ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 2/8] gpu: ipu-v3: Fix CSI offsets for imx53
From: Steve Longerbeam
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]
The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e03 and 0x1e038000 respectively.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Steve Longerbeam
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 0c51b1dde494..df295a0ce87d 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -762,8 +762,8 @@ static struct ipu_devtype ipu_type_imx53 = {
.cpmem_ofs = 0x0700,
.srm_ofs = 0x0704,
.tpm_ofs = 0x0706,
- .csi0_ofs = 0x0703,
- .csi1_ofs = 0x07038000,
+ .csi0_ofs = 0x0603,
+ .csi1_ofs = 0x06038000,
.ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 02/12] gpu: ipu-v3: Fix CSI offsets for imx53
From: Steve Longerbeam
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]
The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e03 and 0x1e038000 respectively.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Steve Longerbeam
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index d41983f3ad3e..57d22bc963b5 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -900,8 +900,8 @@ static struct ipu_devtype ipu_type_imx53 = {
.cpmem_ofs = 0x0700,
.srm_ofs = 0x0704,
.tpm_ofs = 0x0706,
- .csi0_ofs = 0x0703,
- .csi1_ofs = 0x07038000,
+ .csi0_ofs = 0x0603,
+ .csi1_ofs = 0x06038000,
.ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 01/12] gpu: ipu-v3: Fix i.MX51 CSI control registers offset
From: Alexander Shiyan
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]
The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Alexander Shiyan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 99c813a4ec1f..d41983f3ad3e 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -884,8 +884,8 @@ static struct ipu_devtype ipu_type_imx51 = {
.cpmem_ofs = 0x1f00,
.srm_ofs = 0x1f04,
.tpm_ofs = 0x1f06,
- .csi0_ofs = 0x1f03,
- .csi1_ofs = 0x1f038000,
+ .csi0_ofs = 0x1e03,
+ .csi1_ofs = 0x1e038000,
.ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 01/27] drm/imx: ignore plane updates on disabled crtcs
From: Philipp Zabel
[ Upstream commit 4fb873c9648e383206e0a91cef9b03aa54066aca ]
This patch fixes backtraces like the following when sending SIGKILL to a
process with a currently pending plane update:
[drm:ipu_plane_atomic_check] CRTC should be enabled
[drm:drm_framebuffer_remove] *ERROR* failed to commit
[ cut here ]
WARNING: CPU: 3 PID: 63 at drivers/gpu/drm/drm_framebuffer.c:926
drm_framebuffer_remove+0x47c/0x498
atomic remove_fb failed with -22
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index cf98596c7ce1..d0d7f6adbc89 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -348,9 +348,9 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (ret)
return ret;
- /* CRTC should be enabled */
+ /* nothing to check when disabling or disabled */
if (!crtc_state->enable)
- return -EINVAL;
+ return 0;
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: don't block fb changes for async plane updates
On Mon, Mar 11, 2019 at 08:51:27PM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 03:20:09PM +0100, Boris Brezillon wrote:
> > On Mon, 11 Mar 2019 13:15:23 +
> > "Kazlauskas, Nicholas" wrote:
> >
> > > On 3/11/19 6:06 AM, Boris Brezillon wrote:
> > > > Hello Nicholas,
> > > >
> > > > On Mon, 4 Mar 2019 15:46:49 +
> > > > "Kazlauskas, Nicholas" wrote:
> > > >
> > > >> On 3/4/19 9:49 AM, Helen Koike wrote:
> > > >>> In the case of a normal sync update, the preparation of framebuffers
> > > >>> (be
> > > >>> it calling drm_atomic_helper_prepare_planes() or doing setups with
> > > >>> drm_framebuffer_get()) are performed in the new_state and the
> > > >>> respective
> > > >>> cleanups are performed in the old_state.
> > > >>>
> > > >>> In the case of async updates, the preparation is also done in the
> > > >>> new_state but the cleanups are done in the new_state (because updates
> > > >>> are performed in place, i.e. in the current state).
> > > >>>
> > > >>> The current code blocks async udpates when the fb is changed, turning
> > > >>> async updates into sync updates, slowing down cursor updates and
> > > >>> introducing regressions in igt tests with errors of type:
> > > >>>
> > > >>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> > > >>> expect to complete approximately 15360 updates, with the threshold set
> > > >>> at 7680"
> > > >>>
> > > >>> Fb changes in async updates were prevented to avoid the following
> > > >>> scenario:
> > > >>>
> > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup
> > > >>> fb2 (wrong)
> > > >>> Where we have a single call to prepare fb2 but double cleanup call to
> > > >>> fb2.
> > > >>>
> > > >>> To solve the above problems, instead of blocking async fb changes, we
> > > >>> place the old framebuffer in the new_state object, so when the code
> > > >>> performs cleanups in the new_state it will cleanup the old_fb and we
> > > >>> will have the following scenario instead:
> > > >>>
> > > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> > > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> > > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> > > >>>
> > > >>> Where calls to prepare/cleanup are ballanced.
> > > >>>
> > > >>> Cc: # v4.14+: 25dc194b34dd: drm: Block fb
> > > >>> changes for async plane updates
> > > >>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> > > >>> Suggested-by: Boris Brezillon
> > > >>> Signed-off-by: Helen Koike
> > > >>>
> > > >>> ---
> > > >>> Hello,
> > > >>>
> > > >>> As mentioned in the cover letter,
> > > >>> I tested on the rockchip and on i915 (with a patch I am still working
> > > >>> on for
> > > >>> replacing cursors by async update), with igt plane_cursor_legacy and
> > > >>> kms_cursor_legacy and I didn't see any regressions.
> > > >>> I couldn't test on MSM and AMD because I don't have the hardware (and
> > > >>> I am
> > > >>> having some issues testing on vc4) and I would appreciate if anyone
> > > >>> could help
> > > >>> me testing those.
> > > >>>
> > > >>> I also think it would be a better solution if, instead of having async
> > > >>> to do in-place updates in the current state, the async path should be
> > > >>> equivalent to a syncronous update, i.e., modifying new_state and
> > > >>> performing a flip
> > > >>> IMHO, the only difference between sync and async should be that async
> > > >>> update
> > > >>> doesn't wait for vblank and applies the changes immeditally to the hw,
> > > >>> but the code path could be almost the same.
> > > >>> But for now I think this solution is ok (swaping new_fb/old_fb), and
> > > >>> then we can adjust things little by little, what do you think?
> > > >>>
> > > >>> Thanks!
> > > >>> Helen
> > > >>>
> > > >>>drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> > > >>>1 file changed, 10 insertions(+), 10 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> index 540a77a2ade9..e7eb96f1efc2 100644
> > > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > >>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct
> > > >>> drm_device *dev,
> > > >>> old_plane_state->crtc != new_plane_state->crtc)
> > > >>> return -EINVAL;
> > > >>>
> > > >>> - /*
> > > >>> - * FIXME: Since prepare_fb and cleanup_fb are always called on
> > > >>> - * the new_plane_state for async updates we need to block
> > > >>> framebuffer
> > > >>> - * changes. This prevents use of a fb that's been cleaned up and
> > > >>> - * double cleanups from occuring.
> > > >>> - */
> > > >>>
[PATCH AUTOSEL 4.14 04/27] gpu: ipu-v3: Fix CSI offsets for imx53
From: Steve Longerbeam
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]
The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e03 and 0x1e038000 respectively.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Steve Longerbeam
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5f8b31f879ca..f3a57c0500f3 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -910,8 +910,8 @@ static struct ipu_devtype ipu_type_imx53 = {
.cpmem_ofs = 0x0700,
.srm_ofs = 0x0704,
.tpm_ofs = 0x0706,
- .csi0_ofs = 0x0703,
- .csi1_ofs = 0x07038000,
+ .csi0_ofs = 0x0603,
+ .csi1_ofs = 0x06038000,
.ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 02/27] gpu: ipu-v3: Fix i.MX51 CSI control registers offset
From: Alexander Shiyan
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]
The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Alexander Shiyan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 2c8411b8d050..5f8b31f879ca 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -894,8 +894,8 @@ static struct ipu_devtype ipu_type_imx51 = {
.cpmem_ofs = 0x1f00,
.srm_ofs = 0x1f04,
.tpm_ofs = 0x1f06,
- .csi0_ofs = 0x1f03,
- .csi1_ofs = 0x1f038000,
+ .csi0_ofs = 0x1e03,
+ .csi1_ofs = 0x1e038000,
.ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 03/27] drm/imx: imx-ldb: add missing of_node_puts
From: Julia Lawall
[ Upstream commit aa3312012f103f91f123600bbf768b11c8f431bc ]
The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.
Move the initialization channel->child = child; down to just
before the call to imx_ldb_register so that intervening failures
don't need to clear it. Add a label at the end of the function to
do all the of_node_puts.
The semantic patch that finds part of this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
* return ...;
)
...
}
//
Signed-off-by: Julia Lawall
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/imx-ldb.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index dd5312b02a8d..4f2e6c7e04c1 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -652,8 +652,10 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
int bus_format;
ret = of_property_read_u32(child, "reg", &i);
- if (ret || i < 0 || i > 1)
- return -EINVAL;
+ if (ret || i < 0 || i > 1) {
+ ret = -EINVAL;
+ goto free_child;
+ }
if (!of_device_is_available(child))
continue;
@@ -666,7 +668,6 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
channel = &imx_ldb->channel[i];
channel->ldb = imx_ldb;
channel->chno = i;
- channel->child = child;
/*
* The output port is port@4 with an external 4-port mux or
@@ -676,13 +677,13 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
imx_ldb->lvds_mux ? 4 : 2, 0,
&channel->panel,
&channel->bridge);
if (ret && ret != -ENODEV)
- return ret;
+ goto free_child;
/* panel ddc only if there is no bridge */
if (!channel->bridge) {
ret = imx_ldb_panel_ddc(dev, channel, child);
if (ret)
- return ret;
+ goto free_child;
}
bus_format = of_get_bus_format(dev, child);
@@ -698,18 +699,26 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
if (bus_format < 0) {
dev_err(dev, "could not determine data mapping: %d\n",
bus_format);
- return bus_format;
+ ret = bus_format;
+ goto free_child;
}
channel->bus_format = bus_format;
+ channel->child = child;
ret = imx_ldb_register(drm, channel);
- if (ret)
- return ret;
+ if (ret) {
+ channel->child = NULL;
+ goto free_child;
+ }
}
dev_set_drvdata(dev, imx_ldb);
return 0;
+
+free_child:
+ of_node_put(child);
+ return ret;
}
static void imx_ldb_unbind(struct device *dev, struct device *master,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 03/44] drm/imx: imx-ldb: add missing of_node_puts
From: Julia Lawall
[ Upstream commit aa3312012f103f91f123600bbf768b11c8f431bc ]
The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.
Move the initialization channel->child = child; down to just
before the call to imx_ldb_register so that intervening failures
don't need to clear it. Add a label at the end of the function to
do all the of_node_puts.
The semantic patch that finds part of this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
* return ...;
)
...
}
//
Signed-off-by: Julia Lawall
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/imx-ldb.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 3bd0f8a18e74..42daa5c9ff8e 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -651,8 +651,10 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
int bus_format;
ret = of_property_read_u32(child, "reg", &i);
- if (ret || i < 0 || i > 1)
- return -EINVAL;
+ if (ret || i < 0 || i > 1) {
+ ret = -EINVAL;
+ goto free_child;
+ }
if (!of_device_is_available(child))
continue;
@@ -665,7 +667,6 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
channel = &imx_ldb->channel[i];
channel->ldb = imx_ldb;
channel->chno = i;
- channel->child = child;
/*
* The output port is port@4 with an external 4-port mux or
@@ -675,13 +676,13 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
imx_ldb->lvds_mux ? 4 : 2, 0,
&channel->panel,
&channel->bridge);
if (ret && ret != -ENODEV)
- return ret;
+ goto free_child;
/* panel ddc only if there is no bridge */
if (!channel->bridge) {
ret = imx_ldb_panel_ddc(dev, channel, child);
if (ret)
- return ret;
+ goto free_child;
}
bus_format = of_get_bus_format(dev, child);
@@ -697,18 +698,26 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
if (bus_format < 0) {
dev_err(dev, "could not determine data mapping: %d\n",
bus_format);
- return bus_format;
+ ret = bus_format;
+ goto free_child;
}
channel->bus_format = bus_format;
+ channel->child = child;
ret = imx_ldb_register(drm, channel);
- if (ret)
- return ret;
+ if (ret) {
+ channel->child = NULL;
+ goto free_child;
+ }
}
dev_set_drvdata(dev, imx_ldb);
return 0;
+
+free_child:
+ of_node_put(child);
+ return ret;
}
static void imx_ldb_unbind(struct device *dev, struct device *master,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 04/44] gpu: ipu-v3: Fix CSI offsets for imx53
From: Steve Longerbeam
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]
The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e03 and 0x1e038000 respectively.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Steve Longerbeam
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5b7cdbfe062f..0a7d4395d427 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -914,8 +914,8 @@ static struct ipu_devtype ipu_type_imx53 = {
.cpmem_ofs = 0x0700,
.srm_ofs = 0x0704,
.tpm_ofs = 0x0706,
- .csi0_ofs = 0x0703,
- .csi1_ofs = 0x07038000,
+ .csi0_ofs = 0x0603,
+ .csi1_ofs = 0x06038000,
.ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 01/44] drm/imx: ignore plane updates on disabled crtcs
From: Philipp Zabel
[ Upstream commit 4fb873c9648e383206e0a91cef9b03aa54066aca ]
This patch fixes backtraces like the following when sending SIGKILL to a
process with a currently pending plane update:
[drm:ipu_plane_atomic_check] CRTC should be enabled
[drm:drm_framebuffer_remove] *ERROR* failed to commit
[ cut here ]
WARNING: CPU: 3 PID: 63 at drivers/gpu/drm/drm_framebuffer.c:926
drm_framebuffer_remove+0x47c/0x498
atomic remove_fb failed with -22
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 203f247d4854..a323a0db2fc1 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -375,9 +375,9 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (ret)
return ret;
- /* CRTC should be enabled */
+ /* nothing to check when disabling or disabled */
if (!crtc_state->enable)
- return -EINVAL;
+ return 0;
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 02/44] gpu: ipu-v3: Fix i.MX51 CSI control registers offset
From: Alexander Shiyan
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]
The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Alexander Shiyan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 474b00e19697..5b7cdbfe062f 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -898,8 +898,8 @@ static struct ipu_devtype ipu_type_imx51 = {
.cpmem_ofs = 0x1f00,
.srm_ofs = 0x1f04,
.tpm_ofs = 0x1f06,
- .csi0_ofs = 0x1f03,
- .csi1_ofs = 0x1f038000,
+ .csi0_ofs = 0x1e03,
+ .csi1_ofs = 0x1e038000,
.ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 01/52] drm/imx: ignore plane updates on disabled crtcs
From: Philipp Zabel
[ Upstream commit 4fb873c9648e383206e0a91cef9b03aa54066aca ]
This patch fixes backtraces like the following when sending SIGKILL to a
process with a currently pending plane update:
[drm:ipu_plane_atomic_check] CRTC should be enabled
[drm:drm_framebuffer_remove] *ERROR* failed to commit
[ cut here ]
WARNING: CPU: 3 PID: 63 at drivers/gpu/drm/drm_framebuffer.c:926
drm_framebuffer_remove+0x47c/0x498
atomic remove_fb failed with -22
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 40605fdf0e33..b1f327dcea99 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -372,9 +372,9 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (ret)
return ret;
- /* CRTC should be enabled */
+ /* nothing to check when disabling or disabled */
if (!crtc_state->enable)
- return -EINVAL;
+ return 0;
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 02/52] gpu: ipu-v3: Fix i.MX51 CSI control registers offset
From: Alexander Shiyan
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]
The CSI0/CSI1 registers offset is at +0xe03/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Alexander Shiyan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 474b00e19697..5b7cdbfe062f 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -898,8 +898,8 @@ static struct ipu_devtype ipu_type_imx51 = {
.cpmem_ofs = 0x1f00,
.srm_ofs = 0x1f04,
.tpm_ofs = 0x1f06,
- .csi0_ofs = 0x1f03,
- .csi1_ofs = 0x1f038000,
+ .csi0_ofs = 0x1e03,
+ .csi1_ofs = 0x1e038000,
.ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
Hi Noralf. Nice! > +++ b/drivers/gpu/drm/drm_panic.c > @@ -0,0 +1,363 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright 2018 Noralf Trønnes > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Please do not use drmP.h in new stuff. And res-sort the list of include files when add it. I did not read much further, so no further pedantic comments in this round. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 04/52] gpu: ipu-v3: Fix CSI offsets for imx53
From: Steve Longerbeam
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]
The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e03 and 0x1e038000 respectively.
Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")
Signed-off-by: Steve Longerbeam
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 5b7cdbfe062f..0a7d4395d427 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -914,8 +914,8 @@ static struct ipu_devtype ipu_type_imx53 = {
.cpmem_ofs = 0x0700,
.srm_ofs = 0x0704,
.tpm_ofs = 0x0706,
- .csi0_ofs = 0x0703,
- .csi1_ofs = 0x07038000,
+ .csi0_ofs = 0x0603,
+ .csi1_ofs = 0x06038000,
.ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 03/52] drm/imx: imx-ldb: add missing of_node_puts
From: Julia Lawall
[ Upstream commit aa3312012f103f91f123600bbf768b11c8f431bc ]
The device node iterators perform an of_node_get on each
iteration, so a jump out of the loop requires an of_node_put.
Move the initialization channel->child = child; down to just
before the call to imx_ldb_register so that intervening failures
don't need to clear it. Add a label at the end of the function to
do all the of_node_puts.
The semantic patch that finds part of this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
* return ...;
)
...
}
//
Signed-off-by: Julia Lawall
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/imx/imx-ldb.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 3bd0f8a18e74..42daa5c9ff8e 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -651,8 +651,10 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
int bus_format;
ret = of_property_read_u32(child, "reg", &i);
- if (ret || i < 0 || i > 1)
- return -EINVAL;
+ if (ret || i < 0 || i > 1) {
+ ret = -EINVAL;
+ goto free_child;
+ }
if (!of_device_is_available(child))
continue;
@@ -665,7 +667,6 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
channel = &imx_ldb->channel[i];
channel->ldb = imx_ldb;
channel->chno = i;
- channel->child = child;
/*
* The output port is port@4 with an external 4-port mux or
@@ -675,13 +676,13 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
imx_ldb->lvds_mux ? 4 : 2, 0,
&channel->panel,
&channel->bridge);
if (ret && ret != -ENODEV)
- return ret;
+ goto free_child;
/* panel ddc only if there is no bridge */
if (!channel->bridge) {
ret = imx_ldb_panel_ddc(dev, channel, child);
if (ret)
- return ret;
+ goto free_child;
}
bus_format = of_get_bus_format(dev, child);
@@ -697,18 +698,26 @@ static int imx_ldb_bind(struct device *dev, struct device
*master, void *data)
if (bus_format < 0) {
dev_err(dev, "could not determine data mapping: %d\n",
bus_format);
- return bus_format;
+ ret = bus_format;
+ goto free_child;
}
channel->bus_format = bus_format;
+ channel->child = child;
ret = imx_ldb_register(drm, channel);
- if (ret)
- return ret;
+ if (ret) {
+ channel->child = NULL;
+ goto free_child;
+ }
}
dev_set_drvdata(dev, imx_ldb);
return 0;
+
+free_child:
+ of_node_put(child);
+ return ret;
}
static void imx_ldb_unbind(struct device *dev, struct device *master,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: don't block fb changes for async plane updates
On Mon, Mar 04, 2019 at 03:46:49PM +, Kazlauskas, Nicholas wrote:
> On 3/4/19 9:49 AM, Helen Koike wrote:
> > In the case of a normal sync update, the preparation of framebuffers (be
> > it calling drm_atomic_helper_prepare_planes() or doing setups with
> > drm_framebuffer_get()) are performed in the new_state and the respective
> > cleanups are performed in the old_state.
> >
> > In the case of async updates, the preparation is also done in the
> > new_state but the cleanups are done in the new_state (because updates
> > are performed in place, i.e. in the current state).
> >
> > The current code blocks async udpates when the fb is changed, turning
> > async updates into sync updates, slowing down cursor updates and
> > introducing regressions in igt tests with errors of type:
> >
> > "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> > expect to complete approximately 15360 updates, with the threshold set
> > at 7680"
> >
> > Fb changes in async updates were prevented to avoid the following scenario:
> >
> > - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> > - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> > - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> > (wrong)
> > Where we have a single call to prepare fb2 but double cleanup call to fb2.
> >
> > To solve the above problems, instead of blocking async fb changes, we
> > place the old framebuffer in the new_state object, so when the code
> > performs cleanups in the new_state it will cleanup the old_fb and we
> > will have the following scenario instead:
> >
> > - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> > - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> > - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> >
> > Where calls to prepare/cleanup are ballanced.
> >
> > Cc: # v4.14+: 25dc194b34dd: drm: Block fb changes
> > for async plane updates
> > Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> > Suggested-by: Boris Brezillon
> > Signed-off-by: Helen Koike
> >
> > ---
> > Hello,
> >
> > As mentioned in the cover letter,
> > I tested on the rockchip and on i915 (with a patch I am still working on for
> > replacing cursors by async update), with igt plane_cursor_legacy and
> > kms_cursor_legacy and I didn't see any regressions.
> > I couldn't test on MSM and AMD because I don't have the hardware (and I am
> > having some issues testing on vc4) and I would appreciate if anyone could
> > help
> > me testing those.
> >
> > I also think it would be a better solution if, instead of having async
> > to do in-place updates in the current state, the async path should be
> > equivalent to a syncronous update, i.e., modifying new_state and
> > performing a flip
> > IMHO, the only difference between sync and async should be that async update
> > doesn't wait for vblank and applies the changes immeditally to the hw,
> > but the code path could be almost the same.
> > But for now I think this solution is ok (swaping new_fb/old_fb), and
> > then we can adjust things little by little, what do you think?
> >
> > Thanks!
> > Helen
> >
> > drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 540a77a2ade9..e7eb96f1efc2 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device
> > *dev,
> > old_plane_state->crtc != new_plane_state->crtc)
> > return -EINVAL;
> >
> > - /*
> > -* FIXME: Since prepare_fb and cleanup_fb are always called on
> > -* the new_plane_state for async updates we need to block framebuffer
> > -* changes. This prevents use of a fb that's been cleaned up and
> > -* double cleanups from occuring.
> > -*/
> > - if (old_plane_state->fb != new_plane_state->fb)
> > - return -EINVAL;
> > -
> > funcs = plane->helper_private;
> > if (!funcs->atomic_async_update)
> > return -EINVAL;
> > @@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device
> > *dev,
> > int i;
> >
> > for_each_new_plane_in_state(state, plane, plane_state, i) {
> > + struct drm_framebuffer *new_fb = plane_state->fb;
> > + struct drm_framebuffer *old_fb = plane->state->fb;
> > +
> > funcs = plane->helper_private;
> > funcs->atomic_async_update(plane, plane_state);
> >
> > @@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct
> > drm_device *dev,
> > * plane->state in-place, make sure at least common
> > * properties have been properly updated.
> > */
> > - WARN_ON_ONCE(plane->state->fb != plane_s
Re: [PATCH 1/5] drm: don't block fb changes for async plane updates
On Mon, Mar 11, 2019 at 03:20:09PM +0100, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 13:15:23 +
> "Kazlauskas, Nicholas" wrote:
>
> > On 3/11/19 6:06 AM, Boris Brezillon wrote:
> > > Hello Nicholas,
> > >
> > > On Mon, 4 Mar 2019 15:46:49 +
> > > "Kazlauskas, Nicholas" wrote:
> > >
> > >> On 3/4/19 9:49 AM, Helen Koike wrote:
> > >>> In the case of a normal sync update, the preparation of framebuffers (be
> > >>> it calling drm_atomic_helper_prepare_planes() or doing setups with
> > >>> drm_framebuffer_get()) are performed in the new_state and the respective
> > >>> cleanups are performed in the old_state.
> > >>>
> > >>> In the case of async updates, the preparation is also done in the
> > >>> new_state but the cleanups are done in the new_state (because updates
> > >>> are performed in place, i.e. in the current state).
> > >>>
> > >>> The current code blocks async udpates when the fb is changed, turning
> > >>> async updates into sync updates, slowing down cursor updates and
> > >>> introducing regressions in igt tests with errors of type:
> > >>>
> > >>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> > >>> expect to complete approximately 15360 updates, with the threshold set
> > >>> at 7680"
> > >>>
> > >>> Fb changes in async updates were prevented to avoid the following
> > >>> scenario:
> > >>>
> > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> > >>> (wrong)
> > >>> Where we have a single call to prepare fb2 but double cleanup call to
> > >>> fb2.
> > >>>
> > >>> To solve the above problems, instead of blocking async fb changes, we
> > >>> place the old framebuffer in the new_state object, so when the code
> > >>> performs cleanups in the new_state it will cleanup the old_fb and we
> > >>> will have the following scenario instead:
> > >>>
> > >>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> > >>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> > >>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> > >>>
> > >>> Where calls to prepare/cleanup are ballanced.
> > >>>
> > >>> Cc: # v4.14+: 25dc194b34dd: drm: Block fb
> > >>> changes for async plane updates
> > >>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> > >>> Suggested-by: Boris Brezillon
> > >>> Signed-off-by: Helen Koike
> > >>>
> > >>> ---
> > >>> Hello,
> > >>>
> > >>> As mentioned in the cover letter,
> > >>> I tested on the rockchip and on i915 (with a patch I am still working
> > >>> on for
> > >>> replacing cursors by async update), with igt plane_cursor_legacy and
> > >>> kms_cursor_legacy and I didn't see any regressions.
> > >>> I couldn't test on MSM and AMD because I don't have the hardware (and I
> > >>> am
> > >>> having some issues testing on vc4) and I would appreciate if anyone
> > >>> could help
> > >>> me testing those.
> > >>>
> > >>> I also think it would be a better solution if, instead of having async
> > >>> to do in-place updates in the current state, the async path should be
> > >>> equivalent to a syncronous update, i.e., modifying new_state and
> > >>> performing a flip
> > >>> IMHO, the only difference between sync and async should be that async
> > >>> update
> > >>> doesn't wait for vblank and applies the changes immeditally to the hw,
> > >>> but the code path could be almost the same.
> > >>> But for now I think this solution is ok (swaping new_fb/old_fb), and
> > >>> then we can adjust things little by little, what do you think?
> > >>>
> > >>> Thanks!
> > >>> Helen
> > >>>
> > >>>drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> > >>>1 file changed, 10 insertions(+), 10 deletions(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > >>> b/drivers/gpu/drm/drm_atomic_helper.c
> > >>> index 540a77a2ade9..e7eb96f1efc2 100644
> > >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct
> > >>> drm_device *dev,
> > >>> old_plane_state->crtc != new_plane_state->crtc)
> > >>> return -EINVAL;
> > >>>
> > >>> - /*
> > >>> -* FIXME: Since prepare_fb and cleanup_fb are always called on
> > >>> -* the new_plane_state for async updates we need to block
> > >>> framebuffer
> > >>> -* changes. This prevents use of a fb that's been cleaned up and
> > >>> -* double cleanups from occuring.
> > >>> -*/
> > >>> - if (old_plane_state->fb != new_plane_state->fb)
> > >>> - return -EINVAL;
> > >>> -
> > >>> funcs = plane->helper_private;
> > >>> if (!funcs->atomic_async_update)
> > >>> return -EINVAL;
> > >>> @@ -1657,6 +1648,9 @@ void
Re: [PATCH v2 1/3] drm: Add support for panic message output
On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find suitable framebuffers.
> >
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> >
> > Signed-off-by: Noralf Trønnes
>
> Bunch of comments/ideas for you or Darwish below, whoever picks this up.
> -Daniel
>
> > ---
> > drivers/gpu/drm/Kconfig | 3 +
> > drivers/gpu/drm/drm_drv.c | 3 +
> > drivers/gpu/drm/drm_framebuffer.c | 117 ++
> > drivers/gpu/drm/drm_internal.h| 4 +
> > drivers/gpu/drm/drm_panic.c | 363 ++
> > include/drm/drm_framebuffer.h | 41
> > 6 files changed, 531 insertions(+)
> > create mode 100644 drivers/gpu/drm/drm_panic.c
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index bd943a71756c..74c37542f857 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -14,6 +14,9 @@ menuconfig DRM
> > select I2C_ALGOBIT
> > select DMA_SHARED_BUFFER
> > select SYNC_FILE
> > + select FONT_SUPPORT
> > + select FONT_8x8
> > + select FONT_8x16
> > help
> > Kernel-level support for the Direct Rendering Infrastructure (DRI)
> > introduced in XFree86 4.0. If you say Y here, you need to select
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 50d849d1bc6e..b0b870b5dd55 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -1147,6 +1147,7 @@ static const struct file_operations drm_stub_fops = {
> >
> > static void drm_core_exit(void)
> > {
> > + drm_panic_exit(drm_debugfs_root);
> > unregister_chrdev(DRM_MAJOR, "drm");
> > debugfs_remove(drm_debugfs_root);
> > drm_sysfs_destroy();
> > @@ -1178,6 +1179,8 @@ static int __init drm_core_init(void)
> > if (ret < 0)
> > goto error;
> >
> > + drm_panic_init(drm_debugfs_root);
> > +
> > drm_core_init_complete = true;
> >
> > DRM_DEBUG("Initialized\n");
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index d8d75e25f6fb..da2285c5ae90 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -1087,3 +1087,120 @@ int drm_framebuffer_debugfs_init(struct drm_minor
> > *minor)
> > minor->debugfs_root, minor);
> > }
> > #endif
> > +
> > +/**
> > + * drm_framebuffer_panic_draw_xy - draw pixel on fb during panic()
> > + * @fb: DRM framebuffer
> > + * @vmap: Linear virtual mapping
> > + * @x: X coordinate
> > + * @y: Y coordinate
> > + * @foreground: Foreground pixel
> > + *
> > + * This function can be used to draw a pixel during panic message
> > rendering.
> > + * It requires @vmap to be a linear mapping. This is the default
> > implementation
> > + * used if &drm_framebuffer_funcs->panic_draw_xy is not set.
> > + */
> > +void drm_framebuffer_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
> > + int x, int y, bool foreground)
> > +{
> > + void *pix = vmap + fb->offsets[0] + (y * fb->pitches[0]);
> > + u8 *pix8 = pix;
> > + u16 *pix16 = pix;
> > + u32 *pix32 = pix;
> > +
> > + switch (fb->format->format & ~DRM_FORMAT_BIG_ENDIAN) {
> > + case DRM_FORMAT_C8:
> > +
> > + case DRM_FORMAT_RGB332:
> > + case DRM_FORMAT_BGR233:
> > +
> > + case DRM_FORMAT_NV12:
> > + case DRM_FORMAT_NV21:
> > + case DRM_FORMAT_NV16:
> > + case DRM_FORMAT_NV61:
> > + case DRM_FORMAT_NV24:
> > + case DRM_FORMAT_NV42:
> > +
> > + case DRM_FORMAT_YUV410:
> > + case DRM_FORMAT_YVU410:
> > + case DRM_FORMAT_YUV411:
> > + case DRM_FORMAT_YVU411:
> > + case DRM_FORMAT_YUV420:
> > + case DRM_FORMAT_YVU420:
> > + case DRM_FORMAT_YUV422:
> > + case DRM_FORMAT_YVU422:
> > + case DRM_FORMAT_YUV444:
> > + case DRM_FORMAT_YVU444:
> > + pix8[x] = foreground ? 0xff : 0x00;
> > + break;
> > +
> > + case DRM_FORMAT_XRGB:
> > + case DRM_FORMAT_ARGB:
> > + case DRM_FORMAT_XBGR:
> > + case DRM_FORMAT_ABGR:
> > + pix16[x] = foreground ? 0x : 0xf000;
> > + break;
> > +
> > + case DRM_FORMAT_RGBX:
> > + case DRM_FORMAT_RGBA:
> > + case DRM_FORMAT_BGRX:
> > + case DRM_FORMAT_BGRA:
> > + pix16[x] = foreground ? 0x : 0x000f;
> > + break;
> > +
> > + case DRM_FORMAT_XRGB1555:
> > + case DRM_FORMAT_ARGB1555:
> > + case DRM_FORMAT_XBGR1555:
> > + case DRM_FORMAT_ABGR1555:
> > + pix16[x] = foreground ? 0x : 0x8000;
> > + break;
> > +
> > + case DRM_FORMAT_RGBX5551:
> > + case DRM_FORMAT_RGBA5551:
> > + case DRM_FORMAT_BGRX5551:
> > +
Re: [PATCH v2 1/3] drm: Add support for panic message output
On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
>
> Signed-off-by: Noralf Trønnes
Bunch of comments/ideas for you or Darwish below, whoever picks this up.
-Daniel
> ---
> drivers/gpu/drm/Kconfig | 3 +
> drivers/gpu/drm/drm_drv.c | 3 +
> drivers/gpu/drm/drm_framebuffer.c | 117 ++
> drivers/gpu/drm/drm_internal.h| 4 +
> drivers/gpu/drm/drm_panic.c | 363 ++
> include/drm/drm_framebuffer.h | 41
> 6 files changed, 531 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_panic.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index bd943a71756c..74c37542f857 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -14,6 +14,9 @@ menuconfig DRM
> select I2C_ALGOBIT
> select DMA_SHARED_BUFFER
> select SYNC_FILE
> + select FONT_SUPPORT
> + select FONT_8x8
> + select FONT_8x16
> help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> introduced in XFree86 4.0. If you say Y here, you need to select
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 50d849d1bc6e..b0b870b5dd55 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -1147,6 +1147,7 @@ static const struct file_operations drm_stub_fops = {
>
> static void drm_core_exit(void)
> {
> + drm_panic_exit(drm_debugfs_root);
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> @@ -1178,6 +1179,8 @@ static int __init drm_core_init(void)
> if (ret < 0)
> goto error;
>
> + drm_panic_init(drm_debugfs_root);
> +
> drm_core_init_complete = true;
>
> DRM_DEBUG("Initialized\n");
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index d8d75e25f6fb..da2285c5ae90 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -1087,3 +1087,120 @@ int drm_framebuffer_debugfs_init(struct drm_minor
> *minor)
> minor->debugfs_root, minor);
> }
> #endif
> +
> +/**
> + * drm_framebuffer_panic_draw_xy - draw pixel on fb during panic()
> + * @fb: DRM framebuffer
> + * @vmap: Linear virtual mapping
> + * @x: X coordinate
> + * @y: Y coordinate
> + * @foreground: Foreground pixel
> + *
> + * This function can be used to draw a pixel during panic message rendering.
> + * It requires @vmap to be a linear mapping. This is the default
> implementation
> + * used if &drm_framebuffer_funcs->panic_draw_xy is not set.
> + */
> +void drm_framebuffer_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
> +int x, int y, bool foreground)
> +{
> + void *pix = vmap + fb->offsets[0] + (y * fb->pitches[0]);
> + u8 *pix8 = pix;
> + u16 *pix16 = pix;
> + u32 *pix32 = pix;
> +
> + switch (fb->format->format & ~DRM_FORMAT_BIG_ENDIAN) {
> + case DRM_FORMAT_C8:
> +
> + case DRM_FORMAT_RGB332:
> + case DRM_FORMAT_BGR233:
> +
> + case DRM_FORMAT_NV12:
> + case DRM_FORMAT_NV21:
> + case DRM_FORMAT_NV16:
> + case DRM_FORMAT_NV61:
> + case DRM_FORMAT_NV24:
> + case DRM_FORMAT_NV42:
> +
> + case DRM_FORMAT_YUV410:
> + case DRM_FORMAT_YVU410:
> + case DRM_FORMAT_YUV411:
> + case DRM_FORMAT_YVU411:
> + case DRM_FORMAT_YUV420:
> + case DRM_FORMAT_YVU420:
> + case DRM_FORMAT_YUV422:
> + case DRM_FORMAT_YVU422:
> + case DRM_FORMAT_YUV444:
> + case DRM_FORMAT_YVU444:
> + pix8[x] = foreground ? 0xff : 0x00;
> + break;
> +
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + pix16[x] = foreground ? 0x : 0xf000;
> + break;
> +
> + case DRM_FORMAT_RGBX:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_BGRX:
> + case DRM_FORMAT_BGRA:
> + pix16[x] = foreground ? 0x : 0x000f;
> + break;
> +
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_ARGB1555:
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_ABGR1555:
> + pix16[x] = foreground ? 0x : 0x8000;
> + break;
> +
> + case DRM_FORMAT_RGBX5551:
> + case DRM_FORMAT_RGBA5551:
> + case DRM_FORMAT_BGRX5551:
> + case DRM_FORMAT_BGRA5551:
> + pix16[x] = foreground ? 0x : 0x0001;
> + break;
> +
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + pix16[x] = foreground
Re: [PATCH v2 0/3] drm: Add panic handling
On Mon, Mar 11, 2019 at 06:42:15PM +0100, Noralf Trønnes wrote: > This patchset adds a way for DRM drivers to display kernel messages > during panic(). > > I had a Windows blue screen last year and remembered this patchset, so I > did a new version that I never got around to put out. Now that panic > handling came up on the ML, I'm sending it out as part of the discussion. > > TODO: > Determine which part of the framebuffer that is actually visible. I > don't know enough about KMS to do this. See drm_panic_kmsg_render_screen(). drm_plane_state->src should have this, at least for all drivers using the clip helpers. Which I think is rolled out fairly well. If that happens to be all 0, then drm_plane_state->src_[xyhw] is a decent fallback. If the plane is occluded or scaled then I guess that's just bad luck. -Daniel > > Testing: > I have tested[1] using the formats and resolutions support by vc4 and > modetest. I have even recorded it[2]. RG24 and BG24 gave an unexpected > result, not sure what to make of it. > > Noralf. > > [1] https://gist.github.com/notro/b9fdff4c6a68a307091e970598f27ed0 > [2] https://youtu.be/lZ80vL4dgpE > Version 1 (Aug 2016): https://patchwork.freedesktop.org/series/10867/ > > Changes since version 1: > - Use kernel message dumper > - Add multicolumn support > - Support some YUV formats > - cma: vmap PRIME buffers on import to support that case > > Noralf Trønnes (3): > drm: Add support for panic message output > drm/cma-helper: Add support for panic screen > drm/vc4: Support for panic screen > > drivers/gpu/drm/Kconfig | 3 + > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_drv.c| 3 + > drivers/gpu/drm/drm_fb_cma_helper.c | 43 > drivers/gpu/drm/drm_framebuffer.c| 117 + > drivers/gpu/drm/drm_gem_cma_helper.c | 3 + > drivers/gpu/drm/drm_internal.h | 4 + > drivers/gpu/drm/drm_panic.c | 363 +++ > drivers/gpu/drm/vc4/vc4_kms.c| 3 +- > include/drm/drm_fb_cma_helper.h | 4 +- > include/drm/drm_framebuffer.h| 41 +++ > 11 files changed, 583 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/drm_panic.c > > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Remove useless call to drm_connector_register()
On Mon, Mar 11, 2019 at 03:00:04PM -0300, Rodrigo Siqueira wrote:
> On 03/11, Daniel Vetter wrote:
> > On Sun, Mar 10, 2019 at 06:22:41PM -0300, Rodrigo Siqueira wrote:
> > > The function vkms_output_init() is invoked during the module
> > > initialization, and it handles the creation/configuration of the vkms
> > > essential elements (e.g., connectors, encoder, etc). Among the
> > > initializations, this function tries to initialize a connector and
> > > register it by calling drm_connector_register(). However, inside the
> > > drm_connector_register(), at the beginning of this function there is the
> > > following validation:
> > >
> > > if (!connector->dev->registered)
> > >return 0;
> > >
> > > In this sense, invoke drm_connector_register() after initializing the
> > > connector has no effect because the register field is false. The
> > > connector register happens when drm_dev_register() is invoked.
> > > Therefore, this commit removes the drm_connector_register() from
> > > vkms_output_init().
> > >
> > > Signed-off-by: Rodrigo Siqueira
> > > ---
> > > drivers/gpu/drm/vkms/vkms_output.c | 6 --
> > > 1 file changed, 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> > > b/drivers/gpu/drm/vkms/vkms_output.c
> > > index 3b162b25312e..a6cee4c279c2 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_output.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_output.c
> > > @@ -71,12 +71,6 @@ int vkms_output_init(struct vkms_device *vkmsdev)
> > >
> > > drm_connector_helper_add(connector, &vkms_conn_helper_funcs);
> > >
> > > - ret = drm_connector_register(connector);
> >
> > Yeah that's only needed for connectors added when hotplugging at runtime,
> > not for connectors which are created at driver load time.
> >
> > Reviewed-by: Daniel Vetter
> >
> > btw same issue exists with the drm_connector_unregister, that's also not
> > needed.
>
> Thanks for your review :)
>
> Should I send a V2 that also removes the drm_connector_unregister()? Or
> should I send it in a separated patch?
Either is fine with me. Either has my r-b.
-Daniel
>
> Best Regards
>
> > -Daniel
> >
> > > - if (ret) {
> > > - DRM_ERROR("Failed to register connector\n");
> > > - goto err_connector_register;
> > > - }
> > > -
> > > ret = drm_encoder_init(dev, encoder, &vkms_encoder_funcs,
> > > DRM_MODE_ENCODER_VIRTUAL, NULL);
> > > if (ret) {
> > > --
> > > 2.21.0
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
> Graduate Student
> Department of Computer Science
> University of São Paulo
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Fix NULL dereference on atomic_disable helper
On Mon, Mar 11, 2019 at 02:49:58PM -0300, Rodrigo Siqueira wrote: > On 03/11, Gerd Hoffmann wrote: > > Hi, > > > > > > IIRC the drm code checks for the atomic_enable callback presence to > > > > figure whenever it should take the atomic or legacy code paths. > > > > > > It should check for drm_driver->mode_config.funcs.atomic_commit for that, > > > see drm_drv_uses_atomic_modeset(). Anything else should be a bug. > > > > > > Or do you mean the fallback to the old crtc helper prepare/commit > > > callbacks? > > > > Probably the later. There was some reason why I've left in the empty > > bochs_crtc_atomic_enable() callback ... > > Just for checking before I start to work in this patch: > The correct solution should be made atomic_enable and atomic_disable > optional, right? I should do it, and check if Bochs driver really needs > bochs_crtc_atomic_enable after my change, right? Yup. I just tried to remember why we haven't done this yet, but I think that was a patch to make crtc->helper_funcs optional. And that doesn't make sense imo, since if your crtc doesn't do anything then you don't really have an atomic driver :-) And if there's ever a legit use case for this, then that drive probably shouldn't use the atomic helpers ... But making crtc_helper_funcs->atomic_enable/disable optional sounds like a good idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/hdr-formats
On Mon, Mar 11, 2019 at 01:52:13PM -0400, Adam Jackson wrote: > On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote: > > Hey, > > > > Op 07-03-2019 om 18:12 schreef Adam Jackson: > > > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote: > > > > Hi Sean and Joonas, > > > > > > > > Here's a pull request for HDR format enabling in i915. Can this be > > > > pulled to drm-misc-next and dinq? > > > Could you also add Kevin Strasser's patch for FP16 formats? For that > > > matter I'd like to see FP32 added too, but I don't think there's been a > > > patch sent for that yet. > > > > Added kevin to CC. > > > > Is the mesa side considered completely reviewed then? > > Is that strictly necessary for just adding a fourcc? I get wanting to > see a real userspace consumer first, but this is just allocating some > magic numbers not promising that a certain ioctl behaves a certain way. It's a bit a grey area, since uapi/drm/drm_fourcc.h is both a simple magic number registry for userspace and also the source of truth for what that's supposed to mean for AddFB. Which is uapi. Having the full mesa->kms pipeline gives a bit more assurance we didn't flip something somewhere by accident or some other silliness. So for i915.ko stuff we've been pretty strict with this, just to make sure we don't ship broken stuff. But we definitely merged other patches without anything being able to consume/produce those formats in userspace (well anything open source at least), fitting the magic number registry. Imo this is an area each driver team can decide on how they want to handle it (with my maintainer hat on). -Daniel > > That said, I did say r-b for the Mesa series as a whole. Daniel Stone > had some comments on 13/13 that made it sound like it (that specific > patch) was unnecessary/undesirable, but everything before that looked > great to me, and even if we only merged the first 12 we'd still have > FP16 wired through for the gbm EGL platform, meaning HDR scanout could > actually be a thing. > > - ajax > > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Remove useless call to drm_connector_register()
On 03/11, Daniel Vetter wrote:
> On Sun, Mar 10, 2019 at 06:22:41PM -0300, Rodrigo Siqueira wrote:
> > The function vkms_output_init() is invoked during the module
> > initialization, and it handles the creation/configuration of the vkms
> > essential elements (e.g., connectors, encoder, etc). Among the
> > initializations, this function tries to initialize a connector and
> > register it by calling drm_connector_register(). However, inside the
> > drm_connector_register(), at the beginning of this function there is the
> > following validation:
> >
> > if (!connector->dev->registered)
> >return 0;
> >
> > In this sense, invoke drm_connector_register() after initializing the
> > connector has no effect because the register field is false. The
> > connector register happens when drm_dev_register() is invoked.
> > Therefore, this commit removes the drm_connector_register() from
> > vkms_output_init().
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/vkms_output.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> > b/drivers/gpu/drm/vkms/vkms_output.c
> > index 3b162b25312e..a6cee4c279c2 100644
> > --- a/drivers/gpu/drm/vkms/vkms_output.c
> > +++ b/drivers/gpu/drm/vkms/vkms_output.c
> > @@ -71,12 +71,6 @@ int vkms_output_init(struct vkms_device *vkmsdev)
> >
> > drm_connector_helper_add(connector, &vkms_conn_helper_funcs);
> >
> > - ret = drm_connector_register(connector);
>
> Yeah that's only needed for connectors added when hotplugging at runtime,
> not for connectors which are created at driver load time.
>
> Reviewed-by: Daniel Vetter
>
> btw same issue exists with the drm_connector_unregister, that's also not
> needed.
Thanks for your review :)
Should I send a V2 that also removes the drm_connector_unregister()? Or
should I send it in a separated patch?
Best Regards
> -Daniel
>
> > - if (ret) {
> > - DRM_ERROR("Failed to register connector\n");
> > - goto err_connector_register;
> > - }
> > -
> > ret = drm_encoder_init(dev, encoder, &vkms_encoder_funcs,
> >DRM_MODE_ENCODER_VIRTUAL, NULL);
> > if (ret) {
> > --
> > 2.21.0
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/hdr-formats
On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote: > Hey, > > Op 07-03-2019 om 18:12 schreef Adam Jackson: > > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote: > > > Hi Sean and Joonas, > > > > > > Here's a pull request for HDR format enabling in i915. Can this be pulled > > > to drm-misc-next and dinq? > > Could you also add Kevin Strasser's patch for FP16 formats? For that > > matter I'd like to see FP32 added too, but I don't think there's been a > > patch sent for that yet. > > Added kevin to CC. > > Is the mesa side considered completely reviewed then? Is that strictly necessary for just adding a fourcc? I get wanting to see a real userspace consumer first, but this is just allocating some magic numbers not promising that a certain ioctl behaves a certain way. That said, I did say r-b for the Mesa series as a whole. Daniel Stone had some comments on 13/13 that made it sound like it (that specific patch) was unnecessary/undesirable, but everything before that looked great to me, and even if we only merged the first 12 we'd still have FP16 wired through for the gbm EGL platform, meaning HDR scanout could actually be a thing. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Fix NULL dereference on atomic_disable helper
On 03/11, Gerd Hoffmann wrote: > Hi, > > > > IIRC the drm code checks for the atomic_enable callback presence to > > > figure whenever it should take the atomic or legacy code paths. > > > > It should check for drm_driver->mode_config.funcs.atomic_commit for that, > > see drm_drv_uses_atomic_modeset(). Anything else should be a bug. > > > > Or do you mean the fallback to the old crtc helper prepare/commit > > callbacks? > > Probably the later. There was some reason why I've left in the empty > bochs_crtc_atomic_enable() callback ... Just for checking before I start to work in this patch: The correct solution should be made atomic_enable and atomic_disable optional, right? I should do it, and check if Bochs driver really needs bochs_crtc_atomic_enable after my change, right? > cheers, > Gerd > -- Rodrigo Siqueira https://siqueira.tech Graduate Student Department of Computer Science University of São Paulo signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM-based Oops viewer
Den 10.03.2019 02.31, skrev Ahmed S. Darwish: > Hello DRM/UEFI maintainers, > > Several years ago, I wrote a set of patches to dump the kernel > log to disk upon panic -- through BIOS INT 0x13 services. [1] > > The overwhelming response was that it's unsafe to do this in a > generic manner. Linus proposed a video-based viewer instead: [2] > > If you want to do the BIOS services thing, do it for video: copy the > oops to low RAM, return to real mode, re-run the graphics card POST > routines to initialize text-mode, and use the BIOS to print out the > oops. That is WAY less scary than writing to disk. > > Of course it's 2019 now though, and it's quite known that > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3] > > Researching whether this can be done from UEFI, it was also clear > that UEFI "Runtime Services" do not provide any re-initialization > routines. [4] > > The maximum possible that UEFI can provide is a GOP-provided > framebuffer that's ready to use by the OS -- even after the UEFI > boot phase is marked as done through ExitBootServices(). [5] > > Of course, once native drivers like i915 or radeon take over, > such a framebuffer is toast... [6] > > Thus a possible remaining option, is to display the oops through > "minimal" DRM drivers provided for each HW variant... Since > these special drivers will run only and fully under a panic() > context though, several constraints exist: > > - The code should be fully synchronous (irqs are disabled) > - It should not allocate any dynamic memory > - It should make minimal assumptions about HW state > - It should not chain into any other kernel subsystem > - It has ample freedom to use delay-based loops and the > like, the kernel is already dead. > > How feasible is it to have such a special "DRM viewoops" > framework + its minimal drivers in the kernel? > > The target is to start from i915, since that's what in my > laptop now, and work from there.. > > Some final notes: > > - The NT kernel has a similar concept, but for storage instead. > They're used to dump core under kernel panic() situations, > and are called "Minoport storage drivers". [7] > > - Since Windows 7+, a very fancy Blue Screen of Death is > displayed, with Unicode and whatnot, implying GPU drivers > involvement. [8] > > - Mac OS X also does something similar [9] > > - On Linux laptops, the current situation is _really_ bad. > > In any graphical session, type "echo c > /proc/sysrq-trigger"; > the screen will just completely freeze... > > Desired first goal: just print the panic() log > > Thanks a lot, > I just sent out a patchset I had lying around that tries to solve this: https://patchwork.freedesktop.org/series/57849/ Noralf. > [1] https://lore.kernel.org/lkml/20110125134748.GA10051@laptop > [2] > https://lore.kernel.org/lkml/AANLkTinU0KYiCd4p=z+=ojbkeeot2g+cayvdru02k...@mail.gmail.com > > [3] > https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf > > [4] UEFI v2.7 spec, Chapter 8, "Services — Runtime Services" > [5] UEFI v2.7 spec, Section 12.9, "Graphics Output Protocol" > "The Graphics Output Protocol supports this capability by > providing the EFI OS loader access to a hardware frame buffer > and enough information to allow the OS to draw directly to > the graphics output device." > > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > > [7] > https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/restrictions-on-miniport-drivers-that-manage-the-boot-drive > > [8] > https://upload.wikimedia.org/wikipedia/commons/archive/5/56/20181019151937%21Bsodwindows10.png > [9] > https://upload.wikimedia.org/wikipedia/commons/4/4a/Mac_OS_X_10.2_Kernel_Panic.jpg > > --darwi > http://darwish.chasingpointers.com > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm: Add panic handling
This patchset adds a way for DRM drivers to display kernel messages during panic(). I had a Windows blue screen last year and remembered this patchset, so I did a new version that I never got around to put out. Now that panic handling came up on the ML, I'm sending it out as part of the discussion. TODO: Determine which part of the framebuffer that is actually visible. I don't know enough about KMS to do this. See drm_panic_kmsg_render_screen(). Testing: I have tested[1] using the formats and resolutions support by vc4 and modetest. I have even recorded it[2]. RG24 and BG24 gave an unexpected result, not sure what to make of it. Noralf. [1] https://gist.github.com/notro/b9fdff4c6a68a307091e970598f27ed0 [2] https://youtu.be/lZ80vL4dgpE Version 1 (Aug 2016): https://patchwork.freedesktop.org/series/10867/ Changes since version 1: - Use kernel message dumper - Add multicolumn support - Support some YUV formats - cma: vmap PRIME buffers on import to support that case Noralf Trønnes (3): drm: Add support for panic message output drm/cma-helper: Add support for panic screen drm/vc4: Support for panic screen drivers/gpu/drm/Kconfig | 3 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_drv.c| 3 + drivers/gpu/drm/drm_fb_cma_helper.c | 43 drivers/gpu/drm/drm_framebuffer.c| 117 + drivers/gpu/drm/drm_gem_cma_helper.c | 3 + drivers/gpu/drm/drm_internal.h | 4 + drivers/gpu/drm/drm_panic.c | 363 +++ drivers/gpu/drm/vc4/vc4_kms.c| 3 +- include/drm/drm_fb_cma_helper.h | 4 +- include/drm/drm_framebuffer.h| 41 +++ 11 files changed, 583 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/drm_panic.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/vc4: Support for panic screen
Use drm_fb_cma_fb_create() to get panic screen support. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/vc4/vc4_kms.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1ac55c65eac0..3cc57b5c9aff 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -19,7 +19,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ - drm_atomic_uapi.o + drm_atomic_uapi.o drm_panic.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 5160cad25fce..fb9fde08c17f 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include @@ -336,7 +337,7 @@ static struct drm_framebuffer *vc4_fb_create(struct drm_device *dev, mode_cmd = &mode_cmd_local; } - return drm_gem_fb_create(dev, file_priv, mode_cmd); + return drm_fb_cma_fb_create(dev, file_priv, mode_cmd); } /* Our CTM has some peculiar limitations: we can only enable it for one CRTC -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: Add support for panic message output
This adds support for outputting kernel messages on panic().
A kernel message dumper is used to dump the log. The dumper iterates
over each DRM device and it's crtc's to find suitable framebuffers.
All the other dumpers are run before this one except mtdoops.
Only atomic drivers are supported.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 3 +
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_framebuffer.c | 117 ++
drivers/gpu/drm/drm_internal.h| 4 +
drivers/gpu/drm/drm_panic.c | 363 ++
include/drm/drm_framebuffer.h | 41
6 files changed, 531 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panic.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bd943a71756c..74c37542f857 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -14,6 +14,9 @@ menuconfig DRM
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
select SYNC_FILE
+ select FONT_SUPPORT
+ select FONT_8x8
+ select FONT_8x16
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 50d849d1bc6e..b0b870b5dd55 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1147,6 +1147,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drm_panic_exit(drm_debugfs_root);
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1178,6 +1179,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drm_panic_init(drm_debugfs_root);
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index d8d75e25f6fb..da2285c5ae90 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -1087,3 +1087,120 @@ int drm_framebuffer_debugfs_init(struct drm_minor
*minor)
minor->debugfs_root, minor);
}
#endif
+
+/**
+ * drm_framebuffer_panic_draw_xy - draw pixel on fb during panic()
+ * @fb: DRM framebuffer
+ * @vmap: Linear virtual mapping
+ * @x: X coordinate
+ * @y: Y coordinate
+ * @foreground: Foreground pixel
+ *
+ * This function can be used to draw a pixel during panic message rendering.
+ * It requires @vmap to be a linear mapping. This is the default implementation
+ * used if &drm_framebuffer_funcs->panic_draw_xy is not set.
+ */
+void drm_framebuffer_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
+ int x, int y, bool foreground)
+{
+ void *pix = vmap + fb->offsets[0] + (y * fb->pitches[0]);
+ u8 *pix8 = pix;
+ u16 *pix16 = pix;
+ u32 *pix32 = pix;
+
+ switch (fb->format->format & ~DRM_FORMAT_BIG_ENDIAN) {
+ case DRM_FORMAT_C8:
+
+ case DRM_FORMAT_RGB332:
+ case DRM_FORMAT_BGR233:
+
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV21:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
+ case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV42:
+
+ case DRM_FORMAT_YUV410:
+ case DRM_FORMAT_YVU410:
+ case DRM_FORMAT_YUV411:
+ case DRM_FORMAT_YVU411:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ case DRM_FORMAT_YUV422:
+ case DRM_FORMAT_YVU422:
+ case DRM_FORMAT_YUV444:
+ case DRM_FORMAT_YVU444:
+ pix8[x] = foreground ? 0xff : 0x00;
+ break;
+
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
+ pix16[x] = foreground ? 0x : 0xf000;
+ break;
+
+ case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_BGRX:
+ case DRM_FORMAT_BGRA:
+ pix16[x] = foreground ? 0x : 0x000f;
+ break;
+
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_ARGB1555:
+ case DRM_FORMAT_XBGR1555:
+ case DRM_FORMAT_ABGR1555:
+ pix16[x] = foreground ? 0x : 0x8000;
+ break;
+
+ case DRM_FORMAT_RGBX5551:
+ case DRM_FORMAT_RGBA5551:
+ case DRM_FORMAT_BGRX5551:
+ case DRM_FORMAT_BGRA5551:
+ pix16[x] = foreground ? 0x : 0x0001;
+ break;
+
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_BGR565:
+ pix16[x] = foreground ? 0x : 0x;
+ break;
+
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_BGR888:
+ pix8[x * 3] = foreground ? 0xff : 0x00;
+ pix8[(x * 3) + 1] = pix8[x];
+ pix8[(x * 3) + 2] = pix8[x];
+ break;
+
+
[PATCH v2 2/3] drm/cma-helper: Add support for panic screen
Add drm_fb_cma_fb_create() which creates a framebuffer that supports
panic message output.
vmap PRIME buffers on import to support panic on those as well. There
is no atomic way to get a virtual address on a dma_buf.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 43
drivers/gpu/drm/drm_gem_cma_helper.c | 3 ++
include/drm/drm_fb_cma_helper.h | 4 ++-
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 5f8074ffe7d9..9d62dadf5d14 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -56,6 +56,49 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
+static void *drm_fb_cma_fb_panic_vmap(struct drm_framebuffer *fb)
+{
+ return drm_fb_cma_get_gem_obj(fb, 0)->vaddr;
+}
+
+static const struct drm_framebuffer_funcs drm_fb_cma_fb_funcs = {
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .panic_vmap = drm_fb_cma_fb_panic_vmap,
+};
+
+/**
+ * drm_fb_cma_fb_create() - &drm_mode_config_funcs.fb_create callback function
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function creates a new framebuffer object described by
+ * &drm_mode_fb_cmd2. This description includes handles for the buffer(s)
+ * backing the framebuffer.
+ *
+ * If your hardware has special alignment or pitch requirements these should be
+ * checked before calling this function. The function does buffer size
+ * validation.
+ *
+ * Drivers can use this as their &drm_mode_config_funcs.fb_create callback.
+ * The ADDFB2 IOCTL calls into this callback.
+ *
+ * The &drm_framebuffer_funcs.panic_vmap() callback is set supporting panic
+ * screen rendering.
+ *
+ * Returns:
+ * Pointer to a &drm_framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_fb_cma_fb_create(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
+ &drm_fb_cma_fb_funcs);
+}
+EXPORT_SYMBOL_GPL(drm_fb_cma_fb_create);
+
/**
* drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
* formats where values are grouped in blocks this will get you the beginning
of
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index cc26625b4b33..9a4721b5e26d 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -507,6 +507,9 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
cma_obj->paddr = sg_dma_address(sgt->sgl);
cma_obj->sgt = sgt;
+ /* Try to vmap the buffer to support panic rendering */
+ cma_obj->vaddr = dma_buf_vmap(attach->dmabuf);
+
DRM_DEBUG_PRIME("dma_addr = %pad, size = %zu\n", &cma_obj->paddr,
attach->dmabuf->size);
return &cma_obj->base;
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index 4becb09975a4..6c9e5da17140 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -7,7 +7,9 @@ struct drm_plane_state;
struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb,
unsigned int plane);
-
+struct drm_framebuffer *
+drm_fb_cma_fb_create(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd);
dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb,
struct drm_plane_state *state,
unsigned int plane);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/basic_tests.c: check for fork
Am 11.03.19 um 18:17 schrieb Fabrice Fontaine:
> OK, then will you accept a patch that disable amdgpu test if fork is
> not available or a patch that disable all tests (for example through a
> --disable-test-programs option)?
No, we really need to test the correct behavior of fork() with userptrs.
So how do we spawn a child process with uclibc-ng?
I mean it is one of the most fundamental Unix functions, isn't it?
Christian.
> Currently, the user can only disable
> the cairo tests so the whole libdrm package fails to statically build
> with uclibc-ng on ARM cortex M4
> (http://autobuild.buildroot.org/?reason=libdrm-2.4.97).
>
> Best Regards,
>
> Fabrice
>
> Le lun. 11 mars 2019 à 17:40, Christian König
> a écrit :
>> Well NAK, cause that obviously would break the test if fork() isn't
>> available.
>>
>> We certainly don't have any platform where we support amdgpu and fork()
>> is not available, so that change is rather pointless in the first place.
>>
>> Christian.
>>
>> Am 10.03.19 um 10:44 schrieb Fabrice Fontaine:
>>> amdgpu test program use fork since
>>> https://cgit.freedesktop.org/mesa/drm/commit/tests/amdgpu/basic_tests.c?id=736ef0b61cab55378202c5f49d91799cc2b99091
>>>
>>> However, this function is not always available so add a check for it in
>>> configure.ac and use it in tests/amdgpu/basic_tests.c
>>>
>>> Fixes:
>>>-
>>> http://autobuild.buildroot.org/results/8d6194982c1080e173fcef8212fb06e6dc275d58
>>>
>>> Signed-off-by: Fabrice Fontaine
>>> ---
>>>configure.ac | 2 ++
>>>tests/amdgpu/basic_tests.c | 4
>>>2 files changed, 6 insertions(+)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index d72e84ad..6effb9a2 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -193,6 +193,8 @@ AC_CHECK_FUNCS([open_memstream],
>>> [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have
>>> open_memstream()])],
>>> [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
>>>
>>> +AC_CHECK_FUNCS([fork])
>>> +
>>>dnl Use lots of warning flags with with gcc and compatible compilers
>>>
>>>dnl Note: if you change the following variable, the cache is
>>> automatically
>>> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
>>> index dbae4d53..c32a1351 100644
>>> --- a/tests/amdgpu/basic_tests.c
>>> +++ b/tests/amdgpu/basic_tests.c
>>> @@ -1646,10 +1646,12 @@ static void amdgpu_userptr_test(void)
>>>while (j++ < sdma_write_length)
>>>pm4[i++] = 0xdeadbeaf;
>>>
>>> +#ifdef HAVE_FORK
>>>if (!fork()) {
>>>pm4[0] = 0x0;
>>>exit(0);
>>>}
>>> +#endif
>>>
>>>amdgpu_test_exec_cs_helper(context_handle,
>>> AMDGPU_HW_IP_DMA, 0,
>>> @@ -1675,7 +1677,9 @@ static void amdgpu_userptr_test(void)
>>>r = amdgpu_cs_ctx_free(context_handle);
>>>CU_ASSERT_EQUAL(r, 0);
>>>
>>> +#ifdef HAVE_FORK
>>>wait(NULL);
>>> +#endif
>>>}
>>>
>>>static void amdgpu_sync_dependency_test(void)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=109695 Dylan Baker changed: What|Removed |Added Blocks|109535 | --- Comment #11 from Dylan Baker --- I'm removing this from the 19.0 blocking tracker. Generally we don't add bugs to block a release if they were present in the previous release, additionally there doesn't seem to be any consensus on a solution, at this moment. If there is a fix implemented I'd be happy to pull that into a later 19.0 release. Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=109535 [Bug 109535] [Tracker] Mesa 19.0 release tracker -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Clean up TTM mmap offsets
On Mon, Mar 11, 2019 at 05:51:39PM +0100, Christian König wrote: > Am 11.03.19 um 17:39 schrieb Hans de Goede: > > Hi, > > > > On 07-02-19 09:59, Thomas Zimmermann wrote: > > > Almost all TTM-based drivers use the same values for the mmap-able > > > range of BO addresses. Each driver therefore duplicates the > > > DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not > > > configurable by drivers. > > > > > > This patch set replaces driver-specific configuration with a single > > > setup. All code is located within TTM. TTM and GEM share the same > > > range for mmap-able BOs. > > > > > > Thomas Zimmermann (5): > > > staging/vboxvideo: Use same BO mmap offset as other drivers > > > drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant > > > drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() > > > drm/ttm: Quick-test mmap offset in ttm_bo_mmap() > > > drm: Use the same mmap-range offset and size for GEM and TTM > > > > Note I'm about to push a patch-series to drm-misc-next which moves > > vboxvideo out of staging and I see that this series has not landed > > in drm-misc-next yet, so it will needs to be rebased. > > Mhm, TTM is usually not pushed upstream through drm-misc-next, so that will > certainly collide with the next TTM pull request. > > So can you wait with that or should I make an exception and merge this > change though drm-misc-next? Other options: - Get amdgpu added to drm-tip and linux-next so we have a heads-up about the conflict. That's usually good enough to avoid the broken merge conflict. - Do a topic branch, pull it into both trees. - Really stuff ttm into a shared tree if it's meant to be shared infrastructure :-P Waiting+rebasing is imo the worst option, and usually not needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: Zero initialize handle in vmw_execbuf_process
Hi Nathan, Thanks for doing this. I will include this in vmwgfx-next. Reviewed-by: Deepak Rawat On Thu, 2019-03-07 at 15:26 -0700, Nathan Chancellor wrote: > When building with -Wsometimes-uninitialized, Clang warns: > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3964:7: warning: variable > 'handle' is used uninitialized whenever '?:' condition is false > [-Wsometimes-uninitialized] > > It's not wrong; however, in practice, this is never an issue because > the value of handle isn't used when user_fence_rep is NULL because > vmw_execbuf_copy_fence_user returns immediately when that is the > case. > Just zero initialize this variable so that Clang no longer warns. > > Link: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FClangBuiltLinux%2Flinux%2Fissues%2F397&data=02%7C01%7Cdrawat%40vmware.com%7C6b9c429d16d844a5740c08d6a34bedb4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636875943916412703&sdata=Yf7%2BzrbZS96yNJQewYQQ7YsHUDtJSvPaomyTJFZjsDk%3D&reserved=0 > Signed-off-by: Nathan Chancellor > --- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c > index 88b8178d4687..4ba06c2828a1 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c > @@ -3829,7 +3829,7 @@ int vmw_execbuf_process(struct drm_file > *file_priv, > struct vmw_sw_context *sw_context = &dev_priv->ctx; > struct vmw_fence_obj *fence = NULL; > struct vmw_cmdbuf_header *header; > - uint32_t handle; > + uint32_t handle = 0; > int ret; > int32_t out_fence_fd = -1; > struct sync_file *sync_file = NULL; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109941] [CI] igt@i915_pm_rpm@module-reload - crash
https://bugs.freedesktop.org/show_bug.cgi?id=109941 --- Comment #3 from Chris Wilson --- *** Bug 109963 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Clean up TTM mmap offsets
Hi, On 11-03-19 17:51, Christian König wrote: Am 11.03.19 um 17:39 schrieb Hans de Goede: Hi, On 07-02-19 09:59, Thomas Zimmermann wrote: Almost all TTM-based drivers use the same values for the mmap-able range of BO addresses. Each driver therefore duplicates the DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not configurable by drivers. This patch set replaces driver-specific configuration with a single setup. All code is located within TTM. TTM and GEM share the same range for mmap-able BOs. Thomas Zimmermann (5): staging/vboxvideo: Use same BO mmap offset as other drivers drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() drm/ttm: Quick-test mmap offset in ttm_bo_mmap() drm: Use the same mmap-range offset and size for GEM and TTM Note I'm about to push a patch-series to drm-misc-next which moves vboxvideo out of staging and I see that this series has not landed in drm-misc-next yet, so it will needs to be rebased. Mhm, TTM is usually not pushed upstream through drm-misc-next, so that will certainly collide with the next TTM pull request. Ugh, I didn't realize that this series would not be going through drm-misc-next. So can you wait with that or should I make an exception and merge this change though drm-misc-next? I've already pushed it now :| My mail was more intended as a headsup then that I expected an objection, sorry. I see 2 possible solutions: 1) Merge drm-misc-next into the ttm tree (probably the cleanest) 2) Push your series through drm-misc-next Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Clean up TTM mmap offsets
Am 11.03.19 um 17:39 schrieb Hans de Goede: Hi, On 07-02-19 09:59, Thomas Zimmermann wrote: Almost all TTM-based drivers use the same values for the mmap-able range of BO addresses. Each driver therefore duplicates the DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not configurable by drivers. This patch set replaces driver-specific configuration with a single setup. All code is located within TTM. TTM and GEM share the same range for mmap-able BOs. Thomas Zimmermann (5): staging/vboxvideo: Use same BO mmap offset as other drivers drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() drm/ttm: Quick-test mmap offset in ttm_bo_mmap() drm: Use the same mmap-range offset and size for GEM and TTM Note I'm about to push a patch-series to drm-misc-next which moves vboxvideo out of staging and I see that this series has not landed in drm-misc-next yet, so it will needs to be rebased. Mhm, TTM is usually not pushed upstream through drm-misc-next, so that will certainly collide with the next TTM pull request. So can you wait with that or should I make an exception and merge this change though drm-misc-next? Christian. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/basic_tests.c: check for fork
Well NAK, cause that obviously would break the test if fork() isn't
available.
We certainly don't have any platform where we support amdgpu and fork()
is not available, so that change is rather pointless in the first place.
Christian.
Am 10.03.19 um 10:44 schrieb Fabrice Fontaine:
amdgpu test program use fork since
https://cgit.freedesktop.org/mesa/drm/commit/tests/amdgpu/basic_tests.c?id=736ef0b61cab55378202c5f49d91799cc2b99091
However, this function is not always available so add a check for it in
configure.ac and use it in tests/amdgpu/basic_tests.c
Fixes:
-
http://autobuild.buildroot.org/results/8d6194982c1080e173fcef8212fb06e6dc275d58
Signed-off-by: Fabrice Fontaine
---
configure.ac | 2 ++
tests/amdgpu/basic_tests.c | 4
2 files changed, 6 insertions(+)
diff --git a/configure.ac b/configure.ac
index d72e84ad..6effb9a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -193,6 +193,8 @@ AC_CHECK_FUNCS([open_memstream],
[AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have open_memstream()])],
[AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
+AC_CHECK_FUNCS([fork])
+
dnl Use lots of warning flags with with gcc and compatible compilers
dnl Note: if you change the following variable, the cache is automatically
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbae4d53..c32a1351 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1646,10 +1646,12 @@ static void amdgpu_userptr_test(void)
while (j++ < sdma_write_length)
pm4[i++] = 0xdeadbeaf;
+#ifdef HAVE_FORK
if (!fork()) {
pm4[0] = 0x0;
exit(0);
}
+#endif
amdgpu_test_exec_cs_helper(context_handle,
AMDGPU_HW_IP_DMA, 0,
@@ -1675,7 +1677,9 @@ static void amdgpu_userptr_test(void)
r = amdgpu_cs_ctx_free(context_handle);
CU_ASSERT_EQUAL(r, 0);
+#ifdef HAVE_FORK
wait(NULL);
+#endif
}
static void amdgpu_sync_dependency_test(void)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: atomic_helper: Fix spelling errors
Hi Ville, On 11/03/2019 16:00, Ville Syrjälä wrote: > On Mon, Mar 11, 2019 at 03:36:39PM +, Kieran Bingham wrote: >> Trivial fixes identified while working on the DRM code. >> >> s/artifically/artificially/ >> s/achive/acheive/ > > achieve? Good point :) It's rubbish being a native English speaker :( - So much harder to get the spelling correct :D. I'll repost a v2 - sorry for the noise! -- Kieran > >> >> Signed-off-by: Kieran Bingham >> --- >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c >> index 540a77a2ade9..ccb278ed1bf8 100644 >> --- a/drivers/gpu/drm/drm_atomic_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_helper.c >> @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, >> * >> * NOTE: Commit work has multiple phases, first hardware commit, then >> * cleanup. We want them to overlap, hence need system_unbound_wq to >> - * make sure work items don't artifically stall on each another. >> + * make sure work items don't artificially stall on each another. >> */ >> >> drm_atomic_state_get(state); >> @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); >> * >> * Asynchronous workers need to have sufficient parallelism to be able to >> run >> * different atomic commits on different CRTCs in parallel. The simplest >> way to >> - * achive this is by running them on the &system_unbound_wq work queue. Note >> + * acheive this is by running them on the &system_unbound_wq work queue. >> Note >> * that drivers are not required to split up atomic commits and run an >> * individual commit in parallel - userspace is supposed to do that if it >> cares. >> * But it might be beneficial to do that for modesets, since those >> necessarily >> -- >> 2.19.1 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Clean up TTM mmap offsets
Hi, On 07-02-19 09:59, Thomas Zimmermann wrote: Almost all TTM-based drivers use the same values for the mmap-able range of BO addresses. Each driver therefore duplicates the DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not configurable by drivers. This patch set replaces driver-specific configuration with a single setup. All code is located within TTM. TTM and GEM share the same range for mmap-able BOs. Thomas Zimmermann (5): staging/vboxvideo: Use same BO mmap offset as other drivers drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() drm/ttm: Quick-test mmap offset in ttm_bo_mmap() drm: Use the same mmap-range offset and size for GEM and TTM Note I'm about to push a patch-series to drm-misc-next which moves vboxvideo out of staging and I see that this series has not landed in drm-misc-next yet, so it will needs to be rebased. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202873] New: (amdgpu) Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=202873 Bug ID: 202873 Summary: (amdgpu) Screen flickering when using a 75Hz monitor paired with an RX 480 GPU Product: Drivers Version: 2.5 Kernel Version: 4.18, 4.19, 4.20, 5.0 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: m.ivano...@gmail.com Regression: No My monitor is LG 24MP59G-P (75Hz, FreeSync) and my GPU is Sapphire Nitro+ RX 480 8GB. Basically, whenever there is movement on my screen (oddly though, cursor movement doesn't cause it), it would flicker very badly. Here is a video of what I am talking about: https://streamable.com/5eu7p Apart from trying different refresh rates, as seen in the video, I have also tried switching kernel versions, switching from DisplayPort to HDMI, changing compositor settings and turning off FreeSync from the monitor OSD, but nothing seems to resolve the bug. What works for me as a workaround is changing /sys/class/drm/card0/device/power_dpm_force_performance_level from auto to either low or high. When I do watch -n 1 "/sys/class/drm/card0/device/pp_dpm_mclk" with the performance level on auto, it normally stays on the lowest (300MHz) and when I move a window around, it constantly switches from 300MHz to 2000MHz (the max on my GPU). Apparently, that's what's causing it to behave this way. I should emphasize, that I observed the bug in Antergos, Debian 9 Buster (Stretch is good), Manjaro XFCE, Manjaro KDE, Ubuntu 18.10, KUbuntu 18.04 and KUbuntu 18.10. At first I thought it was only related to Arch Linux derivatives, since they all use bleeding-edge packages, but then I noticed, that after switching Debian 9 Stretch's (stable) sources to Buster (testing) and after updating KUbuntu 18.10, the bug appeared in both distros as well. Here is a link to a thread I created in the Manjaro forums, where I asked for help: https://forum.manjaro.org/t/manjaro-kde-screen-flickering-cant-seem-to-find-a-solution/78349 - You can find all kinds of different things I tried there, as well as more in-depth system information. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Add an entry for the vboxvideo driver
Add a MAINTAINERS entry for the vboxvideo driver, now that it has been moved out of staging. Acked-by: Daniel Vetter Signed-off-by: Hans de Goede --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 81d484891b53..36577f5db872 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4932,6 +4932,13 @@ S: Odd Fixes F: drivers/gpu/drm/udl/ T: git git://anongit.freedesktop.org/drm/drm-misc +DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU +M: Hans de Goede +L: dri-devel@lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/vboxvideo/ +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVER FOR VMWARE VIRTUAL GPU M: "VMware Graphics" M: Thomas Hellstrom -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/vboxvideo: Move the vboxvideo driver out of staging
Hi, On 11-03-19 14:09, Daniel Vetter wrote: On Tue, Mar 05, 2019 at 08:03:23AM +0100, Greg Kroah-Hartman wrote: On Mon, Mar 04, 2019 at 05:47:21PM +0100, Hans de Goede wrote: Hi All, This patch-series addresses the 2 TODO / FIXME items recently reported by Daniel and after that moves the vboxvideo driver out of staging. Note this applies on top of drm-misc-next + this patch: https://patchwork.kernel.org/patch/10824279/ Currently that patch is not yet in drm-misc, I can push it myself before pushing the rest of this series (after review). Greg, the intent is for this series to be merged upstream through drm-misc, may we have your Acked-by for that please? For all 3: Acked-by: Greg Kroah-Hartman Please add a patch 4 to add a MAINTAINERS entry pointing at the drm-misc git repo (and I guess Hans as maintainer/reviewer). With that, on all 4 patches: Acked-by: Daniel Vetter Thank you. I agree this needs a MAINTAINERS entry. Note I will send out the MAINTAINRS / 4th patch now, so that patchwork picks it up and dim can extract a patchwork URL. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fbtft-bus: Fix code style problems
Hi Dante Thanks for the patch. On Sat, Mar 09, 2019 at 06:48:52PM -0300, Dante Paz wrote: > From: Dante Paz > > Style and coding function issues were corrected, by avoiding macro > functions with a conflicting coding style. > Signed-off-by: Dante Paz But it raised a few comments. The staging/fbtft is a dumping of a set of drivers that in the end will be migrated to DRM. And there is not much gained trying to do coding style changes to these drivers. So please conmsider finding a drver where this is more relevant. Furthermore that patch presented is hard to review as it contains too much changes in one go. As a rule of thumb include only one type of change per patch. This is worth to keep in mind for future submissions. It it then also good to present the trivial changes first(*), and the less trivial changes later. (*) Like whitespace to tabs, spellign errors etc. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107731] radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)
https://bugs.freedesktop.org/show_bug.cgi?id=107731 --- Comment #4 from Harry Wentland --- Can you post a dmesg log with drm.debug=4? I suspect it's because of a link training failure. drm.debug=4 should confirm that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard wrote: > > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote: > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > > MIPI clock topology in Allwinner DSI controller. > > > > TCON dotclock driver is computing the desired DCLK divider based on > > panel pixel clock along with input DCLK min, max divider values from > > tcon driver and that would eventually set the pll-mipi clock rate. > > > > The current code allows the TCON clock divider to have a default 4 > > for min, max ranges that would fail to compute the desired pll-mipi > > rate while supporting new panels. > > > > So, add the computation logic 'format/lanes' to dclk min and max dividers > > and instead of default 4. This computation logic align with Allwinner A64 > > BSP, hoping that would work even for A33. > > Last time we discussed this, we found out that this wasn't the case, > even in the BSP. This was the case for BSP to compute pll-mipi not for TCON_DSI clock register, SUN4I_TCON0_DCLK_REG, which marked the divider 4 by default. > > What compelling evidence have you found that makes you say otherwise? divider 4 isn't worked, this I would mentioned before as well. Tested this on 4 different panels, and below are the desired divider values and pll-mipi clock rate with respect to pixel clock frequency. - 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider is 6 with the output parent clock rate of 330MHz. - 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider is 6 with parent clock rate of 180MHz. - 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider is 12 with the output parent clock rate of 330MHz. - 147MHz pixel clock with 4-lane panel, and the desired DSI clock divider is 6 with the output parent clock rate of 882MHz. BSP trying to use this format/lane to compute dsi divider that in-turn using pll-mipi set_rate but TCON0_DCLK_REG keep constant 4. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard wrote:
>
> On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> > Vertical video start delay is computed by excluding vertical front
> > porch value from total vertical timings.
> >
> > This clearly confirmed from BSP code and here how it computed,
> >
> > (drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
> > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
> > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
> >- panel->lcd_y - (panel->lcd_vbp)
> > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
> >- panel->lcd_y - panel->lcd_vbp
> > => timmings->ver_front_porch
> >
> > But the current driver is assuming it can exclude vertical front
> > porch along with vertical sync values from total vertical timings,
> > which resulting wrong start delay indeed wrong picture rendering
> > in the panel.
>
> Same story here: which panel, which datasheet, which "wrong picture
> rendering"?
It's bananapi,s070wv20-ct16 DSI
>
> > Example: timings, where it produces the issue.
> > {
> > .vdisplay = 600,
> > .vsync_start= 600 + 12,
> > .vsync_end = 600 + 12 + 2,
> > .vtotal = 600 + 12 + 2 + 21,
> > }
>
> Can you 100% trust those timings?
ie. reason, I have given the Mainline timings [1]. The above timings
are wrongly mentioned actual timings are from [1]
>
> > It produces the desired start delay value as 19 but the correct working
> > value should be 513.
> >
> > So, Fix it by computing proper video start delay.
> >
> > Fixes: 69006ef0ecb1 ("drm/sun4i: dsi: Change the start delay calculation")
> > Signed-off-by: Jagan Teki
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 62a508420227..8d6292c0158b 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -364,8 +364,14 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> > static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> > struct drm_display_mode *mode)
> > {
> > - u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
> > - u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
> > + u16 delay = mode->vtotal - (mode->vsync_start - mode->vdisplay);
> > +
> > + /**
> > + * BSP comment:
> > + * put start_delay to tcon. set ready sync early to dramfreq,
> > + * so set start_delay 1
> > + */
>
> That doesn't make any sense to me... What does it mean?
Which is meaning as above stated as "BSP comment" from here[2]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7
[2]
https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L729
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: atomic_helper: Fix spelling errors
On Mon, Mar 11, 2019 at 03:36:39PM +, Kieran Bingham wrote: > Trivial fixes identified while working on the DRM code. > > s/artifically/artificially/ > s/achive/acheive/ achieve? > > Signed-off-by: Kieran Bingham > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 540a77a2ade9..ccb278ed1bf8 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, >* >* NOTE: Commit work has multiple phases, first hardware commit, then >* cleanup. We want them to overlap, hence need system_unbound_wq to > - * make sure work items don't artifically stall on each another. > + * make sure work items don't artificially stall on each another. >*/ > > drm_atomic_state_get(state); > @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); > * > * Asynchronous workers need to have sufficient parallelism to be able to run > * different atomic commits on different CRTCs in parallel. The simplest way > to > - * achive this is by running them on the &system_unbound_wq work queue. Note > + * acheive this is by running them on the &system_unbound_wq work queue. Note > * that drivers are not required to split up atomic commits and run an > * individual commit in parallel - userspace is supposed to do that if it > cares. > * But it might be beneficial to do that for modesets, since those > necessarily > -- > 2.19.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: add ARM GPU tile format
On Sat, Mar 09, 2019 at 10:09:02PM +0800, Qiang Yu wrote:
Hi Qiang,
Apologies for jumping to the very initial patch. I wanted to have some
understanding of the newly proposed modifiers since they seem to me a
duplicate of the existing AFBC modifiers.
> v2: seperate AFBC and GPU encoding
>
> Cc: Brian Starkey
> Cc: Rob Herring
> Cc: Alyssa Rosenzweig
> Signed-off-by: Qiang Yu
> ---
> include/uapi/drm/drm_fourcc.h | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9fa7cf7bb274..7af5197e7ebc 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -601,6 +601,19 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
>
> +/*
> + * Arm Device code
> + *
> + * Arm has multiple devices which do not share buffer format,
> + * so add a device field at the MSB of the format field to seperate
> + * each device's encoding.
> + */
> +#define DRM_FORMAT_MOD_ARM_DEVICE_AFBC 0x00
Why can't you reuse the existing DRM_FORMAT_MOD_VENDOR_ARM ?
> +#define DRM_FORMAT_MOD_ARM_DEVICE_GPU 0x01
What is the purpose of this? AFBC modifiers are supposed to be used
across gpus, dpus which support AFBC buffers rendering.
> +
> +#define DRM_FORMAT_MOD_ARM_CODE(device, val) \
> + fourcc_mod_code(ARM, ((__u64)device << 48) | ((val) &
> 0xULL))
> +
> /*
> * Arm Framebuffer Compression (AFBC) modifiers
> *
> @@ -615,7 +628,8 @@ extern "C" {
> * Further information on the use of AFBC modifiers can be found in
> * Documentation/gpu/afbc.rst
> */
> -#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
> __afbc_mode)
> +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_AFBC, __afbc_mode)
>
Similar question? Why can't you reuse the existing one?
> /*
> * AFBC superblock size
> @@ -709,6 +723,21 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/*
> + * Arm GPU modifiers
> + */
> +#define DRM_FORMAT_MOD_ARM_GPU(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_GPU, mode)
> +
> +/*
> + * Arm GPU tiled format
> + *
> + * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
> + * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_GPU_TILED DRM_FORMAT_MOD_ARM_GPU(1)
> +
You might want to re-use the exisiting modifier
AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
I would suggest you to have a look at the exisiting AFBC modifiers
(denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is something
you cannot reuse.
> /*
> * Allwinner tiled modifier
> *
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property
Hi!
On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> Sometimes it is desirabled to use a separate i2c controller for ddc
> access. This adds support for the ddc-i2c-bus property of the
> hdmi-connector node, using the specified controller if provided.
>
> Signed-off-by: Mans Rullgard
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 +
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++---
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index b685ee11623d..b08c4453d47c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
> struct clk *tmds_clk;
>
> struct i2c_adapter *i2c;
> + struct i2c_adapter *ddc_i2c;
>
> /* Regmap fields for I2C adapter */
> struct regmap_field *field_ddc_en;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 061d2e0d9011..5b2fac79f5d6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector
> *connector)
> struct edid *edid;
> int ret;
>
> - edid = drm_get_edid(connector, hdmi->i2c);
> + edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
You can't test whether ddc_i2c is NULL or not...
> if (!edid)
> return 0;
>
> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct drm_connector
> *connector)
> return ret;
> }
>
> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
> +{
> + struct device_node *phandle, *remote;
> + struct i2c_adapter *ddc;
> +
> + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> + if (!remote)
> + return ERR_PTR(-EINVAL);
> +
> + phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> + of_node_put(remote);
> + if (!phandle)
> + return NULL;
> +
> + ddc = of_get_i2c_adapter_by_node(phandle);
> + of_node_put(phandle);
> + if (!ddc)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return ddc;
... Since even in (most) error cases you're returning a !NULL pointer.
> +}
> +
> static const struct drm_connector_helper_funcs
> sun4i_hdmi_connector_helper_funcs = {
> .get_modes = sun4i_hdmi_get_modes,
> };
> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, struct
> device *master,
> goto err_disable_mod_clk;
> }
>
> + hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
> + if (IS_ERR(hdmi->ddc_i2c)) {
> + ret = PTR_ERR(hdmi->ddc_i2c);
> + goto err_del_i2c_adapter;
> + }
> +
> drm_encoder_helper_add(&hdmi->encoder,
> &sun4i_hdmi_helper_funcs);
> ret = drm_encoder_init(drm,
> @@ -584,14 +612,14 @@ static int sun4i_hdmi_bind(struct device *dev, struct
> device *master,
> NULL);
> if (ret) {
> dev_err(dev, "Couldn't initialise the HDMI encoder\n");
> - goto err_del_i2c_adapter;
> + goto err_put_ddc_i2c;
> }
>
> hdmi->encoder.possible_crtcs = drm_of_find_possible_crtcs(drm,
> dev->of_node);
> if (!hdmi->encoder.possible_crtcs) {
> ret = -EPROBE_DEFER;
> - goto err_del_i2c_adapter;
> + goto err_put_ddc_i2c;
> }
>
> #ifdef CONFIG_DRM_SUN4I_HDMI_CEC
> @@ -630,6 +658,8 @@ static int sun4i_hdmi_bind(struct device *dev, struct
> device *master,
> err_cleanup_connector:
> cec_delete_adapter(hdmi->cec_adap);
> drm_encoder_cleanup(&hdmi->encoder);
> +err_put_ddc_i2c:
> + i2c_put_adapter(hdmi->ddc_i2c);
> err_del_i2c_adapter:
> i2c_del_adapter(hdmi->i2c);
> err_disable_mod_clk:
> @@ -650,6 +680,7 @@ static void sun4i_hdmi_unbind(struct device *dev, struct
> device *master,
> drm_connector_cleanup(&hdmi->connector);
> drm_encoder_cleanup(&hdmi->encoder);
> i2c_del_adapter(hdmi->i2c);
> + i2c_put_adapter(hdmi->ddc_i2c);
> clk_disable_unprepare(hdmi->mod_clk);
> clk_disable_unprepare(hdmi->bus_clk);
> }
> --
> 2.21.0
>
It looks good otherwise, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #23 from Clément Guérin (li...@protonmail.com) --- Hi Nicholas, any progress on this? Can you answer my question above? Thanks. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote: > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > MIPI clock topology in Allwinner DSI controller. > > TCON dotclock driver is computing the desired DCLK divider based on > panel pixel clock along with input DCLK min, max divider values from > tcon driver and that would eventually set the pll-mipi clock rate. > > The current code allows the TCON clock divider to have a default 4 > for min, max ranges that would fail to compute the desired pll-mipi > rate while supporting new panels. > > So, add the computation logic 'format/lanes' to dclk min and max dividers > and instead of default 4. This computation logic align with Allwinner A64 > BSP, hoping that would work even for A33. Last time we discussed this, we found out that this wasn't the case, even in the BSP. What compelling evidence have you found that makes you say otherwise? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 01/15] drm/sun4i: dsi: Fix video start delay computation
On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> Vertical video start delay is computed by excluding vertical front
> porch value from total vertical timings.
>
> This clearly confirmed from BSP code and here how it computed,
>
> (drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
> => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
> => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
>- panel->lcd_y - (panel->lcd_vbp)
> => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
>- panel->lcd_y - panel->lcd_vbp
> => timmings->ver_front_porch
>
> But the current driver is assuming it can exclude vertical front
> porch along with vertical sync values from total vertical timings,
> which resulting wrong start delay indeed wrong picture rendering
> in the panel.
Same story here: which panel, which datasheet, which "wrong picture
rendering"?
> Example: timings, where it produces the issue.
> {
> .vdisplay = 600,
> .vsync_start= 600 + 12,
> .vsync_end = 600 + 12 + 2,
> .vtotal = 600 + 12 + 2 + 21,
> }
Can you 100% trust those timings?
> It produces the desired start delay value as 19 but the correct working
> value should be 513.
>
> So, Fix it by computing proper video start delay.
>
> Fixes: 69006ef0ecb1 ("drm/sun4i: dsi: Change the start delay calculation")
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 62a508420227..8d6292c0158b 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -364,8 +364,14 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> - u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
> - u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
> + u16 delay = mode->vtotal - (mode->vsync_start - mode->vdisplay);
> +
> + /**
> + * BSP comment:
> + * put start_delay to tcon. set ready sync early to dramfreq,
> + * so set start_delay 1
> + */
That doesn't make any sense to me... What does it mean?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8] drm/lima: driver for ARM Mali4xx GPUs
On Sat, Mar 9, 2019 at 6:21 AM Qiang Yu wrote:
>
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one GP but multiple PP (max 4 for mali 400 and 8
> for mali 450) in the same mali 4xx GPU. All PPs are grouped
> togather to handle a single fragment shader task divided by
> FB output tiled pixels. Mali 400 user space driver is
> responsible for assign target tiled pixels to each PP, but mali
> 450 has a HW module called DLBU to dynamically balance each
> PP's load.
> - User space driver allocate buffer object and map into GPU
> virtual address space, upload command stream and draw data with
> CPU mmap of the buffer object, then submit task to GP/PP with
> a register frame indicating where is the command stream and misc
> settings.
> - There's no command stream validation/relocation due to each user
> process has its own GPU virtual address space. GP/PP's MMU switch
> virtual address space before running two tasks from different
> user process. Error or evil user space code just get MMU fault
> or GP/PP error IRQ, then the HW/SW will be recovered.
> - Use GEM+shmem for MM. Currently just alloc and pin memory when
> gem object creation. GPU vm map of the buffer is also done in
> the alloc stage in kernel space. We may delay the memory
> allocation and real GPU vm map to command submission stage in the
> furture as improvement.
> - Use drm_sched for GPU task schedule. Each OpenGL context should
> have a lima context object in the kernel to distinguish tasks
> from different user. drm_sched gets task from each lima context
> in a fair way.
>
> mesa driver can be found here before upstreamed:
> https://gitlab.freedesktop.org/lima/mesa
>
> v8:
> - add comments for in_sync
> - fix ctx free miss mutex unlock
>
> v7:
> - remove lima_fence_ops with default value
> - move fence slab create to device probe
> - check pad ioctl args to be zero
> - add comments for user/kernel interface
>
> v6:
> - fix comments by checkpatch.pl
>
> v5:
> - export gp/pp version to userspace
> - rebase on drm-misc-next
>
> v4:
> - use get param interface to get info
> - separate context create/free ioctl
> - remove unused max sched task param
> - update copyright time
> - use xarray instead of idr
> - stop using drmP.h
>
> v3:
> - fix comments from kbuild robot
> - restrict supported arch to tested ones
>
> v2:
> - fix syscall argument check
> - fix job finish fence leak since kernel 5.0
> - use drm syncobj to replace native fence
> - move buffer object GPU va map into kernel
> - reserve syscall argument space for future info
> - remove kernel gem modifier
> - switch TTM back to GEM+shmem MM
> - use time based io poll
> - use whole register name
> - adopt gem reservation obj integration
> - use drm_timeout_abs_to_jiffies
>
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Alex Deucher
> Cc: Sam Ravnborg
> Cc: Rob Clark
> Cc: Dave Airlie
> Signed-off-by: Andreas Baierl
> Signed-off-by: Erico Nunes
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Marek Vasut
> Signed-off-by: Neil Armstrong
> Signed-off-by: Simon Shields
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Qiang Yu
> Reviewed-by: Eric Anholt
> Reviewed-by: Rob Herring
> ---
[...]
> +static int lima_gem_lock_bos(struct lima_bo **bos, u32 nr_bos,
> +struct ww_acquire_ctx *ctx)
> +{
> + int i, ret = 0, contended, slow_locked = -1;
> +
> + ww_acquire_init(ctx, &reservation_ww_class);
> +
> +retry:
> + for (i = 0; i < nr_bos; i++) {
> + if (i == slow_locked) {
> + slow_locked = -1;
> + continue;
> + }
> +
> + ret = ww_mutex_lock_interruptible(&bos[i]->gem.resv->lock,
> ctx);
> + if (ret < 0) {
> + contended = i;
> + goto err;
> + }
> + }
> +
> + ww_acquire_done(ctx);
> + return 0;
> +
> +err:
> + for (i--; i >= 0; i--)
> + ww_mutex_unlock(&bos[i]->gem.resv->lock);
> +
> + if (slow_locked >= 0)
> + ww_mutex_unlock(&bos[slow_locked]->gem.resv->lock);
> +
> + if (ret == -EDEADLK) {
> + /* we lost out in a seqno race, lock and retry.. */
> + ret = ww_mutex_lock_slow_interruptible(
> + &bos[contended]->gem.resv->lock, ctx);
> + if (!ret) {
> + slow_locked = contended;
> + goto retry;
> + }
> + }
> + ww_acquire_fini(ctx);
> +
> + return ret;
> +}
> +
> +static void lima_gem_unlock_bos(struct lima_bo **bos, u32 nr_bos,
> + struct ww_acquire_ctx *ctx)
> +{
> + int i;
[PATCH] gpu: drm: atomic_helper: Fix spelling errors
Trivial fixes identified while working on the DRM code. s/artifically/artificially/ s/achive/acheive/ Signed-off-by: Kieran Bingham --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 540a77a2ade9..ccb278ed1bf8 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, * * NOTE: Commit work has multiple phases, first hardware commit, then * cleanup. We want them to overlap, hence need system_unbound_wq to -* make sure work items don't artifically stall on each another. +* make sure work items don't artificially stall on each another. */ drm_atomic_state_get(state); @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); * * Asynchronous workers need to have sufficient parallelism to be able to run * different atomic commits on different CRTCs in parallel. The simplest way to - * achive this is by running them on the &system_unbound_wq work queue. Note + * acheive this is by running them on the &system_unbound_wq work queue. Note * that drivers are not required to split up atomic commits and run an * individual commit in parallel - userspace is supposed to do that if it cares. * But it might be beneficial to do that for modesets, since those necessarily -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109017] The drop in resolution with AMD Kaveri
https://bugs.freedesktop.org/show_bug.cgi?id=109017 --- Comment #9 from Dmitry --- Now the bug does not appear. Perhaps this is due to the fact that I set all the parameters before installing Arch, or it was fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/5] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits
On Mon, Mar 11, 2019 at 7:39 PM Maxime Ripard wrote:
>
> On Thu, Mar 07, 2019 at 09:24:02PM +0530, Jagan Teki wrote:
> > On Thu, Mar 7, 2019 at 9:09 PM Maxime Ripard
> > wrote:
> > >
> > > On Thu, Mar 07, 2019 at 05:49:07PM +0530, Jagan Teki wrote:
> > > > On Mon, Mar 4, 2019 at 9:13 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Sun, Mar 03, 2019 at 11:05:24PM +0530, Jagan Teki wrote:
> > > > > > TCON DRQ for non-burst DSI mode can computed based on horizontal
> > > > > > front porch value, but the current driver trying to include sync
> > > > > > timings along with front porch resulting wrong drq.
> > > > > >
> > > > > > This patch is trying to update the drq by subtracting hsync_start
> > > > > > with hdisplay, which is horizontal front porch.
> > > > > >
> > > > > > Current code:
> > > > > >
> > > > > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync
> > > > > >
> > > > > > With this patch:
> > > > > >
> > > > > > mode->hsync_start - mode->hdisplay => horizontal front porch
> > > > > >
> > > > > > BSP code form BPI-M64-bsp is computing TCON DRQ set bits
> > > > > > for non-burts as (from linux-sunxi/
> > > > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > > > > >
> > > > > > => panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
> > > > > > => (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
> > > > > ^ + sync length +
> > > > > >- panel->lcd_x - panel->hbp
> > > > > > => timmings->hor_front_porch
> > > > >^ + sync
> > > > > > => mode->hsync_start - mode->hdisplay
> > > > >
> > > > > s/hsync_start/hsync_end/
> > > >
> > > > No, it should be front porch so it is hsync_start. This change is
> > > > trying to update DRQ set to use front porch and above evaluation from
> > > > BSP, result the same front front porch
> > > >
> > > > Current driver has hsync_end - hdisplay which is not front porch
> > > > timing (it is adding extra sync timing).
> > >
> > > It would be if you considered that the back porch actually was the
> > > back porch plus the sync length. I have found no such evidence, quite
> > > the opposite actually, everything seems to point at the fact that
> > > unlike the TCON, the DSI block uses the back porch as only the back
> > > porch.
> >
> > Sorry, I'm not clear about back porch here.
> >
> > The current code has mode->hsync_end - mode->hdisplay which is Front
> > porch + sync time do you think it's not?
>
> It is.
>
> > DRQ set time is pure front porch value (according BSP) as I didn't
> > see any information about DRQ set bits in manual or anywhere.
>
> This is what I'm telling you. If you consider the back porch as only
> the back porch, then the result of that BSP calculation you mentionned
> earlier is the front porch and the sync length.
>
> You imply that the back porch should actually be treated as the back
> porch and the sync length in your calculation. What makes you say so?
I'm consider the computations accordingly to drm_modes.h and which
matches similar like BSP code.
mode->hsync_end - mode->hdisplay = front porch + sync
but the actual computation is
mode->hsync_start - mode->hdisplay => front porch
Which is similar to what BSP is using.
=> panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
=> (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
- panel->lcd_x - panel->hbp
=> timmings->hor_front_porch
=> mode->hsync_start - mode->hdisplay
>
> > fyi: atleast if you didn't trust me, here is existing applied patch
> > for about equations.
> > https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c?id=2cfdc24d2f8d9b14704567c065beb2a118a578fa
>
> I'm aware of that patch, but I have no idea why do you bring it up in
> that discussion.
I'm trying to give valid computation which we wrongly mentioned
before. just a reference.
>
> > So, this patch fixed to remove sync time by updating hsync_start -
> > hdisplay which is pure front porch. and it's clear that pane is not
> > working without this.
>
> This is the same discussion over and over again: which panel, which
> datasheet, not working how?
Like I said before. This bananapi,s070wv20-ct16 DSI bridge and we
don't have exact datasheet other than all the information that I sent
in previous mail. Chen-Yu has mentioned all these references before[1]
>
> > > > I believe this is something similar like fixed patches for VBP, HBLK
> > > > timings.
> > > >
> > > > > Did you encounter any panel where this was fixing something? If so,
> > > > > which one, and what is the matching timings and / or datasheet?
> > > >
> > > > W/O this change Bananapi s070wv20 panel has issue on striped lines on
> > > > the panel[1] and timings are
> > > >
> > > > static const struct drm_display_mode s070wv20_default_mode = {
> > > > .clock = 3,
> > > > .vrefresh = 60,
> > > >
> > > > .hdisplay = 800,
> > > > .hsync_sta
Re: [PATCH] drm/stm: fix CONFIG_FB dependency
Le lun. 11 mars 2019 à 15:24, Arnd Bergmann a écrit : > > On Fri, Mar 8, 2019 at 4:50 PM Yannick FERTRE wrote: > > > > Reviewed-by: Yannick Fertré > > Thanks, > > > Arnd, > > could you merge the patch? > > I think that Benjamin could also merge it. > > I think this should go through the drm tree, so someone with > access to that should merge it, not me. Applied on drm-misc-next, Thanks, Benjamin > > Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
