Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
Hi, > buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object > obj->pages-sgl > before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel > console path. That should be the right place. > Once display manger is kicked off for example (sudo systemctl start > lightdm.service) and > resource id 3 gets created from user space down, it still gives a blank black > screen. Hmm. I'd suspect there is simply a code path missing. Can you send the patch you have? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: add timeline support in amdgpu CS
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 111 +++--
include/uapi/drm/amdgpu_drm.h | 9 ++
3 files changed, 100 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 447c4c7a36d6..6e4a3db56833 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -975,6 +975,11 @@ struct amdgpu_cs_chunk {
void*kdata;
};
+struct amdgpu_cs_syncobj_post_dep {
+ struct drm_syncobj *post_dep_syncobj;
+ u64 point;
+};
+
struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -1003,9 +1008,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
-
+ struct amdgpu_cs_syncobj_post_dep *post_dep_syncobjs;
unsigned num_post_dep_syncobjs;
- struct drm_syncobj **post_dep_syncobjs;
};
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 d9d2ede96490..aa829c6ef08e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -204,6 +204,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_DEPENDENCIES:
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
default:
@@ -783,7 +785,7 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser
*parser, int error,
>validated);
for (i = 0; i < parser->num_post_dep_syncobjs; i++)
- drm_syncobj_put(parser->post_dep_syncobjs[i]);
+ drm_syncobj_put(parser->post_dep_syncobjs[i].post_dep_syncobj);
kfree(parser->post_dep_syncobjs);
dma_fence_put(parser->fence);
@@ -1098,11 +1100,11 @@ 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)
{
int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, );
+ r = drm_syncobj_find_fence(p->filp, handle, point, );
if (r)
return r;
@@ -1113,48 +1115,90 @@ 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 amdgpu_cs_chunk *chunk,
+ bool timeline)
{
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);
+ if (!timeline) {
+ struct drm_amdgpu_cs_chunk_sem *deps;
- for (i = 0; i < num_deps; ++i) {
- r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ 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);
if (r)
return r;
+ }
+ } else {
+ struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+
+ 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_syncobj_lookup_and_add_to_sync(p,
syncobj_deps[i].handle,
+
syncobj_deps[i].point);
+ if (r)
+ return r;
+ }
}
+
return 0;
}
static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
-struct amdgpu_cs_chunk *chunk)
+struct amdgpu_cs_chunk *chunk,
+bool timeline)
{
[PATCH 3/4] drm: add timeline syncobj payload query ioctl
user mode can query timeline payload.
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 | 53 ++
include/uapi/drm/drm.h | 11 +++
4 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 566d44e3c782..9c4826411a3c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -189,6 +189,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 c0891614f516..c3c0617e6372 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -675,6 +675,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 311ea7ba6f57..51aec09cb18a 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1305,3 +1305,56 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+
+static void drm_syncobj_timeline_query_payload(struct drm_syncobj *syncobj,
+ uint64_t *point)
+{
+ if (syncobj->type != DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("Normal syncobj cann't be queried!");
+ *point = 0;
+ return;
+ }
+ *point = syncobj->signal_point;
+}
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_query *args = data;
+ struct drm_syncobj **syncobjs;
+ uint64_t *points;
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+ if (ret < 0)
+ return ret;
+
+
+ points = kmalloc_array(args->count_handles, sizeof(*points),
+ GFP_KERNEL);
+ if (points == NULL) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0; i < args->count_handles; i++) {
+ drm_syncobj_timeline_query_payload(syncobjs[i], [i]);
+ copy_to_user(u64_to_user_ptr(args->points), points,
+sizeof(uint64_t) * args->count_handles);
+ }
+
+ kfree(points);
+out:
+ 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 501e86d81f47..188b63f1975b 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -767,6 +767,15 @@ struct drm_syncobj_array {
__u32 pad;
};
+struct drm_syncobj_timeline_query {
+ __u64 handles;
+ /* points are timeline syncobjs payloads returned by query ioctl */
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -924,6 +933,8 @@ extern "C" {
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_query)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
[PATCH 1/4] [RFC]drm: add syncobj timeline support v6
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
v1:
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point, and
this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb
v6: (Christian)
1. merge syncobj_timeline to syncobj structure
2. simplify some check sentences.
3. some misc change.
4. fix CTS failed issue
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 307 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
include/drm/drm_syncobj.h | 65 ++---
include/uapi/drm/drm.h | 1 +
4 files changed, 299 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..987b5a120b65 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_INDIVIDUAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -117,6 +125,9 @@ static void drm_syncobj_add_callback_locked(struct
drm_syncobj *syncobj,
list_add_tail(>node, >cb_list);
}
+static int drm_syncobj_search_fence(struct drm_syncobj *syncobj, u64 point,
+ u64 flags, struct dma_fence **fence);
+
static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
struct dma_fence **fence,
struct drm_syncobj_cb *cb,
@@ -124,8 +135,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
- if (*fence)
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (!ret)
return 1;
spin_lock(>lock);
@@ -133,10 +144,12 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
[PATCH 2/4] drm: add support of syncobj timeline point wait v2
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
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 | 99 +-
include/uapi/drm/drm.h | 14 +
4 files changed, 103 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 0c4eb4a9ab31..566d44e3c782 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -183,6 +183,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 6b4a633b4240..c0891614f516 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -669,6 +669,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 987b5a120b65..311ea7ba6f57 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -129,13 +129,14 @@ static int drm_syncobj_search_fence(struct drm_syncobj
*syncobj, u64 point,
u64 flags, struct dma_fence **fence);
static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
+u64 point,
struct dma_fence **fence,
struct drm_syncobj_cb *cb,
drm_syncobj_func_t func)
{
int ret;
- ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ ret = drm_syncobj_search_fence(syncobj, point, 0, fence);
if (!ret)
return 1;
@@ -146,7 +147,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
*/
if (fence && !list_empty(>signal_pt_list)) {
spin_unlock(>lock);
- drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ drm_syncobj_search_fence(syncobj, point, 0, fence);
if (*fence)
ret = 1;
spin_lock(>lock);
@@ -355,7 +356,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
spin_lock(>lock);
list_for_each_entry_safe(cur, tmp, >cb_list, node) {
list_del_init(>node);
+ spin_unlock(>lock);
cur->func(syncobj, cur);
+ spin_lock(>lock);
}
spin_unlock(>lock);
}
@@ -866,6 +869,7 @@ struct syncobj_wait_entry {
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
struct drm_syncobj_cb syncobj_cb;
+ u64point;
};
static void syncobj_wait_fence_func(struct dma_fence *fence,
@@ -883,12 +887,13 @@ static void syncobj_wait_syncobj_func(struct drm_syncobj
*syncobj,
struct syncobj_wait_entry *wait =
container_of(cb, struct syncobj_wait_entry, syncobj_cb);
- drm_syncobj_search_fence(syncobj, 0, 0, >fence);
+ drm_syncobj_search_fence(syncobj, wait->point, 0, >fence);
wake_up_process(wait->task);
}
static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj
**syncobjs,
+ void __user *user_points,
uint32_t count,
uint32_t flags,
signed long timeout,
@@ -896,13 +901,27 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
+ uint64_t *points;
signed long ret;
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
On 2018年09月18日 16:32, Christian König wrote:
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i]->type == DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("timeline syncobj cannot reset!\n");
Why not? I mean that should still work or do I miss anything?
timeline semaphore spec doesn't require reset interface, it says the
timeline value only can be changed by signal operations.
Yeah, but we don't care about the timeline spec in the kernel.
Question is rather if that still makes sense to support that and as
far as I can see it should be trivial to reinitialize the object.
Hi Daniel Rakos,
Could you give a comment on this question? Is it necessary to support
timeline reset interface? I only see the timeline value can be changed
by signal operations in Spec.
Thanks,
David Zhou
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/scheduler: add a current job field to scheduler
Hi Christian,
Yes you are correct. My bad.
Do you have any comments on the second patch? I will drop this patch and
rebase the second one.
Regards,
Nayan
On Wed, Sep 19, 2018, 2:09 AM Koenig, Christian
wrote:
> Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
> > Which points to the job running on the hardware. This is
> > useful when we need to access the currently executing job
> > from the scheduler.
>
> That should be identical to
> list_first_entry_or_null(>ring_mirror_list), doesn't it?
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Nayan Deshmukh
> > ---list_first_entry_or_null(>ring_mirror_list
> >
> > drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
> > include/drm/gpu_scheduler.h| 2 ++
> > 2 files changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> > index 9ca741f3a0bc..0e6ccc8243db 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -189,6 +189,7 @@ static void drm_sched_job_finish(struct work_struct
> *work)
> > struct drm_sched_job *s_job = container_of(work, struct
> drm_sched_job,
> > finish_work);
> > struct drm_gpu_scheduler *sched = s_job->sched;
> > + struct drm_sched_job *next;
> >
> > /*
> >* Canceling the timeout without removing our job from the ring
> mirror
> > @@ -201,10 +202,10 @@ static void drm_sched_job_finish(struct
> work_struct *work)
> >
> > spin_lock(>job_list_lock);
> > /* queue TDR for next job */
> > + next = list_next_entry(s_job, node);
> > + sched->curr_job = next;
> > if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> > !list_is_last(_job->node, >ring_mirror_list)) {
> > - struct drm_sched_job *next = list_next_entry(s_job, node);
> > -
> > if (!dma_fence_is_signaled(>s_fence->finished))
> > schedule_delayed_work(>work_tdr,
> sched->timeout);
> > }
> > @@ -233,10 +234,12 @@ static void drm_sched_job_begin(struct
> drm_sched_job *s_job)
> >
> > spin_lock(>job_list_lock);
> > list_add_tail(_job->node, >ring_mirror_list);
> > - if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> > - list_first_entry_or_null(>ring_mirror_list,
> > - struct drm_sched_job, node) == s_job)
> > - schedule_delayed_work(_job->work_tdr, sched->timeout);
> > + if (list_first_entry_or_null(>ring_mirror_list,
> > + struct drm_sched_job, node) == s_job) {
> > + if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
> > + schedule_delayed_work(_job->work_tdr,
> sched->timeout);
> > + sched->curr_job = s_job;
> > + }
> > spin_unlock(>job_list_lock);
> > }
> >
> > @@ -316,6 +319,8 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler
> *sched)
> >struct drm_sched_job, node);
> > if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
> > schedule_delayed_work(_job->work_tdr, sched->timeout);
> > + if (s_job)
> > + sched->curr_job = s_job;
> >
> > list_for_each_entry_safe(s_job, tmp, >ring_mirror_list,
> node) {
> > struct drm_sched_fence *s_fence = s_job->s_fence;
> > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > index daec50f887b3..07e776b1ca42 100644
> > --- a/include/drm/gpu_scheduler.h
> > +++ b/include/drm/gpu_scheduler.h
> > @@ -252,6 +252,7 @@ struct drm_sched_backend_ops {
> >* @timeout: the time after which a job is removed from the scheduler.
> >* @name: name of the ring for which this scheduler is being used.
> >* @sched_rq: priority wise array of run queues.
> > + * @curr_job: points to the job currently running on the hardware
> >* @wake_up_worker: the wait queue on which the scheduler sleeps until
> a job
> >* is ready to be scheduled.
> >* @job_scheduled: once @drm_sched_entity_do_release is called the
> scheduler
> > @@ -274,6 +275,7 @@ struct drm_gpu_scheduler {
> > longtimeout;
> > const char *name;
> > struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_MAX];
> > + struct drm_sched_job*curr_job;
> > wait_queue_head_t wake_up_worker;
> > wait_queue_head_t job_scheduled;
> > atomic_thw_rq_count;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/i915: Fix intel_dp_mst_best_encoder()
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port. Additionally, make intel_dp_mst_atomic_check() simply
rely on drm_dp_mst_connector_atomic_check() to prevent new modesets on
no-longer-present MSTB ports.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a366f32b048a..2b798d4592f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -106,14 +106,21 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
}
static int intel_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+struct drm_connector_state *new_conn_state)
{
struct drm_atomic_state *state = new_conn_state->state;
struct drm_connector_state *old_conn_state;
struct drm_crtc *old_crtc;
struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr =
+ _intel_connector(connector)->mst_port->mst_mgr;
int slots, ret = 0;
+ ret = drm_dp_mst_connector_atomic_check(connector, new_conn_state,
+ mgr);
+ if (ret)
+ return ret;
+
old_conn_state = drm_atomic_get_old_connector_state(state, connector);
old_crtc = old_conn_state->crtc;
if (!old_crtc)
@@ -122,12 +129,6 @@ static int intel_dp_mst_atomic_check(struct drm_connector
*connector,
crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
- struct drm_dp_mst_topology_mgr *mgr;
- struct drm_encoder *old_encoder;
-
- old_encoder = old_conn_state->best_encoder;
- mgr = _to_mst(old_encoder)->primary->dp.mst_mgr;
-
ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
if (ret)
DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n",
slots, ret);
@@ -407,8 +408,6 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (intel_connector->mst_port_gone)
- return NULL;
return _dp->mst_encoders[crtc->pipe]->base.base;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_encoder() so that it can always return the correct
encoder for an MST port to prevent legacy DPMS prop changes from
failing. This should be safe, so instead keep intel_connector->mst_port
always set and instead add intel_connector->mst_port_gone in order to
signify whether or not the connector has disappeared from the system.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++---
drivers/gpu/drm/i915/intel_drv.h| 1 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4ecd65375603..fcb9b87b9339 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -311,9 +311,8 @@ static int intel_dp_mst_get_ddc_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- if (!intel_dp) {
+ if (intel_connector->mst_port_gone)
return intel_connector_update_modes(connector, NULL);
- }
edid = drm_dp_mst_get_edid(connector, _dp->mst_mgr,
intel_connector->port);
ret = intel_connector_update_modes(connector, edid);
@@ -328,9 +327,10 @@ intel_dp_mst_detect(struct drm_connector *connector, bool
force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
intel_connector->port);
+ return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
+ intel_connector->port);
}
static void
@@ -370,7 +370,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
int bpp = 24; /* MST uses fixed bpp */
int max_rate, mode_rate, max_lanes, max_link_clock;
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return MODE_ERROR;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
@@ -402,7 +402,7 @@ static struct drm_encoder
*intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (!intel_dp)
+ if (intel_connector->mst_port_gone)
return NULL;
return _dp->mst_encoders[crtc->pipe]->base.base;
}
@@ -514,7 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
connector);
/* prevent race with the check in ->detect */
drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
- intel_connector->mst_port = NULL;
+ intel_connector->mst_port_gone = true;
drm_modeset_unlock(>dev->mode_config.connection_mutex);
drm_connector_put(connector);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fc61e96754f..87ce772ae7f8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -409,6 +409,7 @@ struct intel_connector {
void *port; /* store this opaque as its illegal to dereference it */
struct intel_dp *mst_port;
+ bool mst_port_gone;
/* Work struct to schedule a uevent on link train failure */
struct work_struct modeset_retry_work;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()
Hook this into amdgpu's atomic check for their connectors so they never
get modesets on no-longer-present MST connectors. We'll also expand on
this later once we add DP MST fallback retraining support.
As well, turns out that the only atomic DRM driver without the
->best_encoder() bug is amdgpu. Congrats AMD!
Signed-off-by: Lyude Paul
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9a300732ba37..d011a39f17b2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -294,10 +294,22 @@ static struct drm_encoder *dm_mst_best_encoder(struct
drm_connector *connector)
return _dm_connector->mst_encoder->base;
}
+static int
+amdgpu_dm_mst_connector_atomic_check(struct drm_connector *connector,
+struct drm_connector_state *new_cstate)
+{
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
+
+ return drm_dp_mst_connector_atomic_check(connector, new_cstate,
+>mst_mgr);
+}
+
static const struct drm_connector_helper_funcs
dm_dp_mst_connector_helper_funcs = {
.get_modes = dm_dp_mst_get_modes,
.mode_valid = amdgpu_dm_connector_mode_valid,
.best_encoder = dm_mst_best_encoder,
+ .atomic_check = amdgpu_dm_mst_connector_atomic_check,
};
static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/i915: Skip vcpi allocation for MSTB ports that are gone
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to do in intel_dp_mst_compute_config() will fail with -EINVAL.
Since the only commits we want to allow on no-longer-present MST ports
are ones that shut off display hardware, we already know that no VCPI
allocations are needed. So, hardcode the VCPI slot count to 0 when
intel_dp_mst_compute_config() is called on an MST port that's gone.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index fcb9b87b9339..a366f32b048a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
@@ -76,11 +76,16 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
- slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
- connector->port, mst_pbn);
- if (slots < 0) {
- DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
- return false;
+ if (!connector->mst_port_gone) {
+ slots = drm_dp_atomic_find_vcpi_slots(state,
+ _dp->mst_mgr,
+ connector->port,
+ mst_pbn);
+ if (slots < 0) {
+ DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+ return false;
+ }
}
intel_link_compute_m_n(bpp, lane_count,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic commit to fail.
However, this is wrong in a rather subtle way. If ->best_encoder()
returns NULL, this makes ALL modesets involving the connector fail. This
includes modesets from userspace that would shut off the CRTCs being
used by the connector. Since this results in blocking any changes to a
connector's DPMS prop, it has the sideaffect of preventing legacy
modesetting users from ever disabling a CRTC that was previously enabled
for use in an MST topology. An example of this, where X tries to
change the DPMS property of an MST connector that was just detached from
the system:
[ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6]
[ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6] status updated from connected to disconnected
[ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:82:DP-6] disconnected
[ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
[ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
...
[ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1,
DRM_IOCTL_MODE_SETPROPERTY
[ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state
7155ba49
[ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
[ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
[ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0]
97a6396e state to 7155ba49
[ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all
current connectors for [CRTC:41:head-0] to 7155ba49
[ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
[ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
[ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added
[CONNECTOR:82:DP-6] 87427144 state to 7155ba49
[ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49
[ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]]
[CRTC:41:head-0] active changed
[ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating
routing for [CONNECTOR:82:DP-6]
[ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No
suitable encoder found for [CONNECTOR:82:DP-6]
[ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for
7155ba49 failed: -22
[ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state
7155ba49
[ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
[ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
[ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
[ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
[ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state
7155ba49
[ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
[ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
While this doesn't usually result in any errors that would be obvious to
the user, it does result in us leaving display resources on. This in
turn leads to unwanted sideaffects like inactive GPUs being left on
(usually from the resulting leaked runtime PM ref).
So, provide an easier way of doing this that doesn't require breaking
->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
function that DRM drivers can call in order to have CRTC enabling
commits fail automatically if the MST port driving the connector no
longer exists. We'll also be able to expand upon this later as well once
we add MST fallback retraining support.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..0162d4bf2549 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs
mst_state_funcs = {
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+static bool
+drm_dp_mst_connector_still_exists(struct drm_connector *connector,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_port *port;
+ bool exists = false;
+
+ mstb = drm_dp_get_validated_mstb_ref(mgr, mstb);
+ if
[PATCH 0/6] Fix legacy DPMS changes with MST
There's two major things this patchset does: - Add drm_dp_mst_connector_atomic_check() so drivers don't need to use ->best_encoder() to prevent modesets on zombie MST connectors. We'll use this later for implementing MST fallback retraining as well. - Fix DPMS on->off changes failing with legacy modesetting users after an MST connector's topology has disappeared, which resulted in CRTCs being left on when they shouldn't have been Lyude Paul (6): drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check() drm/nouveau: Unbreak nv50_mstc->best_encoder() drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead drm/i915: Skip vcpi allocation for MSTB ports that are gone drm/i915: Fix intel_dp_mst_best_encoder() drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check() .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 12 +++ drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 46 ++- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 +++--- include/drm/drm_dp_mst_helper.h | 3 + 6 files changed, 132 insertions(+), 31 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTCs on MST connectors after the connector's respective
topology has disappeared.
So, fix this by instead using the new
drm_dp_mst_connector_atomic_check() helper instead while always
returning a valid encoder from ->best_encoder().
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 9da0bdfe1e1c..8d6f6ee9bc75 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -881,22 +881,16 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
{
struct nv50_head *head = nv50_head(connector_state->crtc);
struct nv50_mstc *mstc = nv50_mstc(connector);
- if (mstc->port) {
- struct nv50_mstm *mstm = mstc->mstm;
- return >msto[head->base.index]->encoder;
- }
- return NULL;
+
+ return >mstm->msto[head->base.index]->encoder;
}
static struct drm_encoder *
nv50_mstc_best_encoder(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
- if (mstc->port) {
- struct nv50_mstm *mstm = mstc->mstm;
- return >msto[0]->encoder;
- }
- return NULL;
+
+ return >mstm->msto[0]->encoder;
}
static enum drm_mode_status
@@ -926,10 +920,21 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *state)
+{
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+
+ return drm_dp_mst_connector_atomic_check(connector, state,
+>mstm->mgr);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
+ .atomic_check = nv50_mstc_atomic_check,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107693] [wine] Wolfenstein: The Old Blood - can't find GL_EXT_framebuffer_object
https://bugs.freedesktop.org/show_bug.cgi?id=107693 --- Comment #12 from gloriouseggr...@gmail.com --- We've removed the broken opengl patchset in wine-staging. Seems the problems it resolved originally have all been resolved in wine already. Should be effective next release. it was also affecting DOOM 2016. https://github.com/wine-staging/wine-staging/commits/master commit: bd3794c11e682e8489959ff79405396f742ee7c4 can confirm after your patches wolfenstein TOB works perfectly. thank you! -- 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 17/20] drm/tve200: Use drm_fbdev_generic_setup()
On Sat, Sep 8, 2018 at 6:53 AM Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Cc: Linus Walleij > Signed-off-by: Noralf Trønnes Acked-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > Thanks Imre for your review comments. Please find the comments below:
> > > >
> > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > display power domain for Power well 2.
> > > > > >
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Imre Deak
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > POWER_DOMAIN_MODESET,
> > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > POWER_DOMAIN_INIT,
> > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > >
> > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > functionality which could be on separate power wells in the future.
> > > > >
> > > >
> > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > > > will use this VDSC power well.
> > > > I will change this in the next revision.
> > >
> > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > moving to the pipe later?
> >
> > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > for eDP/DSI VDSC on Pipe A.
>
> And what happens when I want to use pipe B instead?
DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
Can we have a situation where eDP uses Pipe B? Because in case of VDSC
in case of eDP, it will always use the VDSC on transcoder eDP which will
require this power well.
Manasi
>
> > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > will use this power well. But may be we should add a comment that
> > this is only for eDP/DSI on Pipe A since ICL does not support
> > VDSC on DP on Pipe A
> >
> > What do you think?
> >
> > Manasi
> >
> > >
> > > If we call it PIPE_A then it's going to a bit confusing when we
> > > use it with pipe B or C. Needs at least clear comments in the code
> > > why we're doing something that looks like nonsense of the first
> > > glance.
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
> ___
> 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 v8 1/2] drm: Add connector property to limit max bpc
+ Harry, Leo
This would definitely be useful. We ran into a lot of issues when we
enabled >8 bpc support.
On Tue, Sep 18, 2018 at 2:10 PM Radhakrishna Sripada
wrote:
>
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
> V7: Fix checkpatch warnings
> V8: Simplify the connector check code(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 5 +
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 33 +
> include/drm/drm_connector.h | 20
> 5 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2870ae205237..dc76e89c04af 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = >display_info;
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + state->max_bpc = info->bpc ?: 8;
> + if (connector->max_bpc_property)
> + state->max_bpc = min(state->max_bpc,
> state->max_requested_bpc);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
>fence_ptr);
> + } else if (property == connector->max_bpc_property) {
> + state->max_requested_bpc = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == config->writeback_out_fence_ptr_property) {
> *val = 0;
> + } else if (property == connector->max_bpc_property) {
> + *val = state->max_requested_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..65e22c1b37a5 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
>
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > Thanks Imre for your review comments. Please find the comments below:
> > >
> > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > On Icelake, a separate power well PG2 is created for
> > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > display power domain for Power well 2.
> > > > >
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Imre Deak
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > POWER_DOMAIN_MODESET,
> > > > > POWER_DOMAIN_GT_IRQ,
> > > > > POWER_DOMAIN_INIT,
> > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > >
> > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > functionality which could be on separate power wells in the future.
> > > >
> > >
> > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > > will use this VDSC power well.
> > > I will change this in the next revision.
> >
> > Isn't the VDSC in the transcoder for now though? And I guess it's
> > moving to the pipe later?
>
> VDSC engine is attached to the eDP/DSI transcoders and this gets used
> for eDP/DSI VDSC on Pipe A.
And what happens when I want to use pipe B instead?
> So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> will use this power well. But may be we should add a comment that
> this is only for eDP/DSI on Pipe A since ICL does not support
> VDSC on DP on Pipe A
>
> What do you think?
>
> Manasi
>
> >
> > If we call it PIPE_A then it's going to a bit confusing when we
> > use it with pipe B or C. Needs at least clear comments in the code
> > why we're doing something that looks like nonsense of the first
> > glance.
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > Thanks Imre for your review comments. Please find the comments below:
> >
> > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > On Icelake, a separate power well PG2 is created for
> > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > display power domain for Power well 2.
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Imre Deak
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > POWER_DOMAIN_MODESET,
> > > > POWER_DOMAIN_GT_IRQ,
> > > > POWER_DOMAIN_INIT,
> > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > >
> > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > functionality which could be on separate power wells in the future.
> > >
> >
> > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > will use this VDSC power well.
> > I will change this in the next revision.
>
> Isn't the VDSC in the transcoder for now though? And I guess it's
> moving to the pipe later?
VDSC engine is attached to the eDP/DSI transcoders and this gets used
for eDP/DSI VDSC on Pipe A.
So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
will use this power well. But may be we should add a comment that
this is only for eDP/DSI on Pipe A since ICL does not support
VDSC on DP on Pipe A
What do you think?
Manasi
>
> If we call it PIPE_A then it's going to a bit confusing when we
> use it with pipe B or C. Needs at least clear comments in the code
> why we're doing something that looks like nonsense of the first
> glance.
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> Thanks Imre for your review comments. Please find the comments below:
>
> On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > On Icelake, a separate power well PG2 is created for
> > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > display power domain for Power well 2.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Imre Deak
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > b/drivers/gpu/drm/i915/intel_display.h
> > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > POWER_DOMAIN_MODESET,
> > > POWER_DOMAIN_GT_IRQ,
> > > POWER_DOMAIN_INIT,
> > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> >
> > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > functionality which could be on separate power wells in the future.
> >
>
> Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> will use this VDSC power well.
> I will change this in the next revision.
Isn't the VDSC in the transcoder for now though? And I guess it's
moving to the pipe later?
If we call it PIPE_A then it's going to a bit confusing when we
use it with pipe B or C. Needs at least clear comments in the code
why we're doing something that looks like nonsense of the first
glance.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
Thanks Imre for your review comments. Please find the comments below:
On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > On Icelake, a separate power well PG2 is created for
> > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > display power domain for Power well 2.
> >
> > Cc: Rodrigo Vivi
> > Cc: Imre Deak
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/intel_display.h| 1 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > 2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 3fe52788b4cf..bef71d27cdfe 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > POWER_DOMAIN_INIT,
> > + POWER_DOMAIN_VDSC_EDP_MIPI,
>
> This is better named VDSC_PIPE_A. The other pipes have also VDSC
> functionality which could be on separate power wells in the future.
>
Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
will use this VDSC power well.
I will change this in the next revision.
> >
> > POWER_DOMAIN_NUM,
> > };
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 480dadb1047b..146e2d6cf954 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -146,6 +146,8 @@ intel_display_power_domain_str(enum
> > intel_display_power_domain domain)
> > return "MODESET";
> > case POWER_DOMAIN_GT_IRQ:
> > return "GT_IRQ";
> > + case POWER_DOMAIN_VDSC_EDP_MIPI:
> > + return "VDSC_EDP_MIPI";
> > default:
> > MISSING_CASE(domain);
> > return "?";
> > @@ -1966,18 +1968,16 @@ void intel_display_power_put(struct
> > drm_i915_private *dev_priv,
> > BIT_ULL(POWER_DOMAIN_AUDIO) | \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > /*
> > -* - transcoder WD
> > -* - KVMR (HW control)
> > +* - eDP/MIPI DSI VDSC
>
> We're not changing anything in the PW3 domains list, so why changing
> the above?
These comments are below the PW3 domains define and before the PW2 domains
define.
So I thought they were for PW2 domains define. Is that not the case?
If its for PW3 then I can keep them as is and if its for PW2 then we should have
eDP/DSI VDSC , KVMR since KVMR will enable PW2 and PW3. But why have Transcoder
WD comment
for PW2?
>
> > */
> > #define ICL_PW_2_POWER_DOMAINS ( \
> > - ICL_PW_3_POWER_DOMAINS |\
> > - BIT_ULL(POWER_DOMAIN_INIT))
>
> The above is bogus, both the PW3 domains and the INIT domain should
> stay included in the list of PW2 domains.
Okay I will add the PW2 and INIT domains back
>
> > + BIT_ULL(POWER_DOMAIN_VDSC_EDP_MIPI))
> > /*
> > -* - eDP/DSI VDSC
> > +* - transcoder WD
>
> Why adding here the transcoder WD?
This comment is above PW3 domains so PW3 domain has Transcoder WD as per Bspec
and no eDP/DSI VDSC on PW3, so removed that.
Am I misreading something here in terms of comments?
So the basic question is the comments are for the PW domains defined above the
comment or
for the PW domain defines below the comment?
Manasi
>
> > * - KVMR (HW control)
> > */
> > #define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > - ICL_PW_2_POWER_DOMAINS |\
> > + ICL_PW_3_POWER_DOMAINS |\
>
> The PW2 domain list should stay included in the DC_OFF domain list (and
> so no need to add the PW3 domain list either).
>
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) | \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm: Add connector property to limit max bpc
On Tue, Sep 18, 2018 at 11:11:14AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
> V7: Fix checkpatch warnings
> V8: Simplify the connector check code(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 5 +
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 33 +
> include/drm/drm_connector.h | 20
> 5 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2870ae205237..dc76e89c04af 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = >display_info;
Can be const.
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + state->max_bpc = info->bpc ?: 8;
> + if (connector->max_bpc_property)
> + state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
Hopefully this logic is generic enough to work for most drivers.
I haven't actually checked what anyone else does with info->bpc.
Reviewed-by: Ville Syrjälä
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
> fence_ptr);
> + } else if (property == connector->max_bpc_property) {
> + state->max_requested_bpc = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == config->writeback_out_fence_ptr_property) {
> *val = 0;
> + } else if (property == connector->max_bpc_property) {
> + *val = state->max_requested_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..65e22c1b37a5 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
>
Re: [PATCH v8 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
On Tue, Sep 18, 2018 at 11:11:15AM -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the connector and fix CI failure(Ville)
> V6: Use the core function to attach max_bpc property, remove the redundant
> clamping of pipe bpp based on connector info
> V7: Fix Checkpatch warnings
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Kishore Kadiyala
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_display.c | 49
>
> drivers/gpu/drm/i915/intel_dp.c | 5
> drivers/gpu/drm/i915/intel_hdmi.c| 5
> 3 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eb25037d7b38..75afd53590b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10845,29 +10845,37 @@ static void
> intel_modeset_update_connector_atomic_state(struct drm_device *dev)
> }
>
> static void
> -connected_sink_compute_bpp(struct intel_connector *connector,
> -struct intel_crtc_state *pipe_config)
> +connected_sink_max_bpp(struct drm_connector_state *conn_state,
> +struct intel_crtc_state *pipe_config)
> {
> - const struct drm_display_info *info = >base.display_info;
> - int bpp = pipe_config->pipe_bpp;
> -
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
> - connector->base.base.id,
> - connector->base.name);
> -
> - /* Don't use an invalid EDID bpc value */
> - if (info->bpc != 0 && info->bpc * 3 < bpp) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
> max of %d\n",
> - bpp, info->bpc * 3);
> - pipe_config->pipe_bpp = info->bpc * 3;
> + if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
> + conn_state->max_bpc = pipe_config->pipe_bpp / 3;
> + return;
This back and forth between max_bpc and pipe_bpp is a bit confusing.
I'd probably leave max_bpc alone here and just update pipe_bpp as
needed.
> }
>
> - /* Clamp bpp to 8 on screens without EDID 1.4 */
> - if (info->bpc == 0 && bpp > 24) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
> of 24\n",
> - bpp);
> - pipe_config->pipe_bpp = 24;
> + switch (conn_state->max_bpc) {
This is missing the 6bpc case at least. I suppose the current code
isn't particuraly robust against unexpected values coming via
info->bpc. The switch statement does seem an improvement in that
regard. Though would be nice to compact it a bit using eg. the gcc
case range extension.
> + case 8:
> + case 9:
> + pipe_config->pipe_bpp = 8 * 3;
> + break;
> + case 10:
> + case 11:
> + pipe_config->pipe_bpp = 10 * 3;
> + break;
> + case 12:
> + case 13:
> + case 14:
> + case 15:
With the proposed min() we'd never get bpc > 12 here.
> + pipe_config->pipe_bpp = 12 * 3;
> + break;
> + case 16:
> + pipe_config->pipe_bpp = 16 * 3;
> + break;
> + default:
> + break;
Maybe just return an error here. I suppose it should never happen unless
there's some bogus displays out there that report < 6 bpc.
> }
> +
> + DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
Would be nice to include all the relevant information in this debug
print: original pipe_bpp, info->bpc*3, max_requested_bpc.
Maybe something like this would work to keep the code easy to read:
{
bpp = min(pipe_bpp, max_bpc*3);
switch (bpp) {
...
}
if (bpp != pipe_bpp) {
DRM_DEBUG_KMS(...);
pipe_bpp = bpp;
}
}
> }
>
> static int
> @@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
> if (connector_state->crtc != >base)
> continue;
>
> - connected_sink_compute_bpp(to_intel_connector(connector),
> -pipe_config);
> + connected_sink_max_bpp(connector_state, pipe_config);
> }
>
> return bpp;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..aefca1d9e87b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_force_audio_property(connector);
>
>
Re: [PATCH v2 1/8] drm/bridge: use bus flags in bridge timings
On 14.09.2018 02:23, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thankk you for the patch.
>
> On Wednesday, 12 September 2018 21:32:15 EEST Stefan Agner wrote:
>> The DRM bus flags conveys additional information on pixel data on
>> the bus. All currently available bus flags might be of interest for
>> a bridge. In the case at hand a dumb VGA bridge needs a specific
>> data enable polarity (DRM_BUS_FLAG_DE_LOW).
>>
>> Replace the sampling_edge field with input_bus_flags and allow all
>> currently documented bus flags.
>>
>> This changes the perspective from sampling side to the driving
>> side for the currently supported flags. We assume that the sampling
>> edge is always the opposite of the driving edge (hence we need to
>> invert the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE flags). This is an
>> assumption we already make for displays. For all we know it is a
>> safe assumption for bridges too.
>
> Please don't, that will get confusing very quickly. Flag names such as
> DRM_BUS_FLAG_PIXDATA_NEGEDGE don't mention sampling or driving. There's only
> a
> small comment next to their definition, which will easily be overlooked. I'd
> rather update the definition to cover both sampling and driving, and document
> the input_bus_flags field to explain that all flags refer to sampling.
>
There is history to that, and I'd really rather prefer to keep that similar
across the kernel. There is already precedence in the kernel, the display
timings (which is a consumer) defines it from the driving perspective too (see
DISPLAY_FLAGS_PIXDATA_POSEDGE).
That is why I introduced the bus flags using the same perspective.
If we _really_ want it from sampling side, we should create new defines which
are explicit about that, e.g.: DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE.
But again, since even the display flags use the driving perspective, I'd rather
prefer to have it that way also for bridges too.
--
Stefan
>> Signed-off-by: Stefan Agner
>> ---
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +++---
>> include/drm/drm_bridge.h | 11 +--
>> 2 files changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 9b706789a341..d5aa0f931ef2
>> 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>> */
>> static const struct drm_bridge_timings default_dac_timings = {
>> /* Timing specifications, datasheet page 7 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> .setup_time_ps = 500,
>> .hold_time_ps = 1500,
>> };
>> @@ -245,7 +245,7 @@ static const struct drm_bridge_timings
>> default_dac_timings = { */
>> static const struct drm_bridge_timings ti_ths8134_dac_timings = {
>> /* From timing diagram, datasheet page 9 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> /* From datasheet, page 12 */
>> .setup_time_ps = 3000,
>> /* I guess this means latched input */
>> @@ -258,7 +258,7 @@ static const struct drm_bridge_timings
>> ti_ths8134_dac_timings = { */
>> static const struct drm_bridge_timings ti_ths8135_dac_timings = {
>> /* From timing diagram, datasheet page 14 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> /* From datasheet, page 16 */
>> .setup_time_ps = 2000,
>> .hold_time_ps = 500,
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index bd850747ce54..45e90f4b46c3 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -244,14 +244,13 @@ struct drm_bridge_funcs {
>> */
>> struct drm_bridge_timings {
>> /**
>> - * @sampling_edge:
>> + * @input_bus_flags:
>> *
>> - * Tells whether the bridge samples the digital input signal
>> - * from the display engine on the positive or negative edge of the
>> - * clock, this should reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE
>> - * bitwise flags from the DRM connector (bit 2 and 3 valid).
>> + * Additional settings this bridge requires for the pixel data on
>> + * the input bus (e.g. pixel signal polarity). See also
>> + * _display_info->bus_flags.
>> */
>> -u32 sampling_edge;
>> +u32 input_bus_flags;
>> /**
>> * @setup_time_ps:
>> *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/2] drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 5 +
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 20
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..dc76e89c04af 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
{
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+ struct drm_display_info *info = >display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ state->max_bpc = info->bpc ?: 8;
+ if (connector->max_bpc_property)
+ state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->max_requested_bpc !=
+ new_connector_state->max_requested_bpc)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return set_out_fence_for_connector(state->state, connector,
fence_ptr);
+ } else if (property == connector->max_bpc_property) {
+ state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == config->writeback_out_fence_ptr_property) {
*val = 0;
+ } else if (property == connector->max_bpc_property) {
+ *val = state->max_requested_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..65e22c1b37a5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_connector_set_link_status_property);
/**
+ * drm_connector_attach_max_bpc_property - attach "max bpc" property
+ * @connector: connector to attach max bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to add support for limiting the bit depth on a connector.
+ *
+ *
[PATCH v8 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_display.c | 49
drivers/gpu/drm/i915/intel_dp.c | 5
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..75afd53590b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = >base.display_info;
- int bpp = pipe_config->pipe_bpp;
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
- /* Don't use an invalid EDID bpc value */
- if (info->bpc != 0 && info->bpc * 3 < bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
max of %d\n",
- bpp, info->bpc * 3);
- pipe_config->pipe_bpp = info->bpc * 3;
+ if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+ conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+ return;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (info->bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ switch (conn_state->max_bpc) {
+ case 8:
+ case 9:
+ pipe_config->pipe_bpp = 8 * 3;
+ break;
+ case 10:
+ case 11:
+ pipe_config->pipe_bpp = 10 * 3;
+ break;
+ case 12:
+ case 13:
+ case 14:
+ case 15:
+ pipe_config->pipe_bpp = 12 * 3;
+ break;
+ case 16:
+ pipe_config->pipe_bpp = 16 * 3;
+ break;
+ default:
+ break;
}
+
+ DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
}
static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != >base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ connected_sink_max_bpp(connector_state, pipe_config);
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+ drm_connector_attach_max_bpc_property(connector, 8, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+
+
Re: [Intel-gfx] [PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> v3: adding comments about the feature requirement about capabilities
>
> Cc: Chris Wilson
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_ioctl.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 60dfbfae6a02..94bd872d56c4 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> struct drm_set_client_cap *req = data;
>
> + /* No render-only settable capabilities for now */
> +
> + /* Below caps that only works with KMS drivers */
That doesn't seem quite English.
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EOPNOTSUPP;
> +
> switch (req->capability) {
> case DRM_CLIENT_CAP_STEREO_3D:
> if (req->value > 1)
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
On 09/12/2018 02:25 AM, Gerd Hoffmann wrote: > Hi, > >> I attempted to fix it in the ttm layer and here is the discussion >> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/ >> >> The ttm maintainer Christian is suggesting to map and set ttm->pages as >> decrypted >> right after ttm->pages are allocated. >> >> Just checking with you guys maybe there is a better way to handle this in >> the virtio gpu layer instead of the common ttm layer. Could you guys shine >> some >> light on this? Thanks. > > I think the tty layer is the right place to fix this. virtio just calls > down to ttm for mappings. I think virtio should just hint to ttm using > a flag in some struct, probably ttm_buffer_object or > ttm_mem_type_manager, that the objects need decrypted mappings. > > cheers, > Gerd > I tested this patch with non SEV guest. It gives a blank black screen if booting with swiotlb=force. dma_sync is missing if dma op uses swiotlb as bounce buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object obj->pages-sgl before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel console path. Once display manger is kicked off for example (sudo systemctl start lightdm.service) and resource id 3 gets created from user space down, it still gives a blank black screen. In addition, I added dma_sync_sg_for_device() before sending VIRTIO_GPU_CMD_RESOURCE_FLUSH and VIRTIO_GPU_CMD_SET_SCANOUT, still blank black screen after display manger is kicked off. Do you know which path I'm still missing as far as VIRTIO_GPU_CMD goes? Thanks - Jiandi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > Acked-by: Darren Hart (VMware) > > > > As for a longer term solution, would it be possible to init fops in such > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > so we don't have to duplicate this boilerplate for every ioctl fops > > structure? > > Bad idea, that... Because several years down the road somebody will add > an ioctl that takes an unsigned int for argument. Without so much as looking > at your magical mystery macro being used to initialize file_operations. Fair, being explicit in the declaration as it is currently may be preferable then. -- Darren Hart VMware Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
v3: adding comments about the feature requirement about capabilities
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 60dfbfae6a02..94bd872d56c4 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_set_client_cap *req = data;
+ /* No render-only settable capabilities for now */
+
+ /* Below caps that only works with KMS drivers */
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EOPNOTSUPP;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
if (req->value > 1)
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] staging: vboxvideo: Move bo_[un]resere calls into vbox_bo_[un]pin
We always need to reserve the bo around a pin / unpin, so move the
reservation there.
This allows removing the vbox_fb_[un]pin helpers.
Note this means that we now no longer hold the bo reserved while
k[un]mapping it in vbox_fb.c this is fine as it is not necessary
to hold it reserved for this.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 2 +-
drivers/staging/vboxvideo/vbox_fb.c | 27 --
drivers/staging/vboxvideo/vbox_mode.c | 54 ---
drivers/staging/vboxvideo/vbox_ttm.c | 32 +---
4 files changed, 42 insertions(+), 73 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 6a4d3b382e79..fffde1713101 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -245,7 +245,7 @@ int vbox_bo_create(struct vbox_private *vbox, int size, int
align,
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr);
+int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
int vbox_bo_unpin(struct vbox_bo *bo);
static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index 0e5550fa7c57..bdc87d02ecc5 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -104,18 +104,11 @@ static int vboxfb_create(struct drm_fb_helper *helper,
bo = gem_to_vbox_bo(gobj);
- ret = vbox_bo_reserve(bo, false);
+ ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, _addr);
- if (ret) {
- vbox_bo_unreserve(bo);
- return ret;
- }
-
ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >kmap);
- vbox_bo_unreserve(bo);
if (ret) {
DRM_ERROR("failed to kmap fbcon\n");
return ret;
@@ -153,6 +146,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_var(info, >helper, sizes->fb_width,
sizes->fb_height);
+ gpu_addr = vbox_bo_gpu_offset(bo);
info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
info->fix.smem_len = vbox->available_vram_size - gpu_addr;
@@ -190,17 +184,12 @@ void vbox_fbdev_fini(struct vbox_private *vbox)
if (afb->obj) {
struct vbox_bo *bo = gem_to_vbox_bo(afb->obj);
- if (!vbox_bo_reserve(bo, false)) {
- if (bo->kmap.virtual)
- ttm_bo_kunmap(>kmap);
- /*
-* QXL does this, but is it really needed before
-* freeing?
-*/
- if (bo->pin_count)
- vbox_bo_unpin(bo);
- vbox_bo_unreserve(bo);
- }
+ if (bo->kmap.virtual)
+ ttm_bo_kunmap(>kmap);
+
+ if (bo->pin_count)
+ vbox_bo_unpin(bo);
+
drm_gem_object_put_unlocked(afb->obj);
afb->obj = NULL;
}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 910ea19931c9..bef99664d030 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -221,40 +221,6 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
return old_single_framebuffer != vbox->single_framebuffer;
}
-static int vbox_fb_pin(struct drm_framebuffer *fb, u32 pl_flag, u64 *addr)
-{
- struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
- int ret;
-
- ret = vbox_bo_reserve(bo, false);
- if (ret)
- return ret;
-
- ret = vbox_bo_pin(bo, pl_flag, addr);
- vbox_bo_unreserve(bo);
- return ret;
-}
-
-static void vbox_fb_unpin(struct drm_framebuffer *fb)
-{
- struct vbox_bo *bo;
- int ret;
-
- if (!fb)
- return;
-
- bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
-
- ret = vbox_bo_reserve(bo, false);
- if (ret) {
- DRM_ERROR("Error %d reserving fb bo, leaving it pinned\n", ret);
- return;
- }
-
- vbox_bo_unpin(bo);
- vbox_bo_unreserve(bo);
-}
-
static void vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_display_mode *mode,
@@ -296,17 +262,22 @@ static int vbox_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode,
int x, int y, struct drm_framebuffer *old_fb)
{
+
[PATCH 10/12] staging: vboxvideo: Fix NULL ptr deref in vbox_set_up_input_mapping()
When vbox_set_up_input_mapping() gets called the first crtc might be
disable and not have a fb at all, triggering a NUL ptr deref at:
vbox->input_mapping_width = CRTC_FB(crtci)->width;
Instead of using the fb from the crtc with id 0, just use the fb from
the first crtc with a fb. This is in the single_framebuffer = true path,
so all crtc-s point to the same fb anyways.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 1a2416a59fe0..910ea19931c9 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -189,17 +189,17 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
}
}
if (single_framebuffer) {
+ vbox->single_framebuffer = true;
list_for_each_entry(crtci, >ddev.mode_config.crtc_list,
head) {
- if (to_vbox_crtc(crtci)->crtc_id != 0)
+ if (!CRTC_FB(crtci))
continue;
- vbox->single_framebuffer = true;
vbox->input_mapping_width = CRTC_FB(crtci)->width;
vbox->input_mapping_height = CRTC_FB(crtci)->height;
- return old_single_framebuffer !=
- vbox->single_framebuffer;
+ break;
}
+ return old_single_framebuffer != vbox->single_framebuffer;
}
/* Otherwise calculate the total span of all screens. */
list_for_each_entry(connectori, >ddev.mode_config.connector_list,
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] staging: vboxvideo: Init fb_info.fix.smem once from fbdev_create
The fbdev compat fb gets pinned into VRAM at creation and then gets pinned
a second time when set as scanout buffer and unpinned when replaced, this
means its pin count never becomes less then 1, so it is always at the same
address and there is no need for the vbox_fbdev_set_base() call.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 1 -
drivers/staging/vboxvideo/vbox_fb.c | 14 +-
drivers/staging/vboxvideo/vbox_mode.c | 3 ---
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 28ffdffe877a..5034c6bd5445 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -201,7 +201,6 @@ int vbox_framebuffer_init(struct vbox_private *vbox,
int vbox_fbdev_init(struct vbox_private *vbox);
void vbox_fbdev_fini(struct vbox_private *vbox);
-void vbox_fbdev_set_base(struct vbox_private *vbox, unsigned long gpu_addr);
struct vbox_bo {
struct ttm_buffer_object bo;
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index 11b6364ed14a..0e5550fa7c57 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -80,6 +80,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
struct drm_gem_object *gobj;
struct vbox_bo *bo;
int size, ret;
+ u64 gpu_addr;
u32 pitch;
mode_cmd.width = sizes->surface_width;
@@ -107,7 +108,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+ ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, _addr);
if (ret) {
vbox_bo_unreserve(bo);
return ret;
@@ -152,6 +153,9 @@ static int vboxfb_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_var(info, >helper, sizes->fb_width,
sizes->fb_height);
+ info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
+ info->fix.smem_len = vbox->available_vram_size - gpu_addr;
+
info->screen_base = (char __iomem *)bo->kmap.virtual;
info->screen_size = size;
@@ -241,11 +245,3 @@ int vbox_fbdev_init(struct vbox_private *vbox)
drm_fb_helper_fini(>helper);
return ret;
}
-
-void vbox_fbdev_set_base(struct vbox_private *vbox, unsigned long gpu_addr)
-{
- struct fb_info *fbdev = vbox->fbdev->helper.fbdev;
-
- fbdev->fix.smem_start = fbdev->apertures->ranges[0].base + gpu_addr;
- fbdev->fix.smem_len = vbox->available_vram_size - gpu_addr;
-}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index f35045ce154b..6d7a89524fbf 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -276,9 +276,6 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
/* Commit: Update hardware to use the new fb */
mutex_lock(>hw_mutex);
- if (>fbdev->afb == to_vbox_framebuffer(new_fb))
- vbox_fbdev_set_base(vbox, gpu_addr);
-
vbox_crtc->fb_offset = gpu_addr;
/* vbox_do_modeset() checks vbox->single_framebuffer so update it now */
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] staging: vboxvideo: Move pin / unpin of fb out of vbox_crtc_set_base_and_mode
Move pin / unpin of fb out of vbox_crtc_set_base_and_mode() so that it can
be used to implement the atomic_update drm_plane_helper_func for the primary
plane.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 5 +++
drivers/staging/vboxvideo/vbox_mode.c | 52 ++-
drivers/staging/vboxvideo/vbox_ttm.c | 5 ---
3 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 5034c6bd5445..6a4d3b382e79 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -220,6 +220,11 @@ static inline struct vbox_bo *vbox_bo(struct
ttm_buffer_object *bo)
#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
+static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
+{
+ return bo->bo.offset;
+}
+
int vbox_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 6d7a89524fbf..1a2416a59fe0 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -255,28 +255,18 @@ static void vbox_fb_unpin(struct drm_framebuffer *fb)
vbox_bo_unreserve(bo);
}
-static int vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
- struct drm_framebuffer *old_fb,
- struct drm_framebuffer *new_fb,
- struct drm_display_mode *mode,
- int x, int y)
+static void vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_display_mode *mode,
+ int x, int y)
{
+ struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
struct vbox_private *vbox = crtc->dev->dev_private;
struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
- u64 gpu_addr;
- int ret;
-
- /* Prepare: pin the new framebuffer bo */
- ret = vbox_fb_pin(new_fb, TTM_PL_FLAG_VRAM, _addr);
- if (ret) {
- DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
- return ret;
- }
- /* Commit: Update hardware to use the new fb */
mutex_lock(>hw_mutex);
- vbox_crtc->fb_offset = gpu_addr;
+ vbox_crtc->fb_offset = vbox_bo_gpu_offset(bo);
/* vbox_do_modeset() checks vbox->single_framebuffer so update it now */
if (mode && vbox_set_up_input_mapping(vbox)) {
@@ -299,11 +289,6 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
vbox->input_mapping_height);
mutex_unlock(>hw_mutex);
-
- /* Cleanup: unpin the old fb */
- vbox_fb_unpin(old_fb);
-
- return 0;
}
static int vbox_crtc_mode_set(struct drm_crtc *crtc,
@@ -311,8 +296,19 @@ static int vbox_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode,
int x, int y, struct drm_framebuffer *old_fb)
{
- return vbox_crtc_set_base_and_mode(crtc, old_fb, CRTC_FB(crtc),
- mode, x, y);
+ int ret;
+
+ ret = vbox_fb_pin(CRTC_FB(crtc), TTM_PL_FLAG_VRAM, NULL);
+ if (ret) {
+ DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
+ return ret;
+ }
+
+ vbox_crtc_set_base_and_mode(crtc, CRTC_FB(crtc), mode, x, y);
+
+ vbox_fb_unpin(old_fb);
+
+ return 0;
}
static int vbox_crtc_page_flip(struct drm_crtc *crtc,
@@ -324,9 +320,15 @@ static int vbox_crtc_page_flip(struct drm_crtc *crtc,
unsigned long flags;
int rc;
- rc = vbox_crtc_set_base_and_mode(crtc, CRTC_FB(crtc), fb, NULL, 0, 0);
- if (rc)
+ rc = vbox_fb_pin(fb, TTM_PL_FLAG_VRAM, NULL);
+ if (rc) {
+ DRM_WARN("Error %d pinning new fb, out of video mem?\n", rc);
return rc;
+ }
+
+ vbox_crtc_set_base_and_mode(crtc, fb, NULL, 0, 0);
+
+ vbox_fb_unpin(CRTC_FB(crtc));
spin_lock_irqsave(>dev->event_lock, flags);
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
index 7b8eac30faca..0e14556dcd6b 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -343,11 +343,6 @@ int vbox_bo_create(struct vbox_private *vbox, int size,
int align,
return ret;
}
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
- return bo->bo.offset;
-}
-
int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
{
struct ttm_operation_ctx ctx = { false, false };
--
2.19.0.rc1
[PATCH 12/12] staging: vboxvideo: Add vbox_bo_k[un]map helper functions
Add vbox_bo_k[un]map helper functions instead of having code directly
poking struct vbox_bo internals.
While touch neighboring code anyways also fix a return -PTR_ERR(info),
which should be return PTR_ERR(info).
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 2 ++
drivers/staging/vboxvideo/vbox_fb.c | 19 +++
drivers/staging/vboxvideo/vbox_ttm.c | 28 +++-
3 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index fffde1713101..6c52cbd9e91e 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -269,6 +269,8 @@ static inline void vbox_bo_unreserve(struct vbox_bo *bo)
void vbox_ttm_placement(struct vbox_bo *bo, int domain);
int vbox_bo_push_sysram(struct vbox_bo *bo);
int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
+void *vbox_bo_kmap(struct vbox_bo *bo);
+void vbox_bo_kunmap(struct vbox_bo *bo);
/* vbox_prime.c */
int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index bdc87d02ecc5..b8b42f9aafae 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -108,15 +108,14 @@ static int vboxfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
- ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >kmap);
- if (ret) {
- DRM_ERROR("failed to kmap fbcon\n");
- return ret;
- }
-
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info))
- return -PTR_ERR(info);
+ return PTR_ERR(info);
+
+ info->screen_size = size;
+ info->screen_base = (char __iomem *)vbox_bo_kmap(bo);
+ if (IS_ERR(info->screen_base))
+ return PTR_ERR(info->screen_base);
info->par = fbdev;
@@ -150,9 +149,6 @@ static int vboxfb_create(struct drm_fb_helper *helper,
info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
info->fix.smem_len = vbox->available_vram_size - gpu_addr;
- info->screen_base = (char __iomem *)bo->kmap.virtual;
- info->screen_size = size;
-
#ifdef CONFIG_DRM_KMS_FB_HELPER
info->fbdefio = _defio;
fb_deferred_io_init(info);
@@ -184,8 +180,7 @@ void vbox_fbdev_fini(struct vbox_private *vbox)
if (afb->obj) {
struct vbox_bo *bo = gem_to_vbox_bo(afb->obj);
- if (bo->kmap.virtual)
- ttm_bo_kunmap(>kmap);
+ vbox_bo_kunmap(bo);
if (bo->pin_count)
vbox_bo_unpin(bo);
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
index bd0a1603764e..5ecfa7629173 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -418,8 +418,10 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
if (bo->pin_count)
return 0;
- if (bo->kmap.virtual)
+ if (bo->kmap.virtual) {
ttm_bo_kunmap(>kmap);
+ bo->kmap.virtual = NULL;
+ }
vbox_ttm_placement(bo, TTM_PL_FLAG_SYSTEM);
@@ -448,3 +450,27 @@ int vbox_mmap(struct file *filp, struct vm_area_struct
*vma)
return ttm_bo_mmap(filp, vma, >ttm.bdev);
}
+
+void *vbox_bo_kmap(struct vbox_bo *bo)
+{
+ int ret;
+
+ if (bo->kmap.virtual)
+ return bo->kmap.virtual;
+
+ ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >kmap);
+ if (ret) {
+ DRM_ERROR("Error kmapping bo: %d\n", ret);
+ return NULL;
+ }
+
+ return bo->kmap.virtual;
+}
+
+void vbox_bo_kunmap(struct vbox_bo *bo)
+{
+ if (bo->kmap.virtual) {
+ ttm_bo_kunmap(>kmap);
+ bo->kmap.virtual = NULL;
+ }
+}
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] staging: vboxvideo: Fold vbox_drm_resume() into vbox_pm_resume()
vbox_pm_resume() is the only caller of vbox_drm_resume(), so squash the
2 functions into 1.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index c4290d4b4a53..c6a53b0ad66c 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -152,22 +152,6 @@ static int vbox_drm_thaw(struct vbox_private *vbox)
return 0;
}
-static int vbox_drm_resume(struct vbox_private *vbox)
-{
- int ret;
-
- if (pci_enable_device(vbox->ddev.pdev))
- return -EIO;
-
- ret = vbox_drm_thaw(vbox);
- if (ret)
- return ret;
-
- drm_kms_helper_poll_enable(>ddev);
-
- return 0;
-}
-
static int vbox_pm_suspend(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
@@ -186,8 +170,18 @@ static int vbox_pm_suspend(struct device *dev)
static int vbox_pm_resume(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
+ int ret;
- return vbox_drm_resume(vbox);
+ if (pci_enable_device(vbox->ddev.pdev))
+ return -EIO;
+
+ ret = vbox_drm_thaw(vbox);
+ if (ret)
+ return ret;
+
+ drm_kms_helper_poll_enable(>ddev);
+
+ return 0;
}
static int vbox_pm_freeze(struct device *dev)
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] staging: vboxvideo: Fold driver_load/unload into probe/remove functions
Fold the driver_load / unload functions into the probe / remove functions
now that we are no longer using the deprecated drm_get_pci_dev() mechanism.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 71 +--
drivers/staging/vboxvideo/vbox_drv.h | 6 ++-
drivers/staging/vboxvideo/vbox_main.c | 67 ++---
3 files changed, 63 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index 69cc508af1bc..410a1f35b746 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -51,48 +51,89 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
+ struct vbox_private *vbox = NULL;
struct drm_device *dev = NULL;
int ret = 0;
+ if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
+ return -ENODEV;
+
dev = drm_dev_alloc(, >dev);
- if (IS_ERR(dev)) {
- ret = PTR_ERR(dev);
- goto err_drv_alloc;
- }
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
ret = pci_enable_device(pdev);
if (ret)
- goto err_pci_enable;
+ goto err_dev_put;
dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
- ret = vbox_driver_load(dev);
+ vbox = devm_kzalloc(>dev, sizeof(*vbox), GFP_KERNEL);
+ if (!vbox) {
+ ret = -ENOMEM;
+ goto err_pci_disable;
+ }
+
+ dev->dev_private = vbox;
+ vbox->dev = dev;
+
+ mutex_init(>hw_mutex);
+
+ ret = vbox_hw_init(vbox);
+ if (ret)
+ goto err_pci_disable;
+
+ ret = vbox_mm_init(vbox);
if (ret)
- goto err_vbox_driver_load;
+ goto err_hw_fini;
+
+ ret = vbox_mode_init(dev);
+ if (ret)
+ goto err_mm_fini;
+
+ ret = vbox_irq_init(vbox);
+ if (ret)
+ goto err_mode_fini;
+
+ ret = vbox_fbdev_init(dev);
+ if (ret)
+ goto err_irq_fini;
ret = drm_dev_register(dev, 0);
if (ret)
- goto err_drv_dev_register;
+ goto err_fbdev_fini;
- return ret;
+ return 0;
- err_drv_dev_register:
- vbox_driver_unload(dev);
- err_vbox_driver_load:
+err_fbdev_fini:
+ vbox_fbdev_fini(dev);
+err_irq_fini:
+ vbox_irq_fini(vbox);
+err_mode_fini:
+ vbox_mode_fini(dev);
+err_mm_fini:
+ vbox_mm_fini(vbox);
+err_hw_fini:
+ vbox_hw_fini(vbox);
+err_pci_disable:
pci_disable_device(pdev);
- err_pci_enable:
+err_dev_put:
drm_dev_put(dev);
- err_drv_alloc:
return ret;
}
static void vbox_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct vbox_private *vbox = dev->dev_private;
drm_dev_unregister(dev);
- vbox_driver_unload(dev);
+ vbox_fbdev_fini(dev);
+ vbox_irq_fini(vbox);
+ vbox_mode_fini(dev);
+ vbox_mm_fini(vbox);
+ vbox_hw_fini(vbox);
drm_dev_put(dev);
}
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 594f84272957..a8e0dd8b57bf 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -126,8 +126,6 @@ struct vbox_private {
#undef CURSOR_PIXEL_COUNT
#undef CURSOR_DATA_SIZE
-int vbox_driver_load(struct drm_device *dev);
-void vbox_driver_unload(struct drm_device *dev);
void vbox_driver_lastclose(struct drm_device *dev);
struct vbox_gem_object;
@@ -177,6 +175,10 @@ struct vbox_fbdev {
#define to_vbox_encoder(x) container_of(x, struct vbox_encoder, base)
#define to_vbox_framebuffer(x) container_of(x, struct vbox_framebuffer, base)
+bool vbox_check_supported(u16 id);
+int vbox_hw_init(struct vbox_private *vbox);
+void vbox_hw_fini(struct vbox_private *vbox);
+
int vbox_mode_init(struct drm_device *dev);
void vbox_mode_fini(struct drm_device *dev);
diff --git a/drivers/staging/vboxvideo/vbox_main.c
b/drivers/staging/vboxvideo/vbox_main.c
index a1cd29fe98fd..815292f1d7e6 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -228,7 +228,7 @@ static bool have_hgsmi_mode_hints(struct vbox_private *vbox)
return have_hints == VINF_SUCCESS && have_cursor == VINF_SUCCESS;
}
-static bool vbox_check_supported(u16 id)
+bool vbox_check_supported(u16 id)
{
u16 dispi_id;
@@ -242,7 +242,7 @@ static bool vbox_check_supported(u16 id)
* Set up our heaps and data exchange buffers in VRAM before handing the rest
* to the memory manager.
*/
-static int vbox_hw_init(struct vbox_private *vbox)
+int vbox_hw_init(struct vbox_private *vbox)
{
int ret = -ENOMEM;
@@ -309,74 +309,13 @@ static int vbox_hw_init(struct vbox_private *vbox)
return ret;
}
[PATCH 00/12] staging: vboxvideo: Preparation work for moving to atomic modesetting
Hi Greg, Here is a series of various cleanups and other prep. work for moving the vboxvideo driver over to atomic modesetting so that it can be moved out of staging. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] staging: vboxvideo: Embed drm_device into driver structure
This is the recommended way to create the drm_device structure,
according to DRM documentation.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 110 +++---
drivers/staging/vboxvideo/vbox_drv.h | 17 ++--
drivers/staging/vboxvideo/vbox_fb.c | 19 ++---
drivers/staging/vboxvideo/vbox_irq.c | 8 +-
drivers/staging/vboxvideo/vbox_main.c | 30 +++
drivers/staging/vboxvideo/vbox_mode.c | 36 -
drivers/staging/vboxvideo/vbox_ttm.c | 13 ++-
7 files changed, 111 insertions(+), 122 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index 410a1f35b746..c4290d4b4a53 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -51,35 +51,31 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
- struct vbox_private *vbox = NULL;
- struct drm_device *dev = NULL;
+ struct vbox_private *vbox;
int ret = 0;
if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
return -ENODEV;
- dev = drm_dev_alloc(, >dev);
- if (IS_ERR(dev))
- return PTR_ERR(dev);
+ vbox = kzalloc(sizeof(*vbox), GFP_KERNEL);
+ if (!vbox)
+ return -ENOMEM;
- ret = pci_enable_device(pdev);
- if (ret)
- goto err_dev_put;
-
- dev->pdev = pdev;
- pci_set_drvdata(pdev, dev);
-
- vbox = devm_kzalloc(>dev, sizeof(*vbox), GFP_KERNEL);
- if (!vbox) {
- ret = -ENOMEM;
- goto err_pci_disable;
+ ret = drm_dev_init(>ddev, , >dev);
+ if (ret) {
+ kfree(vbox);
+ return ret;
}
- dev->dev_private = vbox;
- vbox->dev = dev;
-
+ vbox->ddev.pdev = pdev;
+ vbox->ddev.dev_private = vbox;
+ pci_set_drvdata(pdev, vbox);
mutex_init(>hw_mutex);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto err_dev_put;
+
ret = vbox_hw_init(vbox);
if (ret)
goto err_pci_disable;
@@ -88,7 +84,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_hw_fini;
- ret = vbox_mode_init(dev);
+ ret = vbox_mode_init(vbox);
if (ret)
goto err_mm_fini;
@@ -96,22 +92,22 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (ret)
goto err_mode_fini;
- ret = vbox_fbdev_init(dev);
+ ret = vbox_fbdev_init(vbox);
if (ret)
goto err_irq_fini;
- ret = drm_dev_register(dev, 0);
+ ret = drm_dev_register(>ddev, 0);
if (ret)
goto err_fbdev_fini;
return 0;
err_fbdev_fini:
- vbox_fbdev_fini(dev);
+ vbox_fbdev_fini(vbox);
err_irq_fini:
vbox_irq_fini(vbox);
err_mode_fini:
- vbox_mode_fini(dev);
+ vbox_mode_fini(vbox);
err_mm_fini:
vbox_mm_fini(vbox);
err_hw_fini:
@@ -119,110 +115,100 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
err_pci_disable:
pci_disable_device(pdev);
err_dev_put:
- drm_dev_put(dev);
+ drm_dev_put(>ddev);
return ret;
}
static void vbox_pci_remove(struct pci_dev *pdev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
- struct vbox_private *vbox = dev->dev_private;
+ struct vbox_private *vbox = pci_get_drvdata(pdev);
- drm_dev_unregister(dev);
- vbox_fbdev_fini(dev);
+ drm_dev_unregister(>ddev);
+ vbox_fbdev_fini(vbox);
vbox_irq_fini(vbox);
- vbox_mode_fini(dev);
+ vbox_mode_fini(vbox);
vbox_mm_fini(vbox);
vbox_hw_fini(vbox);
- drm_dev_put(dev);
+ drm_dev_put(>ddev);
}
-static int vbox_drm_freeze(struct drm_device *dev)
+static int vbox_drm_freeze(struct vbox_private *vbox)
{
- struct vbox_private *vbox = dev->dev_private;
-
- drm_kms_helper_poll_disable(dev);
+ drm_kms_helper_poll_disable(>ddev);
- pci_save_state(dev->pdev);
+ pci_save_state(vbox->ddev.pdev);
drm_fb_helper_set_suspend_unlocked(>fbdev->helper, true);
return 0;
}
-static int vbox_drm_thaw(struct drm_device *dev)
+static int vbox_drm_thaw(struct vbox_private *vbox)
{
- struct vbox_private *vbox = dev->dev_private;
-
- drm_mode_config_reset(dev);
- drm_helper_resume_force_mode(dev);
+ drm_mode_config_reset(>ddev);
+ drm_helper_resume_force_mode(>ddev);
drm_fb_helper_set_suspend_unlocked(>fbdev->helper, false);
return 0;
}
-static int vbox_drm_resume(struct drm_device *dev)
+static int vbox_drm_resume(struct vbox_private *vbox)
{
int ret;
- if (pci_enable_device(dev->pdev))
+ if
[PATCH 02/12] staging: vboxvideo: Move setup of modesetting from driver_load to mode_init
Move the setup of drm modesetting config from vbox_driver_load() to
vbox_mode_init().
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_main.c | 45 ---
drivers/staging/vboxvideo/vbox_mode.c | 62 ---
2 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_main.c
b/drivers/staging/vboxvideo/vbox_main.c
index 783a68c0de3b..a1cd29fe98fd 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -173,40 +173,6 @@ int vbox_framebuffer_init(struct drm_device *dev,
return 0;
}
-static struct drm_framebuffer *vbox_user_framebuffer_create(
- struct drm_device *dev,
- struct drm_file *filp,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- struct drm_gem_object *obj;
- struct vbox_framebuffer *vbox_fb;
- int ret = -ENOMEM;
-
- obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
- if (!obj)
- return ERR_PTR(-ENOENT);
-
- vbox_fb = kzalloc(sizeof(*vbox_fb), GFP_KERNEL);
- if (!vbox_fb)
- goto err_unref_obj;
-
- ret = vbox_framebuffer_init(dev, vbox_fb, mode_cmd, obj);
- if (ret)
- goto err_free_vbox_fb;
-
- return _fb->base;
-
-err_free_vbox_fb:
- kfree(vbox_fb);
-err_unref_obj:
- drm_gem_object_put_unlocked(obj);
- return ERR_PTR(ret);
-}
-
-static const struct drm_mode_config_funcs vbox_mode_funcs = {
- .fb_create = vbox_user_framebuffer_create,
-};
-
static int vbox_accel_init(struct vbox_private *vbox)
{
unsigned int i;
@@ -375,15 +341,6 @@ int vbox_driver_load(struct drm_device *dev)
if (ret)
goto err_hw_fini;
- drm_mode_config_init(dev);
-
- dev->mode_config.funcs = (void *)_mode_funcs;
- dev->mode_config.min_width = 64;
- dev->mode_config.min_height = 64;
- dev->mode_config.preferred_depth = 24;
- dev->mode_config.max_width = VBE_DISPI_MAX_XRES;
- dev->mode_config.max_height = VBE_DISPI_MAX_YRES;
-
ret = vbox_mode_init(dev);
if (ret)
goto err_drm_mode_cleanup;
@@ -403,7 +360,6 @@ int vbox_driver_load(struct drm_device *dev)
err_mode_fini:
vbox_mode_fini(dev);
err_drm_mode_cleanup:
- drm_mode_config_cleanup(dev);
vbox_mm_fini(vbox);
err_hw_fini:
vbox_hw_fini(vbox);
@@ -417,7 +373,6 @@ void vbox_driver_unload(struct drm_device *dev)
vbox_fbdev_fini(dev);
vbox_irq_fini(vbox);
vbox_mode_fini(dev);
- drm_mode_config_cleanup(dev);
vbox_mm_fini(vbox);
vbox_hw_fini(vbox);
}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 70701a6054c2..2587e6aecca2 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -696,6 +696,40 @@ static int vbox_connector_init(struct drm_device *dev,
return 0;
}
+static struct drm_framebuffer *vbox_user_framebuffer_create(
+ struct drm_device *dev,
+ struct drm_file *filp,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct drm_gem_object *obj;
+ struct vbox_framebuffer *vbox_fb;
+ int ret = -ENOMEM;
+
+ obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
+ if (!obj)
+ return ERR_PTR(-ENOENT);
+
+ vbox_fb = kzalloc(sizeof(*vbox_fb), GFP_KERNEL);
+ if (!vbox_fb)
+ goto err_unref_obj;
+
+ ret = vbox_framebuffer_init(dev, vbox_fb, mode_cmd, obj);
+ if (ret)
+ goto err_free_vbox_fb;
+
+ return _fb->base;
+
+err_free_vbox_fb:
+ kfree(vbox_fb);
+err_unref_obj:
+ drm_gem_object_put_unlocked(obj);
+ return ERR_PTR(ret);
+}
+
+static const struct drm_mode_config_funcs vbox_mode_funcs = {
+ .fb_create = vbox_user_framebuffer_create,
+};
+
int vbox_mode_init(struct drm_device *dev)
{
struct vbox_private *vbox = dev->dev_private;
@@ -704,24 +738,42 @@ int vbox_mode_init(struct drm_device *dev)
unsigned int i;
int ret;
+ drm_mode_config_init(dev);
+
+ dev->mode_config.funcs = (void *)_mode_funcs;
+ dev->mode_config.min_width = 64;
+ dev->mode_config.min_height = 64;
+ dev->mode_config.preferred_depth = 24;
+ dev->mode_config.max_width = VBE_DISPI_MAX_XRES;
+ dev->mode_config.max_height = VBE_DISPI_MAX_YRES;
+
/* vbox_cursor_init(dev); */
for (i = 0; i < vbox->num_crtcs; ++i) {
vbox_crtc = vbox_crtc_init(dev, i);
- if (!vbox_crtc)
- return -ENOMEM;
+ if (!vbox_crtc) {
+ ret = -ENOMEM;
+ goto err_drm_mode_cleanup;
+ }
encoder = vbox_encoder_init(dev, i);
- if (!encoder)
- return
[PATCH 01/12] staging: vboxvideo: Let DRM core handle connector registering
Registering the connector explicitly right after creation is not necessary for modesetting drivers, because drm_dev_register already takes care of this on the core side, by calling drm_modeset_register_all. Signed-off-by: Hans de Goede --- drivers/staging/vboxvideo/vbox_mode.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/vboxvideo/vbox_mode.c b/drivers/staging/vboxvideo/vbox_mode.c index e7d70ced5bfd..70701a6054c2 100644 --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -690,7 +690,6 @@ static int vbox_connector_init(struct drm_device *dev, dev->mode_config.suggested_x_property, 0); drm_object_attach_property(>base, dev->mode_config.suggested_y_property, 0); - drm_connector_register(connector); drm_connector_attach_encoder(connector, encoder); -- 2.19.0.rc1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] staging: vboxvideo: Expose creation of universal primary plane
Let's expose the primary plane initialization inside the vboxvideo driver
in preparation for universal planes and atomic.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 78 +--
1 file changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 3beae9d65a09..f35045ce154b 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -382,21 +382,91 @@ static const struct drm_crtc_funcs vbox_crtc_funcs = {
.destroy = vbox_crtc_destroy,
};
+static const uint32_t vbox_primary_plane_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
+static const struct drm_plane_funcs vbox_primary_plane_funcs = {
+ .update_plane = drm_primary_helper_update,
+ .disable_plane = drm_primary_helper_disable,
+ .destroy= drm_primary_helper_destroy,
+};
+
+static struct drm_plane *vbox_create_plane(struct vbox_private *vbox,
+ unsigned int possible_crtcs,
+ enum drm_plane_type type)
+{
+ const struct drm_plane_helper_funcs *helper_funcs = NULL;
+ const struct drm_plane_funcs *funcs;
+ struct drm_plane *plane;
+ const uint32_t *formats;
+ int num_formats;
+ int err;
+
+ if (type == DRM_PLANE_TYPE_PRIMARY) {
+ funcs = _primary_plane_funcs;
+ formats = vbox_primary_plane_formats;
+ num_formats = ARRAY_SIZE(vbox_primary_plane_formats);
+ } else {
+ return ERR_PTR(-EINVAL);
+ }
+
+ plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+ if (!plane)
+ return ERR_PTR(-ENOMEM);
+
+ err = drm_universal_plane_init(>ddev, plane, possible_crtcs,
+ funcs, formats, num_formats,
+ NULL, type, NULL);
+ if (err)
+ goto free_plane;
+
+ drm_plane_helper_add(plane, helper_funcs);
+
+ return plane;
+
+free_plane:
+ kfree(plane);
+ return ERR_PTR(-EINVAL);
+}
+
static struct vbox_crtc *vbox_crtc_init(struct drm_device *dev, unsigned int i)
{
+ struct vbox_private *vbox =
+ container_of(dev, struct vbox_private, ddev);
struct vbox_crtc *vbox_crtc;
+ struct drm_plane *primary;
+ int ret;
vbox_crtc = kzalloc(sizeof(*vbox_crtc), GFP_KERNEL);
if (!vbox_crtc)
- return NULL;
+ return ERR_PTR(-ENOMEM);
+
+ primary = vbox_create_plane(vbox, 1 << i, DRM_PLANE_TYPE_PRIMARY);
+ if (IS_ERR(primary)) {
+ ret = PTR_ERR(primary);
+ goto free_mem;
+ }
vbox_crtc->crtc_id = i;
- drm_crtc_init(dev, _crtc->base, _crtc_funcs);
+ ret = drm_crtc_init_with_planes(dev, _crtc->base, primary, NULL,
+ _crtc_funcs, NULL);
+ if (ret)
+ goto clean_primary;
+
drm_mode_crtc_set_gamma_size(_crtc->base, 256);
drm_crtc_helper_add(_crtc->base, _crtc_helper_funcs);
return vbox_crtc;
+
+clean_primary:
+ drm_plane_cleanup(primary);
+ kfree(primary);
+free_mem:
+ kfree(vbox_crtc);
+ return ERR_PTR(ret);
}
static void vbox_encoder_destroy(struct drm_encoder *encoder)
@@ -750,8 +820,8 @@ int vbox_mode_init(struct vbox_private *vbox)
/* vbox_cursor_init(dev); */
for (i = 0; i < vbox->num_crtcs; ++i) {
vbox_crtc = vbox_crtc_init(dev, i);
- if (!vbox_crtc) {
- ret = -ENOMEM;
+ if (IS_ERR(vbox_crtc)) {
+ ret = PTR_ERR(vbox_crtc);
goto err_drm_mode_cleanup;
}
encoder = vbox_encoder_init(dev, i);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] staging: vboxvideo: Add fl_flag argument to vbox_fb_pin() helper
Allow specifying where to pin the framebuffer bo, so that this helper can
be used from the cursor code too.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 13696ba19c4f..3beae9d65a09 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -221,7 +221,7 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
return old_single_framebuffer != vbox->single_framebuffer;
}
-static int vbox_fb_pin(struct drm_framebuffer *fb, u64 *addr)
+static int vbox_fb_pin(struct drm_framebuffer *fb, u32 pl_flag, u64 *addr)
{
struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
int ret;
@@ -230,7 +230,7 @@ static int vbox_fb_pin(struct drm_framebuffer *fb, u64
*addr)
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, addr);
+ ret = vbox_bo_pin(bo, pl_flag, addr);
vbox_bo_unreserve(bo);
return ret;
}
@@ -267,7 +267,7 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
int ret;
/* Prepare: pin the new framebuffer bo */
- ret = vbox_fb_pin(new_fb, _addr);
+ ret = vbox_fb_pin(new_fb, TTM_PL_FLAG_VRAM, _addr);
if (ret) {
DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
return ret;
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] i915: rename modifiers to follow the naming convention
$ sed -i s/I915_FORMAT_MOD_/DRM_FORMAT_MOD_INTEL_/g $(git grep -l
I915_FORMAT_MOD_)
$ git checkout include/uapi/drm/drm_fourcc.h
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 12 +-
drivers/gpu/drm/i915/intel_display.c | 128 +++---
drivers/gpu/drm/i915/intel_pm.c | 26 ++---
drivers/gpu/drm/i915/intel_sprite.c | 58 +-
4 files changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index fa7df5fe154bf06bdfc5..c26f0b25afa2dc8c3a3c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -126,8 +126,8 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
if (state->fb && drm_rotation_90_or_270(state->rotation)) {
struct drm_format_name_buf format_name;
- if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
- state->fb->modifier != I915_FORMAT_MOD_Yf_TILED) {
+ if (state->fb->modifier != DRM_FORMAT_MOD_INTEL_Y_TILED &&
+ state->fb->modifier != DRM_FORMAT_MOD_INTEL_Yf_TILED) {
DRM_DEBUG_KMS("Y/Yf tiling required for 90/270!\n");
return -EINVAL;
}
@@ -169,10 +169,10 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
*/
if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
- if (state->fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- state->fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
- state->fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- state->fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ if (state->fb->modifier == DRM_FORMAT_MOD_INTEL_Y_TILED ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Yf_TILED ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Y_TILED_CCS ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS) {
DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
mode\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b2bab57cd113f2293850..087302d655f9a146846a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -69,7 +69,7 @@ static const uint32_t i965_primary_formats[] = {
};
static const uint64_t i9xx_format_modifiers[] = {
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
@@ -106,19 +106,19 @@ static const uint32_t skl_pri_planar_formats[] = {
};
static const uint64_t skl_format_modifiers_noccs[] = {
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED,
+ DRM_FORMAT_MOD_INTEL_Y_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
static const uint64_t skl_format_modifiers_ccs[] = {
- I915_FORMAT_MOD_Yf_TILED_CCS,
- I915_FORMAT_MOD_Y_TILED_CCS,
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS,
+ DRM_FORMAT_MOD_INTEL_Y_TILED_CCS,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED,
+ DRM_FORMAT_MOD_INTEL_Y_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
@@ -1925,25 +1925,25 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int plane)
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
return cpp;
- case I915_FORMAT_MOD_X_TILED:
+ case DRM_FORMAT_MOD_INTEL_X_TILED:
if (IS_GEN2(dev_priv))
return 128;
else
return 512;
- case I915_FORMAT_MOD_Y_TILED_CCS:
+ case DRM_FORMAT_MOD_INTEL_Y_TILED_CCS:
if (plane == 1)
return 128;
/* fall through */
- case I915_FORMAT_MOD_Y_TILED:
+ case DRM_FORMAT_MOD_INTEL_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
- case I915_FORMAT_MOD_Yf_TILED_CCS:
+ case DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS:
if (plane == 1)
return 128;
/* fall through */
- case I915_FORMAT_MOD_Yf_TILED:
+ case DRM_FORMAT_MOD_INTEL_Yf_TILED:
switch (cpp) {
case 1:
return 64;
@@ -2055,14
[PATCH 1/2] drm/fourcc: rename Intel modifiers to follow the naming convention
All the other vendors use the format
DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
modifiers, except Intel.
Suggested-by: Gerd Hoffmann
Signed-off-by: Eric Engestrom
---
include/uapi/drm/drm_fourcc.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b871816f9e3dad..170a562223387687592a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -271,7 +271,8 @@ extern "C" {
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
*/
-#define I915_FORMAT_MOD_X_TILEDfourcc_mod_code(INTEL, 1)
+#define DRM_FORMAT_MOD_INTEL_X_TILED fourcc_mod_code(INTEL, 1)
+#define I915_FORMAT_MOD_X_TILEDDRM_FORMAT_MOD_INTEL_X_TILED
/*
* Intel Y-tiling layout
@@ -286,7 +287,8 @@ extern "C" {
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
*/
-#define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 2)
+#define DRM_FORMAT_MOD_INTEL_Y_TILED fourcc_mod_code(INTEL, 2)
+#define I915_FORMAT_MOD_Y_TILEDDRM_FORMAT_MOD_INTEL_Y_TILED
/*
* Intel Yf-tiling layout
@@ -301,7 +303,8 @@ extern "C" {
* 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
width
* in pixel depends on the pixel depth.
*/
-#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define DRM_FORMAT_MOD_INTEL_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define I915_FORMAT_MOD_Yf_TILED DRM_FORMAT_MOD_INTEL_Yf_TILED
/*
* Intel color control surface (CCS) for render compression
@@ -320,8 +323,10 @@ extern "C" {
* But that fact is not relevant unless the memory is accessed
* directly.
*/
-#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
-#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+#define DRM_FORMAT_MOD_INTEL_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Y_TILED_CCSDRM_FORMAT_MOD_INTEL_Y_TILED_CCS
+#define DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+#define I915_FORMAT_MOD_Yf_TILED_CCS DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
--
Cheers,
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/scheduler: add a current job field to scheduler
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
> Which points to the job running on the hardware. This is
> useful when we need to access the currently executing job
> from the scheduler.
That should be identical to
list_first_entry_or_null(>ring_mirror_list), doesn't it?
Regards,
Christian.
>
> Signed-off-by: Nayan Deshmukh
> ---list_first_entry_or_null(>ring_mirror_list
>
> drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
> include/drm/gpu_scheduler.h| 2 ++
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 9ca741f3a0bc..0e6ccc8243db 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -189,6 +189,7 @@ static void drm_sched_job_finish(struct work_struct *work)
> struct drm_sched_job *s_job = container_of(work, struct drm_sched_job,
> finish_work);
> struct drm_gpu_scheduler *sched = s_job->sched;
> + struct drm_sched_job *next;
>
> /*
>* Canceling the timeout without removing our job from the ring mirror
> @@ -201,10 +202,10 @@ static void drm_sched_job_finish(struct work_struct
> *work)
>
> spin_lock(>job_list_lock);
> /* queue TDR for next job */
> + next = list_next_entry(s_job, node);
> + sched->curr_job = next;
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> !list_is_last(_job->node, >ring_mirror_list)) {
> - struct drm_sched_job *next = list_next_entry(s_job, node);
> -
> if (!dma_fence_is_signaled(>s_fence->finished))
> schedule_delayed_work(>work_tdr, sched->timeout);
> }
> @@ -233,10 +234,12 @@ static void drm_sched_job_begin(struct drm_sched_job
> *s_job)
>
> spin_lock(>job_list_lock);
> list_add_tail(_job->node, >ring_mirror_list);
> - if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> - list_first_entry_or_null(>ring_mirror_list,
> - struct drm_sched_job, node) == s_job)
> - schedule_delayed_work(_job->work_tdr, sched->timeout);
> + if (list_first_entry_or_null(>ring_mirror_list,
> + struct drm_sched_job, node) == s_job) {
> + if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
> + schedule_delayed_work(_job->work_tdr, sched->timeout);
> + sched->curr_job = s_job;
> + }
> spin_unlock(>job_list_lock);
> }
>
> @@ -316,6 +319,8 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler
> *sched)
>struct drm_sched_job, node);
> if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
> schedule_delayed_work(_job->work_tdr, sched->timeout);
> + if (s_job)
> + sched->curr_job = s_job;
>
> list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
> struct drm_sched_fence *s_fence = s_job->s_fence;
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index daec50f887b3..07e776b1ca42 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -252,6 +252,7 @@ struct drm_sched_backend_ops {
>* @timeout: the time after which a job is removed from the scheduler.
>* @name: name of the ring for which this scheduler is being used.
>* @sched_rq: priority wise array of run queues.
> + * @curr_job: points to the job currently running on the hardware
>* @wake_up_worker: the wait queue on which the scheduler sleeps until a job
>* is ready to be scheduled.
>* @job_scheduled: once @drm_sched_entity_do_release is called the scheduler
> @@ -274,6 +275,7 @@ struct drm_gpu_scheduler {
> longtimeout;
> const char *name;
> struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_MAX];
> + struct drm_sched_job*curr_job;
> wait_queue_head_t wake_up_worker;
> wait_queue_head_t job_scheduled;
> atomic_thw_rq_count;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and WRITEBACK_CONNECTORS
- Added Arm AFBC modifiers
- Added BROADCOM's SAND and UIF modifiers
- Added Qualcomm's modifiers
- Added some picture aspect ratio and content type options
- Added some drm mode flags
- Added writeback connector id
amdgpu:
- Added GEM domain mask
- Added some GEM flags
- Added some hardware ip flags
- Added chunk id and IB fence.
- Added some query ids
i915:
-Added an IOCTL (I915_PARAM_MMAP_GTT_COHERENT)
qxl:
- Minor changes
radeon:
- Removed RADEON_TILING_R600_NO_SCANOUT
sis:
- Changed the data type of some structure members from 'int' to 'long'.
tegra:
- Added some comments about struct drm_tegra* members
- Modified DRM_IOCTL_TEGRA_CLOSE_CHANNEL
vc4:
- Added some members for 'struct drm_vc4_submit_cl'
via:
- Removed inclusion of 'via_drmclient.h'.
vmwgfx:
- Added some DRM_VMW_* macros
- Renamed some structures like 'drm_vmw_dmabuf_rep' to 'drm_vmw_bo_rep', etc
- Added some new DRM_VMW_GB_SURFACE related structures and unions
Signed-off-by: Ayan Kumar halder
---
Dropped changes to nouveau_drm.h as it causes compilation failure
include/drm/amdgpu_drm.h | 47 -
include/drm/drm.h| 16 ++
include/drm/drm_fourcc.h | 215 +
include/drm/drm_mode.h | 35 +++-
include/drm/i915_drm.h | 22 +++
include/drm/qxl_drm.h| 2 -
include/drm/radeon_drm.h | 1 -
include/drm/sis_drm.h| 8 +-
include/drm/tegra_drm.h | 492 ++-
include/drm/vc4_drm.h| 13 +-
include/drm/via_drm.h| 1 -
include/drm/vmwgfx_drm.h | 166
12 files changed, 957 insertions(+), 61 deletions(-)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index c363b67..1ceec56 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -72,12 +72,41 @@ extern "C" {
#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
#define DRM_IOCTL_AMDGPU_SCHED DRM_IOW(DRM_COMMAND_BASE +
DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
+/**
+ * DOC: memory domains
+ *
+ * %AMDGPU_GEM_DOMAIN_CPU System memory that is not GPU accessible.
+ * Memory in this pool could be swapped out to disk if there is pressure.
+ *
+ * %AMDGPU_GEM_DOMAIN_GTT GPU accessible system memory, mapped into the
+ * GPU's virtual address space via gart. Gart memory linearizes non-contiguous
+ * pages of system memory, allows GPU access system memory in a linezrized
+ * fashion.
+ *
+ * %AMDGPU_GEM_DOMAIN_VRAM Local video memory. For APUs, it is memory
+ * carved out by the BIOS.
+ *
+ * %AMDGPU_GEM_DOMAIN_GDS Global on-chip data storage used to share data
+ * across shader threads.
+ *
+ * %AMDGPU_GEM_DOMAIN_GWS Global wave sync, used to synchronize the
+ * execution of all the waves on a device.
+ *
+ * %AMDGPU_GEM_DOMAIN_OA Ordered append, used by 3D or Compute engines
+ * for appending data.
+ */
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
#define AMDGPU_GEM_DOMAIN_VRAM 0x4
#define AMDGPU_GEM_DOMAIN_GDS 0x8
#define AMDGPU_GEM_DOMAIN_GWS 0x10
#define AMDGPU_GEM_DOMAIN_OA 0x20
+#define AMDGPU_GEM_DOMAIN_MASK (AMDGPU_GEM_DOMAIN_CPU | \
+AMDGPU_GEM_DOMAIN_GTT | \
+AMDGPU_GEM_DOMAIN_VRAM | \
+AMDGPU_GEM_DOMAIN_GDS | \
+AMDGPU_GEM_DOMAIN_GWS | \
+AMDGPU_GEM_DOMAIN_OA)
/* Flag that CPU access will be required for the case of VRAM domain */
#define AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED (1 << 0)
@@ -95,6 +124,10 @@ extern "C" {
#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID (1 << 6)
/* Flag that BO sharing will be explicitly synchronized */
#define AMDGPU_GEM_CREATE_EXPLICIT_SYNC(1 << 7)
+/* Flag that indicates allocating MQD gart on GFX9, where the mtype
+ * for the second page onward should be set to NC.
+ */
+#define AMDGPU_GEM_CREATE_MQD_GFX9 (1 << 8)
struct drm_amdgpu_gem_create_in {
/** the requested memory size */
@@ -473,7 +506,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
-#define AMDGPU_HW_IP_NUM 8
+#define AMDGPU_HW_IP_VCN_JPEG 8
+#define AMDGPU_HW_IP_NUM 9
#define AMDGPU_HW_IP_INSTANCE_MAX_COUNT 1
@@ -482,6 +516,7 @@ struct drm_amdgpu_gem_va {
Re: [PATCH v6 1/2] drm: Add connector property to limit max bpc
On Mon, Sep 17, 2018 at 09:52:08PM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 24
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 34 ++
> include/drm/drm_connector.h | 20
> 5 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7ada75919756..fa9996deb132 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = >display_info;
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + if (connector->max_bpc_property) {
> + if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
> + /* Don't use an invalid EDID bpc value */
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
> + " display bpp (was %d) to EDID
> reported"
> + "max of %d\n", connector->base.id,
> + connector->name,
> + state->max_requested_bpc, info->bpc);
> + state->max_bpc = info->bpc;
> + } else if (info->bpc != 0) {
> + state->max_bpc = state->max_requested_bpc;
> + } else {
> + /* Clamp bpc to 8 on screens witout EDID 1.4 */
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
> + " display bpp (was %d) to default
> limit"
> + " of 24\n", connector->base.id,
> + connector->name,
> state->max_requested_bpc);
> + state->max_bpc = 8;
> + }
> + } else {
> + state->max_bpc = info->bpc ? info->bpc : 8;
> + }
Something like
max_bpc = info->bpc ?: 8;
if (max_bpc_prop)
max_bpc = min(max_bpc, max_requested_bpc);
for short?
Not quite sure the 8bpc fallback should be here. Maybe it should be in
the edid code instead? Though I guess we want something for edidless
displays too so maybe this is fine.
> +
> if (state->crtc)
> crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> state->crtc);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6
[PATCH v7 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_display.c | 49
drivers/gpu/drm/i915/intel_dp.c | 5
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..75afd53590b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = >base.display_info;
- int bpp = pipe_config->pipe_bpp;
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
- /* Don't use an invalid EDID bpc value */
- if (info->bpc != 0 && info->bpc * 3 < bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
max of %d\n",
- bpp, info->bpc * 3);
- pipe_config->pipe_bpp = info->bpc * 3;
+ if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+ conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+ return;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (info->bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ switch (conn_state->max_bpc) {
+ case 8:
+ case 9:
+ pipe_config->pipe_bpp = 8 * 3;
+ break;
+ case 10:
+ case 11:
+ pipe_config->pipe_bpp = 10 * 3;
+ break;
+ case 12:
+ case 13:
+ case 14:
+ case 15:
+ pipe_config->pipe_bpp = 12 * 3;
+ break;
+ case 16:
+ pipe_config->pipe_bpp = 16 * 3;
+ break;
+ default:
+ break;
}
+
+ DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
}
static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != >base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ connected_sink_max_bpp(connector_state, pipe_config);
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+ drm_connector_attach_max_bpc_property(connector, 8, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+
+
[PATCH v7 1/2] drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 24
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 20
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..49078bb500fd 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
{
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+ struct drm_display_info *info = >display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ if (connector->max_bpc_property) {
+ if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
+ /* Don't use an invalid EDID bpc value */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested "
+"display bpp (was %d) to EDID reported
"
+"max of %d\n", connector->base.id,
+connector->name,
+state->max_requested_bpc, info->bpc);
+ state->max_bpc = info->bpc;
+ } else if (info->bpc != 0) {
+ state->max_bpc = state->max_requested_bpc;
+ } else {
+ /* Clamp bpc to 8 on screens witout EDID 1.4 */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested "
+"display bpp (was %d) to default limit
"
+"of 24\n", connector->base.id,
+connector->name,
state->max_requested_bpc);
+ state->max_bpc = 8;
+ }
+ } else {
+ state->max_bpc = info->bpc ? info->bpc : 8;
+ }
+
if (state->crtc)
crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->max_requested_bpc !=
+ new_connector_state->max_requested_bpc)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return set_out_fence_for_connector(state->state, connector,
fence_ptr);
+ } else if (property == connector->max_bpc_property) {
+ state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
[PATCH 2/2] drm/scheduler: remove timeout work_struct from drm_sched_job
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +---
include/drm/gpu_scheduler.h| 6 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 0e6ccc8243db..f213b5c7f718 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_finish(struct work_struct *work)
* manages to find this job as the next job in the list, the fence
* signaled check below will prevent the timeout to be restarted.
*/
- cancel_delayed_work_sync(_job->work_tdr);
+ cancel_delayed_work_sync(>work_tdr);
spin_lock(>job_list_lock);
/* queue TDR for next job */
@@ -207,7 +207,7 @@ static void drm_sched_job_finish(struct work_struct *work)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_is_last(_job->node, >ring_mirror_list)) {
if (!dma_fence_is_signaled(>s_fence->finished))
- schedule_delayed_work(>work_tdr, sched->timeout);
+ schedule_delayed_work(>work_tdr, sched->timeout);
}
/* remove job from ring_mirror_list */
list_del(_job->node);
@@ -237,7 +237,7 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job)
if (list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node) == s_job) {
if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(_job->work_tdr, sched->timeout);
+ schedule_delayed_work(>work_tdr, sched->timeout);
sched->curr_job = s_job;
}
spin_unlock(>job_list_lock);
@@ -245,8 +245,10 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
static void drm_sched_job_timedout(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(work, struct drm_sched_job,
-work_tdr.work);
+ struct drm_gpu_scheduler *sched = container_of(work,
+ struct drm_gpu_scheduler,
+ work_tdr.work);
+ struct drm_sched_job *job = sched->curr_job;
job->sched->ops->timedout_job(job);
}
@@ -318,7 +320,7 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
s_job = list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(_job->work_tdr, sched->timeout);
+ schedule_delayed_work(>work_tdr, sched->timeout);
if (s_job)
sched->curr_job = s_job;
@@ -389,7 +391,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
INIT_WORK(>finish_work, drm_sched_job_finish);
INIT_LIST_HEAD(>node);
- INIT_DELAYED_WORK(>work_tdr, drm_sched_job_timedout);
return 0;
}
@@ -580,6 +581,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
INIT_LIST_HEAD(>ring_mirror_list);
spin_lock_init(>job_list_lock);
atomic_set(>hw_rq_count, 0);
+ INIT_DELAYED_WORK(>work_tdr, drm_sched_job_timedout);
atomic_set(>num_jobs, 0);
atomic64_set(>job_id_count, 0);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 07e776b1ca42..9d50d7f3eaa4 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -175,8 +175,6 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f);
* finished to remove the job from the
* @drm_gpu_scheduler.ring_mirror_list.
* @node: used to append this struct to the
@drm_gpu_scheduler.ring_mirror_list.
- * @work_tdr: schedules a delayed call to @drm_sched_job_timedout after the
timeout
- *interval is over.
* @id: a unique id assigned to each job scheduled on the scheduler.
* @karma: increment on every hang caused by this job. If this exceeds the hang
* limit of the scheduler then the job is marked guilty and will not
@@ -195,7 +193,6 @@ struct drm_sched_job {
struct dma_fence_cb finish_cb;
struct work_struct finish_work;
struct list_headnode;
- struct delayed_work work_tdr;
uint64_tid;
atomic_tkarma;
enum drm_sched_priority s_priority;
@@ -260,6 +257,8 @@ struct drm_sched_backend_ops {
* finished.
* @hw_rq_count: the number of jobs currently in the hardware queue.
*
[PATCH 1/2] drm/scheduler: add a current job field to scheduler
Which points to the job running on the hardware. This is
useful when we need to access the currently executing job
from the scheduler.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
include/drm/gpu_scheduler.h| 2 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9ca741f3a0bc..0e6ccc8243db 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -189,6 +189,7 @@ static void drm_sched_job_finish(struct work_struct *work)
struct drm_sched_job *s_job = container_of(work, struct drm_sched_job,
finish_work);
struct drm_gpu_scheduler *sched = s_job->sched;
+ struct drm_sched_job *next;
/*
* Canceling the timeout without removing our job from the ring mirror
@@ -201,10 +202,10 @@ static void drm_sched_job_finish(struct work_struct *work)
spin_lock(>job_list_lock);
/* queue TDR for next job */
+ next = list_next_entry(s_job, node);
+ sched->curr_job = next;
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_is_last(_job->node, >ring_mirror_list)) {
- struct drm_sched_job *next = list_next_entry(s_job, node);
-
if (!dma_fence_is_signaled(>s_fence->finished))
schedule_delayed_work(>work_tdr, sched->timeout);
}
@@ -233,10 +234,12 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
spin_lock(>job_list_lock);
list_add_tail(_job->node, >ring_mirror_list);
- if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
- list_first_entry_or_null(>ring_mirror_list,
-struct drm_sched_job, node) == s_job)
- schedule_delayed_work(_job->work_tdr, sched->timeout);
+ if (list_first_entry_or_null(>ring_mirror_list,
+ struct drm_sched_job, node) == s_job) {
+ if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
+ schedule_delayed_work(_job->work_tdr, sched->timeout);
+ sched->curr_job = s_job;
+ }
spin_unlock(>job_list_lock);
}
@@ -316,6 +319,8 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
schedule_delayed_work(_job->work_tdr, sched->timeout);
+ if (s_job)
+ sched->curr_job = s_job;
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
struct drm_sched_fence *s_fence = s_job->s_fence;
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index daec50f887b3..07e776b1ca42 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -252,6 +252,7 @@ struct drm_sched_backend_ops {
* @timeout: the time after which a job is removed from the scheduler.
* @name: name of the ring for which this scheduler is being used.
* @sched_rq: priority wise array of run queues.
+ * @curr_job: points to the job currently running on the hardware
* @wake_up_worker: the wait queue on which the scheduler sleeps until a job
* is ready to be scheduled.
* @job_scheduled: once @drm_sched_entity_do_release is called the scheduler
@@ -274,6 +275,7 @@ struct drm_gpu_scheduler {
longtimeout;
const char *name;
struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_MAX];
+ struct drm_sched_job*curr_job;
wait_queue_head_t wake_up_worker;
wait_queue_head_t job_scheduled;
atomic_thw_rq_count;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5 2/8] drm: Add Plane Degamma properties
Hi,
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> v5: Added "Display Color Hardware Pipeline" flow to kernel
> documentation as suggested by "Ville Syrjala" and "Brian Starkey".
> Moved the property creation to drm_color_mgmt.c file to consolidate
> all color operations at one place.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Alexandru Gheorghe
> ---
> Documentation/gpu/drm-kms.rst | 90
> +
> drivers/gpu/drm/drm_atomic.c| 13 ++
> drivers/gpu/drm/drm_atomic_helper.c | 6 +++
> drivers/gpu/drm/drm_color_mgmt.c| 44 --
> include/drm/drm_plane.h | 24 ++
> 5 files changed, 174 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index f8f5bf1..253d546 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -551,12 +551,102 @@ Plane Composition Properties
> Color Management Properties
> ---
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware blocks
> +can help with this. Once the Data is blended, similar color processing
> +can be done on blended output using pipe color hardware blocks.
> +
> +DRM Properties have been created to define and expose all these
> +hardware blocks to userspace. A userspace application (compositor
> +or any color app) can use these interfaces and define policies to
> +efficiently use the display hardware for such color operations.
> +
> +Pipe Color Management Properties
> +-
> +
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :doc: overview
>
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :export:
>
> +Plane Color Management Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: Plane Color Properties
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: export
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d0478ab..e716614 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_device *dev = plane->dev;
>
Re: [RFC v5 0/8] Add Plane Color Properties
On Sun, Sep 16, 2018 at 01:45:23PM +0530, Uma Shankar wrote: > This is how a typical display color hardware pipeline looks like: > +---+ > |RAM| > | +--++-++-+ | > | | FB 1 || FB 2 || FB N| | > | +--++-++-+ | > +---+ >| Plane Color Hardware Block | > ++ > | +---v-+ +---v---+ +---v--+ | > | | Plane A | | Plane B | | Plane N | | > | | DeGamma | | Degamma | | Degamma | | > | +---+-+ +---+---+ +---+--+ | > | | | || > | +---v-+ +---v---+ +---v--+ | > | |Plane A | | Plane B | | Plane N | | > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > | +---+-+ ++--+ ++-+ | > | | | | | > | +---v-+ +v--+ +v-+ | > | | Plane A | | Plane B | | Plane N | | > | | Gamma | | Gamma | | Gamma| | > | +---+-+ ++--+ ++-+ | > | | | | | > ++ > +--v--v---v---| > || || > || Pipe Blender|| > +++ > ||| > |+---v--+ | > || Pipe DeGamma| | > || | | > |+---+--+ | > ||Pipe Color | > |+---v--+ Hardware| > || Pipe CSC/CTM| | > || | | > |+---+--+ | > ||| > |+---v--+ | > || Pipe Gamma | | > || | | > |+---+--+ | > ||| > +-+ > | > v >Pipe Output > > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel > supported color space. These can be utilize by user space to convert > planes from one format to another, one color space to another etc. > > Usersapce can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches just add the property interfaces and enable helper > functions. > > This series adds Intel Gen9 specific plane gamma feature. We can > build up and add other platform/hardware specific implementation > on top of this series > > Note: This is just to get a design feedback whether these interfaces > look ok. Based on community feedback on interfaces, we will implement > IGT tests to validate plane color features. This is un-tested currently. > > Userspace implementation using these properties have been done in drm > hwcomposer by "Alexandru-Cosmin Gheorghe alexandru-cosmin.gheor...@arm.com" > from ARM. A merge request has been opened by Alexandru for drm_hwcomposer, > implementing the property changes for the same. Please review that as well: > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25 > Just heads-up I just pushed a v2 for that. > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added > Gen9/BDW plane gamma feature and rebase on tot. > > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul > comments and moved plane color properties to drm_plane instead of > mode_config. Added property documentation as suggested by Daniel, Vetter. > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > > v4: Rebase > > v5: Added "Display Color Hardware Pipeline" flow to kernel > documentation as suggested by "Ville Syrjala" and "Brian Starkey". > Moved the property creation to drm_color_mgmt.c file to consolidate > all color operations at one place. Addressed Alexandru's review comments. > > Uma Shankar (8): > drm: Add Enhanced Gamma LUT precision structure > drm: Add Plane Degamma properties > drm: Add Plane CTM property > drm: Add Plane Gamma properties > drm: Define helper function for plane color enabling >
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
Hi, Greg
Can you pick up the patch?
Thanks,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e8..d7b9870 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -161,10 +161,8 @@ static int zx_drm_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - for_each_available_child_of_node(parent, child) {
> + for_each_available_child_of_node(parent, child)
> component_match_add(dev, , compare_of, child);
> - of_node_put(child);
> - }
>
> return component_master_add_with_match(dev, _drm_master_ops, match);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Convert drm_atomic_helper_suspend/resume()
On Mon, Sep 10, 2018 at 12:16 PM Souptick Joarder wrote:
>
> On Mon, Aug 6, 2018 at 11:42 AM Souptick Joarder wrote:
> >
> > On Wed, Aug 1, 2018 at 1:37 AM, Souptick Joarder
> > wrote:
> > > convert drm_atomic_helper_suspend/resume() to use
> > > drm_mode_config_helper_suspend/resume().
> > >
> > > With this conversion, tegra_drm_fb_suspend() and
> > > tegra_drm_fb_resume() wil not be used anymore.
> > > Both of these functions can be removed.
> > >
> > > Also, in tegra_drm struct's member state will not be
> > > used anymore. So this can be removed forever.
> > >
> > > Fixed one sparse warning.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Signed-off-by: Ajit Negi
> > > ---
> >
> > Any comment on this patch ?
>
> If no comment, can we get this patch in queue for 4.20 ?
David/ Daniel,
is this patch [1] good to go in 4.20 ?
[1] https://lkml.org/lkml/2018/7/31/839
> >
> > > drivers/gpu/drm/tegra/drm.c | 20 ++--
> > > drivers/gpu/drm/tegra/drm.h | 4
> > > drivers/gpu/drm/tegra/fb.c | 24 +---
> > > 3 files changed, 3 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > > index a2bd587..9a0efce 100644
> > > --- a/drivers/gpu/drm/tegra/drm.c
> > > +++ b/drivers/gpu/drm/tegra/drm.c
> > > @@ -1212,31 +1212,15 @@ static int host1x_drm_remove(struct host1x_device
> > > *dev)
> > > static int host1x_drm_suspend(struct device *dev)
> > > {
> > > struct drm_device *drm = dev_get_drvdata(dev);
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - drm_kms_helper_poll_disable(drm);
> > > - tegra_drm_fb_suspend(drm);
> > > -
> > > - tegra->state = drm_atomic_helper_suspend(drm);
> > > - if (IS_ERR(tegra->state)) {
> > > - tegra_drm_fb_resume(drm);
> > > - drm_kms_helper_poll_enable(drm);
> > > - return PTR_ERR(tegra->state);
> > > - }
> > >
> > > - return 0;
> > > + return drm_mode_config_helper_suspend(drm);
> > > }
> > >
> > > static int host1x_drm_resume(struct device *dev)
> > > {
> > > struct drm_device *drm = dev_get_drvdata(dev);
> > > - struct tegra_drm *tegra = drm->dev_private;
> > >
> > > - drm_atomic_helper_resume(drm, tegra->state);
> > > - tegra_drm_fb_resume(drm);
> > > - drm_kms_helper_poll_enable(drm);
> > > -
> > > - return 0;
> > > + return drm_mode_config_helper_resume(drm);
> > > }
> > > #endif
> > >
> > > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> > > index 92d2487..1012335 100644
> > > --- a/drivers/gpu/drm/tegra/drm.h
> > > +++ b/drivers/gpu/drm/tegra/drm.h
> > > @@ -60,8 +60,6 @@ struct tegra_drm {
> > > unsigned int pitch_align;
> > >
> > > struct tegra_display_hub *hub;
> > > -
> > > - struct drm_atomic_state *state;
> > > };
> > >
> > > struct tegra_drm_client;
> > > @@ -186,8 +184,6 @@ struct drm_framebuffer *tegra_fb_create(struct
> > > drm_device *drm,
> > > void tegra_drm_fb_free(struct drm_device *drm);
> > > int tegra_drm_fb_init(struct drm_device *drm);
> > > void tegra_drm_fb_exit(struct drm_device *drm);
> > > -void tegra_drm_fb_suspend(struct drm_device *drm);
> > > -void tegra_drm_fb_resume(struct drm_device *drm);
> > >
> > > extern struct platform_driver tegra_display_hub_driver;
> > > extern struct platform_driver tegra_dc_driver;
> > > diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> > > index 4c22cdd..b947e82 100644
> > > --- a/drivers/gpu/drm/tegra/fb.c
> > > +++ b/drivers/gpu/drm/tegra/fb.c
> > > @@ -356,7 +356,7 @@ static void tegra_fbdev_exit(struct tegra_fbdev
> > > *fbdev)
> > > /* Undo the special mapping we made in fbdev probe. */
> > > if (bo && bo->pages) {
> > > vunmap(bo->vaddr);
> > > - bo->vaddr = 0;
> > > + bo->vaddr = NULL;
> > > }
> > >
> > > drm_framebuffer_remove(fbdev->fb);
> > > @@ -412,25 +412,3 @@ void tegra_drm_fb_exit(struct drm_device *drm)
> > > tegra_fbdev_exit(tegra->fbdev);
> > > #endif
> > > }
> > > -
> > > -void tegra_drm_fb_suspend(struct drm_device *drm)
> > > -{
> > > -#ifdef CONFIG_DRM_FBDEV_EMULATION
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - console_lock();
> > > - drm_fb_helper_set_suspend(>fbdev->base, 1);
> > > - console_unlock();
> > > -#endif
> > > -}
> > > -
> > > -void tegra_drm_fb_resume(struct drm_device *drm)
> > > -{
> > > -#ifdef CONFIG_DRM_FBDEV_EMULATION
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - console_lock();
> > > - drm_fb_helper_set_suspend(>fbdev->base, 0);
> > > - console_unlock();
> > > -#endif
> > > -}
> > > --
> > > 1.9.1
> > >
___
dri-devel mailing list
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On 2018/9/18 23:02, Greg KH wrote: > On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: >> Hi, Greg >> >> Can you pick up the patch? > Nope: > $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c > Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) > David Airlie (maintainer:DRM DRIVERS) > dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) > linux-ker...@vger.kernel.org (open list) > > why would I take thi when all of those others are the correct > maintainers? > > Also, you only posted this 1 day ago. Please relax and give people time > and a chance to review your patch. It is not instant. No, I posted the patch a month ago. I have sent a ping. but It do not work. :-( . Thanks, zhong jiang > thanks, > > greg k-h > > . > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 0/5] drm: add support for Cadence MHDP DPI/DP bridge.
Got it. -depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m) +depends on DRM_ROCKCHIP=m +select EXTCON Damian -Original Message- From: Heiko Stuebner Sent: Thursday, September 13, 2018 14:32 To: Damian Kos Cc: David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Andrzej Hajda ; Laurent Pinchart ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Quentin Schulz ; dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-rockc...@lists.infradead.org; Przemyslaw Gaj ; Lukasz Tyrala ; Scott Telford ; Artur Jedrysek ; Piotr Sroka Subject: Re: [PATCH v3 0/5] drm: add support for Cadence MHDP DPI/DP bridge. EXTERNAL MAIL Am Dienstag, 28. August 2018, 12:24:43 CEST schrieb Damian Kos: > Hello! > > This is the series of patches that will add support for the Cadence's > DPI/DP bridge. Please note that this is a preliminary version of the > driver and there will be more patches in the future with updates, fixes and > improvements. > Please keep that in mind when looking at FIXME/TODO/XXX comments. > > Initially, MHDP driver was developed as a DRM bridge driver and was > planed to be placed in drivers/gpu/drm/bridge/mhdp.c. However, there > was already a driver for Cadence's DP controller developed by > RockChip, but that driver uses the different DRM framework and looks like a > part of a bigger system. > Both controllers (including firmware) are quite different internally > (MST/FEC/DSC support, link training done by driver, additional > commands, IRQ's > etc.) but they have similar register map, except for Framer/Streamer > (which is noticeably different), so they appear similar. > > The following patches contain: > - Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and > modifying it a bit (mostly new prefixes for functions and data types) so it > can be used by two, higher level, drivers. > - Modifying existing RockChip's DP driver to use the common code after changes > made to it (use the new cdns_mhdp_device structure and new function names). > - Modifying DRM helpers a bit. Some are required for new driver, some are > updates from DP 1.2 to 1.3 or 1.4. > - Adding documentation for device tree bindings. > - Adding preliminary Cadence DPI/DP bridge driver. > > Some of the things that will be added later on include (but are not > limited > to): > - Support for Cadence SD0801 PHY (PHY's driver should be on the way by > now) > - MST support > - DSC support > - FEC support > - HDCP support with te Kconfig issue in patch5 fixed, this series tested on rk3288 (analogix-dp) and rk3399 (analogix-dp + cadence-dp) Everything seems to work that worked before. Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] headers/README: fix/add link to drm-next
On Tue, Sep 18, 2018 at 04:24:37PM +0100, Eric Engestrom wrote: > Signed-off-by: Eric Engestrom Reviewed-by: Sean Paul > --- > include/drm/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/README b/include/drm/README > index 521630db8b4c52749188..ea2320cc9e7728a9c08b 100644 > --- a/include/drm/README > +++ b/include/drm/README > @@ -71,7 +71,7 @@ Note: One should not do _any_ changes to the files apart > from the steps below. > > In order to update the files do the following: > - Switch to a Linux kernel tree/branch which is not rebased. > -For example: airlied/drm-next > + For example: drm-next (https://cgit.freedesktop.org/drm/drm) > - Install the headers via `make headers_install' to a separate location. > - Copy the drm header[s] + git add + git commit. > - Note: Your commit message must include: > -- > Cheers, > Eric > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] headers/README: fix/add link to drm-next
Signed-off-by: Eric Engestrom --- include/drm/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/README b/include/drm/README index 521630db8b4c52749188..ea2320cc9e7728a9c08b 100644 --- a/include/drm/README +++ b/include/drm/README @@ -71,7 +71,7 @@ Note: One should not do _any_ changes to the files apart from the steps below. In order to update the files do the following: - Switch to a Linux kernel tree/branch which is not rebased. -For example: airlied/drm-next + For example: drm-next (https://cgit.freedesktop.org/drm/drm) - Install the headers via `make headers_install' to a separate location. - Copy the drm header[s] + git add + git commit. - Note: Your commit message must include: -- Cheers, Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Tue, Sep 18, 2018 at 5:02 PM, Greg KH wrote: > On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: >> Hi, Greg >> >> Can you pick up the patch? > > Nope: > $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c > Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) > David Airlie (maintainer:DRM DRIVERS) > dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) > linux-ker...@vger.kernel.org (open list) > > why would I take thi when all of those others are the correct > maintainers? > > Also, you only posted this 1 day ago. Please relax and give people time > and a chance to review your patch. It is not instant. First submission was in August, acked by Shawn, but somehow they forgot to actually push the patch out. I pinged Shawn. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Mon, Aug 27, 2018 at 9:18 AM, Shawn Guo wrote: > On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote: >> for_each_available_child_of_node will get and put the node properly, >> the following of_node_put will lead to the double put. So just >> remove it. >> >> Signed-off-by: zhong jiang > > Acked-by: Shawn Guo Shawn, I'm assuming you'll push this to drm-misc-next? You're the maintainer with commit rights after all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: > Hi, Greg > > Can you pick up the patch? Nope: $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) David Airlie (maintainer:DRM DRIVERS) dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) linux-ker...@vger.kernel.org (open list) why would I take thi when all of those others are the correct maintainers? Also, you only posted this 1 day ago. Please relax and give people time and a chance to review your patch. It is not instant. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #14 from Claude Heiland-Allen (cla...@mathr.co.uk) --- I checked out linux v4.19-rc4 from git, then reverted that commit - no change, display goes blank about 5 seconds into boot. I noticed something else in the dmesg (it was there in 4.19-rc1,rc2,rc3,rc4,rc4 with reverted commit, but not earlier versions): [5.109572] amdgpu: [powerplay] Failed to retrieve minimum clocks. [5.109577] amdgpu: [powerplay] Error in phm_get_clock_info [5.109627] [drm] DM_PPLIB: values for Engine clock [5.109629] [drm] DM_PPLIB: 30 [5.109631] [drm] DM_PPLIB: 60 [5.109632] [drm] DM_PPLIB: 90 [5.109633] [drm] DM_PPLIB: 1145000 [5.109634] [drm] DM_PPLIB: 1215000 [5.109636] [drm] DM_PPLIB: 1257000 [5.109637] [drm] DM_PPLIB: 130 [5.109638] [drm] DM_PPLIB: 1366000 [5.109640] [drm] DM_PPLIB: Validation clocks: [5.109641] [drm] DM_PPLIB:engine_max_clock: 136600 [5.109642] [drm] DM_PPLIB:memory_max_clock: 20 [5.109644] [drm] DM_PPLIB:level : 8 [5.109646] [drm] DM_PPLIB: values for Memory clock [5.109647] [drm] DM_PPLIB: 30 [5.109648] [drm] DM_PPLIB: 100 [5.109649] [drm] DM_PPLIB: 200 [5.109651] [drm] DM_PPLIB: Validation clocks: [5.109652] [drm] DM_PPLIB:engine_max_clock: 136600 [5.109653] [drm] DM_PPLIB:memory_max_clock: 20 [5.109655] [drm] DM_PPLIB:level : 8 [5.124083] [drm] Display Core initialized with v3.1.59! The last (largest) value for "engine clock" and "memory clock" are 10x the validation values for "engine clock max" and "memory clock max". I see in the amd/powerplay sources some values are in units of 10kHz, some in units of 1kHz(?) - maybe a conversion was missed somewhere? Or maybe the printout is totally normal and I know nothing :) The error message common to all kernels with amdgpu.dc=1 since 4.17 is: [5.256378] [drm] Cannot find any crtc or sizes -- 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] drm/tegra: Convert drm_atomic_helper_suspend/resume()
On Wed, Aug 01, 2018 at 01:37:05AM +0530, Souptick Joarder wrote: > convert drm_atomic_helper_suspend/resume() to use > drm_mode_config_helper_suspend/resume(). > > With this conversion, tegra_drm_fb_suspend() and > tegra_drm_fb_resume() wil not be used anymore. > Both of these functions can be removed. > > Also, in tegra_drm struct's member state will not be > used anymore. So this can be removed forever. > > Fixed one sparse warning. > > Signed-off-by: Souptick Joarder > Signed-off-by: Ajit Negi > --- > drivers/gpu/drm/tegra/drm.c | 20 ++-- > drivers/gpu/drm/tegra/drm.h | 4 > drivers/gpu/drm/tegra/fb.c | 24 +--- > 3 files changed, 3 insertions(+), 45 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141635|0 |1 is obsolete|| --- Comment #21 from Michel Dänzer --- Comment on attachment 141635 --> https://bugs.freedesktop.org/attachment.cgi?id=141635 Using libunwind Ransu, please try to get the information from your system the same way Mike did. Looks like he's running into a different issue which only happens using the Xorg modesetting driver. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141633|0 |1 is obsolete|| -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141631|0 |1 is obsolete|| -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #13 from Andrey Arapov (andrey.ara...@nixaid.com) --- Could you please try reverting this commit https://github.com/torvalds/linux/commit/e03fd3f300f6184c1264186a4c815e93bf658abb , rebuilding your kernel and let us know if it fixes your issue? Not sure if your problem is related to mine here https://github.com/Dunedan/mbp-2016-linux/issues/73#issuecomment-422397681 But it has helped in my case. -- 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
[Bug 107946] AMDGPU regression, multi-head not working on 4.18, 4.19RC3, but does on 4.16
https://bugs.freedesktop.org/show_bug.cgi?id=107946 --- Comment #3 from Nicholas Kazlauskas --- Please post an Xorg log along with what distro/desktop environment you're using. It may also help if you can post another 4.19 dmesg log with drm.debug=6 in your bootline. -- 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 107978] [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 Bug ID: 107978 Summary: [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: shtetl...@gmail.com After upgrading to Linux 4.19-rc3 (from 4.18.x), I can't switch to tty anymore, the monitor connected over DisplayPort goes into sleep mode. I see this in dmesg when it happens: [37342.777399] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:922 [37342.777477] WARNING: CPU: 4 PID: 14403 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777478] Modules linked in: uas usb_storage rfcomm ebtable_filter ebtables devlink ip6table_filter ip6_tables iptable_filter cmac bnep arc4 nls_ascii nls_cp437 vfat amdkfd fat snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd btusb btrtl amdgpu btbcm snd_hda_codec_hdmi btintel iwlmvm snd_usb_audio snd_hda_intel bluetooth kvm_amd snd_hda_codec snd_usbmidi_lib wmi_bmof mxm_wmi mac80211 snd_hda_core kvm uvcvideo videobuf2_vmalloc snd_hwdep videobuf2_memops snd_rawmidi jitterentropy_rng videobuf2_v4l2 videobuf2_common snd_seq_device chash iwlwifi irqbypass gpu_sched videodev snd_pcm crct10dif_pclmul ttm crc32_pclmul media drbg snd_timer evdev drm_kms_helper cfg80211 ansi_cprng ghash_clmulni_intel efi_pstore pcspkr drm snd k10temp ecdh_generic soundcore efivars rfkill crc16 sp5100_tco sg ccp [37342.777514] rng_core wmi pcc_cpufreq button acpi_cpufreq nct6775 hwmon_vid parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 xfs btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic hid_generic usbhid hid sd_mod crc32c_intel ahci xhci_pci libahci aesni_intel xhci_hcd aes_x86_64 crypto_simd libata igb cryptd glue_helper nvme usbcore scsi_mod i2c_piix4 i2c_algo_bit nvme_core dca usb_common gpio_amdpt gpio_generic [37342.777542] CPU: 4 PID: 14403 Comm: kworker/4:1 Tainted: GW 4.19.0-rc3-amd64 #1 Debian 4.19~rc3-1~exp1 [37342.777542] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Taichi, BIOS L4.64 04/03/2018 [37342.777558] Workqueue: events drm_mode_rmfb_work_fn [drm] [37342.777615] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777617] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 20 9d b5 c1 e8 64 e6 f0 fe 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [37342.777618] RSP: 0018:a2ae81b9ba20 EFLAGS: 00010297 [37342.777620] RAX: RBX: 000a RCX: [37342.777621] RDX: RSI: 93d74eb166a8 RDI: 93d74eb166a8 [37342.777622] RBP: 93d746439180 R08: R09: 00010200 [37342.777623] R10: 0720072007200720 R11: 0720073207320739 R12: 0bb9 [37342.777624] R13: 51e2 R14: 0001 R15: [37342.777625] FS: () GS:93d74eb0() knlGS: [37342.777626] CS: 0010 DS: ES: CR0: 80050033 [37342.777627] CR2: 558f62bfa9d0 CR3: 0003f2c38000 CR4: 003406e0 [37342.777628] Call Trace: [37342.777695] dce110_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [37342.54] core_link_disable_stream+0x54/0x220 [amdgpu] [37342.777813] dce110_reset_hw_ctx_wrap+0xc1/0x1e0 [amdgpu] [37342.777872] dce110_apply_ctx_to_hw+0x45/0x650 [amdgpu] [37342.777928] ? dc_remove_plane_from_context+0x1fc/0x240 [amdgpu] [37342.777985] dc_commit_state+0x2c6/0x520 [amdgpu] [37342.778047] amdgpu_dm_atomic_commit_tail+0x37a/0xd80 [amdgpu] [37342.778052] ? __wake_up_common_lock+0x89/0xc0 [37342.778054] ? _cond_resched+0x15/0x30 [37342.778056] ? wait_for_completion_timeout+0x3b/0x1a0 [37342.778117] ? amdgpu_dm_atomic_commit_tail+0xd80/0xd80 [amdgpu] [37342.778126] commit_tail+0x3d/0x70 [drm_kms_helper] [37342.778133] drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper] [37342.778148] drm_framebuffer_remove+0x361/0x410 [drm] [37342.778164] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] [37342.778167] process_one_work+0x1a7/0x360 [37342.778169] worker_thread+0x30/0x390 [37342.778171] ? pwq_unbound_release_workfn+0xd0/0xd0 [37342.778173] kthread+0x112/0x130 [37342.778175] ? kthread_bind+0x30/0x30 [37342.778177] ret_from_fork+0x22/0x40 [37342.778179] ---[ end trace 3d987dd66a59ffb4 ]--- OS: Debian testing, kernel 4.19~rc3-1~exp1 GPU: Sapphire Pulse Vega 56. amdgpu firmware: 20180825+dfsg-1 -- You are receiving this mail because: You are the assignee for the
[Bug 107953] Screen Corruption (Bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=107953 --- Comment #2 from Nicholas Kazlauskas --- Thanks for the report. This had a Vega specific fix in mind but I guess it extends to Polaris as well. I would imagine the first patch from this thread should fix your issue (ie. the one that's *not* the dce120 one) https://bugzilla.kernel.org/show_bug.cgi?id=201067 If it doesn't, then you should post your full dmesg and Xorg logs. -- 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 101877] R9 390 with multiple monitors always using highest memory clock
https://bugs.freedesktop.org/show_bug.cgi?id=101877 --- Comment #5 from Alexandre Pereira --- I have a similar problem. I have a Rx 580 with 2 exactly equal monitors. On windows, there is no issue and memory clock is always at 300mhz, except when gaming. When on linux, If using graphical display, memory clock is always MAX. If i am only on the tty's ( text mode only ) I can set it to 300mhz, after changing memory clock pp setting ( echo 1 > pp_mclk_od ). Like the op, drawing 40 watts more power than windows, is very undesirable, besides also running much cooler on windows. Also on windows I never saw any problem whatsoever with it running at minimum 300mhz. -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #7 from SET --- With EXA, sddm login screen does not show up. xf86-video-ati 18.1.0 is in testing branch at Arch repositories. Will test when it'll be available as stable. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #20 from Mike Lothian --- Created attachment 141635 --> https://bugs.freedesktop.org/attachment.cgi?id=141635=edit Using libunwind -- 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 2/2] drm: Fix syncobj handing of schedule() returning 0
After schedule() returns 0, we must do one last check of COND to
determine the reason for the wakeup with 0 jiffies remaining before
reporting the timeout -- otherwise we may lose the signal due to
scheduler delays.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 41 +--
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e254f97fed7d..5bcb3ef9b256 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -672,7 +672,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
- signed long ret;
uint32_t signaled_count, i;
entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
@@ -692,7 +691,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
continue;
} else {
- ret = -EINVAL;
+ timeout = -EINVAL;
goto cleanup_entries;
}
}
@@ -704,12 +703,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
}
}
- /* Initialize ret to the max of timeout and 1. That way, the
-* default return value indicates a successful wait and not a
-* timeout.
-*/
- ret = max_t(signed long, timeout, 1);
-
if (signaled_count == count ||
(signaled_count > 0 &&
!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)))
@@ -760,18 +753,17 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
goto done_waiting;
if (timeout == 0) {
- /* If we are doing a 0 timeout wait and we got
-* here, then we just timed out.
-*/
- ret = 0;
+ timeout = -ETIME;
goto done_waiting;
}
- ret = schedule_timeout(ret);
+ if (signal_pending(current)) {
+ timeout = -ERESTARTSYS;
+ goto done_waiting;
+ }
- if (ret > 0 && signal_pending(current))
- ret = -ERESTARTSYS;
- } while (ret > 0);
+ timeout = schedule_timeout(timeout);
+ } while (1);
done_waiting:
__set_current_state(TASK_RUNNING);
@@ -788,7 +780,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
}
kfree(entries);
- return ret;
+ return timeout;
}
/**
@@ -829,19 +821,16 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_syncobj **syncobjs)
{
signed long timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
- signed long ret = 0;
uint32_t first = ~0;
- ret = drm_syncobj_array_wait_timeout(syncobjs,
-wait->count_handles,
-wait->flags,
-timeout, );
- if (ret < 0)
- return ret;
+ timeout = drm_syncobj_array_wait_timeout(syncobjs,
+wait->count_handles,
+wait->flags,
+timeout, );
+ if (timeout < 0)
+ return timeout;
wait->first_signaled = first;
- if (ret == 0)
- return -ETIME;
return 0;
}
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Use default dma_fence hooks where possible for null syncobj
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 497729202bfe..e254f97fed7d 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -66,20 +66,9 @@ static const char *drm_syncobj_stub_fence_get_name(struct
dma_fence *fence)
return "syncobjstub";
}
-static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
-{
-return !dma_fence_is_signaled(fence);
-}
-
-static void drm_syncobj_stub_fence_release(struct dma_fence *f)
-{
- kfree(f);
-}
static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
.get_driver_name = drm_syncobj_stub_fence_get_name,
.get_timeline_name = drm_syncobj_stub_fence_get_name,
- .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
- .release = drm_syncobj_stub_fence_release,
};
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The THC63LVD1024 is restricted to a pixel clock frequency in the range
> of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> accordingly.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Tested-by: Jacopo Mondi
> ---
> drivers/gpu/drm/bridge/thc63lvd1024.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> index c8b9edd5a7f4..63609ba16b6d 100644
> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -45,6 +45,23 @@ static int thc63_attach(struct drm_bridge *bridge)
> return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> }
>
> +static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + /*
> + * The THC63LVD0124 clock frequency range is 8 to 135 MHz in single-in,
That should be THC63LVD1024.
> + * single-out mode.
For the input clock (that's what we're talking about, right?), that also
applies to single-in/dual-out. Maybe just omit the "single-out" clause?
> Note that the limits depends on the mode and will
> + * need to be adjusted accordingly.
> + */
I don't quite understand. Does that refer to the THC63 mode, or the DRM mode?
> + if (mode->clock < 8000)
> + return MODE_CLOCK_LOW;
> +
> + if (mode->clock > 135000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static void thc63_enable(struct drm_bridge *bridge)
> {
> struct thc63_dev *thc63 = to_thc63(bridge);
> @@ -77,6 +94,7 @@ static void thc63_disable(struct drm_bridge *bridge)
>
> static const struct drm_bridge_funcs thc63_bridge_func = {
> .attach = thc63_attach,
> + .mode_valid = thc63_mode_valid,
> .enable = thc63_enable,
> .disable = thc63_disable,
> };
> --
> Regards,
>
> Laurent Pinchart
>
CU
Uli
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops
> = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/16] dt-bindings: display: renesas: du: Document r8a77990 bindings
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > Document the E3 (r8a77990) SoC in the R-Car DU bindings. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt > b/Documentation/devicetree/bindings/display/renesas,du.txt > index caae2348a292..9de67be632d1 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -16,6 +16,7 @@ Required Properties: > - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU > - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU > +- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU > - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU > >- reg: the memory-mapped I/O registers base address and length > @@ -63,6 +64,7 @@ corresponding to each DU output. > R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 - > R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - > R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - - > + R8A77990 (R-Car E3)DPAD 0 LVDS 0 LVDS 1 - > R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 - > > Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/16] drm: rcar-du: lvds: D3/E3 support
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parameters manually.
> - The PLL uses external clocks as inputs, which need to be retrieved
> from DT.
> - In addition to the different PLL setup, the startup sequence has
> changed *again* (seems someone had trouble making his/her mind).
>
> Supporting all this requires DT bindings extensions for external clocks,
> brand new PLL setup code, and a few quirks to handle the differences in
> the startup sequence.
>
> The implementation doesn't support all hardware features yet, namely
>
> - Using the LV[01] clocks generated by the CPG as PLL input.
> - Providing the LVDS PLL clock to the DU for use with the RGB output.
>
> Those features can be added later when the need will arise.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
> ---
> Changes since v1:
>
> - Don't compile-out debug code based on DEBUG and CONFIG_DYNAMIC_DEBUG
> - Test all three input clocks (DOTCLKIN[01] and EXTAL) and pick the best
> one
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 355
> +++
> drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 +++-
> 2 files changed, 351 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index ce0eb68c3416..23e7743144c8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -24,6 +24,8 @@
>
> #include "rcar_lvds_regs.h"
>
> +struct rcar_lvds;
> +
> /* Keep in sync with the LVDCR0.LVMD hardware register values. */
> enum rcar_lvds_mode {
> RCAR_LVDS_MODE_JEIDA = 0,
> @@ -31,14 +33,16 @@ enum rcar_lvds_mode {
> RCAR_LVDS_MODE_VESA = 4,
> };
>
> -#define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3
> inverted */
> -#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1) /* LVDPLLCR has gen2 layout */
> -#define RCAR_LVDS_QUIRK_GEN3_LVEN (1 << 2) /* LVEN bit needs to be set */
> - /* on R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_LANESBIT(0) /* LVDS lanes 1 and 3
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN3_LVENBIT(1) /* LVEN bit needs to be set on
> R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_PWD BIT(2) /* PWD bit available (all of
> Gen3 but E3) */
> +#define RCAR_LVDS_QUIRK_EXT_PLL BIT(3) /* Has extended PLL */
> +#define RCAR_LVDS_QUIRK_DUAL_LINKBIT(4) /* Supports dual-link operation
> */
>
> struct rcar_lvds_device_info {
> unsigned int gen;
> unsigned int quirks;
> + void (*pll_setup)(struct rcar_lvds *lvds, unsigned int freq);
> };
>
> struct rcar_lvds {
> @@ -52,7 +56,11 @@ struct rcar_lvds {
> struct drm_panel *panel;
>
> void __iomem *mmio;
> - struct clk *clock;
> + struct {
> + struct clk *mod;/* CPG module clock */
> + struct clk *extal; /* External clock */
> + struct clk *dotclkin[2];/* External DU clocks */
> + } clocks;
> bool enabled;
>
> struct drm_display_mode display_mode;
> @@ -128,33 +136,212 @@ static const struct drm_connector_funcs
> rcar_lvds_conn_funcs = {
> };
>
> /*
> -
> - * Bridge
> + * PLL Setup
> */
>
> -static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen2(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 39000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> - else if (freq < 61000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> - else if (freq < 121000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> + u32 val;
> +
> + if (freq < 3900)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> + else if (freq < 6100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> + else if (freq < 12100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> else
> - return LVDPLLCR_PLLDLYCNT_150M;
> + val = LVDPLLCR_PLLDLYCNT_150M;
> +
> + rcar_lvds_write(lvds, LVDPLLCR, val);
> }
>
> -static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen3(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 42000)
> - return LVDPLLCR_PLLDIVCNT_42M;
> - else if (freq < 85000)
> - return LVDPLLCR_PLLDIVCNT_85M;
> - else if (freq < 128000)
> - return
[RESEND 1/5] drm/mxsfb: Move axi clk enable/disable to crtc enable/disable
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for symmetry.
This shouldn't have any functional effect.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 0abe77675b76..e4fcbb65b969 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -127,11 +127,10 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
u32 reg;
if (mxsfb->clk_disp_axi)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
- mxsfb_enable_axi_clk(mxsfb);
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
/* Enable the SYNC signals first, then the DMA engine */
@@ -157,12 +156,10 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
reg = readl(mxsfb->base + LCDC_VDCTRL4);
reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
writel(reg, mxsfb->base + LCDC_VDCTRL4);
- mxsfb_disable_axi_clk(mxsfb);
-
clk_disable_unprepare(mxsfb->clk);
if (mxsfb->clk_disp_axi)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
@@ -206,11 +203,10 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/*
* It seems, you can't re-program the controller if it is still
* running. This may lead to shifted pictures (FIFO issue?), so
* first stop the controller and drain its FIFOs.
*/
- mxsfb_enable_axi_clk(mxsfb);
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb->base);
if (err)
return;
@@ -267,23 +263,23 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
mxsfb->base + LCDC_VDCTRL3);
writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
mxsfb->base + LCDC_VDCTRL4);
-
- mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
mxsfb_disable_controller(mxsfb);
+ mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 4/5] drm/mxsfb: Add PM_SLEEP support
Since power to the lcdif block can be lost on suspend implement
PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
the current mode.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 68d79f5dc0d3..d797dfd40d98 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_dev_unref(drm);
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mxsfb_suspend(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_suspend(drm);
+}
+
+static int mxsfb_resume(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_resume(drm);
+}
+#endif
+
+static const struct dev_pm_ops mxsfb_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mxsfb_suspend, mxsfb_resume)
+};
+
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
.name = "mxsfb",
.of_match_table = mxsfb_dt_ids,
+ .pm = _pm_ops,
},
};
module_platform_driver(mxsfb_platform_driver);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: change function signature to pass full range
On Fri, Apr 13, 2018 at 9:59 AM Huang Rui wrote:
> On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
> > In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
> > 255 is done. Since it is always false, change the signature of this
> > function to use an `int` instead, which match the type used in caller:
> > `radeon_atom_hw_i2c_xfer`.
> >
> > Fix the following warning triggered with W=1:
> >
> > CC [M] drivers/gpu/drm/radeon/atombios_i2c.o
> > drivers/gpu/drm/radeon/atombios_i2c.c: In function
> ‘radeon_process_i2c_ch’:
> > drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is
> always false due to limited range of data type [-Wtype-limits]
> >if (num > ATOM_MAX_HW_I2C_READ) {
> >^
> >
> > Signed-off-by: Mathieu Malaterre
>
> Reviewed-by: Huang Rui
>
>
Any chance to be included in the next pull request ? thanks
> > ---
> > drivers/gpu/drm/radeon/atombios_i2c.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c
> b/drivers/gpu/drm/radeon/atombios_i2c.c
> > index 4157780585a0..9022e9af11a0 100644
> > --- a/drivers/gpu/drm/radeon/atombios_i2c.c
> > +++ b/drivers/gpu/drm/radeon/atombios_i2c.c
> > @@ -35,7 +35,7 @@
> >
> > static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
> >u8 slave_addr, u8 flags,
> > - u8 *buf, u8 num)
> > + u8 *buf, int num)
> > {
> > struct drm_device *dev = chan->dev;
> > struct radeon_device *rdev = dev->dev_private;
> > --
> > 2.11.0
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT
在 2018-09-17一的 16:54 +0200，Maxime Ripard写道：
> On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> > Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime
> > Ripard
> > napisal(a):
> > > On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> > > > The R40 HDMI PHY seems to be different to the A64 one, the A64
> > > > one
> > > > has no input mux, but the R40 one has.
> > > >
> > > > Drop the A64 fallback compatible from the HDMI PHY node in R40
> > > > DT.
> > > >
> > > > Signed-off-by: Icenowy Zheng
> > > > ---
> > > >
> > > > arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
> > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > b/arch/arm/boot/dts/sun8i-r40.dtsi index
> > > > ffd9f00f74a4..5f547c161baf
> > > > 100644
> > > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > @@ -800,8 +800,7 @@
> > > >
> > > > };
> > > >
> > > > hdmi_phy: hdmi-phy@1ef {
> > > >
> > > > - compatible = "allwinner,sun8i-r40-hdmi-
> > > > phy",
> > > > -"allwinner,sun50i-a64-
> > > > hdmi-phy";
> > > > + compatible = "allwinner,sun8i-r40-hdmi-
> > > > phy";
> > >
> > > If you could use the A64 phy before, you can still use it now.
> >
> > Not exactly. Given that we don't know how to switch between HDMI
> > PHY clock
> > parents on A64 (if it is actually connected at all, there is no
> > information
> > about that in manual and AW didn't answered our questions, despite
> > asking them
> > through different channels), A64 compatible will be associated with
> > quirk,
> > which will tell that only one clock parent is usable.
> >
> > However, R40 HDMI PHY has definetly two clock parents, as it was
> > tested by me
> > and Icenowy and we know how to switch between them without issues.
> > Technically, we could have A64 compatible there, but that would
> > mean only
> > single PHY parent is considered instead of two.
>
> The DT change above would mean that you can't operate the R40 phy in
> the same way than the A64's. From what you're telling me now, this
> isn't exactly what is going on: you can operate the R40 phy just like
> the A64: with a single PLL instead of two. You operate in a degraded
> and non-optimal mode, but it still works.
The status of R40 HDMI PHY input mux is not determined when use A64
driver, which makes it not working when the bootloader initializes it
to use the second PLL (the A64 driver will assume the parent is the
first PLL).
>
> And it's exactly what the DT is already saying.
>
> Maxime
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > supporting VSP and FCP.
> >
> > Signed-off-by: Laurent Pinchart
> > Tested-by: Jacopo Mondi
> > ---
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> > ++
> > 1 file changed, 167 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > index abb14af76c0e..600074ca3ee5 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -537,6 +537,173 @@
> > resets = < 408>;
> > };
>
> These nodes should be placed after the gic to preserve the sorting
> of nodes by bus address and then IP block.
>
> > + vspb0: vsp@fe96 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe96 0 0x8000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 626>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 626>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvb0: fcp@fe96f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe96f000 0 0x200>;
> > + clocks = < CPG_MOD 607>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 607>;
> > + iommus = <_vp0 5>;
> > + };
> > +
> > + vspi0: vsp@fe9a {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe9a 0 0x8000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 622>;
>
> R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> that this clock should be < CPG_MOD 631>. The clock above is
> (according to my reading of the documentation) correctly
> used for vspd1 below.
>
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 631>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvi0: fcp@fe9af000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe9af000 0 0x200>;
> > + clocks = < CPG_MOD 611>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 611>;
> > + iommus = <_vp0 8>;
> > + };
> > +
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x7000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 623>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 623>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvd0: fcp@fea27000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea27000 0 0x200>;
> > + clocks = < CPG_MOD 603>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 603>;
> > + iommus = <_vi0 8>;
> > + };
> > +
> > + vspd1: vsp@fea28000 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea28000 0 0x7000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 622>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 622>;
> > + renesas,fcp = <>;
> > + };
> > +
> > + fcpvd1: fcp@fea2f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea2f000 0 0x200>;
> > + clocks = < CPG_MOD 602>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 602>;
> > + iommus = <_vi0 9>;
> > + };
> > +
> > + du: display@feb0 {
> > + compatible = "renesas,du-r8a77990";
> > + reg = <0 0xfeb0 0 0x8>;
> > + interrupts = ,
> > +;
> > + clocks = < CPG_MOD 724>,
> > +< CPG_MOD 723>;
> > + clock-names = "du.0", "du.1";
> > + vsps = < 0 0>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +
[RESEND 5/5] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core ensure atomic_plane_update is only called while
the crtc is active. This avoids having to keep track of "enabled" bits
inside the mxsfb driver.
This also requires handling the vblank event for disable from
mxsfb_pipe_disable.
Signed-off-by: Leonard Crestez
Suggested-by: Stefan Agner
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d797dfd40d98..5777e730085b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -96,10 +96,14 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
+static const struct drm_mode_config_helper_funcs mxsfb_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
@@ -113,15 +117,25 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
struct drm_device *drm = pipe->plane.dev;
+ struct drm_crtc *crtc = >crtc;
+ struct drm_pending_vblank_event *event;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
pm_runtime_put_sync(drm->dev);
+
+ spin_lock_irq(>event_lock);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+ drm_crtc_send_vblank_event(crtc, event);
+ }
+ spin_unlock_irq(>event_lock);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
@@ -232,10 +246,11 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.min_width = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
drm->mode_config.max_width = MXSFB_MAX_XRES;
drm->mode_config.max_height = MXSFB_MAX_YRES;
drm->mode_config.funcs = _mode_config_funcs;
+ drm->mode_config.helper_private = _mode_config_helpers;
drm_mode_config_reset(drm);
pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
Adding lcdif nodes to a power domain currently doesn't work, it results in black/corrupted screens or hangs. While the driver does enable runtime pm it does not deal correctly with the block being unpowered. --- All patches in this series have review tags from a while ago and I tested them again on top of next-20180913. No changes since last version: https://lkml.org/lkml/2018/8/27/299 This series stalled so I reached out to Marek on IRC and he was surprised to be listed as maintainer and asked me to resend and add Daniel Vetter. Perhaps it would help to clarify that the pengutronix people should feel free to push patches in this area? Right now drm/imx is mostly for IPUv3 but there are other display output paths on imx, such as the LCDIF supported by this driver. This LCDIF block is included on imx8 so still quite relevant. Leonard Crestez (5): drm/mxsfb: Move axi clk enable/disable to crtc enable/disable drm/mxsfb: Fix initial corrupt frame when activating display drm/mxsfb: Add pm_runtime calls to pipe_enable/disable drm/mxsfb: Add PM_SLEEP support drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ 2 files changed, 74 insertions(+), 19 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()
Hi Inki,
On Tue, Sep 11, 2018 at 2:06 PM Souptick Joarder wrote:
>
> On Thu, Aug 2, 2018 at 9:12 PM Souptick Joarder wrote:
> >
> > convert drm_atomic_helper_suspend/resume() to use
> > drm_mode_config_helper_suspend/resume().
> >
> > exynos_drm_fbdev_suspend/resume can be removed
> > as drm_mode_config_helper_suspend/resume has
> > implement the same in generic way.
> >
> > Remove suspend_state from exynos_drm_private
> > struct as it is no more useful.
> >
> > Signed-off-by: Ajit Negi
> > Signed-off-by: Souptick Joarder
> > Tested-by: Marek Szyprowski
>
> Can we get this patch in queue for 4.20 ? Not yet available in linux-next.
Is this patch queued for 4.20 ?
> > ---
> > v2: Address Inki Dae's comment. Remove ret variable
> > from both suspend/resume function.
> >
> > v3: Tested by Marek. Updated the change log.
> >
> > v4: removing the return as exynos_drm_resume()
> > now returns void.
> >
> > drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 ++
> > drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 17 -
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 --
> > 4 files changed, 2 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index b599f74..6f76baf 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -149,37 +149,15 @@ static void exynos_drm_postclose(struct drm_device
> > *dev, struct drm_file *file)
> > static int exynos_drm_suspend(struct device *dev)
> > {
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > - struct exynos_drm_private *private;
> > -
> > - if (!drm_dev)
> > - return 0;
> > -
> > - private = drm_dev->dev_private;
> > -
> > - drm_kms_helper_poll_disable(drm_dev);
> > - exynos_drm_fbdev_suspend(drm_dev);
> > - private->suspend_state = drm_atomic_helper_suspend(drm_dev);
> > - if (IS_ERR(private->suspend_state)) {
> > - exynos_drm_fbdev_resume(drm_dev);
> > - drm_kms_helper_poll_enable(drm_dev);
> > - return PTR_ERR(private->suspend_state);
> > - }
> >
> > - return 0;
> > + return drm_mode_config_helper_suspend(drm_dev);
> > }
> >
> > static void exynos_drm_resume(struct device *dev)
> > {
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > - struct exynos_drm_private *private;
> > -
> > - if (!drm_dev)
> > - return;
> >
> > - private = drm_dev->dev_private;
> > - drm_atomic_helper_resume(drm_dev, private->suspend_state);
> > - exynos_drm_fbdev_resume(drm_dev);
> > - drm_kms_helper_poll_enable(drm_dev);
> > + drm_mode_config_helper_resume(drm_dev);
> > }
> >
> > static const struct dev_pm_ops exynos_drm_pm_ops = {
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index c737c4b..7349e7c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -195,7 +195,6 @@ struct drm_exynos_file_private {
> > */
> > struct exynos_drm_private {
> > struct drm_fb_helper *fb_helper;
> > - struct drm_atomic_state *suspend_state;
> >
> > struct device *g2d_dev;
> > struct device *dma_dev;
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > index 132dd52..918dd2c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -270,20 +270,3 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
> > private->fb_helper = NULL;
> > }
> >
> > -void exynos_drm_fbdev_suspend(struct drm_device *dev)
> > -{
> > - struct exynos_drm_private *private = dev->dev_private;
> > -
> > - console_lock();
> > - drm_fb_helper_set_suspend(private->fb_helper, 1);
> > - console_unlock();
> > -}
> > -
> > -void exynos_drm_fbdev_resume(struct drm_device *dev)
> > -{
> > - struct exynos_drm_private *private = dev->dev_private;
> > -
> > - console_lock();
> > - drm_fb_helper_set_suspend(private->fb_helper, 0);
> > - console_unlock();
> > -}
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > index b338472..6840b6a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > @@ -19,8 +19,6 @@
> >
> > int exynos_drm_fbdev_init(struct drm_device *dev);
> > void exynos_drm_fbdev_fini(struct drm_device *dev);
> > -void exynos_drm_fbdev_suspend(struct drm_device *drm);
> > -void exynos_drm_fbdev_resume(struct drm_device *drm);
> >
> > #else
> >
> > @@ -39,14 +37,6 @@ static inline void exynos_drm_fbdev_restore_mode(struct
> > drm_device
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> supporting VSP and FCP.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> ++
> 1 file changed, 167 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> index abb14af76c0e..600074ca3ee5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -537,6 +537,173 @@
> resets = < 408>;
> };
These nodes should be placed after the gic to preserve the sorting
of nodes by bus address and then IP block.
> + vspb0: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 626>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 626>;
> + renesas,fcp = <>;
> + };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = < CPG_MOD 607>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 607>;
> + iommus = <_vp0 5>;
> + };
> +
> + vspi0: vsp@fe9a {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9a 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
that this clock should be < CPG_MOD 631>. The clock above is
(according to my reading of the documentation) correctly
used for vspd1 below.
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 631>;
> + renesas,fcp = <>;
> + };
> +
> + fcpvi0: fcp@fe9af000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe9af000 0 0x200>;
> + clocks = < CPG_MOD 611>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 611>;
> + iommus = <_vp0 8>;
> + };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x7000>;
> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 603>;
> + iommus = <_vi0 8>;
> + };
> +
> + vspd1: vsp@fea28000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x7000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 622>;
> + renesas,fcp = <>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = < CPG_MOD 602>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 602>;
> + iommus = <_vi0 9>;
> + };
> +
> + du: display@feb0 {
> + compatible = "renesas,du-r8a77990";
> + reg = <0 0xfeb0 0 0x8>;
> + interrupts = ,
> + ;
> + clocks = < CPG_MOD 724>,
> + < CPG_MOD 723>;
> + clock-names = "du.0", "du.1";
> + vsps = < 0 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du_out_rgb: endpoint {
> + };
> +
Re: [PATCH v2 03/16] dt-bindings: display: renesas: lvds: Add EXTAL and DU_DOTCLKIN clocks
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > On the D3 and E3 SoCs, the LVDS encoder can derive its internal pixel > clock from an externally supplied clock, either through the EXTAL pin or > through one of the DU_DOTCLKINx pins. Add corresponding clocks to the DT > bindings. > > To retain backward compatibility with DT that don't specify the > clock-names property, the functional clock must always be specified > first, and the clock-names property is optional when only the functional > clock is specified. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Changes since v1: > > - Clarified wording > --- > .../devicetree/bindings/display/bridge/renesas,lvds.txt | 12 > +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > index 13af7e2ac7e8..3aeb0ec06fd0 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > @@ -19,7 +19,17 @@ Required properties: >- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders > > - reg: Base address and length for the memory-mapped registers > -- clocks: A phandle + clock-specifier pair for the functional clock > +- clocks: A list of phandles + clock-specifier pairs, one for each entry in > + the clock-names property. > +- clock-names: Name of the clocks. This property is model-dependent. > + - The functional clock, which mandatory for all models, shall be listed > +first, and shall be named "fck". > + - On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or > +DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must > be > +named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN > +numerical index. > + - When the clocks property only contains the functional clock, the > +clock-names property may be omitted. > - resets: A phandle + reset specifier for the module reset > > Required nodes: Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > > supporting VSP and FCP.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > Tested-by: Jacopo Mondi
> > > ---
> > >
> > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +
> > > 1 file changed, 167 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> > > abb14af76c0e..600074ca3ee5 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > @@ -537,6 +537,173 @@
> > > resets = < 408>;
> > > };
> >
> > These nodes should be placed after the gic to preserve the sorting
> > of nodes by bus address and then IP block.
>
> Aren't they already ? :-)
Git didn't seem to think so. But its not a big deal,
I can fix this up locally.
> > > + vspb0: vsp@fe96 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe96 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 626>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 626>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvb0: fcp@fe96f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe96f000 0 0x200>;
> > > + clocks = < CPG_MOD 607>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 607>;
> > > + iommus = <_vp0 5>;
> > > + };
> > > +
> > > + vspi0: vsp@fe9a {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe9a 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 622>;
> >
> > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > that this clock should be < CPG_MOD 631>. The clock above is
> > (according to my reading of the documentation) correctly
> > used for vspd1 below.
>
> Bad copy and paste, thank you for pointing it out, it will be fixed in v3.
>
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 631>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvi0: fcp@fe9af000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe9af000 0 0x200>;
> > > + clocks = < CPG_MOD 611>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 611>;
> > > + iommus = <_vp0 8>;
> > > + };
> > > +
> > > + vspd0: vsp@fea2 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea2 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 623>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 623>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvd0: fcp@fea27000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea27000 0 0x200>;
> > > + clocks = < CPG_MOD 603>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 603>;
> > > + iommus = <_vi0 8>;
> > > + };
> > > +
> > > + vspd1: vsp@fea28000 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea28000 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 622>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 622>;
> > > + renesas,fcp = <>;
> > > + };
> > > +
> > > + fcpvd1: fcp@fea2f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea2f000 0 0x200>;
> > > + clocks = < CPG_MOD 602>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 602>;
> > > + iommus = <_vi0 9>;
> > > + };
> > > +
> > > + du: display@feb0 {
> > > + compatible = "renesas,du-r8a77990";
> > > + reg = <0 0xfeb0 0 0x8>;
> > > + interrupts = ,
> > > + ;
> > > + clocks = < CPG_MOD 724>,
> > > + < CPG_MOD 723>;
> > > +
Re: [PATCH v2 12/16] arm64: dts: renesas: r8a77990: Add I2C device nodes
On Fri, Sep 14, 2018 at 12:10:42PM +0300, Laurent Pinchart wrote:
> From: Takeshi Kihara
>
> Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> tree.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> Tested-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 123
> ++
> 1 file changed, 123 insertions(+)
I believe this duplicates the following patch already queued-up for
v4.20.
Fixes: bc011dfa3065 ("arm64: dts: renesas: r8a77990: Add I2C device nodes")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 3/5] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..68d79f5dc0d3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -101,23 +101,27 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
+ pm_runtime_get_sync(drm->dev);
drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
+ pm_runtime_put_sync(drm->dev);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
On Mon, 2018-09-17 at 15:16 -0400, Sean Paul wrote: > On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote: > > Adding lcdif nodes to a power domain currently doesn't work, it results > > in black/corrupted screens or hangs. While the driver does enable > > runtime pm it does not deal correctly with the block being unpowered. > > > > This series stalled so I reached out to Marek on IRC and he was > > surprised to be listed as maintainer > > Hopefully not too surprised since Marek added themself to MAINTAINERS when > adding the driver :-) > > I suppose we should probably move this to drm-misc since it qualifies as a > "small driver" and needs a home. Looking through git history shows the last > mxsfb-specific change was back in 02/17. Everything else has been drm-wide > refactors. Thoughts? > > Marek/Leonard: Care to sign up to be listed as a reviewers? Since my knowledge of drm is very basic: no thanks. Since this is an imx driver it would make a lot of sense to group this together with the rest of drm/imx somehow. -- Regards, Leonard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 2/5] drm/mxsfb: Fix initial corrupt frame when activating display
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez
Tested-by: Philipp Zabel
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 45 +-
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e4fcbb65b969..24b1f0c1432e 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -191,10 +191,25 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
return ret;
return clear_poll_bit(reset_addr, MODULE_CLKGATE);
}
+static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
+ struct drm_gem_cma_object *gem;
+
+ if (!fb)
+ return 0;
+
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ if (!gem)
+ return 0;
+
+ return gem->paddr;
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
@@ -267,12 +282,22 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
mxsfb->base + LCDC_VDCTRL4);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ dma_addr_t paddr;
+
mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
+
+ /* Write cur_buf as well to avoid an initial corrupt frame */
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ }
+
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
@@ -283,16 +308,12 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
struct drm_simple_display_pipe *pipe = >pipe;
struct drm_crtc *crtc = >crtc;
- struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_pending_vblank_event *event;
- struct drm_gem_cma_object *gem;
-
- if (!crtc)
- return;
+ dma_addr_t paddr;
spin_lock_irq(>dev->event_lock);
event = crtc->state->event;
if (event) {
crtc->state->event = NULL;
@@ -303,14 +324,12 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
drm_crtc_send_vblank_event(crtc, event);
}
}
spin_unlock_irq(>dev->event_lock);
- if (!fb)
- return;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
-
- mxsfb_enable_axi_clk(mxsfb);
- writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ mxsfb_enable_axi_clk(mxsfb);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ mxsfb_disable_axi_clk(mxsfb);
+ }
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/24] powerpc/mm: don't use _PAGE_EXEC for calling hash_preload()
Christophe Leroy writes:
> The 'access' parameter of hash_preload() is either 0 or _PAGE_EXEC.
> Among the two versions of hash_preload(), only the PPC64 one is
> doing something with this 'access' parameter.
>
> In order to remove the use of _PAGE_EXEC outside platform code,
> 'access' parameter is replaced by 'is_exec' which will be either
> true of false, and the PPC64 version of hash_preload() creates
> the access flag based on 'is_exec'.
>
Reviewed-by: Aneesh Kumar K.V
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/mm/hash_utils_64.c | 3 ++-
> arch/powerpc/mm/mem.c | 9 +
> arch/powerpc/mm/mmu_decl.h | 2 +-
> arch/powerpc/mm/pgtable_32.c| 2 +-
> arch/powerpc/mm/ppc_mmu_32.c| 2 +-
> 5 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index f23a89d8e4ce..b8ce0e8cc608 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1482,7 +1482,7 @@ static bool should_hash_preload(struct mm_struct *mm,
> unsigned long ea)
> #endif
>
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> int hugepage_shift;
> unsigned long vsid;
> @@ -1490,6 +1490,7 @@ void hash_preload(struct mm_struct *mm, unsigned long
> ea,
> pte_t *ptep;
> unsigned long flags;
> int rc, ssize, update_flags = 0;
> + unsigned long access = _PAGE_PRESENT | _PAGE_READ | (is_exec ?
> _PAGE_EXEC : 0);
>
> BUG_ON(REGION_ID(ea) != USER_REGION_ID);
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 31bd9b53c358..0ba0cdb3f759 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -507,7 +507,8 @@ void update_mmu_cache(struct vm_area_struct *vma,
> unsigned long address,
>* We don't need to worry about _PAGE_PRESENT here because we are
>* called with either mm->page_table_lock held or ptl lock held
>*/
> - unsigned long access, trap;
> + unsigned long trap;
> + bool is_exec;
>
> if (radix_enabled()) {
> prefetch((void *)address);
> @@ -529,16 +530,16 @@ void update_mmu_cache(struct vm_area_struct *vma,
> unsigned long address,
> trap = current->thread.regs ? TRAP(current->thread.regs) : 0UL;
> switch (trap) {
> case 0x300:
> - access = 0UL;
> + is_exec = false;
> break;
> case 0x400:
> - access = _PAGE_EXEC;
> + is_exec = true;
> break;
> default:
> return;
> }
>
> - hash_preload(vma->vm_mm, address, access, trap);
> + hash_preload(vma->vm_mm, address, is_exec, trap);
> #endif /* CONFIG_PPC_STD_MMU */
> #if (defined(CONFIG_PPC_BOOK3E_64) || defined(CONFIG_PPC_FSL_BOOK3E)) \
> && defined(CONFIG_HUGETLB_PAGE)
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index e5d779eed181..dd7f9b951d25 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -82,7 +82,7 @@ static inline void _tlbivax_bcast(unsigned long address,
> unsigned int pid,
> #else /* CONFIG_PPC_MMU_NOHASH */
>
> extern void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap);
> + bool is_exec, unsigned long trap);
>
>
> extern void _tlbie(unsigned long address);
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 0bbc7b7d8a05..01f348938328 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -261,7 +261,7 @@ static void __init __mapin_ram_chunk(unsigned long
> offset, unsigned long top)
> map_kernel_page(v, p, ktext ? PAGE_KERNEL_TEXT : PAGE_KERNEL);
> #ifdef CONFIG_PPC_STD_MMU_32
> if (ktext)
> - hash_preload(_mm, v, 0, 0x300);
> + hash_preload(_mm, v, false, 0x300);
> #endif
> v += PAGE_SIZE;
> p += PAGE_SIZE;
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index bea6c544e38f..38a793bfca37 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -163,7 +163,7 @@ void __init setbat(int index, unsigned long virt,
> phys_addr_t phys,
> * Preload a translation in the hash table
> */
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> pmd_t *pmd;
>
> --
> 2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/16] dt-bindings: display: renesas: lvds: Document r8a77990 bindings
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > The E3 (r8a77990) supports two LVDS channels. Extend the binding to > support them. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > index 5a4e379bb414..13af7e2ac7e8 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > @@ -15,6 +15,7 @@ Required properties: >- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders >- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders >- "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders > + - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders >- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders > > - reg: Base address and length for the memory-mapped registers Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Mike Lothian changed: What|Removed |Added Attachment #141632|0 |1 is obsolete|| --- Comment #19 from Mike Lothian --- Created attachment 141633 --> https://bugs.freedesktop.org/attachment.cgi?id=141633=edit Report of amdgpu:* I've repeated but using -e amdgpu:* -- 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
