[PATCH v3 2/3] etnaviv: add permon support
Query all domains and their signals and provide it this information
via struct etna_perfmon and the corresponding api functions.
v2:
- code style changes
- etna_perfmon_create(..): add missing clean up in error case
Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
---
etnaviv/Makefile.sources | 1 +
etnaviv/etnaviv-symbol-check | 4 +
etnaviv/etnaviv_drmif.h | 11 +++
etnaviv/etnaviv_perfmon.c| 189 +++
etnaviv/etnaviv_priv.h | 21 +
5 files changed, 226 insertions(+)
create mode 100644 etnaviv/etnaviv_perfmon.c
diff --git a/etnaviv/Makefile.sources b/etnaviv/Makefile.sources
index 52580567..0eb73783 100644
--- a/etnaviv/Makefile.sources
+++ b/etnaviv/Makefile.sources
@@ -3,6 +3,7 @@ LIBDRM_ETNAVIV_FILES := \
etnaviv_gpu.c \
etnaviv_bo.c \
etnaviv_bo_cache.c \
+ etnaviv_perfmon.c \
etnaviv_pipe.c \
etnaviv_cmd_stream.c \
etnaviv_drm.h \
diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index 0e2030e4..bd95b459 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -42,6 +42,10 @@ etna_cmd_stream_flush
etna_cmd_stream_flush2
etna_cmd_stream_finish
etna_cmd_stream_reloc
+etna_perfmon_create
+etna_perfmon_del
+etna_perfmon_get_dom_by_name
+etna_perfmon_get_sig_by_name
EOF
done)
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 87704acd..949b9b62 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -35,6 +35,9 @@ struct etna_pipe;
struct etna_gpu;
struct etna_device;
struct etna_cmd_stream;
+struct etna_perfmon;
+struct etna_perfmon_domain;
+struct etna_perfmon_signal;
enum etna_pipe_id {
ETNA_PIPE_3D = 0,
@@ -190,4 +193,12 @@ struct etna_reloc {
void etna_cmd_stream_reloc(struct etna_cmd_stream *stream, const struct
etna_reloc *r);
+/* performance monitoring functions:
+ */
+
+struct etna_perfmon *etna_perfmon_create(struct etna_pipe *pipe);
+void etna_perfmon_del(struct etna_perfmon *perfmon);
+struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct etna_perfmon
*pm, const char *name);
+struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct
etna_perfmon_domain *dom, const char *name);
+
#endif /* ETNAVIV_DRMIF_H_ */
diff --git a/etnaviv/etnaviv_perfmon.c b/etnaviv/etnaviv_perfmon.c
new file mode 100644
index ..aa5130a6
--- /dev/null
+++ b/etnaviv/etnaviv_perfmon.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2017 Etnaviv Project
+ * Copyright (C) 2017 Zodiac Inflight Innovations
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Christian Gmeiner
+ */
+
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#include "etnaviv_priv.h"
+
+static int etna_perfmon_query_signals(struct etna_perfmon *pm, struct
etna_perfmon_domain *dom)
+{
+ struct etna_device *dev = pm->pipe->gpu->dev;
+ struct drm_etnaviv_pm_signal req = {
+ .pipe = pm->pipe->id,
+ .domain = dom->id
+ };
+
+ do {
+ struct etna_perfmon_signal *sig;
+ int ret;
+
+ ret = drmCommandWriteRead(dev->fd, DRM_ETNAVIV_PM_QUERY_SIG,
&req, sizeof(req));
+ if (ret)
+ break;
+
+ sig = calloc(1, sizeof(*sig));
+ if (!sig)
+ return -ENOMEM;
+
+ INFO_MSG("perfmon signal:");
+ INFO_MSG("id = %d", req.id);
+ INFO_MSG("name = %s", req.name);
+
+ sig->domain = dom;
+ sig->signal = req.id;
+ strncpy(sig->name, req.name, sizeof(sig->name));
+ list_addtail(&sig->head, &dom->signals);
+ } while (req.iter != 0x);
+
+ return 0;
+}
+
+static int etna_perfmon_query_domains(struct etna_perfmon *pm)
+{
+ struct etna_device
[PATCH v3 0/3] perfmon support
Add some basic functions to query performance monitor domains and signals. Also add support to submit performance monitor requests (pmrs). There is only one small change in v3 compared to v2. We mark perfmon bos as RW now. Christian Gmeiner (3): etnaviv: sync uapi header etnaviv: add permon support etnaviv: support performance monitor requests etnaviv/Makefile.sources | 1 + etnaviv/etnaviv-symbol-check | 5 ++ etnaviv/etnaviv_cmd_stream.c | 20 + etnaviv/etnaviv_drm.h| 43 +- etnaviv/etnaviv_drmif.h | 23 ++ etnaviv/etnaviv_perfmon.c| 189 +++ etnaviv/etnaviv_priv.h | 25 ++ 7 files changed, 305 insertions(+), 1 deletion(-) create mode 100644 etnaviv/etnaviv_perfmon.c -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] etnaviv: sync uapi header
Import the etnaviv header changes from kernel commit 05916bed1 (drm-next)
The drm_etnaviv_gem_submit structure was extended to include performance
monitor requests. Also two new ioctls got added to be able to readout
performance monitor domains and their signals.
Signed-off-by: Christian Gmeiner
Acked-by: Lucas Stach
---
etnaviv/etnaviv_drm.h | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
index 76f6f78a..110cc73b 100644
--- a/etnaviv/etnaviv_drm.h
+++ b/etnaviv/etnaviv_drm.h
@@ -150,6 +150,19 @@ struct drm_etnaviv_gem_submit_bo {
__u64 presumed; /* in/out, presumed buffer address */
};
+/* performance monitor request (pmr) */
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+struct drm_etnaviv_gem_submit_pmr {
+ __u32 flags; /* in, when to process request
(ETNA_PM_PROCESS_x) */
+ __u8 domain; /* in, pm domain */
+ __u8 pad;
+ __u16 signal; /* in, pm signal */
+ __u32 sequence; /* in, sequence number */
+ __u32 read_offset;/* in, offset from read_bo */
+ __u32 read_idx; /* in, index of read_bo buffer */
+};
+
/* Each cmdstream submit consists of a table of buffers involved, and
* one or more cmdstream buffers. This allows for conditional execution
* (context-restore), and IB buffers needed for per tile/bin draw cmds.
@@ -175,6 +188,9 @@ struct drm_etnaviv_gem_submit {
__u64 stream; /* in, ptr to cmdstream */
__u32 flags; /* in, mask of ETNA_SUBMIT_x */
__s32 fence_fd; /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x)
*/
+ __u64 pmrs; /* in, ptr to array of submit_pmr's */
+ __u32 nr_pmrs;/* in, number of submit_pmr's */
+ __u32 pad;
};
/* The normal way to synchronize with the GPU is just to CPU_PREP on
@@ -210,6 +226,27 @@ struct drm_etnaviv_gem_wait {
struct drm_etnaviv_timespec timeout;/* in */
};
+/*
+ * Performance Monitor (PM):
+ */
+
+struct drm_etnaviv_pm_domain {
+ __u32 pipe; /* in */
+ __u8 iter; /* in/out, select pm domain at index iter */
+ __u8 id; /* out, id of domain */
+ __u16 nr_signals; /* out, how many signals does this domain provide */
+ char name[64]; /* out, name of domain */
+};
+
+struct drm_etnaviv_pm_signal {
+ __u32 pipe; /* in */
+ __u8 domain; /* in, pm domain index */
+ __u8 pad;
+ __u16 iter; /* in/out, select pm source at index iter */
+ __u16 id; /* out, id of signal */
+ char name[64]; /* out, name of domain */
+};
+
#define DRM_ETNAVIV_GET_PARAM 0x00
/* placeholder:
#define DRM_ETNAVIV_SET_PARAM 0x01
@@ -222,7 +259,9 @@ struct drm_etnaviv_gem_wait {
#define DRM_ETNAVIV_WAIT_FENCE 0x07
#define DRM_ETNAVIV_GEM_USERPTR0x08
#define DRM_ETNAVIV_GEM_WAIT 0x09
-#define DRM_ETNAVIV_NUM_IOCTLS 0x0a
+#define DRM_ETNAVIV_PM_QUERY_DOM 0x0a
+#define DRM_ETNAVIV_PM_QUERY_SIG 0x0b
+#define DRM_ETNAVIV_NUM_IOCTLS 0x0c
#define DRM_IOCTL_ETNAVIV_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE +
DRM_ETNAVIV_GET_PARAM, struct drm_etnaviv_param)
#define DRM_IOCTL_ETNAVIV_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE +
DRM_ETNAVIV_GEM_NEW, struct drm_etnaviv_gem_new)
@@ -233,6 +272,8 @@ struct drm_etnaviv_gem_wait {
#define DRM_IOCTL_ETNAVIV_WAIT_FENCE DRM_IOW(DRM_COMMAND_BASE +
DRM_ETNAVIV_WAIT_FENCE, struct drm_etnaviv_wait_fence)
#define DRM_IOCTL_ETNAVIV_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_ETNAVIV_GEM_USERPTR, struct drm_etnaviv_gem_userptr)
#define DRM_IOCTL_ETNAVIV_GEM_WAIT DRM_IOW(DRM_COMMAND_BASE +
DRM_ETNAVIV_GEM_WAIT, struct drm_etnaviv_gem_wait)
+#define DRM_IOCTL_ETNAVIV_PM_QUERY_DOM DRM_IOWR(DRM_COMMAND_BASE +
DRM_ETNAVIV_PM_QUERY_DOM, struct drm_etnaviv_pm_domain)
+#define DRM_IOCTL_ETNAVIV_PM_QUERY_SIG DRM_IOWR(DRM_COMMAND_BASE +
DRM_ETNAVIV_PM_QUERY_SIG, struct drm_etnaviv_pm_signal)
#if defined(__cplusplus)
}
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] etnaviv: support performance monitor requests
Add etna_cmd_stream_perf(..) to submit perform requests.
Userspace can submit pmrs via submit ioctl to sample perfmon
signals.
v3:
- mark perfmon bos as RW
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv-symbol-check | 1 +
etnaviv/etnaviv_cmd_stream.c | 20
etnaviv/etnaviv_drmif.h | 12
etnaviv/etnaviv_priv.h | 4
4 files changed, 37 insertions(+)
diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index bd95b459..bc509615 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -41,6 +41,7 @@ etna_cmd_stream_timestamp
etna_cmd_stream_flush
etna_cmd_stream_flush2
etna_cmd_stream_finish
+etna_cmd_stream_perf
etna_cmd_stream_reloc
etna_perfmon_create
etna_perfmon_del
diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 8d0e8135..e8c58cd5 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -105,6 +105,7 @@ void etna_cmd_stream_del(struct etna_cmd_stream *stream)
free(stream->buffer);
free(priv->submit.relocs);
+ free(priv->submit.pmrs);
free(priv);
}
@@ -115,6 +116,7 @@ static void reset_buffer(struct etna_cmd_stream *stream)
stream->offset = 0;
priv->submit.nr_bos = 0;
priv->submit.nr_relocs = 0;
+ priv->submit.nr_pmrs = 0;
priv->nr_bos = 0;
if (priv->reset_notify)
@@ -191,6 +193,8 @@ static void flush(struct etna_cmd_stream *stream, int
in_fence_fd,
.nr_bos = priv->submit.nr_bos,
.relocs = VOID2U64(priv->submit.relocs),
.nr_relocs = priv->submit.nr_relocs,
+ .pmrs = VOID2U64(priv->submit.pmrs),
+ .nr_pmrs = priv->submit.nr_pmrs,
.stream = VOID2U64(stream->buffer),
.stream_size = stream->offset * 4, /* in bytes */
};
@@ -260,3 +264,19 @@ void etna_cmd_stream_reloc(struct etna_cmd_stream *stream,
const struct etna_rel
etna_cmd_stream_emit(stream, addr);
}
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct
etna_perf *p)
+{
+ struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
+ struct drm_etnaviv_gem_submit_pmr *pmr;
+ uint32_t idx = APPEND(&priv->submit, pmrs);
+
+ pmr = &priv->submit.pmrs[idx];
+
+ pmr->flags = p->flags;
+ pmr->sequence = p->sequence;
+ pmr->read_offset = p->offset;
+ pmr->read_idx = bo2idx(stream, p->bo, ETNA_SUBMIT_BO_READ |
ETNA_SUBMIT_BO_WRITE);
+ pmr->domain = p->signal->domain->id;
+ pmr->signal = p->signal->signal;
+}
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 949b9b62..5a6bef8d 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -201,4 +201,16 @@ void etna_perfmon_del(struct etna_perfmon *perfmon);
struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct etna_perfmon
*pm, const char *name);
struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct
etna_perfmon_domain *dom, const char *name);
+struct etna_perf {
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+ uint32_t flags;
+ uint32_t sequence;
+ struct etna_perfmon_signal *signal;
+ struct etna_bo *bo;
+ uint32_t offset;
+};
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct
etna_perf *p);
+
#endif /* ETNAVIV_DRMIF_H_ */
diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
index 7b289b61..e45d364c 100644
--- a/etnaviv/etnaviv_priv.h
+++ b/etnaviv/etnaviv_priv.h
@@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
/* reloc's table: */
struct drm_etnaviv_gem_submit_reloc *relocs;
uint32_t nr_relocs, max_relocs;
+
+ /* perf's table: */
+ struct drm_etnaviv_gem_submit_pmr *pmrs;
+ uint32_t nr_pmrs, max_pmrs;
} submit;
/* should have matching entries in submit.bos: */
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] etnaviv: support performance monitor requests
Hi Lucas,
thanks for review.
2017-12-14 12:48 GMT+01:00 Lucas Stach :
> Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
>> Add etna_cmd_stream_perf(..) to submit perform requests.
>> Userspace can submit pmrs via submit ioctl to sample perfmon
>> signals.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> etnaviv/etnaviv-symbol-check | 1 +
>> etnaviv/etnaviv_cmd_stream.c | 20
>> etnaviv/etnaviv_drmif.h | 12
>> etnaviv/etnaviv_priv.h | 4
>> 4 files changed, 37 insertions(+)
>>
>> diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-
>> check
>> index bd95b459..bc509615 100755
>> --- a/etnaviv/etnaviv-symbol-check
>> +++ b/etnaviv/etnaviv-symbol-check
>> @@ -41,6 +41,7 @@ etna_cmd_stream_timestamp
>> etna_cmd_stream_flush
>> etna_cmd_stream_flush2
>> etna_cmd_stream_finish
>> +etna_cmd_stream_perf
>> etna_cmd_stream_reloc
>> etna_perfmon_create
>> etna_perfmon_del
>> diff --git a/etnaviv/etnaviv_cmd_stream.c
>> b/etnaviv/etnaviv_cmd_stream.c
>> index 8d0e8135..d6f26a88 100644
>> --- a/etnaviv/etnaviv_cmd_stream.c
>> +++ b/etnaviv/etnaviv_cmd_stream.c
>> @@ -105,6 +105,7 @@ void etna_cmd_stream_del(struct etna_cmd_stream
>> *stream)
>>
>> free(stream->buffer);
>> free(priv->submit.relocs);
>> + free(priv->submit.pmrs);
>> free(priv);
>> }
>>
>> @@ -115,6 +116,7 @@ static void reset_buffer(struct etna_cmd_stream
>> *stream)
>> stream->offset = 0;
>> priv->submit.nr_bos = 0;
>> priv->submit.nr_relocs = 0;
>> + priv->submit.nr_pmrs = 0;
>> priv->nr_bos = 0;
>>
>> if (priv->reset_notify)
>> @@ -191,6 +193,8 @@ static void flush(struct etna_cmd_stream *stream,
>> int in_fence_fd,
>> .nr_bos = priv->submit.nr_bos,
>> .relocs = VOID2U64(priv->submit.relocs),
>> .nr_relocs = priv->submit.nr_relocs,
>> + .pmrs = VOID2U64(priv->submit.pmrs),
>> + .nr_pmrs = priv->submit.nr_pmrs,
>> .stream = VOID2U64(stream->buffer),
>> .stream_size = stream->offset * 4, /* in bytes */
>> };
>> @@ -260,3 +264,19 @@ void etna_cmd_stream_reloc(struct
>> etna_cmd_stream *stream, const struct etna_rel
>>
>> etna_cmd_stream_emit(stream, addr);
>> }
>> +
>> +void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const
>> struct etna_perf *p)
>> +{
>> + struct etna_cmd_stream_priv *priv =
>> etna_cmd_stream_priv(stream);
>> + struct drm_etnaviv_gem_submit_pmr *pmr;
>> + uint32_t idx = APPEND(&priv->submit, pmrs);
>> +
>> + pmr = &priv->submit.pmrs[idx];
>> +
>> + pmr->flags = p->flags;
>> + pmr->sequence = p->sequence;
>> + pmr->read_offset = p->offset;
>> + pmr->read_idx = bo2idx(stream, p->bo, ETNA_SUBMIT_BO_READ);
>
> This should be BO R/W. While it's not strictly the GPU writing to the
> buffer, the GPU submit will alter the BO.
>
Makes sense - will be changed in v3.
>> + pmr->domain = p->signal->domain->id;
>> + pmr->signal = p->signal->signal;
>> +}
>> diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
>> index 949b9b62..5a6bef8d 100644
>> --- a/etnaviv/etnaviv_drmif.h
>> +++ b/etnaviv/etnaviv_drmif.h
>> @@ -201,4 +201,16 @@ void etna_perfmon_del(struct etna_perfmon
>> *perfmon);
>> struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct
>> etna_perfmon *pm, const char *name);
>> struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct
>> etna_perfmon_domain *dom, const char *name);
>>
>> +struct etna_perf {
>> +#define ETNA_PM_PROCESS_PRE 0x0001
>> +#define ETNA_PM_PROCESS_POST0x0002
>> + uint32_t flags;
>> + uint32_t sequence;
>> + struct etna_perfmon_signal *signal;
>> + struct etna_bo *bo;
>> + uint32_t offset;
>> +};
>> +
>> +void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const
>> struct etna_perf *p);
>> +
>> #endif /* ETNAVIV_DRMIF_H_ */
>> diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
>> index 7b289b61..e45d364c 100644
>> --- a/etnaviv/etnaviv_priv.h
>> +++ b/etnaviv/etnaviv_priv.h
>> @@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
>> /* reloc's table: */
>> struct drm_etnaviv_gem_submit_reloc *relocs;
>> uint32_t nr_relocs, max_relocs;
>> +
>> + /* perf's table: */
>> + struct drm_etnaviv_gem_submit_pmr *pmrs;
>> + uint32_t nr_pmrs, max_pmrs;
>
> max_pmrs isn't used anywhere AFAICS.
There is a macro used called APPEND:
#define APPEND(x, name) ({ \
(x)->name = grow((x)->name, (x)->nr_ ## name, &(x)->max_ ## name,
sizeof((x)->name[0])); \
(x)->nr_ ## name ++; \
})
And here you will find the usage of max_pmrs :)
>
>> } submit;
>>
>> /* should have matching entries in submit.bos: */
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-dev
Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO
Roger and Chrisitian,
Correct me if I'm wrong, but It seems to me like a lot of the recent
changes to ttm_bo.c are to allow recursive reservation object locking in
the case of shared reservation objects, but only in certain functions
and with special arguments so it doesn't look like recursive locking to
the lockdep checker. Wouldn't it be a lot cleaner if we were to hide
all this in a resurrected __ttm_bo_reserve something along the lines of
int __ttm_bo_reserve(struct ttm_bo *bo, struct ttm_operation_ctx *ctx) {
if (ctx && ctx->resv == bo->resv) {
#ifdef CONFIG_LOCKDEP
WARN_ON(bo->reserved);
lockdep_assert_held(&ctx->resv);
ctx->reserve_count++;
bo->reserved = true;
#endif
return0;
} else {
int ret = reservation_object_lock(bo->resv, NULL) ? 0:-EBUSY;
if (ret)
return ret;
#ifdef CONFIG_LOCKDEP
WARN_ON(bo->reserved);
bo->reserved = true;
#endif
return 0;
}
And similar for tryreserve and unreserve? Perhaps with a ww_acquire_ctx
included somewhere as well...
/Thomas
On 12/14/2017 09:10 AM, Roger He wrote:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
- struct reservation_object *resv,
uint32_t mem_type,
const struct ttm_place *place,
struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (bo->resv == resv) {
- if (list_empty(&bo->ddestroy))
+ if (bo->resv == ctx->resv) {
+ if (!ctx->allow_reserved_eviction &&
+ list_empty(&bo->ddestroy))
continue;
} else {
locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
return ret;
if (mem->mm_node)
break;
- ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO
Hi.
On 12/14/2017 09:10 AM, Roger He wrote:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
- struct reservation_object *resv,
uint32_t mem_type,
const struct ttm_place *place,
struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (bo->resv == resv) {
- if (list_empty(&bo->ddestroy))
+ if (bo->resv == ctx->resv) {
+ if (!ctx->allow_reserved_eviction &&
+ list_empty(&bo->ddestroy))
continue;
It looks to me like a value of locked==true could leak through from a
previous loop iteration here, so that locked ends up to be true if
(bo->resv == resv && ctx->allow_reserved_eviction), even if no locking
was taking place. Perhaps-re-initialize locked to false on each loop
iteration?
/Thomas
} else {
locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
return ret;
if (mem->mm_node)
break;
- ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)
https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #1 from Sverd Johnsen --- with 4.15rc (linus tree from today) [ 78.807441] [drm] amdgpu: finishing device. [ 78.887439] amdgpu: [powerplay] [ 78.887454] amdgpu: [powerplay] [ 78.968349] BUG: unable to handle kernel NULL pointer dereference at (null) [ 78.968352] IP: (null) [ 78.968352] PGD 45af1d067 P4D 45af1d067 PUD 45b065067 PMD 0 [ 78.968354] Oops: 0010 [#1] PREEMPT SMP [ 78.968355] Modules linked in: amdgpu(-) chash ttm cls_u32 sch_htb af_packet nft_limit nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nf_log_ipv6 nf_log_ipv4 nf_log_common nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_log nft_ct nf_conntrack xfrm_user xfrm_algo nft_counter nft_meta nft_set_bitmap nft_set_hash nft_set_rbtree nf_tables_netdev nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 dm_cache_smq dm_cache dm_bio_prison dm_persistent_data dm_bufio libcrc32c bcache x86_pkg_temp_thermal intel_powerclamp kvm_intel vhost_net raid0 raid1 tun vhost tap kvm snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec md_mod snd_hwdep irqbypass snd_hda_core intel_cstate mei_me efi_pstore intel_uncore plusb mei input_leds usbnet snd_pcm intel_rapl_perf [ 78.968375] led_class mii efivars tpm_crb usbip_host usbip_core efivarfs algif_skcipher af_alg mousedev joydev psmouse atkbd libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr tpm_tis shpchp tpm_tis_core thermal fan tpm i8042 acpi_pad vfat fat [ 78.968383] CPU: 1 PID: 1493 Comm: rmmod Not tainted 4.15.0-1-rc #2 [ 78.968384] Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD3/Z170X-UD3-CF, BIOS F23d 12/01/2017 [ 78.968384] RIP: 0010: (null) [ 78.968385] RSP: 0018:9c6a8281bd00 EFLAGS: 00010286 [ 78.968386] RAX: 9294612676e0 RBX: 92948b2a3300 RCX: 00018020001e [ 78.968386] RDX: 00018020001f RSI: 5c02 RDI: 929461267120 [ 78.968387] RBP: 9294658a6c90 R08: 0001 R09: 929476247000 [ 78.968387] R10: R11: 0033 R12: 0003 [ 78.968388] R13: 929453e42f18 R14: R15: c09b13e8 [ 78.968389] FS: 7f0d7f498b80() GS:92949ec8() knlGS: [ 78.968389] CS: 0010 DS: ES: CR0: 80050033 [ 78.968390] CR2: CR3: 00046b3f8001 CR4: 003606e0 [ 78.968390] DR0: DR1: DR2: [ 78.968391] DR3: DR6: fffe0ff0 DR7: 0400 [ 78.968391] Call Trace: [ 78.968429] ? destroy+0x1d/0xa0 [amdgpu] [ 78.968440] ? dal_i2caux_destruct+0x58/0x90 [amdgpu] [ 78.968449] ? destroy+0x10/0x30 [amdgpu] [ 78.968458] ? dal_i2caux_destroy+0x17/0x30 [amdgpu] [ 78.968467] ? destruct+0x89/0x110 [amdgpu] [ 78.968476] ? dc_destroy+0xc/0x20 [amdgpu] [ 78.968488] ? dm_hw_fini+0x19/0x20 [amdgpu] [ 78.968493] ? amdgpu_fini+0x90/0x2f0 [amdgpu] [ 78.968499] ? amdgpu_device_fini+0x5f/0x1c0 [amdgpu] [ 78.968505] ? amdgpu_driver_unload_kms+0x45/0x90 [amdgpu] [ 78.968507] ? drm_dev_unregister+0x37/0xe0 [ 78.968512] ? amdgpu_pci_remove+0x14/0x40 [amdgpu] [ 78.968514] ? pci_device_remove+0x31/0xa0 [ 78.968516] ? device_release_driver_internal+0x152/0x210 [ 78.968517] ? driver_detach+0x32/0x70 [ 78.968518] ? bus_remove_driver+0x4c/0xc0 [ 78.968519] ? pci_unregister_driver+0x25/0xa0 [ 78.968529] ? amdgpu_exit+0x11/0x3b6 [amdgpu] [ 78.968530] ? SyS_delete_module+0x19c/0x2a0 [ 78.968532] ? do_syscall_64+0x48/0xe0 [ 78.968533] ? entry_SYSCALL64_slow_path+0x25/0x25 [ 78.968534] Code: Bad RIP value. [ 78.968536] RIP: (null) RSP: 9c6a8281bd00 [ 78.968537] CR2: [ 78.968538] ---[ end trace bbf73cfe467dd4c8 ]--- -- 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 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.
https://bugs.freedesktop.org/show_bug.cgi?id=104275 --- Comment #1 from Kai-Heng Feng --- Created attachment 136186 --> https://bugs.freedesktop.org/attachment.cgi?id=136186&action=edit lspci -- 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 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.
https://bugs.freedesktop.org/show_bug.cgi?id=104275 --- Comment #2 from Kai-Heng Feng --- Created attachment 136187 --> https://bugs.freedesktop.org/attachment.cgi?id=136187&action=edit dmesg with drm.debug=0x0e -- 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 104275] Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode.
https://bugs.freedesktop.org/show_bug.cgi?id=104275 Bug ID: 104275 Summary: Stoney Ridge laptop display goes blank after HDMI gets plugged/unplugged in extended mode. Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: kai.heng.f...@canonical.com Hi, We are enabling a new Stoney Ridge laptop. The issue can be reproduced on branch drm-next-4.16-wip and amd-staging-drm-next. Reproduce steps: 1. Plug HDMI monitor. 2. Change to extended mode. 3. Unplug the HDMI monitor 4. Plug the HDMI monitor Internal display may go blank in step 3. The internal display may also go blank in step 4. The external one shows desktop correctly though. I can see lots of message flooding once I plugged HDMI: [ 120.933668] amdgpu :00:01.0: 30e07f1f pin failed [ 120.933859] [drm:amdgpu_crtc_page_flip_target [amdgpu]] *ERROR* failed to pin new abo buffer before flip These messages stop as soon as the HDMI is unplugged. -- 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 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)
https://bugs.freedesktop.org/show_bug.cgi?id=104274 Bug ID: 104274 Summary: Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0258 (mutex_lock) Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sverd.john...@googlemail.com Use case for this working well is that once GPU is not needed anymore it can be moved into VM with VFIO. Moving from VFIO back to amdgpu already seems to work alright. loading: [4.751628] kernel: LoadPin: kernel-module pinning-ignored obj="/usr/lib/modules/4.14.5-5-ph/kernel/drivers/gpu/drm/ttm/ttm.ko" pid=940 cmdline="modprobe amdgpu disp_priority=1" [4.769592] kernel: LoadPin: kernel-module pinning-ignored obj="/usr/lib/modules/4.14.5-5-ph/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.037887] kernel: [drm] amdgpu kernel modesetting enabled. [46667.037938] kernel: amdgpu :01:00.0: enabling device (0006 -> 0007) [46667.038049] kernel: [drm] initializing kernel modesetting (POLARIS11 0x1002:0x67EF 0x1462:0x809D 0xCF). [46667.038079] kernel: [drm] register mmio base: 0xEFE0 [46667.038079] kernel: [drm] register mmio size: 262144 [46667.038087] kernel: [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e [46667.038087] kernel: [drm] probing mlw for device 8086:1901 = 261ad03 [46667.038093] kernel: [drm] UVD is enabled in VM mode [46667.038094] kernel: [drm] VCE enabled in VM mode [46667.038114] kernel: ATOM BIOS: 113-C99401-S01 [46667.038119] kernel: [drm] GPU post is not needed [46667.038184] kernel: [drm] vm size is 64 GB, block size is 13-bit, fragment size is 4-bit [46667.038205] kernel: LoadPin: firmware pinning-ignored obj="/usr/lib/firmware/amdgpu/polaris11_mc.bin" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.038643] kernel: amdgpu :01:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [46667.038644] kernel: amdgpu :01:00.0: GTT: 256M 0x - 0x0FFF [46667.038649] kernel: [drm] Detected VRAM RAM=2048M, BAR=256M [46667.038649] kernel: [drm] RAM width 128bits GDDR5 [46667.039152] kernel: [TTM] Zone kernel: Available graphics memory: 8082768 kiB [46667.039152] kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB [46667.039153] kernel: [TTM] Initializing pool allocator [46667.039155] kernel: [TTM] Initializing DMA pool allocator [46667.039167] kernel: [drm] amdgpu: 2048M of VRAM memory ready [46667.039168] kernel: [drm] amdgpu: 3072M of GTT memory ready. [46667.039202] kernel: [drm] GART: num cpu pages 65536, num gpu pages 65536 [46667.039284] kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40004). [46667.039300] kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [46667.039301] kernel: [drm] Driver supports precise vblank timestamp query. [46667.039338] kernel: amdgpu :01:00.0: amdgpu: using MSI. [46667.039348] kernel: [drm] amdgpu: irq initialized. [46667.168524] kernel: amdgpu: [powerplay] amdgpu: powerplay sw initialized [46667.168612] kernel: [drm] AMDGPU Display Connectors [46667.168612] kernel: [drm] Connector 0: [46667.168613] kernel: [drm] DP-2 [46667.168613] kernel: [drm] HPD5 [46667.168614] kernel: [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b [46667.168614] kernel: [drm] Encoders: [46667.168614] kernel: [drm] DFP1: INTERNAL_UNIPHY1 [46667.168614] kernel: [drm] Connector 1: [46667.168615] kernel: [drm] HDMI-A-4 [46667.168615] kernel: [drm] HPD3 [46667.168615] kernel: [drm] DDC: 0x4874 0x4874 0x4875 0x4875 0x4876 0x4876 0x4877 0x4877 [46667.168615] kernel: [drm] Encoders: [46667.168616] kernel: [drm] DFP2: INTERNAL_UNIPHY1 [46667.168616] kernel: [drm] Connector 2: [46667.168616] kernel: [drm] DVI-D-1 [46667.168616] kernel: [drm] HPD4 [46667.168617] kernel: [drm] DDC: 0x4878 0x4878 0x4879 0x4879 0x487a 0x487a 0x487b 0x487b [46667.168617] kernel: [drm] Encoders: [46667.168617] kernel: [drm] DFP3: INTERNAL_UNIPHY [46667.168631] kernel: LoadPin: firmware pinning-ignored obj="/usr/lib/firmware/amdgpu/polaris11_pfp.bin" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.168927] kernel: LoadPin: firmware pinning-ignored obj="/usr/lib/firmware/amdgpu/polaris11_me.bin" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.169170] kernel: LoadPin: firmware pinning-ignored obj="/usr/lib/firmware/amdgpu/polaris11_ce.bin" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.169297] kernel: LoadPin: firmware pinning-ignored obj="/usr/lib/firmware/amdgpu/polaris11_rlc.bin" pid=940 cmdline="modprobe amdgpu disp_priority=1" [46667.169543] kernel: LoadPin: firmware pinning-ignored o
Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects
On Thu, 2017-12-14 at 21:30 +0100, Daniel Vetter wrote:
> DK put some nice docs into the commit introducing driver private
> state, but in the git history alone it'll be lost.
>
> Also, since Ville remove the void* usage it's a good opportunity to
> give the driver private stuff some tlc on the doc front.
>
> Finally try to explain why the "let's just subclass drm_atomic_state"
> approach wasn't the greatest, and annotate all those functions as
> deprecated in favour of more standardized driver private states. Also
> note where we could/should extend driver private states going forward
> (atm neither locking nor synchronization is handled in core/helpers,
> which isn't really all that great).
>
I have pointed out a couple of typos below, other than lgtm
Reviewed-by: Dhinakaran Pandiyan
> Cc: Harry Wentland
> Cc: Dhinakaran Pandiyan
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Laurent Pinchart
> Cc: Rob Clark
> Cc: Alex Deucher
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic.c | 45
> ---
> include/drm/drm_atomic.h | 28 +++
> include/drm/drm_mode_config.h | 9 +
> 4 files changed, 85 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 307284125d7a..420025bd6a9b 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -271,6 +271,12 @@ Taken all together there's two consequences for the
> atomic design:
> Read on in this chapter, and also in :ref:`drm_atomic_helper` for more
> detailed
> coverage of specific topics.
>
> +Handling Driver Private State
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
> + :doc: handling driver private state
> +
> Atomic Mode Setting Function Reference
> --
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 37445d50816a..15e1a35c74a8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -50,7 +50,8 @@ EXPORT_SYMBOL(__drm_crtc_commit_free);
> * @state: atomic state
> *
> * Free all the memory allocated by drm_atomic_state_init.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> void drm_atomic_state_default_release(struct drm_atomic_state *state)
> {
> @@ -67,7 +68,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
> * @state: atomic state
> *
> * Default implementation for filling in a new atomic state.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> int
> drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
> @@ -132,7 +134,8 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
> * @state: atomic state
> *
> * Default implementation for clearing atomic state.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> void drm_atomic_state_default_clear(struct drm_atomic_state *state)
> {
> @@ -946,6 +949,42 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> plane->funcs->atomic_print_state(p, state);
> }
>
> +/**
> + * DOC: handling driver private state
> + *
> + * Very often the DRM objects exposed to userspace in the atomic modeset api
> + * (&drm_connector, &drm_crtc and &drm_plane) do not map neatly to the
> + * underlying hardware. Especially for any kind of shared resources (e.g.
> shared
> + * clocks, scaler units, bandwidth and fifo limits shared among a group of
> + * planes or CRTCs, and so on) it makes sense to model these as independent
> + * objects. Drivers then need to similar state tracking and commit ordering
> for
> + * such private (since not exposed to userpace) objects as the atomic core
> and
> + * helpers already provide for connectors, planes and CRTCs.
> + *
> + * To make this easier on drivers the atomic core provides some support to
> track
> + * driver private state objects using struct &drm_private_obj, with the
> + * associated state struct &drm_private_state.
> + *
> + * Similar to userspace-exposed objects, state structures can be acquired by
^private
> + * calling drm_atomic_get_private_obj_state(). Since this function does not
> take
> + * care of locking, drivers should wrap it for each type of private state
> object
> + * they have with the required call to drm_modeset_lock() for the
> corresponding
> + * &drm_mod
Re: [PATCH 5/5] drm/doc: Move legacy kms helpers to the very end
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> We don't want people to accidentally stumble over there.
>
> Also rename the plane helpers to legacy plane helpers. After Ville's
> patch to make the clipping helper atomic and move it to
> drm_atomic_helper.c there's nothing left in there that should be
> useful for modern drivers.
>
> v2: Laurent had a few questions around how state is added to
> drm_atomic_state, tried to clarify that. And spotted another sentence
> where the docs suggested subclassing.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms-helpers.rst | 36
> +--
> Documentation/gpu/drm-kms.rst | 8
> include/drm/drm_atomic.h | 4
> 3 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 3ea622876b67..e37557b30f62 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -74,15 +74,6 @@ Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
> :export:
>
> -Legacy CRTC/Modeset Helper Functions Reference
> -==
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
> - :doc: overview
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
> - :export:
> -
> Simple KMS Helper Reference
> ===
>
> @@ -282,15 +273,6 @@ Flip-work Helper Reference
> .. kernel-doc:: drivers/gpu/drm/drm_flip_work.c
> :export:
>
> -Plane Helper Reference
> -==
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
> - :doc: overview
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
> - :export:
> -
> Auxiliary Modeset Helpers
> =
>
> @@ -308,3 +290,21 @@ Framebuffer GEM Helper Reference
>
> .. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
> :export:
> +
> +Legacy Plane Helper Reference
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
> + :export:
> +
> +Legacy CRTC/Modeset Helper Functions Reference
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
> + :export:
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 420025bd6a9b..cbba93483aec 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -263,10 +263,10 @@ Taken all together there's two consequences for the
> atomic design:
>
> - An atomic update is assembled and validated as an entirely free-standing
> pile
>of structures within the :c:type:`drm_atomic_state `
> - container. Again drivers can subclass that container for their own state
> - structure tracking needs. Only when a state is committed is it applied to
> the
> - driver and modeset objects. This way rolling back an update boils down to
> - releasing memory and unreferencing objects like framebuffers.
> + container. Driver private state structures are also tracked in the same
> + structure, see the next chapter. Only when a state is committed is it
> applied
I think it would be clearer as:
structure (see the next chapter).
or
structure; see the next chapter.
Either way:
Reviewed-by: Alex Deucher
> + to the driver and modeset objects. This way rolling back an update boils
> down
> + to releasing memory and unreferencing objects like framebuffers.
>
> Read on in this chapter, and also in :ref:`drm_atomic_helper` for more
> detailed
> coverage of specific topics.
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 8e4829a25c1b..e7f25e342cc8 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -246,6 +246,10 @@ struct __drm_private_objs_state {
> * @num_private_objs: size of the @private_objs array
> * @private_objs: pointer to array of private object pointers
> * @acquire_ctx: acquire context for this atomic modeset state update
> + *
> + * States are added to an atomic update by calling
> drm_atomic_get_crtc_state(),
> + * drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
> + * private state structures, drm_atomic_get_private_obj_state().
> */
> struct drm_atomic_state {
> struct kref ref;
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/syncobj: some kerneldoc polish
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> Complete a few missing bits, fix up the existing xcross-references and
> add a bunch more.
>
> Cc: Dave Airlie via lists.freedesktop.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 45
> +++
> include/drm/drm_syncobj.h | 32 +-
> 2 files changed, 60 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 9b733c510cbf..b6d0c2c400ec 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -29,9 +29,9 @@
> /**
> * DOC: Overview
> *
> - * DRM synchronisation objects (syncobj) are a persistent objects,
> - * that contain an optional fence. The fence can be updated with a new
> - * fence, or be NULL.
> + * DRM synchronisation objects (syncobj, see struct &drm_syncobj) are a
> + * persistent objects, that contain an optional fence. The fence can be
> updated
grammer:
are persistent objects that contain an optional fence
> + * with a new fence, or be NULL.
> *
> * syncobj's can be waited upon, where it will wait for the underlying
> * fence.
> @@ -61,7 +61,8 @@
> * @file_private: drm file private pointer
> * @handle: sync object handle to lookup.
> *
> - * Returns a reference to the syncobj pointed to by handle or NULL.
> + * Returns a reference to the syncobj pointed to by handle or NULL. The
> + * reference must be released by calling drm_syncobj_put().
> */
> struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> u32 handle)
> @@ -229,6 +230,19 @@ static int drm_syncobj_assign_null_handle(struct
> drm_syncobj *syncobj)
> return 0;
> }
>
> +/**
> + * drm_syncobj_find_fence - lookup and reference the fence in a sync object
> + * @file_private: drm file private pointer
> + * @handle: sync object handle to lookup.
> + * @fence: out parameter for the fence
> + *
> + * This is just a convenience function that combines drm_syncobj_find() and
> + * drm_syncobj_fence_get().
> + *
> + * Returns 0 on success or a negative error value on failure. On success
> @fence
> + * contains a reference to the fence, which mus be released by calling
typo: must
> + * dma_fence_put().
> + */
> int drm_syncobj_find_fence(struct drm_file *file_private,
>u32 handle,
>struct dma_fence **fence)
> @@ -269,6 +283,12 @@ EXPORT_SYMBOL(drm_syncobj_free);
> * @out_syncobj: returned syncobj
> * @flags: DRM_SYNCOBJ_* flags
> * @fence: if non-NULL, the syncobj will represent this fence
> + *
> + * This is the first function to create a sync object. After creating drivers
> + * probably want to make it available to userspace, either through
> + * drm_syncobj_get_handle() or drm_syncobj_get_fd().
grammer:
After creating, drivers probably want to make it available to userspace
> + *
> + * Returns 0 on success or a negative error value on failure.
> */
> int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
>struct dma_fence *fence)
> @@ -302,6 +322,14 @@ EXPORT_SYMBOL(drm_syncobj_create);
>
> /**
> * drm_syncobj_get_handle - get a handle from a syncobj
> + * @file_private: drm file private pointer
> + * @syncobj: Sync object to export
> + * @handle: out parameter with the new handle
> + *
> + * Exports a sync object created with drm_syncobj_create() as a handle on
> + * @file_private to userspace.
> + *
> + * Returns 0 on success or a negative error value on failure.
> */
> int drm_syncobj_get_handle(struct drm_file *file_private,
>struct drm_syncobj *syncobj, u32 *handle)
> @@ -388,6 +416,15 @@ static int drm_syncobj_alloc_file(struct drm_syncobj
> *syncobj)
> return 0;
> }
>
> +/**
> + * drm_syncobj_get_fd - get a file descriptor from a syncobj
> + * @syncobj: Sync object to export
> + * @p_fd: out parameter with the new file descriptor
> + *
> + * Exports a sync object created with drm_syncobj_create() as a file
> descriptor.
> + *
> + * Returns 0 on success or a negative error value on failure.
> + */
> int drm_syncobj_get_fd(struct drm_syncobj *syncobj, int *p_fd)
> {
> int ret;
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 9e8ba90c6784..87865774bdaa 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -33,36 +33,31 @@ struct drm_syncobj_cb;
> /**
> * struct drm_syncobj - sync object.
> *
> - * This structure defines a generic sync object which wraps a dma fence.
> + * This structure defines a generic sync object which wraps a &dma_fence.
> */
> struct drm_syncobj {
> /**
> -* @refcount:
> -*
> -* Reference count of this object.
> +* @refcount: Reference count of this object.
> */
> struct kref refcount;
> /**
>
Re: [PATCH 2/5] drm/print: Unconfuse kerneldoc
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> It thinks we want to document the __printf(2,0) annotion. Not sure we
> want to teach it about all possible gcc-only flags, hence why I opted
> for the cheap trick of just moving it ahead of the kerneldoc.
>
> This is only a problem for static inline functions, since for
> non-inline function the kerneldoc is in the .c file, but the special
> annotations are all in the header.
>
> Cc'ing kernel-doc maintainers as fyi.
>
> Cc: linux-...@vger.kernel.org
> Cc: Jonathan Corbet
> Signed-off-by: Daniel Vetter
Acked-by: Alex Deucher
> ---
> include/drm/drm_print.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 5f9932e2246e..2a4a42e59a47 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -80,13 +80,13 @@ void __drm_printfn_debug(struct drm_printer *p, struct
> va_format *vaf);
> __printf(2, 3)
> void drm_printf(struct drm_printer *p, const char *f, ...);
>
> +__printf(2, 0)
> /**
> * drm_vprintf - print to a &drm_printer stream
> * @p: the &drm_printer
> * @fmt: format string
> * @va: the va_list
> */
> -__printf(2, 0)
> static inline void
> drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
> {
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/edid: kerneldoc for is_hdmi2_sink
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> Also some breadcrumbs for how exactly to find this. Probably should
> pass drm_connector * or at least drm_display_info * to that function
> instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
> drm_connector_state (and the hdmi stuff moved into that), so this is a
> bit more work.
>
> Cc: Ville Syrjälä
> Fixes: 9271c0ca573e ("drm/edid: Don't send non-zero YQ in AVI infoframe for
> HDMI 1.x sinks")
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_edid.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 365901c1c33c..56ebef0c5fad 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4871,6 +4871,11 @@
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> * @mode: DRM display mode
> * @rgb_quant_range: RGB quantization range (Q)
> * @rgb_quant_range_selectable: Sink support selectable RGB quantization
> range (QS)
> + * @is_hdmi2_sink: HDMI 2.0 sink, which has different default recommendations
> + *
> + * Note that @is_hdmi2_sink can be derrived by looking at the
typo : derived
With that fixed:
Acked-by: Alex Deucher
> + * &drm_scdc.supported flag stored in &drm_hdmi_info.scdc,
> + * &drm_display_info.hdmi, which can be found in &drm_connector.display_info.
> */
> void
> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/atomic: document how to handle driver private objects
On Thu, Dec 14, 2017 at 3:30 PM, Daniel Vetter wrote:
> DK put some nice docs into the commit introducing driver private
> state, but in the git history alone it'll be lost.
>
> Also, since Ville remove the void* usage it's a good opportunity to
> give the driver private stuff some tlc on the doc front.
>
> Finally try to explain why the "let's just subclass drm_atomic_state"
> approach wasn't the greatest, and annotate all those functions as
> deprecated in favour of more standardized driver private states. Also
> note where we could/should extend driver private states going forward
> (atm neither locking nor synchronization is handled in core/helpers,
> which isn't really all that great).
>
> Cc: Harry Wentland
> Cc: Dhinakaran Pandiyan
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Laurent Pinchart
> Cc: Rob Clark
> Cc: Alex Deucher
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic.c | 45
> ---
> include/drm/drm_atomic.h | 28 +++
> include/drm/drm_mode_config.h | 9 +
> 4 files changed, 85 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 307284125d7a..420025bd6a9b 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -271,6 +271,12 @@ Taken all together there's two consequences for the
> atomic design:
> Read on in this chapter, and also in :ref:`drm_atomic_helper` for more
> detailed
> coverage of specific topics.
>
> +Handling Driver Private State
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
> + :doc: handling driver private state
> +
> Atomic Mode Setting Function Reference
> --
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 37445d50816a..15e1a35c74a8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -50,7 +50,8 @@ EXPORT_SYMBOL(__drm_crtc_commit_free);
> * @state: atomic state
> *
> * Free all the memory allocated by drm_atomic_state_init.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> void drm_atomic_state_default_release(struct drm_atomic_state *state)
> {
> @@ -67,7 +68,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
> * @state: atomic state
> *
> * Default implementation for filling in a new atomic state.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> int
> drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
> @@ -132,7 +134,8 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
> * @state: atomic state
> *
> * Default implementation for clearing atomic state.
> - * This is useful for drivers that subclass the atomic state.
> + * This should only be used by drivers which are still subclassing
> + * &drm_atomic_state and haven't switched to &drm_private_state yet.
> */
> void drm_atomic_state_default_clear(struct drm_atomic_state *state)
> {
> @@ -946,6 +949,42 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> plane->funcs->atomic_print_state(p, state);
> }
>
> +/**
> + * DOC: handling driver private state
> + *
> + * Very often the DRM objects exposed to userspace in the atomic modeset api
> + * (&drm_connector, &drm_crtc and &drm_plane) do not map neatly to the
> + * underlying hardware. Especially for any kind of shared resources (e.g.
> shared
> + * clocks, scaler units, bandwidth and fifo limits shared among a group of
> + * planes or CRTCs, and so on) it makes sense to model these as independent
> + * objects. Drivers then need to similar state tracking and commit ordering
> for
> + * such private (since not exposed to userpace) objects as the atomic core
> and
> + * helpers already provide for connectors, planes and CRTCs.
This last sentence doesn't quite parse. I think it should be as follows:
Drivers then need to do similar state tracking and commit ordering for
such private (since not exposed to userpace) objects as the atomic core that
helpers already provide for DRM objects (connectors, planes and CRTCs).
Feel free to adjust as you see fit. With that fixed up:
Reviewed-by: Alex Deucher
> + *
> + * To make this easier on drivers the atomic core provides some support to
> track
> + * driver private state objects using struct &drm_private_obj, with the
> + * associated state struct &drm_private_state.
> + *
> + * Similar to userspace-exposed objects, state structures can be acquired by
> + * calling drm_atomic_get_private_obj_state().
[Bug 104142] Stack trace in runpm when Tonga card powers down
https://bugs.freedesktop.org/show_bug.cgi?id=104142 --- Comment #4 from Mike Lothian --- Tried again and it looks a little more promising: 0a214e2fb6b0a56519b6d5efab4b21475c233ee0 is the first bad commit commit 0a214e2fb6b0a56519b6d5efab4b21475c233ee0 Author: Andrey Grodzovsky Date: Thu Jul 13 10:56:48 2017 -0400 drm/amd/display: Release cached atomic state in S3. Fixes memory leak. Signed-off-by: Andrey Grodzovsky Reviewed-by: Tony Cheng Acked-by: Harry Wentland Signed-off-by: Alex Deucher :04 04 494f25ce4ad407678f88d6c85128905762c9fbfb fb36845ef2ccca7bf823c9fec4d13d0a6e71ea2b M drivers Which makes sense as that's the commit that adds the WARN_ON, I guess that takes us back to why is there a cached state -- 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 197851] Resume from suspend sometimes results in black screen on Radeon R5
https://bugzilla.kernel.org/show_bug.cgi?id=197851 --- Comment #4 from Tyler McLean (sonarsoundapplicati...@gmail.com) --- (In reply to Harry Wentland from comment #3) > Do you get different behavior if you enable the new DC display driver by > passing amdgpu.dc=1 to the kernel? Enabling that on the kernel results in an error on boot [drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc! causing Ubuntu to hang on the splash screen -- 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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 --- Comment #14 from Andrew --- Charly, Does X work all the time or only after reboot? -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Priority|high|medium Severity|critical|normal --- Comment #36 from FFAB --- Today I set this bug to "resolved fixed", importance to "medium, normal". Afterward I checked some hw infos, e.g. in the result of "sudo lshw -short" I miss the following line: /0/100/3.1/0 display Topaz XT [Radeon R7 M260/M265] So I assume, at the moment graphic and the A10-8780P APU is not yet full supported. -- 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 95306] Random Blank(black) screens on "Carrizo"
https://bugs.freedesktop.org/show_bug.cgi?id=95306 --- Comment #79 from Charly --- Hi It looks fine for me also !! On my carrizo A10-8700p rev c5 (probook 455 g3), when booting archlinux with kernel 4.15-rc3, journalctl raises an error reported in bug 104206 -- 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 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #18 from James Lovinsky --- Sorry, my mistake. Will refer to #95530, thanks! -- 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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 Charly changed: What|Removed |Added Attachment #136179|0 |1 is obsolete|| --- Comment #13 from Charly --- Created attachment 136182 --> https://bugs.freedesktop.org/attachment.cgi?id=136182&action=edit journalctl of a boot of my archlinux notebook totally cold -- 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 4/5] drm/atomic: document how to handle driver private objects
DK put some nice docs into the commit introducing driver private
state, but in the git history alone it'll be lost.
Also, since Ville remove the void* usage it's a good opportunity to
give the driver private stuff some tlc on the doc front.
Finally try to explain why the "let's just subclass drm_atomic_state"
approach wasn't the greatest, and annotate all those functions as
deprecated in favour of more standardized driver private states. Also
note where we could/should extend driver private states going forward
(atm neither locking nor synchronization is handled in core/helpers,
which isn't really all that great).
Cc: Harry Wentland
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Laurent Pinchart
Cc: Rob Clark
Cc: Alex Deucher
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic.c | 45 ---
include/drm/drm_atomic.h | 28 +++
include/drm/drm_mode_config.h | 9 +
4 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 307284125d7a..420025bd6a9b 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -271,6 +271,12 @@ Taken all together there's two consequences for the atomic
design:
Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
coverage of specific topics.
+Handling Driver Private State
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+ :doc: handling driver private state
+
Atomic Mode Setting Function Reference
--
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 37445d50816a..15e1a35c74a8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -50,7 +50,8 @@ EXPORT_SYMBOL(__drm_crtc_commit_free);
* @state: atomic state
*
* Free all the memory allocated by drm_atomic_state_init.
- * This is useful for drivers that subclass the atomic state.
+ * This should only be used by drivers which are still subclassing
+ * &drm_atomic_state and haven't switched to &drm_private_state yet.
*/
void drm_atomic_state_default_release(struct drm_atomic_state *state)
{
@@ -67,7 +68,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
* @state: atomic state
*
* Default implementation for filling in a new atomic state.
- * This is useful for drivers that subclass the atomic state.
+ * This should only be used by drivers which are still subclassing
+ * &drm_atomic_state and haven't switched to &drm_private_state yet.
*/
int
drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
@@ -132,7 +134,8 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
* @state: atomic state
*
* Default implementation for clearing atomic state.
- * This is useful for drivers that subclass the atomic state.
+ * This should only be used by drivers which are still subclassing
+ * &drm_atomic_state and haven't switched to &drm_private_state yet.
*/
void drm_atomic_state_default_clear(struct drm_atomic_state *state)
{
@@ -946,6 +949,42 @@ static void drm_atomic_plane_print_state(struct
drm_printer *p,
plane->funcs->atomic_print_state(p, state);
}
+/**
+ * DOC: handling driver private state
+ *
+ * Very often the DRM objects exposed to userspace in the atomic modeset api
+ * (&drm_connector, &drm_crtc and &drm_plane) do not map neatly to the
+ * underlying hardware. Especially for any kind of shared resources (e.g.
shared
+ * clocks, scaler units, bandwidth and fifo limits shared among a group of
+ * planes or CRTCs, and so on) it makes sense to model these as independent
+ * objects. Drivers then need to similar state tracking and commit ordering for
+ * such private (since not exposed to userpace) objects as the atomic core and
+ * helpers already provide for connectors, planes and CRTCs.
+ *
+ * To make this easier on drivers the atomic core provides some support to
track
+ * driver private state objects using struct &drm_private_obj, with the
+ * associated state struct &drm_private_state.
+ *
+ * Similar to userspace-exposed objects, state structures can be acquired by
+ * calling drm_atomic_get_private_obj_state(). Since this function does not
take
+ * care of locking, drivers should wrap it for each type of private state
object
+ * they have with the required call to drm_modeset_lock() for the corresponding
+ * &drm_modeset_lock.
+ *
+ * All private state structures contained in a &drm_atomic_state update can be
+ * iterated using for_each_oldnew_private_obj_in_state(),
+ * for_each_old_private_obj_in_state() and for_each_old_private_obj_in_state().
+ * Drivers are recommend to wrap these for each type of driver private state
+ * object they have, filtering on &drm_private_obj.funcs using for_each_if(),
at
+ * least if they want to iterate over all o
[PATCH 3/5] drm/syncobj: some kerneldoc polish
Complete a few missing bits, fix up the existing xcross-references and
add a bunch more.
Cc: Dave Airlie via lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 45 +++
include/drm/drm_syncobj.h | 32 +-
2 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 9b733c510cbf..b6d0c2c400ec 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -29,9 +29,9 @@
/**
* DOC: Overview
*
- * DRM synchronisation objects (syncobj) are a persistent objects,
- * that contain an optional fence. The fence can be updated with a new
- * fence, or be NULL.
+ * DRM synchronisation objects (syncobj, see struct &drm_syncobj) are a
+ * persistent objects, that contain an optional fence. The fence can be updated
+ * with a new fence, or be NULL.
*
* syncobj's can be waited upon, where it will wait for the underlying
* fence.
@@ -61,7 +61,8 @@
* @file_private: drm file private pointer
* @handle: sync object handle to lookup.
*
- * Returns a reference to the syncobj pointed to by handle or NULL.
+ * Returns a reference to the syncobj pointed to by handle or NULL. The
+ * reference must be released by calling drm_syncobj_put().
*/
struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
u32 handle)
@@ -229,6 +230,19 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
return 0;
}
+/**
+ * drm_syncobj_find_fence - lookup and reference the fence in a sync object
+ * @file_private: drm file private pointer
+ * @handle: sync object handle to lookup.
+ * @fence: out parameter for the fence
+ *
+ * This is just a convenience function that combines drm_syncobj_find() and
+ * drm_syncobj_fence_get().
+ *
+ * Returns 0 on success or a negative error value on failure. On success @fence
+ * contains a reference to the fence, which mus be released by calling
+ * dma_fence_put().
+ */
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle,
struct dma_fence **fence)
@@ -269,6 +283,12 @@ EXPORT_SYMBOL(drm_syncobj_free);
* @out_syncobj: returned syncobj
* @flags: DRM_SYNCOBJ_* flags
* @fence: if non-NULL, the syncobj will represent this fence
+ *
+ * This is the first function to create a sync object. After creating drivers
+ * probably want to make it available to userspace, either through
+ * drm_syncobj_get_handle() or drm_syncobj_get_fd().
+ *
+ * Returns 0 on success or a negative error value on failure.
*/
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
struct dma_fence *fence)
@@ -302,6 +322,14 @@ EXPORT_SYMBOL(drm_syncobj_create);
/**
* drm_syncobj_get_handle - get a handle from a syncobj
+ * @file_private: drm file private pointer
+ * @syncobj: Sync object to export
+ * @handle: out parameter with the new handle
+ *
+ * Exports a sync object created with drm_syncobj_create() as a handle on
+ * @file_private to userspace.
+ *
+ * Returns 0 on success or a negative error value on failure.
*/
int drm_syncobj_get_handle(struct drm_file *file_private,
struct drm_syncobj *syncobj, u32 *handle)
@@ -388,6 +416,15 @@ static int drm_syncobj_alloc_file(struct drm_syncobj
*syncobj)
return 0;
}
+/**
+ * drm_syncobj_get_fd - get a file descriptor from a syncobj
+ * @syncobj: Sync object to export
+ * @p_fd: out parameter with the new file descriptor
+ *
+ * Exports a sync object created with drm_syncobj_create() as a file
descriptor.
+ *
+ * Returns 0 on success or a negative error value on failure.
+ */
int drm_syncobj_get_fd(struct drm_syncobj *syncobj, int *p_fd)
{
int ret;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 9e8ba90c6784..87865774bdaa 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -33,36 +33,31 @@ struct drm_syncobj_cb;
/**
* struct drm_syncobj - sync object.
*
- * This structure defines a generic sync object which wraps a dma fence.
+ * This structure defines a generic sync object which wraps a &dma_fence.
*/
struct drm_syncobj {
/**
-* @refcount:
-*
-* Reference count of this object.
+* @refcount: Reference count of this object.
*/
struct kref refcount;
/**
* @fence:
* NULL or a pointer to the fence bound to this object.
*
-* This field should not be used directly. Use drm_syncobj_fence_get
-* and drm_syncobj_replace_fence instead.
+* This field should not be used directly. Use drm_syncobj_fence_get()
+* and drm_syncobj_replace_fence() instead.
*/
struct dma_fence __rcu *fence;
/**
-* @cb_list:
-* List of callbacks to call wh
[PATCH 1/5] drm/edid: kerneldoc for is_hdmi2_sink
Also some breadcrumbs for how exactly to find this. Probably should
pass drm_connector * or at least drm_display_info * to that function
instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
drm_connector_state (and the hdmi stuff moved into that), so this is a
bit more work.
Cc: Ville Syrjälä
Fixes: 9271c0ca573e ("drm/edid: Don't send non-zero YQ in AVI infoframe for
HDMI 1.x sinks")
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 365901c1c33c..56ebef0c5fad 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4871,6 +4871,11 @@ EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
* @mode: DRM display mode
* @rgb_quant_range: RGB quantization range (Q)
* @rgb_quant_range_selectable: Sink support selectable RGB quantization range
(QS)
+ * @is_hdmi2_sink: HDMI 2.0 sink, which has different default recommendations
+ *
+ * Note that @is_hdmi2_sink can be derrived by looking at the
+ * &drm_scdc.supported flag stored in &drm_hdmi_info.scdc,
+ * &drm_display_info.hdmi, which can be found in &drm_connector.display_info.
*/
void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/print: Unconfuse kerneldoc
It thinks we want to document the __printf(2,0) annotion. Not sure we
want to teach it about all possible gcc-only flags, hence why I opted
for the cheap trick of just moving it ahead of the kerneldoc.
This is only a problem for static inline functions, since for
non-inline function the kerneldoc is in the .c file, but the special
annotations are all in the header.
Cc'ing kernel-doc maintainers as fyi.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
---
include/drm/drm_print.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 5f9932e2246e..2a4a42e59a47 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -80,13 +80,13 @@ void __drm_printfn_debug(struct drm_printer *p, struct
va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
+__printf(2, 0)
/**
* drm_vprintf - print to a &drm_printer stream
* @p: the &drm_printer
* @fmt: format string
* @va: the va_list
*/
-__printf(2, 0)
static inline void
drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
{
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/doc: Move legacy kms helpers to the very end
We don't want people to accidentally stumble over there.
Also rename the plane helpers to legacy plane helpers. After Ville's
patch to make the clipping helper atomic and move it to
drm_atomic_helper.c there's nothing left in there that should be
useful for modern drivers.
v2: Laurent had a few questions around how state is added to
drm_atomic_state, tried to clarify that. And spotted another sentence
where the docs suggested subclassing.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 36 +--
Documentation/gpu/drm-kms.rst | 8
include/drm/drm_atomic.h | 4
3 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 3ea622876b67..e37557b30f62 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -74,15 +74,6 @@ Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:export:
-Legacy CRTC/Modeset Helper Functions Reference
-==
-
-.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
- :doc: overview
-
-.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
- :export:
-
Simple KMS Helper Reference
===
@@ -282,15 +273,6 @@ Flip-work Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_flip_work.c
:export:
-Plane Helper Reference
-==
-
-.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
- :doc: overview
-
-.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
- :export:
-
Auxiliary Modeset Helpers
=
@@ -308,3 +290,21 @@ Framebuffer GEM Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
:export:
+
+Legacy Plane Helper Reference
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
+ :export:
+
+Legacy CRTC/Modeset Helper Functions Reference
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
+ :export:
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 420025bd6a9b..cbba93483aec 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -263,10 +263,10 @@ Taken all together there's two consequences for the
atomic design:
- An atomic update is assembled and validated as an entirely free-standing pile
of structures within the :c:type:`drm_atomic_state `
- container. Again drivers can subclass that container for their own state
- structure tracking needs. Only when a state is committed is it applied to the
- driver and modeset objects. This way rolling back an update boils down to
- releasing memory and unreferencing objects like framebuffers.
+ container. Driver private state structures are also tracked in the same
+ structure, see the next chapter. Only when a state is committed is it
applied
+ to the driver and modeset objects. This way rolling back an update boils down
+ to releasing memory and unreferencing objects like framebuffers.
Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
coverage of specific topics.
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 8e4829a25c1b..e7f25e342cc8 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -246,6 +246,10 @@ struct __drm_private_objs_state {
* @num_private_objs: size of the @private_objs array
* @private_objs: pointer to array of private object pointers
* @acquire_ctx: acquire context for this atomic modeset state update
+ *
+ * States are added to an atomic update by calling drm_atomic_get_crtc_state(),
+ * drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
+ * private state structures, drm_atomic_get_private_obj_state().
*/
struct drm_atomic_state {
struct kref ref;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] bunch of drm kernel-doc patches
Hi all, Originally I wanted to include the atomic helper split-up here, but once more I failed to get that done. So just a few patches to clean up accumlated kernel-doc warnings, plus some real docs for the new best practices for handling driver private objects. That was motivated by a recent discussion. Cheers, Daniel Daniel Vetter (5): drm/edid: kerneldoc for is_hdmi2_sink drm/print: Unconfuse kerneldoc drm/syncobj: some kerneldoc polish drm/atomic: document how to handle driver private objects drm/doc: Move legacy kms helpers to the very end Documentation/gpu/drm-kms-helpers.rst | 36 ++-- Documentation/gpu/drm-kms.rst | 14 +++ drivers/gpu/drm/drm_atomic.c | 45 --- drivers/gpu/drm/drm_edid.c| 5 drivers/gpu/drm/drm_syncobj.c | 45 +++ include/drm/drm_atomic.h | 32 + include/drm/drm_mode_config.h | 9 +++ include/drm/drm_print.h | 2 +- include/drm/drm_syncobj.h | 32 +++-- 9 files changed, 177 insertions(+), 43 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION
On Thu, Dec 14, 2017 at 08:10:08PM +0100, Noralf Trønnes wrote: > Make it possible to opt out of fbdev emulation. > DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so > this doesn't change the default behaviour. > > Cc: Laurent Pinchart > Signed-off-by: Noralf Trønnes For all the patches I didn't comment on: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/Kconfig | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index d853989848d6..fe1b6030d3c6 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -143,10 +143,7 @@ config DRM_KMS_CMA_HELPER > bool > depends on DRM > select DRM_GEM_CMA_HELPER > - select DRM_KMS_FB_HELPER > - select FB_SYS_FILLRECT > - select FB_SYS_COPYAREA > - select FB_SYS_IMAGEBLIT > + select DRM_KMS_HELPER > help > Choose this if you need the KMS CMA helper functions > > -- > 2.14.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()
On Thu, Dec 14, 2017 at 08:10:06PM +0100, Noralf Trønnes wrote:
> Add helper for initializing fbdev deferred I/O.
>
> The cleanup could have happened in drm_fb_helper_fini(), but that would
> have required me to set fb_info->fbdefio to NULL in a couple of drivers
> before they call _fini() to avoid double defio cleanup. The problem is
> that one of those is vboxvideo which lives in Greg's staging tree.
> So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
> but not that bad either.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 53
> +
> include/drm/drm_fb_helper.h | 6 +
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 14aa83579e76..d5eeed1c7749 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
> }
> EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>
> +/**
> + * drm_fb_helper_defio_init - fbdev deferred I/O initialization
> + * @fb_helper: driver-allocated fbdev helper
> + *
> + * This function allocates &fb_deferred_io, sets callback to
> + * drm_fb_helper_deferred_io(), delay to 50ms and calls
> fb_deferred_io_init().
> + * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
> + *
> + * NOTE: A copy of &fb_ops is made and assigned to &info->fbops. This is done
> + * because fb_deferred_io_cleanup() clears &fbops->fb_mmap and would thereby
> + * affect other instances of that &fb_ops.
Do we need to call this before initial_config? Or after? Should be
documented imo.
Also, did you look into just fixing fb_deferred_io_cleanup to no longer do
this? Changing function tables is definitely not cool (because that means
we can't put them into read-only memory and protect them from attackers -
function tables are a high-value target in the kernel, since usually easy
to trigger them).
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
> +{
> + struct fb_info *info = fb_helper->fbdev;
> + struct fb_deferred_io *fbdefio;
> + struct fb_ops *fbops;
> +
> + fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> + fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> + if (!fbdefio || !fbops) {
> + kfree(fbdefio);
> + kfree(fbops);
> + return -ENOMEM;
> + }
> +
> + info->fbdefio = fbdefio;
> + fbdefio->delay = msecs_to_jiffies(50);
> + fbdefio->deferred_io = drm_fb_helper_deferred_io;
> +
> + *fbops = *info->fbops;
> + info->fbops = fbops;
> +
> + fb_deferred_io_init(info);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_defio_init);
> +
> /**
> * drm_fb_helper_sys_read - wrapper around fb_sys_read
> * @info: fb_info struct pointer
> @@ -2743,6 +2785,9 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
> * The caller must to provide a &drm_fb_helper_funcs->fb_probe callback
> * function.
> *
> + * Drivers that need fbdev deferred I/O should use drm_fb_helper_defio_init()
> + * to set it up.
Not exactly sure why you put this here ... Maybe throw it into the
overview documentation, in a new paragraph that explains when you have a
non-NULL fb->dirty callback, then you most likely want to setup
defio_init. Except for the shmem fun. Explaining all that would be good
(maybe even put it under a "Framebuffer Flushing" heading).
Otherwise looks all reasonable to me.
Cheers, Daniel
> + *
> * See also: drm_fb_helper_initial_config()
> *
> * Returns:
> @@ -2818,6 +2863,7 @@ EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
> void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
> {
> struct drm_fb_helper *fb_helper = dev->fb_helper;
> + struct fb_ops *fbops = NULL;
>
> if (!fb_helper)
> return;
> @@ -2826,7 +2872,14 @@ void drm_fb_helper_fbdev_teardown(struct drm_device
> *dev)
> if (fb_helper->fbdev && fb_helper->fbdev->dev)
> drm_fb_helper_unregister_fbi(fb_helper);
>
> + if (fb_helper->fbdev && fb_helper->fbdev->fbdefio) {
> + fb_deferred_io_cleanup(fb_helper->fbdev);
> + kfree(fb_helper->fbdev->fbdefio);
> + fbops = fb_helper->fbdev->fbops;
> + }
> +
> drm_fb_helper_fini(fb_helper);
> + kfree(fbops);
>
> if (fb_helper->fb)
> drm_framebuffer_remove(fb_helper->fb);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index aa78ac3b8ad0..b069433e7fc1 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -276,6 +276,7 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper
> *fb_helper);
>
> void drm_fb_helper_deferred_io(struct fb_info *info,
> struct list_head *pagelist);
> +int drm_fb_helper_defio_init(struct drm_fb_helper *fb_he
[Bug 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #17 from Gert Wollny --- @James Lovinsky: since you are running the game on Intel graphics hardware you probably saw #95530, this bug refers to AMD hardware (r600). -- 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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 --- Comment #12 from Charly --- hi team By installing kerenl 4.15-rc3 the blamk screen related on bug 95306 seems to be fixed, and I'm very happy for that ! the message : [drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc! only appers when the laptop is cold (not a reboot, but a boot after it was powered off until it is cold) The APU is a carrizo A10-8700p rev c5. Absolutely no issue with X: I can start (xfce4) manually. I guess the error appears during mode setting. Before we got blamk screen... and now we have this message ... -- 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 2/7] drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
On Thu, Dec 14, 2017 at 08:10:03PM +0100, Noralf Trønnes wrote:
> Add helpers to setup and teardown fbdev emulation.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 106
>
> include/drm/drm_fb_helper.h | 25 ++
> 2 files changed, 131 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 04a3a5ce370a..823fc8f50d85 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2729,6 +2729,112 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
> *fb_helper)
> }
> EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
>
> +/**
> + * drm_fb_helper_fbdev_setup() - Setup fbdev emulation
> + * @dev: DRM device
> + * @fb_helper: fbdev helper structure to set up
> + * @funcs: fbdev helper functions
> + * @preferred_bpp: Preferred bits per pixel for the device.
> + * @dev->mode_config.preferred_depth is used if this is zero.
> + * @max_conn_count: Maximum number of connectors.
> + * @dev->mode_config.num_connector is used if this is zero.
> + *
> + * This function sets up fbdev emulation and registers fbdev for access by
> + * userspace. If all connectors are disconnected, setup is deferred to the
> next
> + * time drm_fb_helper_hotplug_event() is called.
> + * The caller must to provide a &drm_fb_helper_funcs->fb_probe callback
> + * function.
I think we should be a bit clearer when it's not advisable to use this
helper because there are issues:
- when connectors can be hotplugged (e.g. dp mst). For that case you need
to init the fbdev before you enabling hotplugging, but call
initial_config after you've enabled hotplugging. Otherwise there's a
posssible race window.
- when there's anything else that mus be done before we do the fbdev
registration, e.g. defio_init.
So still not 100% sure this will help you all that much, but it's also not
an unreasonable idea.
Assuming we can agree on the ceveats and how do document them:
Reviewed-by: Daniel Vetter
> + *
> + * See also: drm_fb_helper_initial_config()
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_fb_helper_fbdev_setup(struct drm_device *dev,
> + struct drm_fb_helper *fb_helper,
> + const struct drm_fb_helper_funcs *funcs,
> + unsigned int preferred_bpp,
> + unsigned int max_conn_count)
> +{
> + int ret;
> +
> + if (!preferred_bpp)
> + preferred_bpp = dev->mode_config.preferred_depth;
> + if (!preferred_bpp)
> + preferred_bpp = 32;
> +
> + if (!max_conn_count)
> + max_conn_count = dev->mode_config.num_connector;
> + if (!max_conn_count) {
> + DRM_DEV_ERROR(dev->dev, "No connectors\n");
> + return -EINVAL;
> + }
> +
> + drm_fb_helper_prepare(dev, fb_helper, funcs);
> +
> + ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper\n");
> + return ret;
> + }
> +
> + ret = drm_fb_helper_single_add_all_connectors(fb_helper);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev->dev, "Failed to add connectors\n");
> + goto err_drm_fb_helper_fini;
> + }
> +
> + if (!drm_drv_uses_atomic_modeset(dev))
> + drm_helper_disable_unused_functions(dev);
> +
> + ret = drm_fb_helper_initial_config(fb_helper, preferred_bpp);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev->dev, "Failed to set fbdev configuration\n");
> + goto err_drm_fb_helper_fini;
> + }
> +
> + return 0;
> +
> +err_drm_fb_helper_fini:
> + drm_fb_helper_fini(fb_helper);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
> +
> +/**
> + * drm_fb_helper_fbdev_teardown - Tear down fbdev emulation
> + * @dev: DRM device
> + *
> + * This function unregisters fbdev if not already done and cleans up the
> + * associated resources including the &drm_framebuffer.
> + * The driver is responsible for freeing the &drm_fb_helper structure which
> is
> + * stored in &drm_device->fb_helper. Do note that this pointer has been
> cleared
> + * when this function returns.
> + *
> + * In order to support device removal/unplug while file handles are still
> open,
> + * drm_fb_helper_unregister_fbi() should be called on device removal and
> + * drm_fb_helper_fbdev_teardown() in the &drm_driver->release callback when
> + * file handles are closed.
> + */
> +void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
> +{
> + struct drm_fb_helper *fb_helper = dev->fb_helper;
> +
> + if (!fb_helper)
> + return;
> +
> + /* Unregister if it hasn't been done already */
> + if (fb_helper->fbdev && fb_helper->fbdev->dev)
> + drm_fb_helper_unregi
[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 --- Comment #11 from Charly --- Created attachment 136181 --> https://bugs.freedesktop.org/attachment.cgi?id=136181&action=edit kernel parameters set for 4.15-rc3 -- 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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #10 from Charly ---
Created attachment 136180
--> https://bugs.freedesktop.org/attachment.cgi?id=136180&action=edit
lspci -vv {Probook 455 G3 carrizo a10-8700p rev c5)
--
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 --- Comment #9 from Charly --- Created attachment 136179 --> https://bugs.freedesktop.org/attachment.cgi?id=136179&action=edit journalctl from a boot with a cold laptop archlinux -- 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 1/7] drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
On Thu, Dec 14, 2017 at 08:10:02PM +0100, Noralf Trønnes wrote:
> Set dev->fb_helper even when fbdev emulation is compiled out,
> so drivers can use it to free the structure.
> Clear it for consistency.
>
> Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_fb_helper.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 1494b12a984a..1bd624579db7 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -33,6 +33,7 @@
> struct drm_fb_helper;
>
> #include
> +#include
> #include
>
> enum mode_set_atomic {
> @@ -332,11 +333,17 @@ static inline int drm_fb_helper_init(struct drm_device
> *dev,
> struct drm_fb_helper *helper,
> int max_conn)
> {
> + /* So drivers can use it to free the struct */
> + helper->dev = dev;
> + dev->fb_helper = helper;
Not sure I forgot it, or it got dropped, but I'd like
dev->mode_config.fb_helper better. That's where all the other kms stuff
resides.
But 100% bikeshed, so feel free to ignore. Definitely only a follow-up
patch.
-Daniel
> +
> return 0;
> }
>
> static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
> {
> + if (helper && helper->dev)
> + helper->dev->fb_helper = NULL;
> }
>
> static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
> --
> 2.14.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: add separate entry for DRM TTM
On Thu, Dec 14, 2017 at 04:15:27PM +0100, Christian König wrote: > Am 14.12.2017 um 15:41 schrieb Daniel Vetter: > > On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote: > > > On Thu, Dec 14, 2017 at 8:37 AM, Christian König > > > wrote: > > > > AMD is the major user of TTM, so it also makes sense that we maintain > > > > it. > > > > > > > > Signed-off-by: Christian König > > > Acked-by: Alex Deucher > > > > > > > --- > > > > MAINTAINERS | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 069ba63190b2..72e8f8f750ec 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -4805,6 +4805,14 @@ S: Maintained > > > > F: drivers/gpu/drm/tinydrm/ > > > > F: include/drm/tinydrm/ > > > > > > > > +DRM TTM SUBSYSTEM > > > > +M: Christian Koenig > > > > +M: Roger He > > > > +S: Maintained > > > > +L: dri-devel@lists.freedesktop.org > > > > +F: include/drm/ttm/ > > > > +F: drivers/gpu/drm/ttm/ > > A git tree would be good here I think. Defacto that's right now the amd > > tree. > > Yeah, I was wondering what to do with that as well. > > I see three possible options of hand: > A) Stick with the amd trees maintained by Alex. > B) Come up with separate ones. > C) Use drm-misc. > > For now I think I will stick with A if there are no objections. For C, would be happy to add Roger He as committer if there's a need. Assuming you make sure he writes good commit message ofc :-) -Daniel > > Christian. > > > -Daniel > > > > > > + > > > > DSBR100 USB FM RADIO DRIVER > > > > M: Alexey Klimov > > > > L: linux-me...@vger.kernel.org > > > > -- > > > > 2.11.0 > > > > > > > > ___ > > > > 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 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: tinydrm: page allocation failure
Den 14.12.2017 17.25, skrev David Lechner:
On 12/11/2017 06:45 AM, Noralf Trønnes wrote:
Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as
seen in the stack traces below. I'm not really sure what to make of
it. Any ideas?
I'm starting to wonder if there is some sort of race condition
involved. I only get this warning on some boots, but when I do, it
happens multiple times. Also, when I was debugging a an unrelated
problem, I enabled some of the spin lock checking kernel options that
really slow down the kernel. When I did this, I got this warning all
of the time.
Would it be sensible to allocate a dummy RX buffer once instead of
letting SPI allocate a new one for every transfer?
I have looked at the code and the dummy buffer is needed by some
drivers for DMA transfers. They need both tx and rx buffers to do the
transfer. A solution might be to let tinydrm allocate a dummy rx buffer
and attach it to every spi_transfer.
We could check if it's really needed:
if (spi->controller->flags & (SPI_CONTROLLER_MUST_RX |
SPI_CONTROLLER_MUST_TX))
// allocate dummy rx buffer
And maybe something like this:
+ * @dummy_rx_buf: Optional dummy rx buffer to avoid per transfer
allocation of
+ * dummy rx buffers in the spi core.
int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
struct spi_transfer *header, u8 bpw, const void *buf,
- size_t len)
+ size_t len, void dummy_rx_buf)
{
struct spi_transfer tr = {
.bits_per_word = bpw,
.speed_hz = speed_hz,
+ .rx_buf = dummy_rx_buf,
};
Noralf.
The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller
order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.
On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:
$ sudo cat /proc/buddyinfo
Node 0, zone Normal 40 68 66 51 43 46 13
1 3 3 75
I don't know what those dummy buffers are used for.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-fixes
On Thu, Dec 14, 2017 at 6:50 AM, Daniel Vetter wrote: > > Imo that's enough that I figured better not delay until Dave is back. > Linus, can you pls apply? Pulled. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, I'm back, resuming with fixes for v4.15. BR, Jani. The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36: Linux 4.15-rc3 (2017-12-10 17:56:26 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-12-14 for you to fetch changes up to 2cf654db8d7eafb973d28eb3cddf043d353e1345: drm/i915/fence: Use rcu to defer freeing of irq_work (2017-12-14 10:58:59 +0200) drm/i915 fixes for v4.15-rc4 Chris Wilson (4): drm/i915: Flush pending GTT writes before unbinding drm/i915: Drop fb reference on load_detect_pipe failure path drm/i915: Stop listening to request resubmission from the signaler kthread drm/i915/fence: Use rcu to defer freeing of irq_work drivers/gpu/drm/i915/i915_gem.c | 9 + drivers/gpu/drm/i915/i915_sw_fence.c | 3 ++- drivers/gpu/drm/i915/intel_breadcrumbs.c | 22 +++--- drivers/gpu/drm/i915/intel_display.c | 3 +-- 4 files changed, 15 insertions(+), 22 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()
Add helpers to setup and teardown fbdev emulation.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 106
include/drm/drm_fb_helper.h | 25 ++
2 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04a3a5ce370a..823fc8f50d85 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2729,6 +2729,112 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
+/**
+ * drm_fb_helper_fbdev_setup() - Setup fbdev emulation
+ * @dev: DRM device
+ * @fb_helper: fbdev helper structure to set up
+ * @funcs: fbdev helper functions
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ * @max_conn_count: Maximum number of connectors.
+ * @dev->mode_config.num_connector is used if this is zero.
+ *
+ * This function sets up fbdev emulation and registers fbdev for access by
+ * userspace. If all connectors are disconnected, setup is deferred to the next
+ * time drm_fb_helper_hotplug_event() is called.
+ * The caller must to provide a &drm_fb_helper_funcs->fb_probe callback
+ * function.
+ *
+ * See also: drm_fb_helper_initial_config()
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fb_helper_fbdev_setup(struct drm_device *dev,
+ struct drm_fb_helper *fb_helper,
+ const struct drm_fb_helper_funcs *funcs,
+ unsigned int preferred_bpp,
+ unsigned int max_conn_count)
+{
+ int ret;
+
+ if (!preferred_bpp)
+ preferred_bpp = dev->mode_config.preferred_depth;
+ if (!preferred_bpp)
+ preferred_bpp = 32;
+
+ if (!max_conn_count)
+ max_conn_count = dev->mode_config.num_connector;
+ if (!max_conn_count) {
+ DRM_DEV_ERROR(dev->dev, "No connectors\n");
+ return -EINVAL;
+ }
+
+ drm_fb_helper_prepare(dev, fb_helper, funcs);
+
+ ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper\n");
+ return ret;
+ }
+
+ ret = drm_fb_helper_single_add_all_connectors(fb_helper);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev->dev, "Failed to add connectors\n");
+ goto err_drm_fb_helper_fini;
+ }
+
+ if (!drm_drv_uses_atomic_modeset(dev))
+ drm_helper_disable_unused_functions(dev);
+
+ ret = drm_fb_helper_initial_config(fb_helper, preferred_bpp);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev->dev, "Failed to set fbdev configuration\n");
+ goto err_drm_fb_helper_fini;
+ }
+
+ return 0;
+
+err_drm_fb_helper_fini:
+ drm_fb_helper_fini(fb_helper);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
+
+/**
+ * drm_fb_helper_fbdev_teardown - Tear down fbdev emulation
+ * @dev: DRM device
+ *
+ * This function unregisters fbdev if not already done and cleans up the
+ * associated resources including the &drm_framebuffer.
+ * The driver is responsible for freeing the &drm_fb_helper structure which is
+ * stored in &drm_device->fb_helper. Do note that this pointer has been cleared
+ * when this function returns.
+ *
+ * In order to support device removal/unplug while file handles are still open,
+ * drm_fb_helper_unregister_fbi() should be called on device removal and
+ * drm_fb_helper_fbdev_teardown() in the &drm_driver->release callback when
+ * file handles are closed.
+ */
+void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
+{
+ struct drm_fb_helper *fb_helper = dev->fb_helper;
+
+ if (!fb_helper)
+ return;
+
+ /* Unregister if it hasn't been done already */
+ if (fb_helper->fbdev && fb_helper->fbdev->dev)
+ drm_fb_helper_unregister_fbi(fb_helper);
+
+ drm_fb_helper_fini(fb_helper);
+
+ if (fb_helper->fb)
+ drm_framebuffer_remove(fb_helper->fb);
+}
+EXPORT_SYMBOL(drm_fb_helper_fbdev_teardown);
+
/**
* drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
* @dev: DRM device
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 1bd624579db7..aa78ac3b8ad0 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -320,6 +320,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
*fb_helper, struct drm_
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector);
+int drm_fb_helper_fbdev_setup(struct drm_device *dev,
+ struct drm_fb_helper *fb_helper,
+
[PATCH 3/7] drm/docs: Add todo entry for drm_fb_helper_fbdev_setup()
Add entry for conversion of drivers to new helpers. Signed-off-by: Noralf Trønnes --- Documentation/gpu/todo.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index f421a54527d2..1e593370f64f 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -194,6 +194,24 @@ drm_mode_config_helper_suspend/resume(). Contact: Maintainer of the driver you plan to convert +Convert drivers to use drm_fb_helper_fbdev_setup/teardown() +--- + +Most drivers can use drm_fb_helper_fbdev_setup() except maybe: + +- amdgpu which has special logic to decide whether to call + drm_helper_disable_unused_functions() + +- armada which isn't atomic and doesn't call + drm_helper_disable_unused_functions() + +- i915 which calls drm_fb_helper_initial_config() in a worker + +Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can +probably use drm_fb_helper_fbdev_teardown(). + +Contact: Maintainer of the driver you plan to convert + Core refactorings = -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/fb-helper: Add drm_fb_helper_defio_init()
Add helper for initializing fbdev deferred I/O.
The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h | 6 +
2 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14aa83579e76..d5eeed1c7749 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1022,6 +1022,48 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
+/**
+ * drm_fb_helper_defio_init - fbdev deferred I/O initialization
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This function allocates &fb_deferred_io, sets callback to
+ * drm_fb_helper_deferred_io(), delay to 50ms and calls fb_deferred_io_init().
+ * drm_fb_helper_fbdev_teardown() cleans up deferred I/O.
+ *
+ * NOTE: A copy of &fb_ops is made and assigned to &info->fbops. This is done
+ * because fb_deferred_io_cleanup() clears &fbops->fb_mmap and would thereby
+ * affect other instances of that &fb_ops.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
+{
+ struct fb_info *info = fb_helper->fbdev;
+ struct fb_deferred_io *fbdefio;
+ struct fb_ops *fbops;
+
+ fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
+ fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+ if (!fbdefio || !fbops) {
+ kfree(fbdefio);
+ kfree(fbops);
+ return -ENOMEM;
+ }
+
+ info->fbdefio = fbdefio;
+ fbdefio->delay = msecs_to_jiffies(50);
+ fbdefio->deferred_io = drm_fb_helper_deferred_io;
+
+ *fbops = *info->fbops;
+ info->fbops = fbops;
+
+ fb_deferred_io_init(info);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_defio_init);
+
/**
* drm_fb_helper_sys_read - wrapper around fb_sys_read
* @info: fb_info struct pointer
@@ -2743,6 +2785,9 @@ EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
* The caller must to provide a &drm_fb_helper_funcs->fb_probe callback
* function.
*
+ * Drivers that need fbdev deferred I/O should use drm_fb_helper_defio_init()
+ * to set it up.
+ *
* See also: drm_fb_helper_initial_config()
*
* Returns:
@@ -2818,6 +2863,7 @@ EXPORT_SYMBOL(drm_fb_helper_fbdev_setup);
void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
{
struct drm_fb_helper *fb_helper = dev->fb_helper;
+ struct fb_ops *fbops = NULL;
if (!fb_helper)
return;
@@ -2826,7 +2872,14 @@ void drm_fb_helper_fbdev_teardown(struct drm_device *dev)
if (fb_helper->fbdev && fb_helper->fbdev->dev)
drm_fb_helper_unregister_fbi(fb_helper);
+ if (fb_helper->fbdev && fb_helper->fbdev->fbdefio) {
+ fb_deferred_io_cleanup(fb_helper->fbdev);
+ kfree(fb_helper->fbdev->fbdefio);
+ fbops = fb_helper->fbdev->fbops;
+ }
+
drm_fb_helper_fini(fb_helper);
+ kfree(fbops);
if (fb_helper->fb)
drm_framebuffer_remove(fb_helper->fb);
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index aa78ac3b8ad0..b069433e7fc1 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -276,6 +276,7 @@ void drm_fb_helper_unlink_fbi(struct drm_fb_helper
*fb_helper);
void drm_fb_helper_deferred_io(struct fb_info *info,
struct list_head *pagelist);
+int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper);
ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
size_t count, loff_t *ppos);
@@ -423,6 +424,11 @@ static inline void drm_fb_helper_deferred_io(struct
fb_info *info,
{
}
+static inline int drm_fb_helper_defio_init(struct drm_fb_helper *fb_helper)
+{
+ return -ENODEV;
+}
+
static inline ssize_t drm_fb_helper_sys_read(struct fb_info *info,
char __user *buf, size_t count,
loff_t *ppos)
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/fb-helper: Update DOC with new helpers
Promote new helpers for dealing with fbdev emulation. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 823fc8f50d85..14aa83579e76 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -66,19 +66,17 @@ static DEFINE_MUTEX(kernel_fb_helper_lock); * helper functions used by many drivers to implement the kernel mode setting * interfaces. * - * Initialization is done as a four-step process with drm_fb_helper_prepare(), - * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and - * drm_fb_helper_initial_config(). Drivers with fancier requirements than the - * default behaviour can override the third step with their own code. - * Teardown is done with drm_fb_helper_fini() after the fbdev device is - * unregisters using drm_fb_helper_unregister_fbi(). + * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it + * down by calling drm_fb_helper_fbdev_teardown(). * - * At runtime drivers should restore the fbdev console by calling - * drm_fb_helper_restore_fbdev_mode_unlocked() from their &drm_driver.lastclose - * callback. They should also notify the fb helper code from updates to the - * output configuration by calling drm_fb_helper_hotplug_event(). For easier - * integration with the output polling code in drm_crtc_helper.c the modeset - * code provides a &drm_mode_config_funcs.output_poll_changed callback. + * At runtime drivers should restore the fbdev console by using + * drm_fb_helper_lastclose() as their &drm_driver.lastclose callback. + * They should also notify the fb helper code from updates to the output + * configuration by using drm_fb_helper_output_poll_changed() as their + * &drm_mode_config_funcs.output_poll_changed callback. + * + * For suspend/resume consider using drm_mode_config_helper_suspend() and + * drm_mode_config_helper_resume() which takes care of fbdev as well. * * All other functions exported by the fb helper library can be used to * implement the fbdev driver interface by the driver. -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/fb-cma-helper: Use drm_fb_helper_fbdev_setup/teardown()
Use the new setup/teardown helpers as well as drm_fb_helper_defio_init().
Wrap fb_deferred_io_mmap() in ifdef so we can make fbdev optional.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
I had to touch drm_fbdev_cma_fini() here, but that will be rebased away
when I this patch is unblocked and applied:
[PATCH v3 11/11] drm/cma-helper: Remove drm_fbdev_cma* functions
drivers/gpu/drm/drm_fb_cma_helper.c | 111 +---
1 file changed, 15 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..9f8210130dc6 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -26,8 +26,6 @@
#include
#include
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
const struct drm_framebuffer_funcs *fb_funcs;
@@ -149,58 +147,14 @@ static struct fb_ops drm_fbdev_cma_ops = {
static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
+#ifdef CONFIG_FB_DEFERRED_IO
fb_deferred_io_mmap(info, vma);
+#endif
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
return 0;
}
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdefio = fbdefio;
- fb_deferred_io_init(fbi);
- fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
-
- return 0;
-}
-
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
- if (!fbi->fbdefio)
- return;
-
- fb_deferred_io_cleanup(fbi);
- kfree(fbi->fbdefio);
- kfree(fbi->fbops);
-}
-
static int
drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
@@ -258,9 +212,15 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
fbi->fix.smem_len = size;
if (fb->funcs->dirty) {
- ret = drm_fbdev_cma_defio_init(fbi, obj);
+ ret = drm_fb_helper_defio_init(helper);
if (ret)
goto err_cma_destroy;
+
+ /* can't be offset from vaddr since dirty() uses cma obj */
+ fbi->screen_buffer = obj->vaddr;
+ /* fb_deferred_io_fault() needs a physical address */
+ fbi->fix.smem_start = page_to_phys(virt_to_page(obj->vaddr));
+ fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
}
return 0;
@@ -296,52 +256,23 @@ int drm_fb_cma_fbdev_init_with_funcs(struct drm_device
*dev,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_fbdev_cma *fbdev_cma;
- struct drm_fb_helper *fb_helper;
int ret;
- if (!preferred_bpp)
- preferred_bpp = dev->mode_config.preferred_depth;
- if (!preferred_bpp)
- preferred_bpp = 32;
-
- if (!max_conn_count)
- max_conn_count = dev->mode_config.num_connector;
-
fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
if (!fbdev_cma)
return -ENOMEM;
fbdev_cma->fb_funcs = funcs;
- fb_helper = &fbdev_cma->fb_helper;
- drm_fb_helper_prepare(dev, fb_helper, &drm_fb_cma_helper_funcs);
-
- ret = drm_fb_helper_init(dev, fb_helper, max_conn_count);
+ ret = drm_fb_helper_fbdev_setup(dev, &fbdev_cma->fb_helper,
+ &drm_fb_cma_helper_funcs,
+ preferred_bpp, max_conn_count);
if (ret < 0) {
- DRM_DEV_ERROR(dev->dev, "Failed to initialize fbdev helper.\n");
- goto err_free;
- }
-
- ret = drm_fb_helper_single_add_all_connectors(fb_helper);
- if (ret < 0) {
- DRM_DEV_ERROR(dev->dev, "Failed to add connectors.\n");
- goto err_drm_fb_helper_fini;
- }
-
- ret = drm_fb_helper_initi
[PATCH 1/7] drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini
Set dev->fb_helper even when fbdev emulation is compiled out,
so drivers can use it to free the structure.
Clear it for consistency.
Fixes: 29ad20b22c8f ("drm: Add drm_device->fb_helper pointer")
Signed-off-by: Noralf Trønnes
---
include/drm/drm_fb_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 1494b12a984a..1bd624579db7 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -33,6 +33,7 @@
struct drm_fb_helper;
#include
+#include
#include
enum mode_set_atomic {
@@ -332,11 +333,17 @@ static inline int drm_fb_helper_init(struct drm_device
*dev,
struct drm_fb_helper *helper,
int max_conn)
{
+ /* So drivers can use it to free the struct */
+ helper->dev = dev;
+ dev->fb_helper = helper;
+
return 0;
}
static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
{
+ if (helper && helper->dev)
+ helper->dev->fb_helper = NULL;
}
static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION
Make it possible to opt out of fbdev emulation. DRM_FBDEV_EMULATION selects DRM_KMS_FB_HELPER and is default yes so this doesn't change the default behaviour. Cc: Laurent Pinchart Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/Kconfig | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d853989848d6..fe1b6030d3c6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -143,10 +143,7 @@ config DRM_KMS_CMA_HELPER bool depends on DRM select DRM_GEM_CMA_HELPER - select DRM_KMS_FB_HELPER - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT + select DRM_KMS_HELPER help Choose this if you need the KMS CMA helper functions -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] Add drm_fb_helper_fbdev_setup/teardown()
Hi, This is a new attempt at simplifying fbdev setup/teardown in drivers. Hopefully this one is better than my previous attempt. The previous version allocated the drm_fb_helper struct as well, this time I leave it to the driver. I've included an fbdev deferred I/O setup helper as well since it's part of the teardown. As always I struggle with documentation so I welcome all help in getting the words right. Noralf. Noralf Trønnes (7): drm/fb-helper: Set/clear dev->fb_helper in dummy init/fini drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown() drm/docs: Add todo entry for drm_fb_helper_fbdev_setup() drm/fb-helper: Update DOC with new helpers drm/fb-helper: Add drm_fb_helper_defio_init() drm/fb-cma-helper: Use drm_fb_helper_fbdev_setup/teardown() drm/fb-cma-helper: Honour DRM_FBDEV_EMULATION Documentation/gpu/todo.rst | 18 drivers/gpu/drm/Kconfig | 5 +- drivers/gpu/drm/drm_fb_cma_helper.c | 111 +++--- drivers/gpu/drm/drm_fb_helper.c | 181 +--- include/drm/drm_fb_helper.h | 38 5 files changed, 241 insertions(+), 112 deletions(-) -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu and ttm drm-fixes-4.15
Hi Dave, Nothing too major here. A couple more ttm fixes for huge page and a kiq fix for amdgpu. The following changes since commit 90eeb3aa34831ff3d031589c0c24892eb8a07e51: Merge tag 'drm-misc-fixes-2017-12-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2017-12-08 08:17:53 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.15 for you to fetch changes up to 0507f438ea19d4280006467ba02956f6a693deca: drm/amdgpu: fix MAP_QUEUES paramter (2017-12-12 15:40:11 -0500) Monk Liu (3): drm/ttm: fix incorrect calculate on shrink_pages drm/ttm: max_cpages is in unit of native page drm/amdgpu: fix MAP_QUEUES paramter drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: add separate entry for DRM TTM
On 12/14/2017 06:48 PM, Emil Velikov wrote: On 14 December 2017 at 13:37, Christian König wrote: AMD is the major user of TTM, so it also makes sense that we maintain it. Signed-off-by: Christian König --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 069ba63190b2..72e8f8f750ec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4805,6 +4805,14 @@ S: Maintained F: drivers/gpu/drm/tinydrm/ F: include/drm/tinydrm/ +DRM TTM SUBSYSTEM +M: Christian Koenig +M: Roger He +S: Maintained +L: dri-devel@lists.freedesktop.org +F: include/drm/ttm/ +F: drivers/gpu/drm/ttm/ + IIRC Thomas was one of the people heavily involved in TTM, at least in the early days. An Ack from him might be a good idea, for posterity? -Emil Acked-by: Thomas Hellstrom Although of course I think it's important that we keep sending patches out before merging for reviewing and commenting, since even if AMD is the major user, it's still used by a number of other drivers. Thanks, /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: ipp: Remove Exynos DRM IPP subsystem
On Thu, Dec 14, 2017 at 04:10:15PM +0100, Marek Szyprowski wrote:
> Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
> dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
> broken and never really functional. It will be replaced by a completely
> rewritten API.
>
> Exynos DRM IPP user-space API can be obsoleted for the following
> reasons:
>
> 1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so
> userspace should not rely that it is always available and should have
> a software fallback in case it is not there.
>
> 2. The only mode which was initially semi-working was memory-to-memory
> image processing. The remaining modes (LCD-"writeback" and "output")
> were never operational due to missing code (both in mainline and even
> vendor kernels).
>
> 3. Exynos DRM IPP mainline user-space API compatibility for
> memory-to-memory got broken very early by commit 083500baefd5 ("drm:
> remove DRM_FORMAT_NV12MT", which removed the support for tiled formats,
> the main feature which made this API somehow useful on Exynos platforms
> (video codec that time produced only tiled frames, to implement xvideo
> or any other video overlay, one has to de-tile them for proper
> display).
>
> 4. Broken drivers. Especially once support for IOMMU has been added,
> it revealed that drivers don't configure DMA operations properly and in
> many cases operate outside the provided buffers trashing memory around.
>
> 5. Need for external patches. Although IPP user-space API has been used
> in some vendor kernels, but in such cases there were additional patches
> applied (like reverting mentioned 083500baefd5 patch) what means that
> those userspace apps which might use it, still won't work with the
> mainline kernel version.
>
> We don't have time machines, so we cannot change it, but Exynos DRM IPP
> extension should never have been merged to mainline in that form.
>
> Exynos IPP subsystem and user-space API will be rewritten, so remove
> current IPP core code and mark existing drivers as BROKEN.
>
> Signed-off-by: Marek Szyprowski
> ---
> This is a follow-up of the discussion in the following thread:
> https://lists.freedesktop.org/archives/dri-devel/2017-November/158989.html
>
> This patch was a part of the "Exynos DRM: rewrite IPP subsystem and
> userspace API" patchset:
> https://lists.freedesktop.org/archives/dri-devel/2017-November/157130.html
> ---
> drivers/gpu/drm/exynos/Kconfig | 11 +-
> drivers/gpu/drm/exynos/Makefile |1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 252 -
> include/uapi/drm/exynos_drm.h | 192 +---
> 7 files changed, 4 insertions(+), 2272 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: add separate entry for DRM TTM
On 14 December 2017 at 13:37, Christian König wrote: > AMD is the major user of TTM, so it also makes sense that we maintain > it. > > Signed-off-by: Christian König > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 069ba63190b2..72e8f8f750ec 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4805,6 +4805,14 @@ S: Maintained > F: drivers/gpu/drm/tinydrm/ > F: include/drm/tinydrm/ > > +DRM TTM SUBSYSTEM > +M: Christian Koenig > +M: Roger He > +S: Maintained > +L: dri-devel@lists.freedesktop.org > +F: include/drm/ttm/ > +F: drivers/gpu/drm/ttm/ > + IIRC Thomas was one of the people heavily involved in TTM, at least in the early days. An Ack from him might be a good idea, for posterity? -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave, More of the same. A lot of improvements from Noralf on this one. Nothing really big here. Regards, Gustavo drm-misc-next-2017-12-14: drm-misc-next for 4.16: Cross-subsystem Changes: - Documentation for amlogic dt dt-bindings Core Changes: - Update edid-derived drm_display_info fields at edid property set Driver Changes: - A bunch of clean up from Noralf, including the last patches to reduce fbdev emulation footprint. The following changes since commit bc29489f712079378081e43d5b1b7470ed70184d: drm/sun4i: Fix uninitialized variables in vi layer (2017-12-07 09:51:41 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2017-12-14 for you to fetch changes up to ca40cfc85e548424e39dc3aebe61873535ddf7b6: drm/atomic-helper: Make zpos property kerneldoc less misleading (2017-12-14 14:20:35 +0100) drm-misc-next for 4.16: Cross-subsystem Changes: - Documentation for amlogic dt dt-bindings Core Changes: - Update edid-derived drm_display_info fields at edid property set Driver Changes: - A bunch of clean up from Noralf, including the last patches to reduce fbdev emulation footprint. Daniel Vetter (1): drm: More debug info for fb leaks in mode_config_cleanup Jani Nikula (1): MAINTAINERS: Remove Jani as drm-misc co-maintainer Keith Packard (1): drm: Update edid-derived drm_display_info fields at edid property set [v2] Neil Armstrong (4): dt-bindings: display: amlogic, meson-vpu: Add optional power domain property dt-bindings: display: amlogic, meson-dw-hdmi: Add optional HDMI 5V regulator drm/meson: dw_hdmi: Add support for an optional external 5V regulator drm/meson: Add missing VPU init Noralf Trønnes (22): drm/armada: Use drm_fb_helper_lastclose() and _poll_changed() drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed() drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed() drm/msm: Use drm_fb_helper_lastclose() and _poll_changed() drm/nouveau: Use drm_fb_helper_output_poll_changed() drm/omap: Use drm_fb_helper_lastclose() and _poll_changed() drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed() drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed() drm/gem-fb-helper: drm_gem_fbdev_fb_create() make funcs optional drm/cma-helper: Add drm_fb_cma_fbdev_init/fini() drm/atmel-hlcdc: Use drm_fb_cma_fbdev_init/fini() drm/imx: Use drm_fb_cma_fbdev_init/fini() drm/pl111: Use drm_fb_cma_fbdev_init/fini() drm/sti: Use drm_fb_cma_fbdev_init/fini() drm/stm: Use drm_fb_cma_fbdev_init/fini() drm/sun4i: Use drm_fb_cma_fbdev_init/fini() drm/tilcdc: Use drm_fb_cma_fbdev_init/fini() drm/tve200: Use drm_fb_cma_fbdev_init/fini() drm/vc4: Use drm_fb_cma_fbdev_init/fini() drm/zte: Use drm_fb_cma_fbdev_init/fini() drm/arm/mali: Use drm_fb_cma_fbdev_init/fini() drm/tinydrm: Use drm_fb_cma_fbdev_init_with_funcs/fini() Thierry Reding (1): drm/atomic-helper: Make zpos property kerneldoc less misleading .../bindings/display/amlogic,meson-dw-hdmi.txt | 4 + .../bindings/display/amlogic,meson-vpu.txt | 4 + Documentation/gpu/todo.rst | 5 - MAINTAINERS| 1 - drivers/gpu/drm/arm/malidp_drv.c | 39 ++- drivers/gpu/drm/arm/malidp_drv.h | 1 - drivers/gpu/drm/armada/armada_drm.h| 1 - drivers/gpu/drm/armada/armada_drv.c| 8 +- drivers/gpu/drm/armada/armada_fb.c | 11 +- drivers/gpu/drm/armada/armada_fbdev.c | 8 -- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 26 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/drm_blend.c| 8 +- drivers/gpu/drm/drm_connector.c| 13 +++ drivers/gpu/drm/drm_edid.c | 53 ++--- drivers/gpu/drm/drm_fb_cma_helper.c| 119 - drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/drm_mode_config.c | 3 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 8 +- drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 2 - drivers/gpu/drm/gma500/framebuffer.c | 9 +- drivers/gpu/drm/gma500/psb_drv.c | 15 +-- drivers/gpu/drm/imx/imx-drm-core.c | 33 ++ drivers/gpu/drm/imx/imx-drm.h | 1 - drivers/gpu/drm/meson/meson_drv.c | 9 ++ drivers/gpu/drm/meson/meson_dw_hdmi.c |
[Bug 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #16 from James Lovinsky --- I'm using Stellaris v1.9 through the Steam client on Linux Mint 18.3 with the MATE desktop. -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #15 from james...@gmail.com --- I have a thinkpad x220 (Intel HD 3000 integrated graphics). I can confirm that this bug is fixed for me with MESA 17.2.4 /--/ server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.4 Max core profile version: 3.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.4 OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 17.2.4 OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 /--/ Bug was present in previous MESA version, I believe it was ~17.0.5. -- 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] drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Hi, On 14 December 2017 at 15:10, Marek Szyprowski wrote: > Exynos DRM IPP subsystem is in fact non-functional and frankly speaking > dead-code. This patch clearly marks that Exynos DRM IPP subsystem is > broken and never really functional. It will be replaced by a completely > rewritten API. I certainly won't be sad to see the back of that pile of integer overflow. Acked-by: Daniel Stone Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104266] [polaris10][arm] blurred screen on AMD Radeon Pro WX 7100
https://bugs.freedesktop.org/show_bug.cgi?id=104266 Bug ID: 104266 Summary: [polaris10][arm] blurred screen on AMD Radeon Pro WX 7100 Product: Mesa Version: 17.2 Hardware: ARM OS: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: ved...@miletic.net QA Contact: dri-devel@lists.freedesktop.org Created attachment 136175 --> https://bugs.freedesktop.org/attachment.cgi?id=136175&action=edit Photo >From ML Mesa-dev: https://lists.freedesktop.org/archives/mesa-dev/2017-December/179186.html https://lists.freedesktop.org/archives/mesa-dev/2017-December/179426.html https://lists.freedesktop.org/archives/mesa-dev/2017-December/180001.html Hi, We met a problem on ubuntu17.10 for arm server with amdgpu (AMD RADEON PRO WX 7100), we use open source driver which are integrated in ubuntu17.10 (Mesa 17.2.2). And the architecture is AArch64-linux-gnu. we install: apt-get install xserver-xorg xinit xfce4 and mesa-utils glmark2 we start x server: startx and then the monitor shows the screen and the screen is blurred (something wrong). And I have tried some opengl applications, the output has same problem.(something is missing or in the wrong place.) But in a x86_64 architecture server, with same OS. The screen output is normal. (I check xorg\DDX\mesa\libdrm etc.all the versions are the same with aarch64 server.) What I have done: 1. I upgrade kernel to 4.15-rc2 ,upgrade DRM to 3.23,upgrade DDX to 1.40,upgrade mesa to 17.2.6, but the problem still exist. 2. I enable ‘shadowprimary’ option, the screen output became normal, but the performance drop quickly——glxgears drop from 4800fps to 600fps, glmark drop from 4300 score to 730 score. (We solve the glxgears segmentation fault problem by add the compile flags: -fsigned-char. In arm platform, char variant default to "unsigned-char", that makes problem of glxgears segmentation fault. But after we recompile mesa with -fsigned-char. The screen output still tearing(blurred). the display problem still exist.) -- 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: tinydrm: page allocation failure
On 12/11/2017 06:45 AM, Noralf Trønnes wrote: Den 11.12.2017 04.28, skrev David Lechner: I'm using drm-misc/drm-misc-next and occasionally getting errors as seen in the stack traces below. I'm not really sure what to make of it. Any ideas? I'm starting to wonder if there is some sort of race condition involved. I only get this warning on some boots, but when I do, it happens multiple times. Also, when I was debugging a an unrelated problem, I enabled some of the spin lock checking kernel options that really slow down the kernel. When I did this, I got this warning all of the time. Would it be sensible to allocate a dummy RX buffer once instead of letting SPI allocate a new one for every transfer? The spi controller driver has told the spi core to allocate dummy buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg -> krealloc -> __do_krealloc -> kmalloc_track_caller order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which probably is the max DMA limit. So this is a pixel data transfer. On my Raspberry Pi I've got 43 chunks of 64kB available if I have understood this right: $ sudo cat /proc/buddyinfo Node 0, zone Normal 40 68 66 51 43 46 13 1 3 3 75 I don't know what those dummy buffers are used for. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
4.14 + amdgpupro opencl: sleepng function called:
Hi I am trying to use amdgpupro opencl on top of amdgpu and everything seems to run fine except this OOPS that I get once per execution: [ 120.180229] BUG: sleeping function called from invalid context at /var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/work-shared/qt5122/kernel-source/mm/slab.h:421 [ 120.181159] in_atomic(): 1, irqs_disabled(): 0, pid: 677, name: clinfo [ 120.181979] CPU: 1 PID: 677 Comm: clinfo Not tainted 4.14.0-qtec-standard #1 [ 120.181979] Hardware name: AMD FP4/FP4, BIOS qtec 12/29/2016 [ 120.181980] Call Trace: [ 120.181987] dump_stack+0x4d/0x67 [ 120.181990] ___might_sleep+0xdf/0x100 [ 120.181991] __might_sleep+0x4a/0x80 [ 120.181994] __kmalloc+0x118/0x1d0 [ 120.181997] ? reservation_object_copy_fences+0x38/0x100 [ 120.181998] reservation_object_copy_fences+0x38/0x100 [ 120.182006] ttm_bo_unref+0x12b/0x330 [ttm] [ 120.182045] amdgpu_bo_unref+0x2a/0x50 [amdgpu] [ 120.182063] amdgpu_vm_free_levels+0x2b/0x60 [amdgpu] [ 120.182081] amdgpu_vm_free_levels+0x48/0x60 [amdgpu] [ 120.182098] amdgpu_vm_fini+0x201/0x280 [amdgpu] [ 120.182113] amdgpu_driver_postclose_kms+0x111/0x1f0 [amdgpu] [ 120.182133] drm_release+0x265/0x380 [drm] [ 120.182136] __fput+0xbe/0x200 [ 120.182137] fput+0xe/0x10 [ 120.182139] task_work_run+0x99/0xd0 [ 120.182142] do_exit+0x2e6/0xb70 [ 120.182143] ? __do_page_fault+0x273/0x4f0 [ 120.182145] do_group_exit+0x3b/0xb0 [ 120.182146] SyS_exit_group+0x14/0x20 [ 120.182148] do_syscall_64+0x74/0x1d0 [ 120.182150] entry_SYSCALL64_slow_path+0x25/0x25 [ 120.182151] RIP: 0033:0x3586ebec80 [ 120.182152] RSP: 002b:7fff00ca6cf8 EFLAGS: 0246 ORIG_RAX: 00e7 [ 120.182154] RAX: ffda RBX: RCX: 003586ebec80 [ 120.182154] RDX: RSI: 003c RDI: [ 120.182155] RBP: 0035871a28b8 R08: 00e7 R09: ff78 [ 120.182156] R10: 003588c15168 R11: 0246 R12: 0035871a28b8 [ 120.182156] R13: 0035871a7d40 R14: R15: [ 212.756710] BUG: sleeping function called from invalid context at /var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/work-shared/qt5122/kernel-source/mm/slab.h:421 [ 212.758876] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: clpeak [ 212.760986] CPU: 3 PID: 678 Comm: clpeak Tainted: GW 4.14.0-qtec-standard #1 [ 212.760987] Hardware name: AMD FP4/FP4, BIOS qtec 12/29/2016 [ 212.760989] Call Trace: [ 212.761004] dump_stack+0x4d/0x67 [ 212.761012] ___might_sleep+0xdf/0x100 [ 212.761017] __might_sleep+0x4a/0x80 [ 212.761024] __kmalloc+0x118/0x1d0 [ 212.761030] ? reservation_object_copy_fences+0x38/0x100 [ 212.761038] reservation_object_copy_fences+0x38/0x100 [ 212.761054] ttm_bo_unref+0x12b/0x330 [ttm] [ 212.761117] amdgpu_bo_unref+0x2a/0x50 [amdgpu] [ 212.761160] amdgpu_vm_free_levels+0x2b/0x60 [amdgpu] [ 212.761206] amdgpu_vm_free_levels+0x48/0x60 [amdgpu] [ 212.761252] amdgpu_vm_fini+0x201/0x280 [amdgpu] [ 212.761289] amdgpu_driver_postclose_kms+0x111/0x1f0 [amdgpu] [ 212.761320] drm_release+0x265/0x380 [drm] [ 212.761324] __fput+0xbe/0x200 [ 212.761328] fput+0xe/0x10 [ 212.761331] task_work_run+0x99/0xd0 [ 212.761336] do_exit+0x2e6/0xb70 [ 212.761339] ? __do_page_fault+0x273/0x4f0 [ 212.761342] do_group_exit+0x3b/0xb0 [ 212.761345] SyS_exit_group+0x14/0x20 [ 212.761348] do_syscall_64+0x74/0x1d0 [ 212.761352] entry_SYSCALL64_slow_path+0x25/0x25 [ 212.761354] RIP: 0033:0x3586ebec80 [ 212.761356] RSP: 002b:7ffecb885588 EFLAGS: 0246 ORIG_RAX: 00e7 [ 212.761359] RAX: ffda RBX: RCX: 003586ebec80 [ 212.761361] RDX: RSI: 003c RDI: [ 212.761363] RBP: 0035871a28b8 R08: 00e7 R09: ff58 [ 212.761364] R10: 003588c15168 R11: 0246 R12: 0035871a28b8 [ 212.761365] R13: 0035871a7d40 R14: R15: before I start digging in the code: have someone seen this issue before? Thanks! -- Ricardo Ribalda ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen
On 12/14/2017 12:55 AM, Randy Dunlap wrote: > On 12/13/2017 11:47 AM, Max Staudt wrote: >> This is the initial prototype for a lean Linux kernel bootsplash. >> >> As it is now, it will show a black screen rather than a logo, and >> only if manually enabled via the kernel cmdline: >> >> bootsplash.enable=1 > > Is it .enable or .enabled? (compare below) Oops. It's neither, I've kicked out the option and updated the documentation, but forgot about the commit message. Thanks! Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
On 12/13/2017 10:35 PM, Daniel Vetter wrote:
> Using drm directly would allow you to flush the contents without the fake
> (and tbh, really expensive on most drivers) copy op. If you insist on
> using fbdev for this stuff, then at least add a new hook to flush cpu
> rendering.
My reasoning is as follows:
1) The splash screen is meant to appear as early as possible in the boot
process, and even on devices that don't have a DRM driver. For example, an ARM
box with only efifb. Thus, the choice to work on top of FB.
2) We need to go out of the way when a graphical application starts, and come
back when it's done. fbcon already has the logic for this, and fbcon is also
the thing we're trying to hide. So it seems natural to add the splash on top of
fbcon - at least for now.
3) I can't use DRM from the kernel, for the same reason for which there is no
"drmcon" to supplant fbcon: There is no interface to reserve framebuffer memory
from kernel space: To get memory for a framebuffer, one needs to have a struct
file that is passed through the DRM stack down into the drivers.
If this interface existed, then there could be a generic "fb2drm" translation
layer, and we would no longer need FB compatibility code in each KMS driver.
Actually, I tried to implement this translation layer a year ago, and hit too
many walls.
I've prepared the code for a future in which fbdev no longer exists: My sysfs
interface is generically called "bootsplash", in the hope that it will one day
move on top of KMS. The hooks into fbcon are minimal and the code is
straightforward to port to KMS operations rather than FB. But that's for
another day, as far as I can see.
4) I don't fully understand what you'd like me to do. Last time I tried to add
a new entry to the fbops struct (namely fb_open_adj_file()), you told me not to
touch the framebuffer subsystem anymore, as it is meant to die and driver
developers shall use KMS instead. Have I misunderstood?
Something like fb->flush() to finish kernel space accesses would be nice to
have, but would need to be implemented for all affected drivers separately. The
copy op hack is ugly, but solves the problem generically.
What shall I do?
Shall I add a new FB op for flushing when writing to the raw memory from the
kernel?
As far as I can see, it would be needed for defio drivers only, is that correct?
>> + *
>> + * A few DRM drivers' FB implementations are broken by not using
>> + * deferred_io when they really should - we match on the known
>> + * bad ones manually for now.
>> + */
>> +if (info->fbdefio
>> +|| !strcmp(info->fix.id, "astdrmfb")
>> +|| !strcmp(info->fix.id, "cirrusdrmfb")
>> +|| !strcmp(info->fix.id, "mgadrmfb")) {
>
> We have a shared defio implementation now in drm_fb_helper.c, there's not
> really many excuses to not fix up these drivers to just use those ...
I'll look into it.
Thanks!
Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197851] Resume from suspend sometimes results in black screen on Radeon R5
https://bugzilla.kernel.org/show_bug.cgi?id=197851 Harry Wentland (harry.wentl...@amd.com) changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #3 from Harry Wentland (harry.wentl...@amd.com) --- Do you get different behavior if you enable the new DC display driver by passing amdgpu.dc=1 to the kernel? -- 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] MAINTAINERS: add separate entry for DRM TTM
Am 14.12.2017 um 15:41 schrieb Daniel Vetter: On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote: On Thu, Dec 14, 2017 at 8:37 AM, Christian König wrote: AMD is the major user of TTM, so it also makes sense that we maintain it. Signed-off-by: Christian König Acked-by: Alex Deucher --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 069ba63190b2..72e8f8f750ec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4805,6 +4805,14 @@ S: Maintained F: drivers/gpu/drm/tinydrm/ F: include/drm/tinydrm/ +DRM TTM SUBSYSTEM +M: Christian Koenig +M: Roger He +S: Maintained +L: dri-devel@lists.freedesktop.org +F: include/drm/ttm/ +F: drivers/gpu/drm/ttm/ A git tree would be good here I think. Defacto that's right now the amd tree. Yeah, I was wondering what to do with that as well. I see three possible options of hand: A) Stick with the amd trees maintained by Alex. B) Come up with separate ones. C) Use drm-misc. For now I think I will stick with A if there are no objections. Christian. -Daniel + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-me...@vger.kernel.org -- 2.11.0 ___ 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking
dead-code. This patch clearly marks that Exynos DRM IPP subsystem is
broken and never really functional. It will be replaced by a completely
rewritten API.
Exynos DRM IPP user-space API can be obsoleted for the following
reasons:
1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so
userspace should not rely that it is always available and should have
a software fallback in case it is not there.
2. The only mode which was initially semi-working was memory-to-memory
image processing. The remaining modes (LCD-"writeback" and "output")
were never operational due to missing code (both in mainline and even
vendor kernels).
3. Exynos DRM IPP mainline user-space API compatibility for
memory-to-memory got broken very early by commit 083500baefd5 ("drm:
remove DRM_FORMAT_NV12MT", which removed the support for tiled formats,
the main feature which made this API somehow useful on Exynos platforms
(video codec that time produced only tiled frames, to implement xvideo
or any other video overlay, one has to de-tile them for proper
display).
4. Broken drivers. Especially once support for IOMMU has been added,
it revealed that drivers don't configure DMA operations properly and in
many cases operate outside the provided buffers trashing memory around.
5. Need for external patches. Although IPP user-space API has been used
in some vendor kernels, but in such cases there were additional patches
applied (like reverting mentioned 083500baefd5 patch) what means that
those userspace apps which might use it, still won't work with the
mainline kernel version.
We don't have time machines, so we cannot change it, but Exynos DRM IPP
extension should never have been merged to mainline in that form.
Exynos IPP subsystem and user-space API will be rewritten, so remove
current IPP core code and mark existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski
---
This is a follow-up of the discussion in the following thread:
https://lists.freedesktop.org/archives/dri-devel/2017-November/158989.html
This patch was a part of the "Exynos DRM: rewrite IPP subsystem and
userspace API" patchset:
https://lists.freedesktop.org/archives/dri-devel/2017-November/157130.html
---
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile |1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806 ---
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 252 -
include/uapi/drm/exynos_drm.h | 192 +---
7 files changed, 4 insertions(+), 2272 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5a7c9d8abd6b..735ce47688f9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -95,26 +95,21 @@ config DRM_EXYNOS_G2D
help
Choose this option if you want to use Exynos G2D for DRM.
-config DRM_EXYNOS_IPP
- bool "Image Post Processor"
- help
- Choose this option if you want to use IPP feature for DRM.
-
config DRM_EXYNOS_FIMC
bool "FIMC"
- depends on DRM_EXYNOS_IPP && MFD_SYSCON
+ depends on BROKEN && MFD_SYSCON
help
Choose this option if you want to use Exynos FIMC for DRM.
config DRM_EXYNOS_ROTATOR
bool "Rotator"
- depends on DRM_EXYNOS_IPP
+ depends on BROKEN
help
Choose this option if you want to use Exynos Rotator for DRM.
config DRM_EXYNOS_GSC
bool "GScaler"
- depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+ depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index bdf4212dde7b..a51c5459bb13 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -18,7 +18,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER) += exynos_mixer.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 82b72425a42f..41ad19e59f8d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -28,7 +28,6 @@
#include "exynos_drm_plane.h"
#include "exynos_drm_vidi.h"
#include "exyn
[Bug 104142] Stack trace in runpm when Tonga card powers down
https://bugs.freedesktop.org/show_bug.cgi?id=104142 --- Comment #3 from Mike Lothian --- I bisected this back to: d21becbe0225de0e2582d17d4fbc73fbd103b1f7 is the first bad commit commit d21becbe0225de0e2582d17d4fbc73fbd103b1f7 Author: Tony Cheng Date: Wed Jul 12 11:54:10 2017 -0400 drm/amd/display: avoid disabling opp clk before hubp is blanked. Signed-off-by: Tony Cheng Reviewed-by: Eric Yang Acked-by: Harry Wentland Signed-off-by: Alex Deucher :04 04 61debba3cf73670d29975bc136d01862c2a54576 3d2315a1843d6276655b1550cb9f18fab47c5ce4 M drivers -- 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
[PULL] drm-misc-fixes
Hi Linus&Dave, drm-misc-fixes-2017-12-14: drm-misc-fixes for 4.15-rc4 2 fixes for new core features, a corner case fix for the connnector_iter fix from last week (that one is cc: stable) and 1 vc4 fix. Imo that's enough that I figured better not delay until Dave is back. Linus, can you pls apply? i915 CI is happy, but then the connector_iter patch from last week blew up on some arm driver on probe-defer, so who knows :-) Cheers, Daniel The following changes since commit 90eeb3aa34831ff3d031589c0c24892eb8a07e51: Merge tag 'drm-misc-fixes-2017-12-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2017-12-08 08:17:53 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-12-14 for you to fetch changes up to bd36d3bab2e3d08f80766c86487090dbceed4651: drm/drm_lease: Prevent deadlock in case drm_lease_create() fails (2017-12-14 08:25:37 +0100) drm-misc-fixes for 4.15-rc4 Daniel Vetter (1): drm: rework delayed connector cleanup in connector_iter Keith Packard (1): drm: Update edid-derived drm_display_info fields at edid property set [v2] Marius Vlad (1): drm/drm_lease: Prevent deadlock in case drm_lease_create() fails Stefan Schake (1): drm/vc4: Release fence after signalling drivers/gpu/drm/drm_connector.c | 63 - drivers/gpu/drm/drm_crtc_internal.h | 1 + drivers/gpu/drm/drm_edid.c | 52 +- drivers/gpu/drm/drm_lease.c | 4 +-- drivers/gpu/drm/drm_mode_config.c | 5 ++- drivers/gpu/drm/vc4/vc4_gem.c | 4 ++- drivers/gpu/drm/vc4/vc4_irq.c | 1 + include/drm/drm_connector.h | 10 +++--- include/drm/drm_edid.h | 2 ++ include/drm/drm_mode_config.h | 18 ++- 10 files changed, 122 insertions(+), 38 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Non-blocking commits on -ERESTARTSYS
On 2017-12-13 02:24 PM, Leo Li wrote:
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object during
non-blocking commits. Within drm_atomic_helper_setup_commit, a reference
to the commit object is obtained by the new_crtc_state. This reference
is suppose to be 'put' once flip_done is signaled (via the
release_crtc_commit callback), but never happens if .prepare_fb returns
-ERESTARTSYS: drm_atomic_helper_commit early returns before the
commit_tail work is queued.
We're starting to bump into this issue again. Regarding Daniel's
suggestion for an IGT test, has there been any work done on it? I'd be
interested in taking a look otherwise. As a side note, I can also
reproduce this on i915.
Thanks,
Leo
I'm curious, isn't it better to handle this in
__drm_atomic_helper_crtc_destroy_state with the attached patch?
Good point, it seems sane to me. I gave it a spin and it fixes the issue.
I was concerned that it'll contend with the worker thread, possibly
freeing the crtc_commit before the flip is done. It seems the
atomic_state_get before the work is queued will prevent that.
Leo
No idea if sane though, but drivers are supposed to clear
crtc_state->event on success..
Hi Maarten,
If there are no objections, can I submit a patch with your change below?
Thanks,
Leo
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 593b30d38ce0..e71233b4c651 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3435,6 +3435,8 @@
EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state
*state)
{
if (state->commit) {
+ if (state->event)
+ drm_crtc_commit_put(state->commit);
kfree(state->commit->event);
state->commit->event = NULL;
drm_crtc_commit_put(state->commit);
___
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] MAINTAINERS: add separate entry for DRM TTM
On Thu, Dec 14, 2017 at 08:45:10AM -0500, Alex Deucher wrote: > On Thu, Dec 14, 2017 at 8:37 AM, Christian König > wrote: > > AMD is the major user of TTM, so it also makes sense that we maintain > > it. > > > > Signed-off-by: Christian König > > Acked-by: Alex Deucher > > > --- > > MAINTAINERS | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 069ba63190b2..72e8f8f750ec 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4805,6 +4805,14 @@ S: Maintained > > F: drivers/gpu/drm/tinydrm/ > > F: include/drm/tinydrm/ > > > > +DRM TTM SUBSYSTEM > > +M: Christian Koenig > > +M: Roger He > > +S: Maintained > > +L: dri-devel@lists.freedesktop.org > > +F: include/drm/ttm/ > > +F: drivers/gpu/drm/ttm/ A git tree would be good here I think. Defacto that's right now the amd tree. -Daniel > > + > > DSBR100 USB FM RADIO DRIVER > > M: Alexey Klimov > > L: linux-me...@vger.kernel.org > > -- > > 2.11.0 > > > > ___ > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete
On 12/14/2017 02:17 PM, Christian König wrote:
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a
nice cleanup there are two things below I think needs fixing.
On 11/15/2017 01:31 PM, Christian König wrote:
There is no guarantee that the next entry on the ddelete list stays on
the list when we drop the locks.
Completely rework this mess by moving processed entries on a temporary
list.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77
++--
1 file changed, 25 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c1eac4f4b4b..ad0afdd71f21 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -572,71 +572,47 @@ static int ttm_bo_cleanup_refs(struct
ttm_buffer_object *bo,
* Traverse the delayed list, and call ttm_bo_cleanup_refs on all
* encountered buffers.
*/
-
-static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool
remove_all)
+static bool ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool
remove_all)
{
struct ttm_bo_global *glob = bdev->glob;
- struct ttm_buffer_object *entry = NULL;
- int ret = 0;
-
- spin_lock(&glob->lru_lock);
- if (list_empty(&bdev->ddestroy))
- goto out_unlock;
+ struct list_head removed;
+ bool empty;
- entry = list_first_entry(&bdev->ddestroy,
- struct ttm_buffer_object, ddestroy);
- kref_get(&entry->list_kref);
+ INIT_LIST_HEAD(&removed);
- for (;;) {
- struct ttm_buffer_object *nentry = NULL;
-
- if (entry->ddestroy.next != &bdev->ddestroy) {
- nentry = list_first_entry(&entry->ddestroy,
- struct ttm_buffer_object, ddestroy);
- kref_get(&nentry->list_kref);
- }
-
- ret = reservation_object_trylock(entry->resv) ? 0 : -EBUSY;
- if (remove_all && ret) {
- spin_unlock(&glob->lru_lock);
- ret = reservation_object_lock(entry->resv, NULL);
- spin_lock(&glob->lru_lock);
- }
+ spin_lock(&glob->lru_lock);
+ while (!list_empty(&bdev->ddestroy)) {
+ struct ttm_buffer_object *bo;
- if (!ret)
- ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
- true);
- else
- spin_unlock(&glob->lru_lock);
+ bo = list_first_entry(&bdev->ddestroy, struct
ttm_buffer_object,
+ ddestroy);
+ kref_get(&bo->list_kref);
+ list_move_tail(&bo->ddestroy, &removed);
+ spin_unlock(&glob->lru_lock);
- kref_put(&entry->list_kref, ttm_bo_release_list);
- entry = nentry;
+ reservation_object_lock(bo->resv, NULL);
Reservation may be a long lived lock, and typically if the object is
reserved here, it's being evicted somewhere and there might be a
substantial stall, which isn't really acceptable in the global
workqueue. Better to move on to the next bo.
This function was really intended to be non-blocking, unless
remove_all == true. I even think it's safe to keep the spinlock held
on tryreserve?
This approach doesn't really work with shared reservation objects and
was actually the originally reason why I stumbled over the function
being a bit buggy.
Actually I think it was correct, but very non-deterministic and
difficult to follow. Both me and Maarten had our passes trying to make
it look better but failed :(. It relied on the ddestroy list node either
being on the ddestroy list or not on a list at all.
So if the ->next pointer was on the list, we'd continue iteration, even
though the object might have moved on the list. But it looks much better
now.
The reservation object is a really busy lock because of all the
command submission going on. So when you only have a single trylock
every few ms it is rather unlikely that you can actually grab it. We
ended up with tons of objects on the ddestroy list which couldn't be
reaped because of this.
OK, I see.
At least amdgpu tries to avoid to wait for any GPU operation while
holding the reservation locks, so at least for us that shouldn't be an
issue any more. And I'm going to pipeline delayed deletes as well
rather soon.
What we could do here is to use a test like "bo->resv ==
&bo->ttm_resv" and only trylock if it isn't a shared reservation
object. How about that?
Either that or a private workqueue separate from the global one is fine
with me.
Thanks,
Thomas
Regards,
Christian.
- if (ret || !entry)
- goto out;
+ spin_lock(&glob->lru_lock);
+ ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+ kref_put(&bo->list_kref, ttm_bo_release_list);
Calling a release function in atomic context is a bad thing. Nobody
knows what locks needs to be taken in the release function a
Re: [PATCH] MAINTAINERS: add separate entry for DRM TTM
On Thu, Dec 14, 2017 at 8:37 AM, Christian König wrote: > AMD is the major user of TTM, so it also makes sense that we maintain > it. > > Signed-off-by: Christian König Acked-by: Alex Deucher > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 069ba63190b2..72e8f8f750ec 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4805,6 +4805,14 @@ S: Maintained > F: drivers/gpu/drm/tinydrm/ > F: include/drm/tinydrm/ > > +DRM TTM SUBSYSTEM > +M: Christian Koenig > +M: Roger He > +S: Maintained > +L: dri-devel@lists.freedesktop.org > +F: include/drm/ttm/ > +F: drivers/gpu/drm/ttm/ > + > DSBR100 USB FM RADIO DRIVER > M: Alexey Klimov > L: linux-me...@vger.kernel.org > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: add separate entry for DRM TTM
AMD is the major user of TTM, so it also makes sense that we maintain it. Signed-off-by: Christian König --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 069ba63190b2..72e8f8f750ec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4805,6 +4805,14 @@ S: Maintained F: drivers/gpu/drm/tinydrm/ F: include/drm/tinydrm/ +DRM TTM SUBSYSTEM +M: Christian Koenig +M: Roger He +S: Maintained +L: dri-devel@lists.freedesktop.org +F: include/drm/ttm/ +F: drivers/gpu/drm/ttm/ + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-me...@vger.kernel.org -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete
Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:
Hi, Christian,
While this has probably already been committed, and looks like a nice
cleanup there are two things below I think needs fixing.
On 11/15/2017 01:31 PM, Christian König wrote:
There is no guarantee that the next entry on the ddelete list stays on
the list when we drop the locks.
Completely rework this mess by moving processed entries on a temporary
list.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77
++--
1 file changed, 25 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c1eac4f4b4b..ad0afdd71f21 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -572,71 +572,47 @@ static int ttm_bo_cleanup_refs(struct
ttm_buffer_object *bo,
* Traverse the delayed list, and call ttm_bo_cleanup_refs on all
* encountered buffers.
*/
-
-static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool
remove_all)
+static bool ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool
remove_all)
{
struct ttm_bo_global *glob = bdev->glob;
- struct ttm_buffer_object *entry = NULL;
- int ret = 0;
-
- spin_lock(&glob->lru_lock);
- if (list_empty(&bdev->ddestroy))
- goto out_unlock;
+ struct list_head removed;
+ bool empty;
- entry = list_first_entry(&bdev->ddestroy,
- struct ttm_buffer_object, ddestroy);
- kref_get(&entry->list_kref);
+ INIT_LIST_HEAD(&removed);
- for (;;) {
- struct ttm_buffer_object *nentry = NULL;
-
- if (entry->ddestroy.next != &bdev->ddestroy) {
- nentry = list_first_entry(&entry->ddestroy,
- struct ttm_buffer_object, ddestroy);
- kref_get(&nentry->list_kref);
- }
-
- ret = reservation_object_trylock(entry->resv) ? 0 : -EBUSY;
- if (remove_all && ret) {
- spin_unlock(&glob->lru_lock);
- ret = reservation_object_lock(entry->resv, NULL);
- spin_lock(&glob->lru_lock);
- }
+ spin_lock(&glob->lru_lock);
+ while (!list_empty(&bdev->ddestroy)) {
+ struct ttm_buffer_object *bo;
- if (!ret)
- ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
- true);
- else
- spin_unlock(&glob->lru_lock);
+ bo = list_first_entry(&bdev->ddestroy, struct
ttm_buffer_object,
+ ddestroy);
+ kref_get(&bo->list_kref);
+ list_move_tail(&bo->ddestroy, &removed);
+ spin_unlock(&glob->lru_lock);
- kref_put(&entry->list_kref, ttm_bo_release_list);
- entry = nentry;
+ reservation_object_lock(bo->resv, NULL);
Reservation may be a long lived lock, and typically if the object is
reserved here, it's being evicted somewhere and there might be a
substantial stall, which isn't really acceptable in the global
workqueue. Better to move on to the next bo.
This function was really intended to be non-blocking, unless
remove_all == true. I even think it's safe to keep the spinlock held
on tryreserve?
This approach doesn't really work with shared reservation objects and
was actually the originally reason why I stumbled over the function
being a bit buggy.
The reservation object is a really busy lock because of all the command
submission going on. So when you only have a single trylock every few ms
it is rather unlikely that you can actually grab it. We ended up with
tons of objects on the ddestroy list which couldn't be reaped because of
this.
At least amdgpu tries to avoid to wait for any GPU operation while
holding the reservation locks, so at least for us that shouldn't be an
issue any more. And I'm going to pipeline delayed deletes as well rather
soon.
What we could do here is to use a test like "bo->resv == &bo->ttm_resv"
and only trylock if it isn't a shared reservation object. How about that?
Regards,
Christian.
- if (ret || !entry)
- goto out;
+ spin_lock(&glob->lru_lock);
+ ttm_bo_cleanup_refs(bo, false, !remove_all, true);
+ kref_put(&bo->list_kref, ttm_bo_release_list);
Calling a release function in atomic context is a bad thing. Nobody
knows what locks needs to be taken in the release function and such
code is prone to lock inversion and sleep-while-atomic bugs. Not long
ago vfree() was even forbidden from atomic context. But here it's
easily avoidable.
Hmm. It actually looks like ttm_bo_cleanup_refs unlocks the
glob->lru_lock just loke ttm_bo_cleanup_refs_and_unlock did, so my
latter comment actually isn't correct. Intuitively removing the
"unlock" prefix from the function would also mean that the unlocking
functionality went away, but that doesn't seem to be the case. Also
the commit message "needed for the next patch" isn't very helpful when
the next patch
[PATCH] drm/virtio: Add window server support
This is to allow clients running within VMs to be able to communicate
with a compositor in the host. Clients will use the communication
protocol that the compositor supports, and virtio-gpu will assist with
making buffers available in both sides, and copying content as needed.
It is expected that a service in the guest will act as a proxy,
interacting with virtio-gpu to support unmodified clients. For some
features of the protocol, the hypervisor might have to intervene and
also parse the protocol data to properly bridge resources. The following
IOCTLs have been added to this effect:
*_WINSRV_CONNECT: Opens a connection to the compositor in the host,
returns a FD that represents this connection and on which the following
IOCTLs can be used. Callers are expected to poll this FD for new
messages from the compositor.
*_WINSRV_TX: Asks the hypervisor to forward a message to the compositor
*_WINSRV_RX: Returns all queued messages
Alongside protocol data that is opaque to the kernel, the client can
send file descriptors that reference GEM buffers allocated by
virtio-gpu. The guest proxy is expected to figure out when a client is
passing a FD that refers to shared memory in the guest and allocate a
virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.
When the client notifies the compositor that it can read from that buffer,
the proxy should copy the contents from the SHM region to the virtio-gpu
resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.
This has been tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.
Signed-off-by: Tomeu Vizoso
Cc: Zach Reizner
---
Hi,
this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
There's two features missing in this patch when compared with virtio_wl:
* Allow the guest access directly host memory, without having to resort
to TRANSFER_TO_HOST
* Pass FDs from host to guest (Wayland specifies that the compositor
shares keyboard data with the guest via a shared buffer)
I plan to work on this next, but I would like to get some comments on
the general approach so I can better choose which patch to follow.
Thanks,
Tomeu
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 39 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 58 +--
drivers/gpu/drm/virtio/virtgpu_vq.c| 283 +
include/uapi/drm/virtgpu_drm.h | 29
include/uapi/linux/virtio_gpu.h| 39 +
6 files changed, 602 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index da2fb585fea4..268b386e1232 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -178,6 +178,8 @@ struct virtio_gpu_device {
struct virtio_gpu_queue ctrlq;
struct virtio_gpu_queue cursorq;
+ struct virtio_gpu_queue winsrv_rxq;
+ struct virtio_gpu_queue winsrv_txq;
struct kmem_cache *vbufs;
bool vqs_ready;
@@ -205,10 +207,32 @@ struct virtio_gpu_device {
struct virtio_gpu_fpriv {
uint32_t ctx_id;
+
+ struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
+ spinlock_t winsrv_lock;
+};
+
+struct virtio_gpu_winsrv_rx_qentry {
+ struct virtio_gpu_winsrv_rx *cmd;
+ struct list_head next;
+};
+
+struct virtio_gpu_winsrv_conn {
+ struct virtio_gpu_device *vgdev;
+
+ spinlock_t lock;
+
+ int fd;
+ struct drm_file *drm_file;
+
+ struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
+ wait_queue_head_t cmdwq;
+
+ struct list_head next;
};
/* virtio_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 10
+#define DRM_VIRTIO_NUM_IOCTLS 11
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
/* virtio_kms.c */
@@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device
*vgdev,
void virtio_gpu_ctrl_ack(struct virtqueue *vq);
void virtio_gpu_cursor_ack(struct virtqueue *vq);
void virtio_gpu_fence_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_rx_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_tx_func(struct work_struct *work);
void virtio_gpu_dequeue_fence_func(struct work_struct *work);
+void virtio_gpu_fill_winsrv_rx(struct virtio_gpu_device *vgdev);
+void virtio_gpu_queue_winsrv_rx_in(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_winsrv_rx *cmd);
+int virti
Re: [PATCH v2 3/3] etnaviv: support performance monitor requests
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Add etna_cmd_stream_perf(..) to submit perform requests.
> Userspace can submit pmrs via submit ioctl to sample perfmon
> signals.
>
> Signed-off-by: Christian Gmeiner
> ---
> etnaviv/etnaviv-symbol-check | 1 +
> etnaviv/etnaviv_cmd_stream.c | 20
> etnaviv/etnaviv_drmif.h | 12
> etnaviv/etnaviv_priv.h | 4
> 4 files changed, 37 insertions(+)
>
> diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-
> check
> index bd95b459..bc509615 100755
> --- a/etnaviv/etnaviv-symbol-check
> +++ b/etnaviv/etnaviv-symbol-check
> @@ -41,6 +41,7 @@ etna_cmd_stream_timestamp
> etna_cmd_stream_flush
> etna_cmd_stream_flush2
> etna_cmd_stream_finish
> +etna_cmd_stream_perf
> etna_cmd_stream_reloc
> etna_perfmon_create
> etna_perfmon_del
> diff --git a/etnaviv/etnaviv_cmd_stream.c
> b/etnaviv/etnaviv_cmd_stream.c
> index 8d0e8135..d6f26a88 100644
> --- a/etnaviv/etnaviv_cmd_stream.c
> +++ b/etnaviv/etnaviv_cmd_stream.c
> @@ -105,6 +105,7 @@ void etna_cmd_stream_del(struct etna_cmd_stream
> *stream)
>
> free(stream->buffer);
> free(priv->submit.relocs);
> + free(priv->submit.pmrs);
> free(priv);
> }
>
> @@ -115,6 +116,7 @@ static void reset_buffer(struct etna_cmd_stream
> *stream)
> stream->offset = 0;
> priv->submit.nr_bos = 0;
> priv->submit.nr_relocs = 0;
> + priv->submit.nr_pmrs = 0;
> priv->nr_bos = 0;
>
> if (priv->reset_notify)
> @@ -191,6 +193,8 @@ static void flush(struct etna_cmd_stream *stream,
> int in_fence_fd,
> .nr_bos = priv->submit.nr_bos,
> .relocs = VOID2U64(priv->submit.relocs),
> .nr_relocs = priv->submit.nr_relocs,
> + .pmrs = VOID2U64(priv->submit.pmrs),
> + .nr_pmrs = priv->submit.nr_pmrs,
> .stream = VOID2U64(stream->buffer),
> .stream_size = stream->offset * 4, /* in bytes */
> };
> @@ -260,3 +264,19 @@ void etna_cmd_stream_reloc(struct
> etna_cmd_stream *stream, const struct etna_rel
>
> etna_cmd_stream_emit(stream, addr);
> }
> +
> +void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const
> struct etna_perf *p)
> +{
> + struct etna_cmd_stream_priv *priv =
> etna_cmd_stream_priv(stream);
> + struct drm_etnaviv_gem_submit_pmr *pmr;
> + uint32_t idx = APPEND(&priv->submit, pmrs);
> +
> + pmr = &priv->submit.pmrs[idx];
> +
> + pmr->flags = p->flags;
> + pmr->sequence = p->sequence;
> + pmr->read_offset = p->offset;
> + pmr->read_idx = bo2idx(stream, p->bo, ETNA_SUBMIT_BO_READ);
This should be BO R/W. While it's not strictly the GPU writing to the
buffer, the GPU submit will alter the BO.
> + pmr->domain = p->signal->domain->id;
> + pmr->signal = p->signal->signal;
> +}
> diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
> index 949b9b62..5a6bef8d 100644
> --- a/etnaviv/etnaviv_drmif.h
> +++ b/etnaviv/etnaviv_drmif.h
> @@ -201,4 +201,16 @@ void etna_perfmon_del(struct etna_perfmon
> *perfmon);
> struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct
> etna_perfmon *pm, const char *name);
> struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct
> etna_perfmon_domain *dom, const char *name);
>
> +struct etna_perf {
> +#define ETNA_PM_PROCESS_PRE 0x0001
> +#define ETNA_PM_PROCESS_POST0x0002
> + uint32_t flags;
> + uint32_t sequence;
> + struct etna_perfmon_signal *signal;
> + struct etna_bo *bo;
> + uint32_t offset;
> +};
> +
> +void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const
> struct etna_perf *p);
> +
> #endif /* ETNAVIV_DRMIF_H_ */
> diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
> index 7b289b61..e45d364c 100644
> --- a/etnaviv/etnaviv_priv.h
> +++ b/etnaviv/etnaviv_priv.h
> @@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
> /* reloc's table: */
> struct drm_etnaviv_gem_submit_reloc *relocs;
> uint32_t nr_relocs, max_relocs;
> +
> + /* perf's table: */
> + struct drm_etnaviv_gem_submit_pmr *pmrs;
> + uint32_t nr_pmrs, max_pmrs;
max_pmrs isn't used anywhere AFAICS.
> } submit;
>
> /* should have matching entries in submit.bos: */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] etnaviv: add permon support
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Query all domains and their signals and provide it this information
> via struct etna_perfmon and the corresponding api functions.
>
> v2:
> - code style changes
> - etna_perfmon_create(..): add missing clean up in error case
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> etnaviv/Makefile.sources | 1 +
> etnaviv/etnaviv-symbol-check | 4 +
> etnaviv/etnaviv_drmif.h | 11 +++
> etnaviv/etnaviv_perfmon.c| 189
> +++
> etnaviv/etnaviv_priv.h | 21 +
> 5 files changed, 226 insertions(+)
> create mode 100644 etnaviv/etnaviv_perfmon.c
>
> diff --git a/etnaviv/Makefile.sources b/etnaviv/Makefile.sources
> index 52580567..0eb73783 100644
> --- a/etnaviv/Makefile.sources
> +++ b/etnaviv/Makefile.sources
> @@ -3,6 +3,7 @@ LIBDRM_ETNAVIV_FILES := \
> etnaviv_gpu.c \
> etnaviv_bo.c \
> etnaviv_bo_cache.c \
> + etnaviv_perfmon.c \
> etnaviv_pipe.c \
> etnaviv_cmd_stream.c \
> etnaviv_drm.h \
> diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-
> check
> index 0e2030e4..bd95b459 100755
> --- a/etnaviv/etnaviv-symbol-check
> +++ b/etnaviv/etnaviv-symbol-check
> @@ -42,6 +42,10 @@ etna_cmd_stream_flush
> etna_cmd_stream_flush2
> etna_cmd_stream_finish
> etna_cmd_stream_reloc
> +etna_perfmon_create
> +etna_perfmon_del
> +etna_perfmon_get_dom_by_name
> +etna_perfmon_get_sig_by_name
> EOF
> done)
>
> diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
> index 87704acd..949b9b62 100644
> --- a/etnaviv/etnaviv_drmif.h
> +++ b/etnaviv/etnaviv_drmif.h
> @@ -35,6 +35,9 @@ struct etna_pipe;
> struct etna_gpu;
> struct etna_device;
> struct etna_cmd_stream;
> +struct etna_perfmon;
> +struct etna_perfmon_domain;
> +struct etna_perfmon_signal;
>
> enum etna_pipe_id {
> ETNA_PIPE_3D = 0,
> @@ -190,4 +193,12 @@ struct etna_reloc {
>
> void etna_cmd_stream_reloc(struct etna_cmd_stream *stream, const
> struct etna_reloc *r);
>
> +/* performance monitoring functions:
> + */
> +
> +struct etna_perfmon *etna_perfmon_create(struct etna_pipe *pipe);
> +void etna_perfmon_del(struct etna_perfmon *perfmon);
> +struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct
> etna_perfmon *pm, const char *name);
> +struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct
> etna_perfmon_domain *dom, const char *name);
> +
> #endif /* ETNAVIV_DRMIF_H_ */
> diff --git a/etnaviv/etnaviv_perfmon.c b/etnaviv/etnaviv_perfmon.c
> new file mode 100644
> index ..aa5130a6
> --- /dev/null
> +++ b/etnaviv/etnaviv_perfmon.c
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2017 Etnaviv Project
> + * Copyright (C) 2017 Zodiac Inflight Innovations
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice (including
> the next
> + * paragraph) shall be included in all copies or substantial
> portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS IN THE
> + * SOFTWARE.
> + *
> + * Authors:
> + *Christian Gmeiner
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +# include
> +#endif
> +
> +#include "etnaviv_priv.h"
> +
> +static int etna_perfmon_query_signals(struct etna_perfmon *pm,
> struct etna_perfmon_domain *dom)
> +{
> + struct etna_device *dev = pm->pipe->gpu->dev;
> + struct drm_etnaviv_pm_signal req = {
> + .pipe = pm->pipe->id,
> + .domain = dom->id
> + };
> +
> + do {
> + struct etna_perfmon_signal *sig;
> + int ret;
> +
> + ret = drmCommandWriteRead(dev->fd,
> DRM_ETNAVIV_PM_QUERY_SIG, &req, sizeof(req));
> + if (ret)
> + break;
> +
> + sig = calloc(1, sizeof(*sig));
> + if (!sig)
> + return -ENOMEM;
> +
> + INFO_MSG("perfmon signal:");
> + INFO_MSG("id = %d", req.id);
> + INFO_MSG("name = %s", req.name);
> +
> + sig->domain
[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #35 from Michel Dänzer --- (In reply to FFAB from comment #32) > I'll set this bug as r e s o l v e d when the solution is in released > ubuntu versions available This is an upstream bug tracker, not an Ubuntu one. If the problem is fixed with upstream 4.15-rc3, please resolve this report as fixed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] etnaviv: sync uapi header
Am Dienstag, den 12.12.2017, 22:27 +0100 schrieb Christian Gmeiner:
> Import the etnaviv header changes from kernel commit 05916bed1 (drm-
> next)
>
> The drm_etnaviv_gem_submit structure was extended to include
> performance
> monitor requests. Also two new ioctls got added to be able to readout
> performance monitor domains and their signals.
>
> Signed-off-by: Christian Gmeiner
Acked-by: Lucas Stach
> ---
> etnaviv/etnaviv_drm.h | 43
> ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
> index 76f6f78a..110cc73b 100644
> --- a/etnaviv/etnaviv_drm.h
> +++ b/etnaviv/etnaviv_drm.h
> @@ -150,6 +150,19 @@ struct drm_etnaviv_gem_submit_bo {
> __u64 presumed; /* in/out, presumed buffer address */
> };
>
> +/* performance monitor request (pmr) */
> +#define ETNA_PM_PROCESS_PRE 0x0001
> +#define ETNA_PM_PROCESS_POST0x0002
> +struct drm_etnaviv_gem_submit_pmr {
> + __u32 flags; /* in, when to process request
> (ETNA_PM_PROCESS_x) */
> + __u8 domain; /* in, pm domain */
> + __u8 pad;
> + __u16 signal; /* in, pm signal */
> + __u32 sequence; /* in, sequence number */
> + __u32 read_offset;/* in, offset from read_bo */
> + __u32 read_idx; /* in, index of read_bo buffer */
> +};
> +
> /* Each cmdstream submit consists of a table of buffers involved,
> and
> * one or more cmdstream buffers. This allows for conditional
> execution
> * (context-restore), and IB buffers needed for per tile/bin draw
> cmds.
> @@ -175,6 +188,9 @@ struct drm_etnaviv_gem_submit {
> __u64 stream; /* in, ptr to cmdstream */
> __u32 flags; /* in, mask of ETNA_SUBMIT_x */
> __s32 fence_fd; /* in/out, fence fd (see
> ETNA_SUBMIT_FENCE_FD_x) */
> + __u64 pmrs; /* in, ptr to array of submit_pmr's */
> + __u32 nr_pmrs;/* in, number of submit_pmr's */
> + __u32 pad;
> };
>
> /* The normal way to synchronize with the GPU is just to CPU_PREP on
> @@ -210,6 +226,27 @@ struct drm_etnaviv_gem_wait {
> struct drm_etnaviv_timespec timeout;/* in */
> };
>
> +/*
> + * Performance Monitor (PM):
> + */
> +
> +struct drm_etnaviv_pm_domain {
> + __u32 pipe; /* in */
> + __u8 iter; /* in/out, select pm domain at index iter
> */
> + __u8 id; /* out, id of domain */
> + __u16 nr_signals; /* out, how many signals does this domain
> provide */
> + char name[64]; /* out, name of domain */
> +};
> +
> +struct drm_etnaviv_pm_signal {
> + __u32 pipe; /* in */
> + __u8 domain; /* in, pm domain index */
> + __u8 pad;
> + __u16 iter; /* in/out, select pm source at index iter
> */
> + __u16 id; /* out, id of signal */
> + char name[64]; /* out, name of domain */
> +};
> +
> #define DRM_ETNAVIV_GET_PARAM 0x00
> /* placeholder:
> #define DRM_ETNAVIV_SET_PARAM 0x01
> @@ -222,7 +259,9 @@ struct drm_etnaviv_gem_wait {
> #define DRM_ETNAVIV_WAIT_FENCE 0x07
> #define DRM_ETNAVIV_GEM_USERPTR0x08
> #define DRM_ETNAVIV_GEM_WAIT 0x09
> -#define DRM_ETNAVIV_NUM_IOCTLS 0x0a
> +#define DRM_ETNAVIV_PM_QUERY_DOM 0x0a
> +#define DRM_ETNAVIV_PM_QUERY_SIG 0x0b
> +#define DRM_ETNAVIV_NUM_IOCTLS 0x0c
>
> #define DRM_IOCTL_ETNAVIV_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE +
> DRM_ETNAVIV_GET_PARAM, struct drm_etnaviv_param)
> #define DRM_IOCTL_ETNAVIV_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE +
> DRM_ETNAVIV_GEM_NEW, struct drm_etnaviv_gem_new)
> @@ -233,6 +272,8 @@ struct drm_etnaviv_gem_wait {
> #define DRM_IOCTL_ETNAVIV_WAIT_FENCE DRM_IOW(DRM_COMMAND_BASE +
> DRM_ETNAVIV_WAIT_FENCE, struct drm_etnaviv_wait_fence)
> #define DRM_IOCTL_ETNAVIV_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
> DRM_ETNAVIV_GEM_USERPTR, struct drm_etnaviv_gem_userptr)
> #define DRM_IOCTL_ETNAVIV_GEM_WAIT DRM_IOW(DRM_COMMAND_BASE +
> DRM_ETNAVIV_GEM_WAIT, struct drm_etnaviv_gem_wait)
> +#define DRM_IOCTL_ETNAVIV_PM_QUERY_DOM DRM_IOWR(DRM_COMMAND_BASE +
> DRM_ETNAVIV_PM_QUERY_DOM, struct drm_etnaviv_pm_domain)
> +#define DRM_IOCTL_ETNAVIV_PM_QUERY_SIG DRM_IOWR(DRM_COMMAND_BASE +
> DRM_ETNAVIV_PM_QUERY_SIG, struct drm_etnaviv_pm_signal)
>
> #if defined(__cplusplus)
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] x86/gpu: add CFL to early quirks
On Wed, 13 Dec 2017, Lucas De Marchi wrote:
> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
> allow the memory region to be stolen, otherwise we could have RAM being
> arbitrarily overwritten if for example we keep using the UEFI framebuffer,
> depending on how BIOS has set up the e820 map.
>
> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
> Signed-off-by: Lucas De Marchi
> Cc: Rodrigo Vivi
> Cc: Anusha Srivatsa
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: David Airlie
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: Thomas Gleixner
> Cc: x...@kernel.org
> Cc: # v4.13+ 0890540e21cf drm/i915: add GT number to
> intel_device_info
> Cc: # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL
> pci id to GT2 from GT1.5
> Cc: # v4.13+
Agreed on the Fixes: and Cc: stable here.
Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
> ---
>
> v2: improve commit message, add Fixes tag and CC stable
>
> arch/x86/kernel/early-quirks.c | 1 +
> include/drm/i915_pciids.h | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 3cbb2c78a9df..bae0d32e327b 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -528,6 +528,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> INTEL_SKL_IDS(&gen9_early_ops),
> INTEL_BXT_IDS(&gen9_early_ops),
> INTEL_KBL_IDS(&gen9_early_ops),
> + INTEL_CFL_IDS(&gen9_early_ops),
> INTEL_GLK_IDS(&gen9_early_ops),
> INTEL_CNL_IDS(&gen9_early_ops),
> };
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 972a25633525..c65e4489006d 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -392,6 +392,12 @@
> INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
> INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */
>
> +#define INTEL_CFL_IDS(info) \
> + INTEL_CFL_S_GT1_IDS(info), \
> + INTEL_CFL_S_GT2_IDS(info), \
> + INTEL_CFL_H_GT2_IDS(info), \
> + INTEL_CFL_U_GT3_IDS(info)
> +
> /* CNL U 2+2 */
> #define INTEL_CNL_U_GT2_IDS(info) \
> INTEL_VGA_DEVICE(0x5A52, info), \
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend
Hi,
On Wed, Dec 13, 2017 at 05:23:04PM +0100, Thomas van Kleef wrote:
> I wondered if the following is still valid?
> In file sun4i_layer.c, func sun4i_layers_init
>
> --
> /*
> * The hardware is a bit unusual here.
> *
> * Even though it supports 4 layers, it does the composition
> * in two separate steps.
> *
> * The first one is assigning a layer to one of its two
> * pipes. If more that 1 layer is assigned to the same pipe,
> * and if pixels overlaps, the pipe will take the pixel from
> * the layer with the highest priority.
> *
> * The second step is the actual alpha blending, that takes
> * the two pipes as input, and uses the eventual alpha
> * component to do the transparency between the two.
> *
> * This two steps scenario makes us unable to guarantee a
> * robust alpha blending between the 4 layers in all
> * situations. So we just expose two layers, one per pipe. On
> * SoCs that support it, sprites could fill the need for more
> * layers.
> */
> for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
> const struct sun4i_plane_desc *plane =
> &sun4i_backend_planes[i];
> struct sun4i_layer *layer;
>
> layer = sun4i_layer_init_one(drm, backend, plane);
> if (IS_ERR(layer)) {
> dev_err(drm->dev, "Couldn't initialize %s plane\n",
> i ? "overlay" : "primary");
> return ERR_CAST(layer);
> };
>
> DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
> i ? "overlay" : "primary", plane->pipe);
> regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
>SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK,
>
> SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
>
> layer->id = i;
> planes[i] = &layer->plane;
> };
> -
>
> I have been using the 3rd layer (layer2) as the input for the
> frontend. This essentially overlays the other 2 layers. Is it still
> the case that we can only have 2 layers here?
Yes.
> Or could be present 1 additional layer when it is attached to the
> frontend?
The frontend will still consume a backend layer. In this current
serie, we still define only two layers for the reasons exposed above,
and whatever layer using hardware scaling will use the frontend.
I have a few patches that would remove that limitation, but we need a
few things in order to do that properly.
The first one would be to add a check on the alpha component of our
layers. We basically have two rules:
- the lowest plane shouldn't use alpha at all, because of a bug in
the display engine that would render the pixels completely
transparents if the alpha is set to something less than 255 on the
lowest plane.
- we can only have a plane with alpha as the lowest plane of each
pipe.
This effectively means that the only scenario that works would be that
there can be only one plane can use alpha at a time, that it shouldn't
be the lowest one, and that it must be assigned to the second pipe.
I worked on that a bit quite some time ago, and the only thing I was
missing was a proper way to check for that in atomic_check, but with
the work done in this serie it shouldn't be too hard.
Then, we can enable the four layers, which is not really difficult in
itself.
> Perhaps this is not relevant for this patchset.
Yep, that's quite orthogonal.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support
On Thu, Dec 14, 2017 at 11:30:21AM +0800, Chen-Yu Tsai wrote: > >> > + /* Map output pins to channel 0 */ > >> > + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG, > >> > + SUN4I_TCON_GCTL_IOMAP_MASK, > >> > + SUN4I_TCON_GCTL_IOMAP_TCON0); > >> > + > >> > + /* Enable the output on the pins */ > >> > + regmap_write(tcon->regs, SUN4I_TCON0_IO_TRI_REG, 0xe000); > >> > >> Is this still needed? You are no longer using the TCON LCD pins > >> with LVDS. > > > > We do. It's a separate function of the pins, but it's the same pins. > > OK. I assume you've tried it without setting it and it failed? > I just assume that these refer to the TCON LCD output, whereas > LVDS looks like a separate module and function, and shouldn't > need it. Argh, I forgot to test that. I'll test it for real this time and will update that part with a comment if that's needed. Sorry :/ Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx
Hi Thomas:
Really sorry for that and will keep that in mind.
If necessary, next time I will send cover letter to provide more background and
details.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Thursday, December 14, 2017 3:21 AM
To: He, Roger ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into
ttm_operation_ctx
Hi,
I think this series is quite poorly documented. We should have a log message
explaining the purpose of the commit.
Also since it's not obvious what the series is attempting to achieve, please
add a 0/X series header message..
/Thomas
On 12/12/2017 10:33 AM, Roger He wrote:
> on_alloc_stage: is this operation on allocation stage
> resv: reservation bo used of this operation
>
> Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
> Signed-off-by: Roger He
> ---
> include/drm/ttm/ttm_bo_api.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/ttm/ttm_bo_api.h
> b/include/drm/ttm/ttm_bo_api.h index 368eb02..25de597 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
>*
>* @interruptible: Sleep interruptible if sleeping.
>* @no_wait_gpu: Return immediately if the GPU is busy.
> + * @on_alloc_stage: is this operation on allocation stage
> + * @resv: resvation bo used
>*
>* Context for TTM operations like changing buffer placement or general
> memory
>* allocation.
> @@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
> struct ttm_operation_ctx {
> bool interruptible;
> bool no_wait_gpu;
> + bool on_alloc_stage;
> + struct reservation_object *resv;
> uint64_t bytes_moved;
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx
Am 14.12.2017 um 09:55 schrieb Thomas Hellstrom: Hi, Christian, On 12/14/2017 09:40 AM, Christian König wrote: Hi Thomas, sorry for that. Noted on the rest of that series as well that we need to improve the commit messages. But this one somehow slipped through because I discussed this change previously internally with Roger. That made the change completely logical for me, but without this context everybody else just thinks "Hui what?". Going to keep that in mind the next time. But back to topic: This series allows BOs which share the same reservation object as the BO currently allocated/validated to be evicted even when they are reserved. This is useful because amdgpu wants to use a single reservation object for almost all BOs of a process. Yes, that indeed makes the whole thing more clear, and makes sense. Out of interest, is the shared reservation object usage a speed optimization (avoiding the ww_mutex_locks at reservation time?) or something else? Avoiding taking many ww_mutex_locks is one reason. The other major reason comes with GPU-VM page tables. Just the same as CPU page tables multi level GPU page tables are allocated individually when needed. But during command submission we must make sure that all GPU page tables are validated and fences added to all of them. Because of this we are using the reservation object of the root page directory (because that one is always allocated) as reservation object for all other page tables. The effect is that you have to add the resulting fence of a command submission to only one reservation object and not a couple of hundreds or even thousands. I guess that even if LRU lists might get crowded with unevictable BOs, iterating through those lists isn't really part of the fast path. Yes, exactly. When we start to massively evict things performance goes down so much anyway that this extra cycling over the LRU doesn't hurt us much. Christian. /Thomas Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] vmwgfx: use monotonic event timestamps
On Wed, Dec 13, 2017 at 9:56 PM, Sinclair Yeh wrote: > This looks okay to me. Although we should change eaction->tv_* type > to 64-bit as well. I thought about it but it would add significant complication without real gain, as the eaction->tv_* pointers point into uapi structures (drm_vmw_event_fence and drm_event_vblank) that are defined as 32-bit times and cannot be changed. Changing the temporary pointer to 64 bit would require adding a temporary variable to point to and then doing the truncation in the callers. With monotonic times, we know that 32-bit times are sufficient, they are good for 136 years after boot (68 years when interpreted as signed). Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx
Hi, Christian, On 12/14/2017 09:40 AM, Christian König wrote: Hi Thomas, sorry for that. Noted on the rest of that series as well that we need to improve the commit messages. But this one somehow slipped through because I discussed this change previously internally with Roger. That made the change completely logical for me, but without this context everybody else just thinks "Hui what?". Going to keep that in mind the next time. But back to topic: This series allows BOs which share the same reservation object as the BO currently allocated/validated to be evicted even when they are reserved. This is useful because amdgpu wants to use a single reservation object for almost all BOs of a process. Yes, that indeed makes the whole thing more clear, and makes sense. Out of interest, is the shared reservation object usage a speed optimization (avoiding the ww_mutex_locks at reservation time?) or something else? I guess that even if LRU lists might get crowded with unevictable BOs, iterating through those lists isn't really part of the fast path. /Thomas Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter
Hi Laurent,
On Thu, Dec 14, 2017 at 9:17 AM, Laurent Pinchart
wrote:
> On Thursday, 14 December 2017 04:10:27 EET Kuninori Morimoto wrote:
>> >> + if ((fvco < 2000) ||
>> >> + (fvco > 409600ll))
>> >
>> > No need for the inner parentheses, and you can write both conditions on a
>> > single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's
>> > no need for the ll.
>>
>> Yes, but compiled by 32bit too, right ?
>> Without this "ll", 32bit compiler say
>>
>> warning: this decimal constant is unsigned only in ISO C90
>
> That's right. How about 409600UL then, to force unsigned integer types ?
> Or possibly even better, 4096 * 1000 * 1000UL to make it more readable ?
If it's just about making the number unsigned, and not about 64-bit arithmetic,
a "U" suffix should be sufficient.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx
Hi Thomas,
sorry for that. Noted on the rest of that series as well that we need to
improve the commit messages. But this one somehow slipped through
because I discussed this change previously internally with Roger.
That made the change completely logical for me, but without this context
everybody else just thinks "Hui what?". Going to keep that in mind the
next time.
But back to topic: This series allows BOs which share the same
reservation object as the BO currently allocated/validated to be evicted
even when they are reserved.
This is useful because amdgpu wants to use a single reservation object
for almost all BOs of a process.
Regards,
Christian.
Am 13.12.2017 um 20:21 schrieb Thomas Hellstrom:
Hi,
I think this series is quite poorly documented. We should have a log
message explaining the purpose of the commit.
Also since it's not obvious what the series is attempting to achieve,
please add a 0/X series header message..
/Thomas
On 12/12/2017 10:33 AM, Roger He wrote:
on_alloc_stage: is this operation on allocation stage
resv: reservation bo used of this operation
Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
Signed-off-by: Roger He
---
include/drm/ttm/ttm_bo_api.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 368eb02..25de597 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
*
* @interruptible: Sleep interruptible if sleeping.
* @no_wait_gpu: Return immediately if the GPU is busy.
+ * @on_alloc_stage: is this operation on allocation stage
+ * @resv: resvation bo used
*
* Context for TTM operations like changing buffer placement or
general memory
* allocation.
@@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
struct ttm_operation_ctx {
bool interruptible;
bool no_wait_gpu;
+ bool on_alloc_stage;
+ struct reservation_object *resv;
uint64_t bytes_moved;
};
___
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 v4 00/15] drm/sun4i: Add A83t LVDS support
On Thu, Dec 14, 2017 at 07:01:57AM +, Priit Laes wrote: > On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote: > > Hi, > > > > Here is an attempt at supporting the LVDS output in our DRM driver. This > > has been tested on the A83T (with DE2), but since everything is basically > > in the TCON, it should also be usable on the older SoCs with minor > > modifications. > > I managed to get the single-channel LVDS working on an A10 tablet after > doing those minor modifications (although, the colours are off a bit). > So in general this series looks good :) Is that a Tested-by? :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/sun4i: Support the Display Engine frontend
Hi Thomas, On Wed, Dec 13, 2017 at 05:16:22PM +0100, Thomas van Kleef wrote: > Hi, > > On 13-12-17 16:33, Maxime Ripard wrote: > > Hi, > > > > This is a first serie to enable the display engine frontend. > > > > This hardware block is found in the first generation Display Engine from > > Allwinner. Its role is to implement more advanced features that the > > associated backend, even though the backend alone can be used (and was used > > so far) for basic composition. > > > > Among those features, we will find hardware scaling, that is supported in > > this serie, colorspace conversions, or more exotic formats support such as > > the one output by the VPU. > > So, if I have read the code correctly. The frontend will be used whenever the > input size differs from the output size. Yes :) My current plan is to extend it as needed when we'll need to deal with a format not supported by the backend (for the VPU), or anything the backend cannot support. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/vmwgfx: Add and connect plane helper functions
Hello Sinclair Yeh,
This is a semi-automatic email about new static checker warnings.
The patch 060e2ad57041: "drm/vmwgfx: Add and connect plane helper
functions" from Mar 23, 2017, leads to the following Smatch complaint:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:466 vmw_du_primary_plane_atomic_check()
error: we previously assumed 'crtc' could be null (see line 463)
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
441 int vmw_du_primary_plane_atomic_check(struct drm_plane *plane,
442struct drm_plane_state *state)
443 {
444 struct drm_crtc_state *crtc_state = NULL;
445 struct drm_framebuffer *new_fb = state->fb;
446 struct drm_rect clip = {};
447 int ret;
448
449 if (state->crtc)
^^^
Check for NULL
450 crtc_state =
drm_atomic_get_new_crtc_state(state->state, state->crtc);
451
452 if (crtc_state && crtc_state->enable) {
453 clip.x2 = crtc_state->adjusted_mode.hdisplay;
454 clip.y2 = crtc_state->adjusted_mode.vdisplay;
455 }
456
457 ret = drm_atomic_helper_check_plane_state(state, crtc_state,
&clip,
458
DRM_PLANE_HELPER_NO_SCALING,
459
DRM_PLANE_HELPER_NO_SCALING,
460false, true);
461
462 if (!ret && new_fb) {
463 struct drm_crtc *crtc = state->crtc;
464 struct vmw_connector_state *vcs;
465 struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
466 struct vmw_private *dev_priv = vmw_priv(crtc->dev);
^
Unchecked dereference
467 struct vmw_framebuffer *vfb =
vmw_framebuffer_to_vfb(new_fb);
468
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support
On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote: > Hi, > > Here is an attempt at supporting the LVDS output in our DRM driver. This > has been tested on the A83T (with DE2), but since everything is basically > in the TCON, it should also be usable on the older SoCs with minor > modifications. I managed to get the single-channel LVDS working on an A10 tablet after doing those minor modifications (although, the colours are off a bit). So in general this series looks good :) > > This was the occasion to refactor a bunch of things. The most notable ones > would be the documentation, and split of the UI layers in the mixer code, > and the switch to kfifo for our endpoint parsing code in the driver that > fixes an issue introduced by the switch to BFS. > > Let me know what you think, > Maxime > > Changes from v3: > - Collect the tags > - Use SPDX headers when possible > - Added the new mixer configuration options > - Changed the LVDS clock for lvds-alt instead of lvds-pll > - Removed the MIPI PLL from the A31s > - Changed the LVDS_ANA0 macros name to reflect the generation they were > introduced in, and added a comment to mention the changes needed to > support the older SoCs > > Changes from v2: > - Move the module clock rate to the mixer structure > - Adjusted the simple-panel documentation for power-supply > - Changed the compatible for the first A83t mixer to mixer 0 > - Rebased on top of current drm-misc > - Split out the A83t bindings in its separate patch > > Changes from v1: > - Added a fix for the error path handling in the TCON > - Enable the TCON by default > - Removed the patch that changes the channels offset but kept most of the > modifications as a cleanup > - Deal with the LVDS clock being able to have another PLL parent on some > SoCs > - Renamed the TCON compatible to TCON-TV, following the convention used > on newer SoCs > - Removed the hardcoded timings > - Moved LVDS enable quirks to a separate function > - Used clock indices define in the DT > - Removed the hardcoded clock rate in the DT and moved it to the driver > - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent > - Added the various tags collected > - Rebased on top of 4.15 > > Maxime Ripard (15): > dt-bindings: panel: lvds: Document power-supply property > drm/panel: lvds: Add support for the power-supply property > dt-bindings: display: sun4i-drm: Add LVDS properties > dt-bindings: display: sun4i-drm: Add A83T pipeline > drm/sun4i: Fix error path handling > drm/sun4i: Force the mixer rate at 150MHz > drm/sun4i: Create minimal multipliers and dividers > drm/sun4i: Add LVDS support > drm/sun4i: Add A83T support > ARM: dts: sun8i: a83t: Add display pipeline > ARM: dts: sun8i: a83t: Enable the PWM > ARM: dts: sun8i: a83t: Add LVDS pins group > ARM: dts: sun8i: a83t: Add the PWM pin group > ARM: dts: sun8i: a711: Reinstate the PMIC compatible > ARM: dts: sun8i: a711: Enable the LCD > > Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++- > Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +- > Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt| 12 +++- > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts| 62 > ++- > arch/arm/boot/dts/sun8i-a83t.dtsi| 99 > - > drivers/gpu/drm/panel/panel-lvds.c | 23 > +++- > drivers/gpu/drm/sun4i/Makefile | 1 +- > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 10 ++- > drivers/gpu/drm/sun4i/sun4i_drv.c| 1 +- > drivers/gpu/drm/sun4i/sun4i_lvds.c | 177 > +++- > drivers/gpu/drm/sun4i/sun4i_lvds.h | 18 +- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 251 > +++- > drivers/gpu/drm/sun4i/sun4i_tcon.h | 31 > +- > drivers/gpu/drm/sun4i/sun8i_mixer.c | 20 > ++- > drivers/gpu/drm/sun4i/sun8i_mixer.h | 3 +- > 16 files changed, 710 insertions(+), 7 deletions(-) > create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c > create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h > > base-commit: 3b71239181e5429702387666f1ac70a9e6856cce > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace
On Wed, Dec 13, 2017 at 03:41:49PM +, Daniel Stone wrote:
> Hi Russell,
>
> On 8 December 2017 at 12:31, Russell King wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion. This is mutually
> > exclusive with the CSC_YUV CRTC property - the last property to be set
> > determines the resulting colorspace conversion.
>
> I haven't seen this in other drivers - is it a 'defacto standard'?
As far as I know, nothing for this is standardised - when I implemented
this method, I did survey the drivers, and decided it was best to use
what existing implementations were already using. I wrote this patch
back in February, so memory is now hazy, but iirc, it came from:
drivers/gpu/drm/nouveau/dispnv04/overlay.c
> I prefer VIlle's choice of an explicit 601/709 enum, since that's more
> easily expandable. I do worry about the interaction with the CTM
> properties, but I also don't have a good answer as to what that would
> look like. I also worry that implementing the 'last-property-set'
> semantics might be difficult to implement in an atomic driver.
Nothing really made use of the CRTC property, so its unlikely that
there'll be a conflict. I suspect I could delete the CRTC property
when eventually switching to atomic modeset.
>
> > struct armada_ovl_plane {
> > @@ -252,6 +254,10 @@ armada_ovl_plane_update(struct drm_plane *plane,
> > struct drm_crtc *crtc,
> > if (!dcrtc->plane) {
> > dcrtc->plane = plane;
> > armada_ovl_update_attr(&dplane->prop, dcrtc);
> > + if (dplane->prop.csc_set) {
> > + armada_drm_crtc_set_yuv_colorimetry(dcrtc,
> > dplane->prop.csc);
> > + dplane->prop.csc_set = false;
> > + }
> > }
>
> Just trying to understand this a little better: setting this property
> on a plane results in a CRTC change. This is only implemented for the
> overlay ('video') plane, but the primary ('graphics') plane also
> supports YUV formats. Does this mean that the two planes have to have
> the same configuration wrt 601/709 if both are YUV? That could again
> get painful to express.
The same is true of the saturation, brightness, contrast etc values.
There is only one set of YUV to RGB conversion in the hardware block
and its settings will be used for both.
However, practically I don't think YUV is ever used for the primary
plane, so I could just drop those from the list of primary plane
formats.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter
Hi Laurent
Thank you for your feedback
> > +* NOTES
> > +* N = (n + 1), M = (m + 1), P = 2
> > +* 2000 < fvco < 4096Mhz
>
> Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz -
> 4GHz would be a surprisingly large range.
It is 2kHz. This is came from HW team, and indicated
on HW design sheet (?)
> > +* Basically M=1
>
> Why is this ?
This is came from HW team, too.
They are assuming M=1, basically.
But yes confusable, let's remove it from comment.
m is started from 0 (= M=1), no need to explain.
> > + for (m = 0; m < 4; m++) {
> > + for (n = 119; n > 38; n--) {
> > + unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
>
> This code runs for Gen3 only, so unsigned long would be enough. The rest of
> the function already relies on native support for 64-bit calculation. If you
> wanted to run this on a 32-bit CPU, you would likely need to do_div() for the
> division, and convert input to u64 to avoid integer overflows, otherwise the
> calculation will be performed on 32-bit before a final conversion to 64-bit.
(snip)
> > + if ((fvco < 2000) ||
> > + (fvco > 409600ll))
>
> No need for the inner parentheses, and you can write both conditions on a
> single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's no
> need for the ll.
Yes, but compiled by 32bit too, right ?
Without this "ll", 32bit compiler say
warning: this decimal constant is unsigned only in ISO C90
# anyway, I will add this assumption (= used only by 64bit CPU)
# on comment to avoid future confusion
> I think you can then drop the output >= 40 check inside the inner
> fdpll loop, as the output frequency can't be higher than 4GHz if the VCO
> frequency isn't.
I think code has
if (output >= 4)
This is 400MHz, not 4GHz
> > for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
>
> The output frequency on the line below can be calculated with
>
> output = fvco / 2 / (fdpll + 1)
>
> to avoid the multiplication by (n + 1) and division by (m + 1).
It is nice idea to avoid extra calculation.
I will use this idea, and add extrate comment to avoid confusion
Best regards
---
Kuninori Morimoto
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: UDL's fbdev doesn't work for user-space apps
Hi Noralf, On Tue, 2017-12-12 at 22:58 +0100, Noralf Trønnes wrote: > Den 04.12.2017 12.32, skrev Alexey Brodkin: > > Hello, > > > > I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only > > video output and I want to get Xserver working on top of that. > > > > I'm not very familiar with all the parts of Linux GPU/video stack > > (especially its user-space counterpart) so my assumptions might be wrong > > in that case please correct me. > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > (/dev/fbX) > > and it cannot use DRI video card natively. Is that correct? > > > > So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & > > CONFIG_DRM_FBDEV_EMULATION. > > That gave me boot console on HDMI screen and I was full of expectations. > > But when I tried to use /dev/fb0 from whatever user-space app nothing got > > displayed on the screen... as well as no error messages appeared. > > > > After eyeballing at UDL code (especially in comparison with QXC which uses > > deferredio > > as well) I noticed that in UDL fb_deferred_io_init() is called from > > udl_fb_open(), > > i.e. .fb_open call-back (in other words every time user-space app opens > > /dev/fb0) > > while in QXC this is done only once and much earlier in qxlfb_create(), > > which is > > called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL > > driver from > > udl_fb_open() to udlfb_create() which is also called from .fb_probe. > > > > With that change I finally got video output via fbdev from user-space app, > > but only on the first run. The next attempt to run inevitably ends with > > kernel crash showing the following stack-trace (having half of the new > > screen > > rendered on display): > > >8- > > Stack Trace: > >udl_handle_damage+0x48/0x210 > >udl_crtc_mode_set+0x6ee/0x754 > >drm_crtc_helper_set_mode+0x25e/0x438 > >drm_crtc_helper_set_config+0x6d6/0x814 > >__drm_mode_set_config_internal+0x48/0xc8 > >drm_mode_setcrtc+0x320/0x478 > >drm_ioctl+0x22c/0x3e4 > >SyS_ioctl+0xa4/0x8cc > >EV_Trap+0x108/0x10c > > random: crng init done > > >8- > > > > I'm wondering if UDL driver (its DRM flavor) was ever tested for > > fbdev in user-space? If so and it really works for somebody > > maybe I'm doing something terribly wrong - in that case any comments > > are very welcome. > > udl uses shmem buffers which doesn't work with fbdev deferred io. > They fight over page->lru and page->mapping. See this commit: > drm/udl: disable fb_defio by default > 677d23b70bf949f75746c80cbae92c233c6b5e2a Well that's interesting indeed, but IMHO that's not the most important problem with UDL as of now since DRI-aware apps and Xserver stuff work fine with /dev/dri/cardX. What bothers me is some problem [probably] with export of its DMA buffers, so Vivante GPU does render stuff but it is not displayed on the screen... in absense of error messages I'd conclude that the GPU just renders to some virtuall addresses which are not mapped to UDL's "frame-buffers". And it's not about improper handling of caches - I tried with data caches disabled but still to no avail :( -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix a possible sleep-in-atomic bug in show_leaks
The driver may sleep under a spinlock. The function call path is: drm_vma_offset_manager_destroy (acquire the spinlock) drm_mm_takedown show_leaks kmalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/gpu/drm/drm_mm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 61a1c8e..5b9965d 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -127,7 +127,7 @@ static void show_leaks(struct drm_mm *mm) unsigned long entries[STACKDEPTH]; char *buf; - buf = kmalloc(BUFSZ, GFP_KERNEL); + buf = kmalloc(BUFSZ, GFP_ATOMIC); if (!buf) return; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend
On 13-12-17 16:33, Maxime Ripard wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not perform the DMA but
> receive its data from the frontend.
>
> Note that we're still not making any use of the frontend itself, as no one
> is setting the flag yet.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 53 -
> drivers/gpu/drm/sun4i/sun4i_backend.h | 3 ++-
> drivers/gpu/drm/sun4i/sun4i_layer.c | 27 --
> drivers/gpu/drm/sun4i/sun4i_layer.h | 1 +-
> 4 files changed, 81 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index e83e1fe43823..f1d19767c55d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -26,6 +26,7 @@
>
> #include "sun4i_backend.h"
> #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
> #include "sun4i_layer.h"
> #include "sunxi_engine.h"
>
> @@ -203,6 +204,30 @@ int sun4i_backend_update_layer_formats(struct
> sun4i_backend *backend,
> return 0;
> }
>
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> + int layer, uint32_t fmt)
> +{
> + u32 val;
> + int ret;
> +
> + ret = sun4i_backend_drm_format_to_layer(NULL, fmt, &val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid format\n");
> + return ret;
> + }
> +
> + regmap_update_bits(backend->engine.regs,
> +SUN4I_BACKEND_ATTCTL_REG0(layer),
> +SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
> +SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);
> +
> + regmap_update_bits(backend->engine.regs,
> +SUN4I_BACKEND_ATTCTL_REG1(layer),
> +SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
> +
> + return 0;
> +}
> +
> int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> int layer, struct drm_plane *plane)
> {
> @@ -330,6 +355,34 @@ static int sun4i_backend_of_get_id(struct device_node
> *node)
> return ret;
> }
>
> +static struct sun4i_frontend *sun4i_backend_find_frontend(struct sun4i_drv
> *drv,
> + struct device_node
> *node)
> +{
> + struct device_node *port, *ep, *remote;
> + struct sun4i_frontend *frontend;
> +
> + port = of_graph_get_port_by_id(node, 0);
> + if (!port)
> + return ERR_PTR(-EINVAL);
> +
> + for_each_available_child_of_node(port, ep) {
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote)
> + continue;
> +
> + /* does this node match any registered engines? */
> + list_for_each_entry(frontend, &drv->frontend_list, list) {
> + if (remote == frontend->node) {
> + of_node_put(remote);
> + of_node_put(port);
> + return frontend;
> + }
> + }
> + }
> +
> + return ERR_PTR(-EINVAL);
> +}
> +
> static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
> .commit = sun4i_backend_commit,
> .layers_init= sun4i_layers_init,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h
> b/drivers/gpu/drm/sun4i/sun4i_backend.h
> index ba1410fd5410..636a51521e77 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
> @@ -72,6 +72,7 @@
> #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x) ((x) << 15)
> #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASKGENMASK(11, 10)
> #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x) ((x) <<
> 10)
> +#define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN BIT(1)
>
> #define SUN4I_BACKEND_ATTCTL_REG1(l) (0x8a0 + (0x4 * (l)))
> #define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCTGENMASK(15, 14)
> @@ -171,5 +172,7 @@ int sun4i_backend_update_layer_formats(struct
> sun4i_backend *backend,
> int layer, struct drm_plane *plane);
> int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> int layer, struct drm_plane *plane);
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> + int layer, uint32_t in_fmt);
>
> #endif /* _SUN4I_BACKEND_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
> b/drivers/gpu/drm/sun4i/sun4i_layer.c
> index c3afcf888906..3b58667a06dc 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
>
