Re: backend-drm and scanning really large resolutions
On Tue, 21 Jan 2020 08:51:26 -0600 Matt Hoosier wrote: > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote: > > > On Fri, 17 Jan 2020 10:51:45 -0600 > > Matt Hoosier wrote: > > > > > Hi all, > > > > > > I'm confronting a situation where the hardware with which I work is > > capable > > > of driving connectors at 4K or 8K, but doing so requires bonding the > > > scanning of multiple planes together. > > > > > > The scenario is that you'd have a big primary framebuffer whose size is > > too > > > large for an individual hardware scanning pipeline on the display > > > controller to traverse within its maximum allowed clock rate. > > > > > > The hardware supplier's approach is to assign multiple planes, which in > > the > > > KMS driver map to hardware scanning pipelines, to each be responsible for > > > scanning a smaller section of the framebuffer. The planes are all > > assigned > > > to the same CRTC, and in concert with each other they cover the whole > > area > > > of the framebuffer and CRTC. > > > > > > This sounds a little bit wild to me. I hadn't been aware it's even legal > > to > > > have more than one plane treated a the source of scanout for a single > > > framebuffer. Maybe that distinction isn't really relevant nowadays with > > > universal plane support. > > > > > > I'm wondering if anybody here knows whether this a legit approach for a > > > compositor's DRM backend to take? > > > > Hi Pekka; thanks for the reply. > > > > > > Hi, > > > > I was aware of tiled monitors that need two connectors driven by two > > CRTCs to cover the whole display, but that sounds new to me. > > Libweston/DRM still doesn't support tiled monitors. > > > > What a compositor's DRM-backend can or should do must be generic. It > > cannot be driver or hardware dependent, so handling your case specially > > in userspace would need KMS UAPI to communicate the need in the first > > place. (There is no shared library for "KMS userspace drivers", yet at > > least.) > > > > I am not aware of any KMS UAPI that would indicate the need to use two > > primary planes in a specific configuration for a specific video mode. > > I'm saying two primary planes, because that is the only way I can see > > this situation even hinted at userspace with the current UAPI. I also > > don't know if multiple primary planes is allowed, but it certainly is > > not expected by userspace, so userspace can't make use of it as is. > > > > Just to double-check: I think we're still talking here about > universal-plane mode, so we only mean "primary plane" in an informal sense? Hi, I'm talking in both universal-planes and atomic modesetting mode. I always talk from the userspace point of view as I'm not a kernel developer. In my mind, the concept of "primary plane" does not exist before universal planes. There is only drmModeSetCrtc() in the pre-atomic world and that acts on a CRTC, not a plane, and assumes the FB must cover the whole CRTC area exactly and without scaling. IOW, there is no legacy UAPI that you could even use to poke more than one (primary) plane AFAIU. > This problem would crop up on any attempt to attach a huge framebuffer to a > single plane (whether it happened to be the bottom z-sorted one or a > something used as an overlay). Traditionally hardware has required that a CRTC must have exactly one primary plane enabled and that plane must cover the whole CRTC area exactly. Otherwise the CRTC will not light up. Therefore userspace has been written with this assumption, so it special-cases the primary plane. Some KMS programs might try other things first, but this is the baseline they expect to be the right thing to do when nothing else works. Non-primary planes, that is overlays and underlays (both as type "overlay" in universal planes), and cursors kind of, are traditionally much more flexible, but I don't know of any userspace that would attempt to use more than one plane to present one FB. If using a non-primary plane fails on the first try, userspace doesn't know why - there are a million things it could attempt to change, so it probably just doesn't bother. Documenting what fallback strategies to try would be nice on one hand, but OTOH the more strategies there are, the more time it will take for userspace to search that solution space. > > The idea that comes to my mind is to hide all the details in the > > driver. Expose just one primary plane as usual, and if the video mode > > and FB actually need two scanout units, then steal one under the hood > > in the driver. If that makes another KMS plane (exposed to userspace) > > unusable, that is fine. Userspace with atomic modesetting needs to be > > checking with TEST_ONLY to see if a configuration is possible, and will > > fall back to something else. > > > > I think that's about the only approach that would make sense. Who would be > a good person to sanity-check that with? Daniel V? Daniel S? Daniel Vetter is an authority to me
Re: backend-drm and scanning really large resolutions
On Fri, 24 Jan 2020 10:25:05 +0200 Pekka Paalanen wrote: > On Tue, 21 Jan 2020 08:51:26 -0600 > Matt Hoosier wrote: > > > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote: > > > > > On Fri, 17 Jan 2020 10:51:45 -0600 > > > Matt Hoosier wrote: > > > > > > > Hi all, > > > > > > > > I'm confronting a situation where the hardware with which I work is > > > capable > > > > of driving connectors at 4K or 8K, but doing so requires bonding the > > > > scanning of multiple planes together. > > > > > > > > The scenario is that you'd have a big primary framebuffer whose size is > > > > > > > too > > > > large for an individual hardware scanning pipeline on the display > > > > controller to traverse within its maximum allowed clock rate. > > > > > > > > The hardware supplier's approach is to assign multiple planes, which in > > > > > > > the > > > > KMS driver map to hardware scanning pipelines, to each be responsible > > > > for > > > > scanning a smaller section of the framebuffer. The planes are all > > > assigned > > > > to the same CRTC, and in concert with each other they cover the whole > > > > > > > area > > > > of the framebuffer and CRTC. > > > > > > > > This sounds a little bit wild to me. I hadn't been aware it's even > > > > legal > > > to > > > > have more than one plane treated a the source of scanout for a single > > > > framebuffer. Maybe that distinction isn't really relevant nowadays with > > > > universal plane support. > > > > > > > > I'm wondering if anybody here knows whether this a legit approach for a > > > > compositor's DRM backend to take? > > > > > > > Hi Pekka; thanks for the reply. > > > > > > > > > > Hi, > > > > > > I was aware of tiled monitors that need two connectors driven by two > > > CRTCs to cover the whole display, but that sounds new to me. > > > Libweston/DRM still doesn't support tiled monitors. > > > > > > What a compositor's DRM-backend can or should do must be generic. It > > > cannot be driver or hardware dependent, so handling your case specially > > > in userspace would need KMS UAPI to communicate the need in the first > > > place. (There is no shared library for "KMS userspace drivers", yet at > > > least.) > > > > > > I am not aware of any KMS UAPI that would indicate the need to use two > > > primary planes in a specific configuration for a specific video mode. > > > I'm saying two primary planes, because that is the only way I can see > > > this situation even hinted at userspace with the current UAPI. I also > > > don't know if multiple primary planes is allowed, but it certainly is > > > not expected by userspace, so userspace can't make use of it as is. > > > > > > > Just to double-check: I think we're still talking here about > > universal-plane mode, so we only mean "primary plane" in an informal sense? > > > > Hi, > > I'm talking in both universal-planes and atomic modesetting mode. I > always talk from the userspace point of view as I'm not a kernel > developer. In my mind, the concept of "primary plane" does not exist > before universal planes. There is only drmModeSetCrtc() in the > pre-atomic world and that acts on a CRTC, not a plane, and assumes > the FB must cover the whole CRTC area exactly and without scaling. > > IOW, there is no legacy UAPI that you could even use to poke more than > one (primary) plane AFAIU. ... > Besides, Weston is not at all the only display server you'd have to > patch. There is Xorg/modesetting, every single DE that runs with > Wayland, and all apps written for KMS directly. Even more, you also get > to fix all apps that use DRM leases, which likely includes things like > VR compositors. Btw. GNOME/Wayland (Mutter) is only getting into atomic modesetting soon(?), it has had a long road of re-architecting to get into a position where it can start implementing atomic KMS usage. And Xorg/modesetting is still legacy-only too, in spite of the poor attempt to make it atomic which had to be disabled on the kernel DRM side, and probably unlikely to ever be atomic really due to the amount of work needed to make it fit in IIUC. Thanks, pq pgpsHaWyKhqxJ.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()
From: Chris Wilson
> Sent: 15 January 2020 20:53
>
> Since we may try and flush the cachelines associated with large buffers
> (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> If we call cond_resched() between each sg chunk, that it about every 128
> pages, we have a natural break point in which to check if the process
> needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
> only be called from process context -- which is true at the moment. The
> other clflush routines remain usable from atomic context.
>
> Even though flushing large objects takes a demonstrable amount to time
> to flush all the cachelines, clflush is still preferred over a
> system-wide wbinvd as the latter has unpredictable latencies affecting
> the whole system not just the local task.
Any progress on this.
I think the patch itself has it's whitespace messed up.
I've just done a measurement on a newer system that supports clflushopt.
drm_clflush_sg() took 400us for a 1920x1080 display.
No idea how fast the cpus were running, somewhere between 800MHz and 4GHz
depending on the whim of the hardware (probable at the low end).
Considerably faster, and enough that calling cond_resched() every 4k
is probably noticable.
So every 128 pages is probably a reasonable compromise.
David
> Reported-by: David Laight
> Signed-off-by: Chris Wilson
> Cc: David Laight
> ---
> drivers/gpu/drm/drm_cache.c | 49 ++---
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 03e01b000f7a..fbd2bb644544 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,23 +112,64 @@ drm_clflush_pages(struct page *pages[], unsigned long
> num_pages)
> }
> EXPORT_SYMBOL(drm_clflush_pages);
>
> +static __always_inline struct sgt_iter {
> +struct scatterlist *sgp;
> +unsigned long pfn;
> +unsigned int curr;
> +unsigned int max;
> +} __sgt_iter(struct scatterlist *sgl) {
> +struct sgt_iter s = { .sgp = sgl };
> +
> +if (s.sgp) {
> +s.max = s.curr = s.sgp->offset;
> +s.max += s.sgp->length;
> +s.pfn = page_to_pfn(sg_page(s.sgp));
> +}
> +
> +return s;
> +}
> +
> +static inline struct scatterlist *__sg_next_resched(struct scatterlist *sg)
> +{
> +if (sg_is_last(sg))
> +return NULL;
> +
> +++sg;
> +if (unlikely(sg_is_chain(sg))) {
> +sg = sg_chain_ptr(sg);
> +cond_resched();
> +}
> +return sg;
> +}
> +
> +#define for_each_sgt_page(__pp, __iter, __sgt)\
> +for ((__iter) = __sgt_iter((__sgt)->sgl);\
> + ((__pp) = (__iter).pfn == 0 ? NULL :\
> + pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
> + (((__iter).curr += PAGE_SIZE) >= (__iter).max) ?\
> + (__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)
> +
> /**
> * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
> * @st: struct sg_table.
> *
> * Flush every data cache line entry that points to an address in the
> - * sg.
> + * sg. This may schedule between scatterlist chunks, in order to keep
> + * the system preemption-latency down for large buffers.
> */
> void
> drm_clflush_sg(struct sg_table *st)
> {
> +might_sleep();
> +
> #if defined(CONFIG_X86)
> if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
> -struct sg_page_iter sg_iter;
> +struct sgt_iter sg_iter;
> +struct page *page;
>
> mb(); /*CLFLUSH is ordered only by using memory barriers*/
> -for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
> -drm_clflush_page(sg_page_iter_page(&sg_iter));
> +for_each_sgt_page(page, sg_iter, st)
> +drm_clflush_page(page);
> mb(); /*Make sure that all cache line entry is flushed*/
>
> return;
> --
> 2.25.0
>
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl
Implements an ioctl to wait until a value at a given iova is greater
than or equal to a supplied value.
This will initially be used by turnip (open-source Vulkan driver for
QC in mesa) for occlusion queries where the userspace driver can
block on a query becoming available before continuing via
vkGetQueryPoolResults.
Change-Id: I1413fc34b7eb8ba569c765ad65126e9024341730
Signed-off-by: Brian Ho
---
drivers/gpu/drm/msm/msm_drv.c | 61 +--
include/uapi/drm/msm_drm.h| 14
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c84f0a8b3f2c..f746ac86bca3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -36,10 +36,11 @@
* MSM_GEM_INFO ioctl.
* - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
* GEM object's debug name
- * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
+ * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
+ * - 1.6.0 - Add WAIT_IOVA ioctl
*/
#define MSM_VERSION_MAJOR 1
-#define MSM_VERSION_MINOR 5
+#define MSM_VERSION_MINOR 6
#define MSM_VERSION_PATCHLEVEL 0
static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -952,6 +953,61 @@ static int msm_ioctl_submitqueue_close(struct drm_device
*dev, void *data,
return msm_submitqueue_remove(file->driver_priv, id);
}
+static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct drm_gem_object *obj;
+ struct drm_msm_wait_iova *args = data;
+ ktime_t timeout = to_ktime(args->timeout);
+ unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
+ struct msm_gpu *gpu = priv->gpu;
+ void *base_vaddr;
+ uint64_t *vaddr;
+ int ret;
+
+ if (args->pad)
+ return -EINVAL;
+
+ if (!gpu)
+ return -ENODEV;
+
+ obj = drm_gem_object_lookup(file, args->handle);
+ if (!obj)
+ return -ENOENT;
+
+ if (args->offset + sizeof(*vaddr) < args->offset ||
+ args->offset + sizeof(*vaddr) > obj->size) {
+ ret = -EINVAL;
+ goto err_put_gem_object;
+ }
+
+ base_vaddr = msm_gem_get_vaddr(obj);
+ if (IS_ERR(base_vaddr)) {
+ ret = PTR_ERR(base_vaddr);
+ goto err_put_gem_object;
+ }
+
+ vaddr = base_vaddr + args->offset;
+
+ /* TODO: Support 64 bit reference values with a flag. */
+ ret = wait_event_interruptible_timeout(gpu->event,
+ (int32_t)((uint32_t)(*vaddr & args->mask) -
+ (uint32_t)args->value) >= 0,
+ remaining_jiffies);
+
+ if (ret == 0)
+ ret = -ETIMEDOUT;
+ else if (ret > 0)
+ ret = 0;
+
+msm_gem_put_vaddr(obj);
+
+err_put_gem_object:
+ drm_gem_object_put_unlocked(obj);
+ return ret;
+}
+
static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new,
DRM_RENDER_ALLOW),
@@ -964,6 +1020,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MSM_WAIT_IOVA, msm_ioctl_wait_iova, DRM_RENDER_ALLOW),
};
static const struct vm_operations_struct vm_ops = {
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 0b85ed6a3710..d4eac312f56e 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -298,6 +298,18 @@ struct drm_msm_submitqueue_query {
__u32 pad;
};
+/* This ioctl blocks until the value at bo + offset is greater than or equal
+ * to the reference value.
+ */
+struct drm_msm_wait_iova {
+ __u32 handle; /* in, GEM handle */
+ __u32 pad;
+ struct drm_msm_timespec timeout; /* in */
+ __u64 offset; /* in, offset into bo */
+ __u64 mask;/* in, mask of the value at bo + offset */
+ __u64 value; /* in, reference value, 32 bits */
+};
+
#define DRM_MSM_GET_PARAM 0x00
/* placeholder:
#define DRM_MSM_SET_PARAM 0x01
@@ -315,6 +327,7 @@ struct drm_msm_submitqueue_query {
#define DRM_MSM_SUBMITQUEUE_NEW0x0A
#define DRM_MSM_SUBMITQUEUE_CLOSE 0x0B
#define DRM_MSM_SUBMITQUEUE_QUERY 0x0C
+#define DRM_MSM_WAIT_IOVA 0x0D
#define DRM_IOCTL_MSM_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE +
DRM_MSM_GET_PARAM, struct drm_msm_param)
#define DRM_IOCTL
[PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not
On 32 bits powerPC (book3s/32), only write accesses to user are
protected and there is no point spending time on unlocking for reads.
On 64 bits powerpc (book3s/64 at least), access can be granted
read only, write only or read/write.
Add an argument to user_access_begin() to tell when it's for write and
return an opaque key that will be used by user_access_end() to know
what was done by user_access_begin().
Signed-off-by: Christophe Leroy
---
v3: new
---
arch/x86/include/asm/uaccess.h | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++-
fs/readdir.c | 16 ++--
include/linux/uaccess.h| 4 ++--
kernel/compat.c| 16 ++--
kernel/exit.c | 17 +++--
lib/strncpy_from_user.c| 6 --
lib/strnlen_user.c | 6 --
lib/usercopy.c | 8 +---
9 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 61d93f062a36..05eccdc0366a 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -709,7 +709,8 @@ extern struct movsl_mask {
* checking before using them, but you have to surround them with the
* user_access_begin/end() pair.
*/
-static __must_check __always_inline bool user_access_begin(const void __user
*ptr, size_t len)
+static __must_check __always_inline unsigned long
+user_access_begin(const void __user *ptr, size_t len, bool write)
{
if (unlikely(!access_ok(ptr,len)))
return 0;
@@ -717,7 +718,7 @@ static __must_check __always_inline bool
user_access_begin(const void __user *pt
return 1;
}
#define user_access_begin(a,b) user_access_begin(a,b)
-#define user_access_end() __uaccess_end()
+#define user_access_end(x) __uaccess_end()
#define user_access_save() smap_save()
#define user_access_restore(x) smap_restore(x)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bc3a67226163..509bfb6116ac 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1615,6 +1615,7 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
const unsigned int count = eb->buffer_count;
unsigned int i;
int err;
+ unsigned long key;
for (i = 0; i < count; i++) {
const unsigned int nreloc = eb->exec[i].relocation_count;
@@ -1662,14 +1663,15 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
* happened we would make the mistake of assuming that the
* relocations were valid.
*/
- if (!user_access_begin(urelocs, size))
+ key = user_access_begin(urelocs, size, true);
+ if (!key)
goto end;
for (copied = 0; copied < nreloc; copied++)
unsafe_put_user(-1,
&urelocs[copied].presumed_offset,
end_user);
- user_access_end();
+ user_access_end(key);
eb->exec[i].relocs_ptr = (uintptr_t)relocs;
}
@@ -1677,7 +1679,7 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
return 0;
end_user:
- user_access_end();
+ user_access_end(key);
end:
kvfree(relocs);
err = -EFAULT;
@@ -2906,6 +2908,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_exec_object2 __user *user_exec_list =
u64_to_user_ptr(args->buffers_ptr);
unsigned int i;
+ unsigned long key;
/* Copy the new buffer offsets back to the user's exec list. */
/*
@@ -2915,7 +2918,9 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
* And this range already got effectively checked earlier
* when we did the "copy_from_user()" above.
*/
- if (!user_access_begin(user_exec_list, count *
sizeof(*user_exec_list)))
+ key = user_access_begin(user_exec_list,
+ count * sizeof(*user_exec_list), true);
+ if (!key)
goto end;
for (i = 0; i < args->buffer_count; i++) {
@@ -2929,7 +2934,7 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
end_user);
}
end_user:
- user_access_end();
+ user_access_end(key);
end:;
}
diff --git a/fs/readdir.c b/fs/readdir.c
index 4b466cbb0f3a..47b9ef97e16e 1006
Re: [PATCH v4 2/3] dt-bindings: panel-simple: add bindings for logic technologies displays
On Mon, Jan 20, 2020 at 10:02 AM Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > Add bindings for the following 3 to be added display panels manufactured > by Logic Technologies Limited: > > - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display > 7" Parallel [1] > - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7" > Parallel [2] > - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display > 10.1" LVDS [3] > > Those panels may also be distributed by Endrich Bauelemente Vertriebs > GmbH [4]. > > [1] > https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf > [2] > https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf > [3] > https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf > [4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30 > > Signed-off-by: Marcel Ziswiler Reviewed-by: Oleksandr Suvorov > > --- > > Changes in v4: > - Re-ordered commits as suggested by Sam and re-worded commit message. > > Changes in v3: > - Add it to recently introduced panel-simple.yaml instead as suggested > by Sam. > > Changes in v2: > - New patch adding display panel bindings as well as suggested by Rob. > > .../devicetree/bindings/display/panel/panel-simple.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 4a8064e31793..f33c5d979f96 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -41,6 +41,12 @@ properties: >- frida,frd350h54004 > # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel >- giantplus,gpm940b0 > +# Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module > + - logictechno,lt161010-2nhc > +# Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module > + - logictechno,lt161010-2nhr > +# Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch > Mod. > + - logictechno,lt170410-2whc > # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel >- satoz,sat050at40h12r2 > # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel > -- > 2.24.1 > -- Best regards Oleksandr Suvorov Toradex AG Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 4800 (main line) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not
Le 23/01/2020 à 19:02, Linus Torvalds a écrit : On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy wrote: On 32 bits powerPC (book3s/32), only write accesses to user are protected and there is no point spending time on unlocking for reads. Honestly, I'm starting to think that 32-bit ppc just needs to look more like everybody else, than make these changes. Well, beside ppc32, I was also seen it as an opportunity for the modern ppc64. On it, you can unlock either read or write or both. And this is what is done for get_user() / put_user() and friends: unlock only reads for get_user() and only writes for put_user(). Could also be a compromise between performance and security: keeping reads allowed at all time and only protect against writes on modern architectures which support it like ppc64. We used to have a read/write argument to the old "verify_area()" and "access_ok()" model, and it was a mistake. It was due to odd i386 user access issues. We got rid of it. I'm not convinced this is any better - it looks very similar and for odd ppc access issues. I'm going to leave it aside, at least for the time being, and do it as a second step later after evaluating the real performance impact. I'll respin tomorrow in that way. But if we really do want to do this, then: Indeed I took the idea from a discussion in last Octobre (Subject: "book3s/32 KUAP (was Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user())" ) https://lore.kernel.org/lkml/87h84avffi@mpe.ellerman.id.au/ Add an argument to user_access_begin() to tell when it's for write and return an opaque key that will be used by user_access_end() to know what was done by user_access_begin(). You should make it more opaque than "unsigned long". Also, it shouldn't be a "is this a write". What if it's a read _and_ a write? Only a write? Only a read? Indeed that was more: does it includes a write. It's either RO or RW Christophe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2] arm64: dts: sc7180: add display dt nodes
Add display, DSI hardware DT nodes for sc7180.
Changes in v1:
-Added display DT nodes for sc7180
Changes in v2:
-Renamed node names
-Corrected code alignments
-Removed extra new line
Signed-off-by: Harigovindan P
---
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 57 +++
arch/arm64/boot/dts/qcom/sc7180.dtsi| 125
2 files changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 388f50a..f410614 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -232,6 +232,50 @@
};
};
+&dsi_controller {
+ status = "okay";
+
+ vdda-supply = <&vreg_l3c_1p2>;
+
+ panel@0 {
+ compatible = "visionox,rm69299-1080p-display";
+ reg = <0>;
+
+ vdda-supply = <&vreg_l8c_1p8>;
+ vdd3p3-supply = <&vreg_l18a_2p8>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&disp_pins_default>;
+ pinctrl-1 = <&disp_pins_default>;
+
+ reset-gpios = <&pm6150l_gpio 3 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi_phy {
+ status = "okay";
+};
+
&qspi {
status = "okay";
pinctrl-names = "default";
@@ -289,6 +333,19 @@
/* PINCTRL - additions to nodes defined in sc7180.dtsi */
+&pm6150l_gpio {
+ disp_pins {
+ disp_pins_default: disp_pins_default {
+ pins = "gpio3";
+ function = "func1";
+ qcom,drive-strength = <2>;
+ power-source = <0>;
+ bias-disable;
+ output-low;
+ };
+ };
+};
+
&qspi_clk {
pinconf {
pins = "gpio63";
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 3bc3f64..81c3aab 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1184,6 +1184,131 @@
#power-domain-cells = <1>;
};
+ display_subsystem: mdss@ae0 {
+ compatible = "qcom,sc7180-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_HF_AXI_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "gcc_bus", "ahb", "core";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ display_controller: mdp@ae0 {
+ compatible = "qcom,sc7180-dpu";
+ reg = <0 0x0ae0 0 0x1000>,
+ <0 0x0ae01000 0 0x8f000>,
+ <0 0x0aeb 0 0x2008>,
+ <0 0x0af03000 0 0x16>;
+ reg-names = "mdss", "mdp", "vbif", "disp_cc";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_ROT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>,
+<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "rot", "lut", "core",
+ "vsync";
+ assigned-clocks = <&dispcc
DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc
DISP_CC_MDSS_VSYNC_CLK>;
+
[v2] arm64: dts: sc7180: add display dt nodes
Add display, DSI hardware DT nodes for sc7180.
Changes in v1:
-Added display DT nodes for sc7180
Changes in v2:
-Renamed node names
-Corrected code alignments
-Removed extra new line
-Added DISP AHB clock for register access
under display_subsystem node for global settings
Signed-off-by: Harigovindan P
---
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 57 +++
arch/arm64/boot/dts/qcom/sc7180.dtsi| 125
2 files changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 388f50a..f410614 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -232,6 +232,50 @@
};
};
+&dsi_controller {
+ status = "okay";
+
+ vdda-supply = <&vreg_l3c_1p2>;
+
+ panel@0 {
+ compatible = "visionox,rm69299-1080p-display";
+ reg = <0>;
+
+ vdda-supply = <&vreg_l8c_1p8>;
+ vdd3p3-supply = <&vreg_l18a_2p8>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&disp_pins_default>;
+ pinctrl-1 = <&disp_pins_default>;
+
+ reset-gpios = <&pm6150l_gpio 3 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi_phy {
+ status = "okay";
+};
+
&qspi {
status = "okay";
pinctrl-names = "default";
@@ -289,6 +333,19 @@
/* PINCTRL - additions to nodes defined in sc7180.dtsi */
+&pm6150l_gpio {
+ disp_pins {
+ disp_pins_default: disp_pins_default{
+ pins = "gpio3";
+ function = "func1";
+ qcom,drive-strength = <2>;
+ power-source = <0>;
+ bias-disable;
+ output-low;
+ };
+ };
+};
+
&qspi_clk {
pinconf {
pins = "gpio63";
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 3bc3f64..81c3aab 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1184,6 +1184,131 @@
#power-domain-cells = <1>;
};
+ display_subsystem: mdss@ae0 {
+ compatible = "qcom,sc7180-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_HF_AXI_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "gcc_bus", "ahb", "core";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ display_controller: mdp@ae0 {
+ compatible = "qcom,sc7180-dpu";
+ reg = <0 0x0ae0 0 0x1000>,
+ <0 0x0ae01000 0 0x8f000>,
+ <0 0x0aeb 0 0x2008>,
+ <0 0x0af03000 0 0x16>;
+ reg-names = "mdss", "mdp", "vbif", "disp_cc";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_ROT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>,
+<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "rot", "lut", "core",
+ "vsync";
+ assigned-clocks = <&dispcc
DISP_CC_MDSS_MDP_CLK>,
+
Re: linux-next: Tree for Jan 23 (gpu/drm/panel/)
On 1/23/20 11:49 AM, Sam Ravnborg wrote: > Hi Randy. > > Thanks - I think (kidding, this has bugged of for a long time). > > On Thu, Jan 23, 2020 at 12:44:25AM -0800, Randy Dunlap wrote: >> On 1/22/20 10:21 PM, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20200122: >>> >> >> >> on i386: >> >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-rocktech-jh057n00900.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-raydium-rm68200.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-innolux-p079zca.ko] undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-ilitek-ili9881c.ko] undefined! >> ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-lvds.ko] >> undefined! >> ERROR: "drm_panel_of_backlight" >> [drivers/gpu/drm/panel/panel-boe-himax8279d.ko] >> >> >> Full randconfig file is attached. > > I tried reproducing with latest drm-misc-next - no luck. > > Can you check if you have: > > 8d6cb2f7fb90018d9e3efdc9bc95e6da213a352f > drm/drm_panel: fix export of drm_panel_of_backlight, try #3 > > > As we expect this to fix it for good. > Maybe the patch has not hit the right tree > and is thus not in -next. Hi Sam, Sorry, I don't have the linux-next git tree so I can't check that commit. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm/panel: simple: add display timings for logic technologies displays
On Mon, Jan 20, 2020 at 10:02 AM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Add display timings for the following 3 display panels manufactured by
> Logic Technologies Limited:
>
> - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
> 7" Parallel [1]
> - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7"
> Parallel [2]
> - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display
> 10.1" LVDS [3]
>
> Those panels may also be distributed by Endrich Bauelemente Vertriebs
> GmbH [4].
>
> [1]
> https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf
> [2]
> https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf
> [3]
> https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf
> [4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
>
> Signed-off-by: Marcel Ziswiler
> Reviewed-by: Philippe Schenker
Reviewed-by: Oleksandr Suvorov
>
> ---
>
> Changes in v4:
> - Added recently made mandatory connector_type information as pointed
> out by Sam.
>
> Changes in v3:
> - Fix typo in pixelclock frequency for lt170410_2whc as recently
> discovered by Philippe.
>
> Changes in v2:
> - Added Philippe's reviewed-by.
>
> drivers/gpu/drm/panel/panel-simple.c | 67
> 1 file changed, 67 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index d6f77bc494c7..a0dd84e11db7 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2107,6 +2107,64 @@ static const struct panel_desc lg_lp129qe = {
> },
> };
>
> +static const struct display_timing logictechno_lt161010_2nh_timing = {
> + .pixelclock = { 2640, 3330, 4680 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 16, 210, 354 },
> + .hback_porch = { 46, 46, 46 },
> + .hsync_len = { 1, 20, 40 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 7, 22, 147 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 1, 10, 20 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> +DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
> +DISPLAY_FLAGS_SYNC_POSEDGE,
> +};
> +
> +static const struct panel_desc logictechno_lt161010_2nh = {
> + .timings = &logictechno_lt161010_2nh_timing,
> + .num_timings = 1,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> +DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> +DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
> + .connector_type = DRM_MODE_CONNECTOR_DPI,
> +};
> +
> +static const struct display_timing logictechno_lt170410_2whc_timing = {
> + .pixelclock = { 6890, 7110, 7340 },
> + .hactive = { 1280, 1280, 1280 },
> + .hfront_porch = { 23, 60, 71 },
> + .hback_porch = { 23, 60, 71 },
> + .hsync_len = { 15, 40, 47 },
> + .vactive = { 800, 800, 800 },
> + .vfront_porch = { 5, 7, 10 },
> + .vback_porch = { 5, 7, 10 },
> + .vsync_len = { 6, 9, 12 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> +DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
> +DISPLAY_FLAGS_SYNC_POSEDGE,
> +};
> +
> +static const struct panel_desc logictechno_lt170410_2whc = {
> + .timings = &logictechno_lt170410_2whc_timing,
> + .num_timings = 1,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> +DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> +DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
> +
> static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
> .clock = 30400,
> .hdisplay = 800,
> @@ -3417,6 +3475,15 @@ static const struct of_device_id platform_of_match[] =
> {
> }, {
> .compatible = "logicpd,type28",
> .data = &logicpd_type_28,
> + }, {
> + .compatible = "logictechno,lt161010-2nhc",
> + .data = &logictechno_lt161010_2nh,
> + }, {
> + .compatible = "logictechno,lt161010-2nhr",
> + .data = &logictechno_lt161010_2nh,
> + }, {
> + .compatible = "logictechno,lt170410-2whc",
> + .data = &logictechno_lt170410_2whc,
> }, {
> .compatible = "mitsubishi,aa070mc01-ca1",
> .data = &mitsubishi_aa070mc01,
> --
> 2.24.1
>
--
Best regards
Oleksandr Suvorov
Tor
[PATCH v3 1/2] drm/msm: Add a GPU-wide wait queue
This wait queue is signaled on all IRQs for a given GPU and will be
used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep
until the value at a given iova reaches a certain condition.
Signed-off-by: Brian Ho
---
drivers/gpu/drm/msm/msm_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a052364a5d74..d7310c1336e5 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -779,6 +779,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit,
static irqreturn_t irq_handler(int irq, void *data)
{
struct msm_gpu *gpu = data;
+ wake_up_all(&gpu->event);
+
return gpu->funcs->irq(gpu);
}
@@ -871,6 +873,8 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
spin_lock_init(&gpu->perf_lock);
+ init_waitqueue_head(&gpu->event);
+
/* Map registers: */
gpu->mmio = msm_ioremap(pdev, config->ioname, name);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index ab8f0f9c9dc8..60562f065dbc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -104,6 +104,9 @@ struct msm_gpu {
struct msm_gem_address_space *aspace;
+ /* GPU-wide wait queue that is signaled on all IRQs */
+ wait_queue_head_t event;
+
/* Power Control: */
struct regulator *gpu_reg, *gpu_cx;
struct clk_bulk_data *grp_clks;
--
2.25.0.341.g760bfbb309-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] arm64: dts: sc7180: add display dt nodes
On Thu 23 Jan 04:15 PST 2020, Harigovindan P wrote:
> Add display, DSI hardware DT nodes for sc7180.
>
> Changes in v1:
> -Added display DT nodes for sc7180
> Changes in v2:
> -Renamed node names
> -Corrected code alignments
> -Removed extra new line
Please keep the changelist after the '---' for the dts patches.
>
> Signed-off-by: Harigovindan P
> ---
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 57 +++
> arch/arm64/boot/dts/qcom/sc7180.dtsi| 125
>
> 2 files changed, 182 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50a..f410614 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -232,6 +232,50 @@
> };
> };
>
> +&dsi_controller {
> + status = "okay";
> +
> + vdda-supply = <&vreg_l3c_1p2>;
> +
> + panel@0 {
> + compatible = "visionox,rm69299-1080p-display";
> + reg = <0>;
> +
> + vdda-supply = <&vreg_l8c_1p8>;
> + vdd3p3-supply = <&vreg_l18a_2p8>;
> +
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <&disp_pins_default>;
> + pinctrl-1 = <&disp_pins_default>;
> +
> + reset-gpios = <&pm6150l_gpio 3 0>;
Please replace the 0 here with GPIO_ACTIVE_HIGH
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + };
> + };
[..]
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 3bc3f64..81c3aab 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1184,6 +1184,131 @@
> #power-domain-cells = <1>;
> };
>
> + display_subsystem: mdss@ae0 {
It was the name, not the label, that Stephen asked you to make generic.
> + compatible = "qcom,sc7180-mdss";
> + reg = <0 0x0ae0 0 0x1000>;
> + reg-names = "mdss";
> +
[..]
> + display_controller: mdp@ae0 {
mdp: display-controller@ae0 {
[..]
> + };
> +
> + dsi_controller: qcom,mdss_dsi_ctrl0@ae94000 {
In particular you shouldn't have qcom, in the node name.
[..]
> +
> + dsi_phy: dsi-phy0@ae94400 {
phy@ae94400
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/msm: Add the MSM_WAIT_IOVA ioctl
This patch set implements the MSM_WAIT_IOVA ioctl which lets userspace sleep until the value at a given iova reaches a certain condition. This is needed in turnip to implement the VK_QUERY_RESULT_WAIT_BIT flag for vkGetQueryPoolResults. First, we add a GPU-wide wait queue that is signaled on all IRQs. We can then wait on this wait queue inside MSM_WAIT_IOVA until the condition is met. The corresponding merge request in mesa can be found at: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3279 Changes in v2: * Updated cleanup logic on error * Added a mask * 32 bit values by default Changes in v3: * Fixed a bug where the mask was being applied incorrectly Brian Ho (2): drm/msm: Add a GPU-wide wait queue drm/msm: Add MSM_WAIT_IOVA ioctl drivers/gpu/drm/msm/msm_drv.c | 61 +-- drivers/gpu/drm/msm/msm_gpu.c | 4 +++ drivers/gpu/drm/msm/msm_gpu.h | 3 ++ include/uapi/drm/msm_drm.h| 14 4 files changed, 80 insertions(+), 2 deletions(-) -- 2.25.0.341.g760bfbb309-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] msm:disp:dpu1: add UBWC support for display on SC7180
Add UBWC global configuration for display on
SC7180 target.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 29705e7..80d3cfc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -12,6 +12,7 @@
#define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
+#define HW_REV 0x0
#define HW_INTR_STATUS 0x0010
/* Max BW defined in KBps */
@@ -22,6 +23,17 @@ struct dpu_irq_controller {
struct irq_domain *domain;
};
+struct dpu_hw_cfg {
+ u32 val;
+ u32 offset;
+};
+
+struct dpu_mdss_hw_init_handler {
+ u32 hw_rev;
+ u32 hw_reg_count;
+ struct dpu_hw_cfg* hw_cfg;
+};
+
struct dpu_mdss {
struct msm_mdss base;
void __iomem *mmio;
@@ -32,6 +44,44 @@ struct dpu_mdss {
u32 num_paths;
};
+static struct dpu_hw_cfg hw_cfg[] = {
+{
+ /* UBWC global settings */
+ .val = 0x1E,
+ .offset = 0x144,
+}
+};
+
+static struct dpu_mdss_hw_init_handler cfg_handler[] = {
+{ .hw_rev = DPU_HW_VER_620,
+ .hw_reg_count = ARRAY_SIZE(hw_cfg),
+ .hw_cfg = hw_cfg
+},
+};
+
+static void dpu_mdss_hw_init(struct dpu_mdss *dpu_mdss, u32 hw_rev)
+{
+ int i;
+ u32 count = 0;
+ struct dpu_hw_cfg *hw_cfg = NULL;
+
+ for (i = 0; i < ARRAY_SIZE(cfg_handler); i++) {
+ if (cfg_handler[i].hw_rev == hw_rev) {
+ hw_cfg = cfg_handler[i].hw_cfg;
+ count = cfg_handler[i].hw_reg_count;
+ break;
+ }
+ }
+
+ for (i = 0; i < count; i++ ) {
+ writel_relaxed(hw_cfg->val,
+ dpu_mdss->mmio + hw_cfg->offset);
+ hw_cfg++;
+ }
+
+return;
+}
+
static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
struct dpu_mdss *dpu_mdss)
{
@@ -174,12 +224,18 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = &dpu_mdss->mp;
int ret;
+ u32 mdss_rev;
dpu_mdss_icc_request_bw(mdss);
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
- if (ret)
+ if (ret) {
DPU_ERROR("clock enable failed, ret:%d\n", ret);
+ return ret;
+ }
+
+ mdss_rev = readl_relaxed(dpu_mdss->mmio + HW_REV);
+ dpu_mdss_hw_init(dpu_mdss, mdss_rev);
return ret;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 00/12] drm/i915/svm: Add SVM support
On Fri, Dec 13, 2019 at 01:56:02PM -0800, Niranjana Vishwanathapura wrote: Shared Virtual Memory (SVM) allows the programmer to use a single virtual address space which will be shared between threads executing on CPUs and GPUs. It abstracts away from the user the location of the backing memory, and hence simplifies the user programming model. SVM supports two types of virtual memory allocation methods. Runtime allocator requires the driver to provide memory allocation and management interface, like buffer object (BO) interface. Whereas system allocator makes use of default OS memory allocation and management support like malloc(). This patch series adds both SVM system and runtime allocator support to i915 driver. I will split runtime allocator and system allocator support into separate RFC series. I will prioritize runtime allocator support to address the feedback in patch [02] of this series. Thanks, Niranjana The patch series includes - SVM support for both system and runtime allocation. - Plugin in device memory with the Linux kernel. - User API advertising SVM capability and configuration by user on per vm basis. - User API to bind an address range or a BO with a device page table. - User API to prefetch an address range to device memory. - Implicit migration by moving pages or BOs back from device to host memory upon CPU access. - CPU copy and blitter copy support for migrating the pages/BOs. - Large page mapping support - Page table dump support. References: https://www.kernel.org/doc/Documentation/vm/hmm.rst The HMM use cases in the Linux kernel. Test RFC series "[RFC i-g-t 0/7] tests/i915/svm: Shared Virtual Memory (SVM) test" v2: - Use updated HMM API - HMM usage changes as per review feedback - UAPI name change as per review feedback - Reformat RFC series - Some minor fixes Niranjana Vishwanathapura (11): drm/i915/svm: Add SVM documentation drm/i915/svm: Runtime (RT) allocator support drm/i915/svm: Page table update support for SVM drm/i915/svm: Page table mirroring support drm/i915/svm: Device memory support drm/i915/svm: Implicitly migrate pages upon CPU fault drm/i915/svm: Page copy support during migration drm/i915/svm: Add functions to blitter copy SVM buffers drm/i915/svm: Use blitter copy for migration drm/i915/svm: Add support to en/disable SVM drm/i915/svm: Add page table dump support Venkata Sandeep Dhanalakota (1): drm/i915/svm: Implicitly migrate BOs upon CPU access Documentation/gpu/i915.rst| 29 + drivers/gpu/drm/i915/Kconfig | 23 + drivers/gpu/drm/i915/Kconfig.debug| 14 + drivers/gpu/drm/i915/Makefile | 6 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 95 ++- drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 65 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 43 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 + drivers/gpu/drm/i915/gem/i915_gem_svm.c | 60 ++ drivers/gpu/drm/i915/gem/i915_gem_svm.h | 22 + drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +- drivers/gpu/drm/i915/i915_buddy.h | 12 + drivers/gpu/drm/i915/i915_drv.c | 31 +- drivers/gpu/drm/i915/i915_drv.h | 32 + drivers/gpu/drm/i915/i915_gem_gtt.c | 158 +++- drivers/gpu/drm/i915/i915_gem_gtt.h | 41 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_svm.c | 330 drivers/gpu/drm/i915/i915_svm.h | 71 ++ drivers/gpu/drm/i915/i915_svm_copy.c | 172 drivers/gpu/drm/i915/i915_svm_devmem.c| 781 ++ drivers/gpu/drm/i915/intel_memory_region.c| 4 - drivers/gpu/drm/i915/intel_memory_region.h| 18 + drivers/gpu/drm/i915/intel_region_lmem.c | 10 + include/uapi/drm/i915_drm.h | 73 ++ 28 files changed, 2078 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.h create mode 100644 drivers/gpu/drm/i915/i915_svm.c create mode 100644 drivers/gpu/drm/i915/i915_svm.h create mode 100644 drivers/gpu/drm/i915/i915_svm_copy.c create mode 100644 drivers/gpu/drm/i915/i915_svm_devmem.c -- 2.21.0.rc0.32.g243a4c7e27 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: only reject timeouts with tv_nsec >= 2 seconds
Hi Russel,
On Wed, Jan 22, 2020 at 10:35:53AM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 22, 2020 at 11:30:34AM +0100, Guido Günther wrote:
> > Hi,
> > On Tue, Jan 21, 2020 at 08:05:27PM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 21, 2020 at 5:10 PM Lucas Stach
> > > wrote:
> > > >
> > > > Hi Guido,
> > > >
> > > > On Di, 2020-01-21 at 13:55 +0100, Guido Günther wrote:
> > > > > Hi,
> > > > > On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
> > > > > > As Guido Günther reported, get_abs_timeout() in the etnaviv user
> > > > > > space
> > > > > > sometimes passes timeouts with nanosecond values larger than
> > > > > > 10,
> > > > > > which gets rejected after my first patch.
> > > > > >
> > > > > > To avoid breaking this, while also not allowing completely arbitrary
> > > > > > values, set the limit to 19 and use
> > > > > > set_normalized_timespec64()
> > > > > > to get the correct format before comparing it.
> > > > >
> > > > > I'm seeing values up to 5 seconds so I need
> > > > >
> > > > > if (args->timeout.tv_nsec > (5 * NSEC_PER_SEC))
> > > > >
> > > > > to unbreak rendering. Which seems to match what mesa's
> > > > > get_abs_timeout()
> > > > > does and how it's invoked.
> > > >
> > > > I have not tested this myself yet, only looked at the code. From the
> > > > code I quoted earlier, I don't see how we end up with 5 * NSEC_PER_SEC
> > > > in the tv_nsec member, even if the timeout passed to get_abs_timeout()
> > > > is 5 seconds.
> > >
> > > I can think of two different ways you'd end up with around five seconds
> > > here:
> > >
> > > a) you have a completely arbitrary 32-bit number through truncation,
> > > which is up to 4.2 seconds
> > > b) you have the same kind of 32-bit number, but add up to another
> > > 9
> > > nanoseconds, so you get up to 5.2 seconds in the 64-bit field.
> >
> > I've dumped out some values tv_nsec values with current mesa git on arm64:
> >
> > [ 33.699652] etnaviv_ioctl_gem_cpu_prep: 4990449401
> > [ 33.813081] etnaviv_ioctl_gem_cpu_prep: 5103872445
> > [ 33.822936] etnaviv_ioctl_gem_cpu_prep: 5113731286
> > [ 33.840963] etnaviv_ioctl_gem_cpu_prep: 5131762726
> > [ 33.854120] etnaviv_ioctl_gem_cpu_prep: 5144920127
> > [ 33.861426] etnaviv_ioctl_gem_cpu_prep: 5152227527
> > [ 33.872666] etnaviv_ioctl_gem_cpu_prep: 5163466968
> > [ 33.879485] etnaviv_ioctl_gem_cpu_prep: 5170286808
> >
> > The problem is that in mesa/libdrm
> >
> > static inline void get_abs_timeout(struct drm_etnaviv_timespec *tv,
> > uint64_t ns)
> > {
> > struct timespec t;
> > uint32_t s = ns / 10;
> > clock_gettime(CLOCK_MONOTONIC, &t);
> > tv->tv_sec = t.tv_sec + s;
> > tv->tv_nsec = t.tv_nsec + ns - (s * 10);
> > ^^^
> >this overflows (since `s` is `uint_32t` and hence we substract a way
> >too small value with ns = 50 which mesa uses in
> >etna_bo_cpu_prep.
> > }
> >
> > So with current mesa/libdrm (which needs to be fixed) we'd have a maximum
> >
> > t.tv_nsec + ns - (s_max * 10)
> >
> > 9 + 50 - 705032704= 5294967295
> >
> > Does that make sense? If so that'd be the possible upper bound for the
> > kernel. Note that this only applies to etnaviv_ioctl_gem_cpu_prep. While
> > etnaviv_ioctl_wait_fence and etnaviv_ioctl_gem_wait are affected too
> > i've not yet seen user space passing in larger values.
>
> Except the fact that the calculation being done above is buggy.
> Not only do we end up with tv_sec incremented by 5 seconds, but
> we also end up with tv_nsec containing around 5 seconds in
> nanoseconds, which means we end up with about a 10 second timeout.
yes.
>
> I think it would probably be better for the kernel to print a
> warning once when noticing over-large nsec values, suggesting a
> userspace upgrade is in order, but continue the existing behaviour.
That makes sense to me. This also makes sure we don't break other (non
mesa using) stuff accidentally. We have
https://gitlab.freedesktop.org/mesa/mesa/commit/d817f2c69615cf37b78f484a25b7831ebe9dbe6f
and
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3534
to normalize nsec to [0..9] now.
Cheers,
-- Guido
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] Huge page-table entries for TTM
In order to reduce TLB misses and CPU usage this patchset enables huge-
and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries
on huge_fault fallbacks. Typically on COW or on buffer-objects that want
write-notify. COW and write-notification is always done on the lowest
page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate
the caching- and encryption flags of huge page-table entries without ugly
hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured
to support transhuge pages, either by default or using madvise().
However, they are unlikely to be inserted unless the kernel buffer object
pfns and user-space addresses align perfectly. There are various options
here, but since buffer objects that reside in system pages typically start
at huge page boundaries if they are backed by huge pages, we try to enforce
buffer object starting pfns and user-space addresses to be huge page-size
aligned if their size exceeds a huge page-size. If pud-size transhuge
("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx.
The vmwgfx driver may perform dirty-tracking and needs some special code
to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according
to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for
graphics IO memory. This may later be reused by other graphics drivers
if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
A similar change is needed for graphics drivers that want a reasonable
likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned,
its size will NOT be inflated by this patchset. This means that the buffer
object tail will use smaller size page-table entries and thus no memory
overhead occurs. Drivers that want to pay the memory overhead price need to
implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to
work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing
using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
memory resources.
Comments and suggestions welcome.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase
adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support
transhuge pages.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] mm: Split huge pages on write-notify or COW
From: Thomas Hellstrom
We currently only do COW and write-notify on the PTE level, so if the
huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
split the huge pages and page-table entries. Also do this for huge PUDs
if there is no huge_fault() handler and the vma is not anonymous, similar
to how it's done for PMDs.
Note that fs/dax.c does the splitting in the huge_fault() handler, but as
huge_fault() is implemented by modules we need to consider whether to
export the splitting functions for use in the modules or whether to try
to keep calls in the core. Opt for the latter. A follow-up patch can
remove the dax.c split_huge_pmd() if needed.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
---
mm/memory.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 17aadc751e5c..4c49fe963e5c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3880,11 +3880,14 @@ static inline vm_fault_t wp_huge_pmd(struct vm_fault
*vmf, pmd_t orig_pmd)
{
if (vma_is_anonymous(vmf->vma))
return do_huge_pmd_wp_page(vmf, orig_pmd);
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
- /* COW handled on pte level: split pmd */
- VM_BUG_ON_VMA(vmf->vma->vm_flags & VM_SHARED, vmf->vma);
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+
+ /* COW or write-notify handled on pte level: split pmd. */
__split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
return VM_FAULT_FALLBACK;
@@ -3897,12 +3900,20 @@ static inline bool vma_is_accessible(struct
vm_area_struct *vma)
static vm_fault_t create_huge_pud(struct vm_fault *vmf)
{
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE) &&\
+ defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
/* No support for anonymous transparent PUD pages yet */
if (vma_is_anonymous(vmf->vma))
- return VM_FAULT_FALLBACK;
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+ goto split;
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+split:
+ /* COW or write-notify not handled on PUD level: split pud.*/
+ __split_huge_pud(vmf->vma, vmf->pud, vmf->address);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
return VM_FAULT_FALLBACK;
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries
From: Thomas Hellstrom
For graphics drivers needing to modify the page-protection, add
huge page-table entries counterparts to vmf_insert_prn_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
---
include/linux/huge_mm.h | 41 +++--
mm/huge_memory.c| 38 --
2 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 0b84e13e88e2..a95d1bc8ffe8 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -47,8 +47,45 @@ extern bool move_huge_pmd(struct vm_area_struct *vma,
unsigned long old_addr,
extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long addr, pgprot_t newprot,
int prot_numa);
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pmd - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pmd_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pud - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pud_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+
enum transparent_hugepage_flag {
TRANSPARENT_HUGEPAGE_FLAG,
TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f8d24fc3f4df..b2ec62cca3ae 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -811,11 +811,24 @@ static void insert_pfn_pmd(struct vm_area_struct *vma,
unsigned long addr,
pte_free(mm, pgtable);
}
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pmd_prot - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PMD_MASK;
struct vm_area_struct *vma = vmf->vma;
- pgprot_t pgprot = vma->vm_page_prot;
pgtable_t pgtable = NULL;
/*
@@ -843,7 +856,7 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t
pfn, bool write)
insert_pfn_pmd(vma, addr, vmf->pmd, pfn, pgprot, write, pgtable);
return VM_FAULT_NOPAGE;
}
-EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd);
+EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd_prot);
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma)
@@ -889,11 +902,24 @@ static void insert_pfn_pud(struct vm_area_struct *vma,
unsigned long addr,
spin_unlock(ptl);
}
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pud_prot - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PUD_MASK;
struct vm_area_struct *vma = vmf->vma;
- pgprot_t pgprot = vma->vm_page_prot;
[PATCH 5/9] mm, drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be
compiled with trans-huge-pages always enabled, or the kernel needs to be
compiled with trans-huge-pages enabled using madvise, and the user-space
app needs to call madvise() to enable trans-huge pages on a per-mapping
basis.
Furthermore huge page-faults will not succeed unless buffer objects and
user-space addresses are aligned on huge page size boundaries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 145 -
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 3 +-
3 files changed, 145 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b8c4dd..49704261a00d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -156,6 +156,89 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/**
+ * ttm_bo_vm_insert_huge - Insert a pfn for PUD or PMD faults
+ * @vmf: Fault data
+ * @bo: The buffer object
+ * @page_offset: Page offset from bo start
+ * @fault_page_size: The size of the fault in pages.
+ * @pgprot: The page protections.
+ * Does additional checking whether it's possible to insert a PUD or PMD
+ * pfn and performs the insertion.
+ *
+ * Return: VM_FAULT_NOPAGE on successful insertion, VM_FAULT_FALLBACK if
+ * a huge fault was not possible, and a VM_FAULT_ERROR code otherwise.
+ */
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ pgoff_t i;
+ vm_fault_t ret;
+ unsigned long pfn;
+ pfn_t pfnt;
+ struct ttm_tt *ttm = bo->ttm;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+
+ /* Fault should not cross bo boundary. */
+ page_offset &= ~(fault_page_size - 1);
+ if (page_offset + fault_page_size > bo->num_pages)
+ goto out_fallback;
+
+ if (bo->mem.bus.is_iomem)
+ pfn = ttm_bo_io_mem_pfn(bo, page_offset);
+ else
+ pfn = page_to_pfn(ttm->pages[page_offset]);
+
+ /* pfn must be fault_page_size aligned. */
+ if ((pfn & (fault_page_size - 1)) != 0)
+ goto out_fallback;
+
+ /* Check that memory is contiguous. */
+ if (!bo->mem.bus.is_iomem)
+ for (i = 1; i < fault_page_size; ++i) {
+ if (page_to_pfn(ttm->pages[page_offset + i]) != pfn + i)
+ goto out_fallback;
+ }
+ /* IO mem without the io_mem_pfn callback is always contiguous. */
+ else if (bo->bdev->driver->io_mem_pfn)
+ for (i = 1; i < fault_page_size; ++i) {
+ if (ttm_bo_io_mem_pfn(bo, page_offset + i) != pfn + i)
+ goto out_fallback;
+ }
+
+ pfnt = __pfn_to_pfn_t(pfn, PFN_DEV);
+ if (fault_page_size == (HPAGE_PMD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write);
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ else if (fault_page_size == (HPAGE_PUD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pud_prot(vmf, pfnt, pgprot, write);
+#endif
+ else
+ WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);
+
+ if (ret != VM_FAULT_NOPAGE)
+ goto out_fallback;
+
+ return VM_FAULT_NOPAGE;
+out_fallback:
+ count_vm_event(THP_FAULT_FALLBACK);
+ return VM_FAULT_FALLBACK;
+}
+#else
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ return VM_FAULT_NOPAGE;
+}
+#endif
+
/**
* ttm_bo_vm_fault_reserved - TTM fault helper
* @vmf: The struct vm_fault given as argument to the fault callback
@@ -163,6 +246,7 @@ EXPORT_SYMBOL(ttm_bo_vm_reserve);
* @num_prefault: Maximum number of prefault pages. The caller may want to
* specify this based on madvice settings and the size of the GPU object
* backed by the memory.
+ * @fa
[PATCH 9/9] drm/vmwgfx: Hook up the helpers to align buffer objects
From: Thomas Hellstrom
Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/drm_file.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 13 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 40fae356d202..1df2fca608c3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -932,3 +932,4 @@ unsigned long drm_get_unmapped_area(struct file *file,
return current->mm->get_unmapped_area(file, uaddr, len, pgoff, flags);
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+EXPORT_SYMBOL_GPL(drm_get_unmapped_area);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index e962048f65d2..5452cabb4a2e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1215,6 +1215,18 @@ static void vmw_remove(struct pci_dev *pdev)
drm_put_dev(dev);
}
+static unsigned long
+vmw_get_unmapped_area(struct file *file, unsigned long uaddr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct drm_file *file_priv = file->private_data;
+ struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+
+ return drm_get_unmapped_area(file, uaddr, len, pgoff, flags,
+&dev_priv->vma_manager);
+}
+
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
void *ptr)
{
@@ -1386,6 +1398,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.compat_ioctl = vmw_compat_ioctl,
#endif
.llseek = noop_llseek,
+ .get_unmapped_area = vmw_get_unmapped_area,
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 06267184aa0a..9ea145cffa3d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -929,6 +929,7 @@ extern int vmw_mmap(struct file *filp, struct
vm_area_struct *vma);
extern void vmw_validation_mem_init_ttm(struct vmw_private *dev_priv,
size_t gran);
+
/**
* TTM buffer object driver - vmwgfx_ttm_buffer.c
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d8ea3dd10af0..34c721ab3ff3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -754,7 +754,7 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
+ man->func = &vmw_thp_func;
man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm: Add a drm_get_unmapped_area() helper
From: Thomas Hellstrom
Unaligned virtual addresses makes it unlikely that huge page-table entries
can be used.
So align virtual buffer object address huge page boundaries to the
underlying physical address huge page boundaries taking buffer object
sizes into account to determine when it might be possible to use huge
page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/drm_file.c | 136 +
include/drm/drm_file.h | 5 ++
2 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 92d16724f949..40fae356d202 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -39,10 +39,13 @@
#include
#include
+#include
+
#include
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -796,3 +799,136 @@ struct file *mock_drm_getfile(struct drm_minor *minor,
unsigned int flags)
return file;
}
EXPORT_SYMBOL_FOR_TESTS_ONLY(mock_drm_getfile);
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * drm_addr_inflate() attempts to construct an aligned area by inflating
+ * the area size and skipping the unaligned start of the area.
+ * adapted from shmem_get_unmapped_area()
+ */
+static unsigned long drm_addr_inflate(unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags,
+ unsigned long huge_size)
+{
+ unsigned long offset, inflated_len;
+ unsigned long inflated_addr;
+ unsigned long inflated_offset;
+
+ offset = (pgoff << PAGE_SHIFT) & (huge_size - 1);
+ if (offset && offset + len < 2 * huge_size)
+ return addr;
+ if ((addr & (huge_size - 1)) == offset)
+ return addr;
+
+ inflated_len = len + huge_size - PAGE_SIZE;
+ if (inflated_len > TASK_SIZE)
+ return addr;
+ if (inflated_len < len)
+ return addr;
+
+ inflated_addr = current->mm->get_unmapped_area(NULL, 0, inflated_len,
+ 0, flags);
+ if (IS_ERR_VALUE(inflated_addr))
+ return addr;
+ if (inflated_addr & ~PAGE_MASK)
+ return addr;
+
+ inflated_offset = inflated_addr & (huge_size - 1);
+ inflated_addr += offset - inflated_offset;
+ if (inflated_offset > offset)
+ inflated_addr += huge_size;
+
+ if (inflated_addr > TASK_SIZE - len)
+ return addr;
+
+ return inflated_addr;
+}
+
+/**
+ * drm_get_unmapped_area() - Get an unused user-space virtual memory area
+ * suitable for huge page table entries.
+ * @file: The struct file representing the address space being mmap()'d.
+ * @uaddr: Start address suggested by user-space.
+ * @len: Length of the area.
+ * @pgoff: The page offset into the address space.
+ * @flags: mmap flags
+ * @mgr: The address space manager used by the drm driver. This argument can
+ * probably be removed at some point when all drivers use the same
+ * address space manager.
+ *
+ * This function attempts to find an unused user-space virtual memory area
+ * that can accommodate the size we want to map, and that is properly
+ * aligned to facilitate huge page table entries matching actual
+ * huge pages or huge page aligned memory in buffer objects. Buffer objects
+ * are assumed to start at huge page boundary pfns (io memory) or be
+ * populated by huge pages aligned to the start of the buffer object
+ * (system- or coherent memory). Adapted from shmem_get_unmapped_area.
+ *
+ * Return: aligned user-space address.
+ */
+unsigned long drm_get_unmapped_area(struct file *file,
+ unsigned long uaddr, unsigned long len,
+ unsigned long pgoff, unsigned long flags,
+ struct drm_vma_offset_manager *mgr)
+{
+ unsigned long addr;
+ unsigned long inflated_addr;
+ struct drm_vma_offset_node *node;
+
+ if (len > TASK_SIZE)
+ return -ENOMEM;
+
+ /*
+* @pgoff is the file page-offset the huge page boundaries of
+* which typically aligns to physical address huge page boundaries.
+* That's not true for DRM, however, where physical address huge
+* page boundaries instead are aligned with the offset from
+* buffer object start. So adjust @pgoff to be the offset from
+* buffer object start.
+*/
+ drm_vma_offset_lock_lookup(mgr);
+ node = drm_vma_offset_lookup_locked(mgr, pgoff, 1);
+ if (node)
+ pgoff -= node->vm_node
[PATCH 2/9] mm: Introduce vma_is_special_huge
From: Thomas Hellstrom
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
and -page table entries, introduce vma_is_special_huge() that takes the
same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do not wish to be associated with a "struct page"
(either it doesn't exist, or it exists but they don't want to touch it)
For PAGE_SIZE pages, "special" is determined per page table entry to be
able to deal with COW pages. But since we don't have huge COW pages,
we can classify a vma as either "special huge" or "normal huge".
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
---
include/linux/mm.h | 17 +
mm/huge_memory.c | 6 +++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0157d293935f..d370ce2932a1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2822,6 +2822,23 @@ extern long copy_huge_page_from_user(struct page
*dst_page,
const void __user *usr_src,
unsigned int pages_per_huge_page,
bool allow_pagefault);
+
+/**
+ * vma_is_special_huge - Are transhuge page-table entries considered special?
+ * @vma: Pointer to the struct vm_area_struct to consider
+ *
+ * Whether transhuge page-table entries are considered "special" following
+ * the definition in vm_normal_page().
+ *
+ * Return: true if transhuge page-table entries should be considered special,
+ * false otherwise.
+ */
+static inline bool vma_is_special_huge(const struct vm_area_struct *vma)
+{
+ return vma_is_dax(vma) || (vma->vm_file &&
+ (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)));
+}
+
#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 41a0fbddc96b..f8d24fc3f4df 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1789,7 +1789,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
vm_area_struct *vma,
orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd,
tlb->fullmm);
tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
if (arch_needs_pgtable_deposit())
zap_deposited_table(tlb->mm, pmd);
spin_unlock(ptl);
@@ -2053,7 +2053,7 @@ int zap_huge_pud(struct mmu_gather *tlb, struct
vm_area_struct *vma,
*/
pudp_huge_get_and_clear_full(tlb->mm, addr, pud, tlb->fullmm);
tlb_remove_pud_tlb_entry(tlb, pud, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
spin_unlock(ptl);
/* No zero page support yet */
} else {
@@ -2162,7 +2162,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct
*vma, pmd_t *pmd,
*/
if (arch_needs_pgtable_deposit())
zap_deposited_table(mm, pmd);
- if (vma_is_dax(vma))
+ if (vma_is_special_huge(vma))
return;
page = pmd_page(_pmd);
if (!PageDirty(page) && pmd_dirty(_pmd))
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/vmwgfx: Introduce a huge page aligning TTM range manager
From: Thomas Hellstrom
Using huge page-table entries requires that the physical address of the
start of a buffer object is huge page size aligned.
Make a special version of the TTM range manager that accomplishes this,
but falls back to a smaller page size alignment (PUD->PMD, PMD->NORMAL)
to avoid eviction.
If other drivers want to use it in the future, it can be made a
TTM generic helper. Note that drivers can force eviction for a certain
alignment by assigning the TTM GPU alignment correspondingly.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/Makefile | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 7 ++
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 166
3 files changed, 174 insertions(+)
create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index c877a21a0739..421dd2a497a5 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -11,4 +11,5 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_validation.o vmwgfx_page_dirty.o \
ttm_object.o ttm_lock.o
+vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 82d86f2d2569..06267184aa0a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1433,6 +1433,13 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
enum page_entry_size pe_size);
#endif
+/* Transparent hugepage support - vmwgfx_thp.c */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+extern const struct ttm_mem_type_manager_func vmw_thp_func;
+#else
+#define vmw_thp_func ttm_bo_manager_func
+#endif
+
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
new file mode 100644
index ..b7c816ba7166
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Huge page-table-entry support for IO memory.
+ *
+ * Copyright (C) 2007-2019 Vmware, Inc. All rights reservedd.
+ */
+#include "vmwgfx_drv.h"
+#include
+#include
+#include
+
+/**
+ * struct vmw_thp_manager - Range manager implementing huge page alignment
+ *
+ * @mm: The underlying range manager. Protected by @lock.
+ * @lock: Manager lock.
+ */
+struct vmw_thp_manager {
+ struct drm_mm mm;
+ spinlock_t lock;
+};
+
+static int vmw_thp_insert_aligned(struct drm_mm *mm, struct drm_mm_node *node,
+ unsigned long align_pages,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem,
+ unsigned long lpfn,
+ enum drm_mm_insert_mode mode)
+{
+ if (align_pages >= mem->page_alignment &&
+ (!mem->page_alignment || align_pages % mem->page_alignment == 0)) {
+ return drm_mm_insert_node_in_range(mm, node,
+ mem->num_pages,
+ align_pages, 0,
+ place->fpfn, lpfn, mode);
+ }
+
+ return -ENOSPC;
+}
+
+static int vmw_thp_get_node(struct ttm_mem_type_manager *man,
+ struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+ struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
+ struct drm_mm *mm = &rman->mm;
+ struct drm_mm_node *node;
+ unsigned long align_pages;
+ unsigned long lpfn;
+ enum drm_mm_insert_mode mode = DRM_MM_INSERT_BEST;
+ int ret;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ lpfn = place->lpfn;
+ if (!lpfn)
+ lpfn = man->size;
+
+ mode = DRM_MM_INSERT_BEST;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
+
+ spin_lock(&rman->lock);
+ if (IS_ENABLED(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)) {
+ align_pages = (HPAGE_PUD_SIZE >> PAGE_SHIFT);
+ if (mem->num_pages >= align_pages) {
+ ret = vmw_thp_insert_aligned(mm, node, align_pages,
+place, mem, lpfn, mode);
+ if (!ret)
+ goto found_unlock;
+ }
+ }
+
+ align_pages = (HP
[PATCH 1/9] fs: Constify vma argument to vma_is_dax
From: Thomas Hellstrom
The vma argument is only dereferenced for reading.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 98e0349adb52..4f41fdbf402f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3367,7 +3367,7 @@ static inline bool io_is_direct(struct file *filp)
return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
}
-static inline bool vma_is_dax(struct vm_area_struct *vma)
+static inline bool vma_is_dax(const struct vm_area_struct *vma)
{
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/vmwgfx: Support huge page faults
From: Thomas Hellstrom
With vmwgfx dirty-tracking we need a specialized huge_fault
callback. Implement and hook it up.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 ++
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 74 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 5 +-
3 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index a31e726d6d71..82d86f2d2569 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1428,6 +1428,10 @@ void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo,
pgoff_t start, pgoff_t end);
vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf);
vm_fault_t vmw_bo_vm_mkwrite(struct vm_fault *vmf);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size);
+#endif
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
index 17a5dca7b921..cde3e07ebaf7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
@@ -473,7 +473,7 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
* a lot of unnecessary write faults.
*/
if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE)
- prot = vma->vm_page_prot;
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
else
prot = vm_get_page_prot(vma->vm_flags);
@@ -486,3 +486,75 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
return ret;
}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
+ vma->vm_private_data;
+ struct vmw_buffer_object *vbo =
+ container_of(bo, struct vmw_buffer_object, base);
+ pgprot_t prot;
+ vm_fault_t ret;
+ pgoff_t fault_page_size;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+ bool is_cow_mapping =
+ (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
+
+ switch (pe_size) {
+ case PE_SIZE_PMD:
+ fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
+ break;
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ case PE_SIZE_PUD:
+ fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
+ break;
+#endif
+ default:
+ WARN_ON_ONCE(1);
+ return VM_FAULT_FALLBACK;
+ }
+
+ /* Always do write dirty-tracking and COW on PTE level. */
+ if (write && (READ_ONCE(vbo->dirty) || is_cow_mapping))
+ return VM_FAULT_FALLBACK;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ if (vbo->dirty) {
+ pgoff_t allowed_prefault;
+ unsigned long page_offset;
+
+ page_offset = vmf->pgoff -
+ drm_vma_node_start(&bo->base.vma_node);
+ if (page_offset >= bo->num_pages ||
+ vmw_resources_clean(vbo, page_offset,
+ page_offset + PAGE_SIZE,
+ &allowed_prefault)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_unlock;
+ }
+
+ /*
+* Write protect, so we get a new fault on write, and can
+* split.
+*/
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
+ } else {
+ prot = vm_get_page_prot(vma->vm_flags);
+ }
+
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+out_unlock:
+ dma_resv_unlock(bo->base.resv);
+
+ return ret;
+}
+#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index ce288756531b..34100d1f5a9d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -34,7 +34,10 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
.page_mkwrite = vmw_bo_vm_mkwrite,
.fault = vmw_bo_vm_fault,
.open = ttm_bo_vm_open,
- .close = ttm_bo_vm_close
+ .close = ttm_bo_vm_close,
+#ifdef CONFIG_TRANSPARENT_HUGEPAG
[PATCH] dma-buf: fix locking in sync_print_obj()
This is always called with IRQs disabled and we don't actually want to
enable IRQs at the end.
Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
context")
Signed-off-by: Dan Carpenter
---
drivers/dma-buf/sync_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 101394f16930..952331344b1c 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -107,15 +107,16 @@ static void sync_print_fence(struct seq_file *s,
static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj)
{
struct list_head *pos;
+ unsigned long flags;
seq_printf(s, "%s: %d\n", obj->name, obj->value);
- spin_lock_irq(&obj->lock);
+ spin_lock_irqsave(&obj->lock, flags);
list_for_each(pos, &obj->pt_list) {
struct sync_pt *pt = container_of(pos, struct sync_pt, link);
sync_print_fence(s, &pt->base, false);
}
- spin_unlock_irq(&obj->lock);
+ spin_unlock_irqrestore(&obj->lock, flags);
}
static void sync_print_sync_file(struct seq_file *s,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix locking in sync_print_obj()
Quoting Dan Carpenter (2020-01-24 10:13:12)
> This is always called with IRQs disabled and we don't actually want to
> enable IRQs at the end.
>
> Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
> context")
> Signed-off-by: Dan Carpenter
> ---
> drivers/dma-buf/sync_debug.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index 101394f16930..952331344b1c 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -107,15 +107,16 @@ static void sync_print_fence(struct seq_file *s,
> static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj)
> {
> struct list_head *pos;
> + unsigned long flags;
>
> seq_printf(s, "%s: %d\n", obj->name, obj->value);
>
> - spin_lock_irq(&obj->lock);
> + spin_lock_irqsave(&obj->lock, flags);
Exactly, it can be just spin_lock() as the irq state is known.
Once again I question why this [sync_debug.c] code even exists.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix locking in sync_print_obj()
On Fri, Jan 24, 2020 at 10:20:56AM +, Chris Wilson wrote:
> Quoting Dan Carpenter (2020-01-24 10:13:12)
> > This is always called with IRQs disabled and we don't actually want to
> > enable IRQs at the end.
> >
> > Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
> > context")
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/dma-buf/sync_debug.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > index 101394f16930..952331344b1c 100644
> > --- a/drivers/dma-buf/sync_debug.c
> > +++ b/drivers/dma-buf/sync_debug.c
> > @@ -107,15 +107,16 @@ static void sync_print_fence(struct seq_file *s,
> > static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj)
> > {
> > struct list_head *pos;
> > + unsigned long flags;
> >
> > seq_printf(s, "%s: %d\n", obj->name, obj->value);
> >
> > - spin_lock_irq(&obj->lock);
> > + spin_lock_irqsave(&obj->lock, flags);
>
> Exactly, it can be just spin_lock() as the irq state is known.
>
I did consider that but I wasn't sure how this is going to be used in
the future so I took a conservative approach.
> Once again I question why this [sync_debug.c] code even exists.
No idea.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 15/22] drm/stm: Convert to CRTC VBLANK callbacks
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert stm over.
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/drv.c | 1 -
> drivers/gpu/drm/stm/ltdc.c | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 486985604109..ea9fcbdc68b3 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -72,7 +72,6 @@ static struct drm_driver drv_driver = {
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> };
>
> static int drv_load(struct drm_device *ddev)
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 8b6d1a2252e3..ee2a8cac59cb 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -722,6 +722,7 @@ static const struct drm_crtc_funcs ltdc_crtc_funcs = {
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .enable_vblank = ltdc_crtc_enable_vblank,
> .disable_vblank = ltdc_crtc_disable_vblank,
> + .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
> .gamma_set = drm_atomic_helper_legacy_gamma_set,
> };
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/22] drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
> over.
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/drv.c | 1 -
> drivers/gpu/drm/stm/ltdc.c | 65 --
> drivers/gpu/drm/stm/ltdc.h | 5 ---
> 3 files changed, 34 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 5a9f9aca8bc2..486985604109 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -72,7 +72,6 @@ static struct drm_driver drv_driver = {
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .get_scanout_position = ltdc_crtc_scanoutpos,
> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> };
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index c2815e8ae1da..8b6d1a2252e3 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -636,38 +636,13 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc
> *crtc,
> }
> }
>
> -static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> - .mode_valid = ltdc_crtc_mode_valid,
> - .mode_fixup = ltdc_crtc_mode_fixup,
> - .mode_set_nofb = ltdc_crtc_mode_set_nofb,
> - .atomic_flush = ltdc_crtc_atomic_flush,
> - .atomic_enable = ltdc_crtc_atomic_enable,
> - .atomic_disable = ltdc_crtc_atomic_disable,
> -};
> -
> -static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
> -{
> - struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> -
> - DRM_DEBUG_DRIVER("\n");
> - reg_set(ldev->regs, LTDC_IER, IER_LIE);
> -
> - return 0;
> -}
> -
> -static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
> -{
> - struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> -
> - DRM_DEBUG_DRIVER("\n");
> - reg_clear(ldev->regs, LTDC_IER, IER_LIE);
> -}
> -
> -bool ltdc_crtc_scanoutpos(struct drm_device *ddev, unsigned int pipe,
> - bool in_vblank_irq, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode)
> +static bool ltdc_crtc_get_scanout_position(struct drm_crtc *crtc,
> +bool in_vblank_irq,
> +int *vpos, int *hpos,
> +ktime_t *stime, ktime_t *etime,
> +const struct drm_display_mode *mode)
> {
> + struct drm_device *ddev = crtc->dev;
> struct ltdc_device *ldev = ddev->dev_private;
> int line, vactive_start, vactive_end, vtotal;
>
> @@ -710,6 +685,34 @@ bool ltdc_crtc_scanoutpos(struct drm_device *ddev,
> unsigned int pipe,
> return true;
> }
>
> +static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> + .mode_valid = ltdc_crtc_mode_valid,
> + .mode_fixup = ltdc_crtc_mode_fixup,
> + .mode_set_nofb = ltdc_crtc_mode_set_nofb,
> + .atomic_flush = ltdc_crtc_atomic_flush,
> + .atomic_enable = ltdc_crtc_atomic_enable,
> + .atomic_disable = ltdc_crtc_atomic_disable,
> + .get_scanout_position = ltdc_crtc_get_scanout_position,
> +};
> +
> +static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> +
> + DRM_DEBUG_DRIVER("\n");
> + reg_set(ldev->regs, LTDC_IER, IER_LIE);
> +
> + return 0;
> +}
> +
> +static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> +
> + DRM_DEBUG_DRIVER("\n");
> + reg_clear(ldev->regs, LTDC_IER, IER_LIE);
> +}
> +
> static const struct drm_crtc_funcs ltdc_crtc_funcs = {
> .destroy = drm_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index a1ad0ae3b006..c5467d74e707 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -39,11 +39,6 @@ struct ltdc_device {
> struct drm_atomic_state *suspend_state;
> };
>
> -bool ltdc_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
> - bool in_vblank_irq, int *vpos, int *hpos,
> - ktime_t *stime, ktime_t *etime,
> - const struct drm_display_mode *mode);
> -
> int ltdc_load(struct drm_device *ddev);
> void ltdc_unload(struct drm_device *ddev);
> void ltdc_suspend(struct drm_device *ddev);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/ma
[PATCH v2 2/2] drm/bridge: Add tc358768 driver
Add basic support for the Toshiba TC358768 RGB to DSI bridge. Not all the features of the TC358768 is implemented by the initial driver: MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested. Only write is implemented for mipi_dsi_host_ops.transfer. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358768.c | 992 ++ 3 files changed, 1003 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358768.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 0b9ca5862455..3fef3513bdd0 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767 ---help--- Toshiba TC358767 eDP bridge chip driver. +config DRM_TOSHIBA_TC358768 + tristate "Toshiba TC358768 MIPI DSI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. + config DRM_TI_TFP410 tristate "TI TFP410 DVI/HDMI bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index cd16ce830270..06fc265de0ef 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o +obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c new file mode 100644 index ..5e12b1390254 --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358768.c @@ -0,0 +1,992 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com + * Author: Peter Ujfalusi + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +/* Global (16-bit addressable) */ +#define TC358768_CHIPID0x +#define TC358768_SYSCTL0x0002 +#define TC358768_CONFCTL 0x0004 +#define TC358768_VSDLY 0x0006 +#define TC358768_DATAFMT 0x0008 +#define TC358768_GPIOEN0x000E +#define TC358768_GPIODIR 0x0010 +#define TC358768_GPIOIN0x0012 +#define TC358768_GPIOOUT 0x0014 +#define TC358768_PLLCTL0 0x0016 +#define TC358768_PLLCTL1 0x0018 +#define TC358768_CMDBYTE 0x0022 +#define TC358768_PP_MISC 0x0032 +#define TC358768_DSITX_DT 0x0050 +#define TC358768_FIFOSTATUS0x00F8 + +/* Debug (16-bit addressable) */ +#define TC358768_VBUFCTRL 0x00E0 +#define TC358768_DBG_WIDTH 0x00E2 +#define TC358768_DBG_VBLANK0x00E4 +#define TC358768_DBG_DATA 0x00E8 + +/* TX PHY (32-bit addressable) */ +#define TC358768_CLW_DPHYCONTTX0x0100 +#define TC358768_D0W_DPHYCONTTX0x0104 +#define TC358768_D1W_DPHYCONTTX0x0108 +#define TC358768_D2W_DPHYCONTTX0x010C +#define TC358768_D3W_DPHYCONTTX0x0110 +#define TC358768_CLW_CNTRL 0x0140 +#define TC358768_D0W_CNTRL 0x0144 +#define TC358768_D1W_CNTRL 0x0148 +#define TC358768_D2W_CNTRL 0x014C +#define TC358768_D3W_CNTRL 0x0150 + +/* TX PPI (32-bit addressable) */ +#define TC358768_STARTCNTRL0x0204 +#define TC358768_DSITXSTATUS 0x0208 +#define TC358768_LINEINITCNT 0x0210 +#define TC358768_LPTXTIMECNT 0x0214 +#define TC358768_TCLK_HEADERCNT0x0218 +#define TC358768_TCLK_TRAILCNT 0x021C +#define TC358768_THS_HEADERCNT 0x0220 +#define TC358768_TWAKEUP 0x0224 +#define TC358768_TCLK_POSTCNT 0x0228 +#define TC358768_THS_TRAILCNT 0x022C +#define TC358768_HSTXVREGCNT 0x0230 +#define TC358768_HSTXVREGEN0x0234 +#define TC358768_TXOPTIONCNTRL 0x0238 +#define TC358768_BTACNTRL1 0x023C + +/* TX CTRL (32-bit addressable) */ +#define TC358768_DSI_CONTROL 0x040C +#define TC358768_DSI_STATUS0x0410 +#define TC358768_DSI_INT 0x0414 +#define TC358768_DSI_INT_ENA 0x0418 +#define TC358768_DSICMD_RDFIFO 0x0430 +#define TC358768_DSI_ACKERR0x0434 +#define TC358768_DSI_ACKERR_INTEN
[PATCH v2 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge
Hi, Changes since v1: DT bindings document: - Removed MaxItems for the regulators - additionalProperties: false added to port@1 Driver: - Year is now 2020 - Includes shorted - The three letter members of the private struct documented 0 they are named as in the datasheet - Error handling for the IO functions is following what sil-sii8620.c does - regmap regcache is disabled along with refcache_sync() and volatile callback for regmap - The hw enable and disable functions got separated - Taken the suggested simplifactions from Andrzej for tc358768_calc_pll() and tc358768_dsi_host_transfer() - The driver no longer stores the drm_display_mode, it relies on priv->bridge.encoder->crtc->state->adjusted_mode where it needs it - tc358768_calc_pll() can be used for verification only to not modify the state - refcounting added for hw enable state as a dsi transfer was shutting down the bridge when it was already enabled. Tested on top of drm-next + LED backlight patches + DT patches on dra7-evm with osd101t2045 (panel-simple) and osd101t2587 panel drivers. Cover letter from v1: TC358768 is a parallel RGB to MIPI DSI bridge. The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware where other modes can be tested. Regards, Peter --- Peter Ujfalusi (2): dt-bindings: display: bridge: Add documentation for Toshiba tc358768 drm/bridge: Add tc358768 driver .../display/bridge/toshiba,tc358768.yaml | 158 +++ drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358768.c | 992 ++ 4 files changed, 1161 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml create mode 100644 drivers/gpu/drm/bridge/tc358768.c -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 158 ++
1 file changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
new file mode 100644
index ..8dd8cca39a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The TC358768/TC358778 is bridge device which converts RGB to DSI.
+
+properties:
+ compatible:
+enum:
+ - toshiba,tc358768
+ - toshiba,tc358778
+
+ reg:
+maxItems: 1
+description: base I2C address of the device
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low RESX pin
+
+ vddc-supply:
+description: Regulator for 1.2V internal core power.
+
+ vddmipi-supply:
+description: Regulator for 1.2V for the MIPI.
+
+ vddio-supply:
+description: Regulator for 1.8V - 3.3V IO power.
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: refclk
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+additionalProperties: false
+
+description: |
+ Video port for RGB input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ endpoint:
+type: object
+additionalProperties: false
+
+properties:
+ data-lines:
+enum: [ 16, 18, 24 ]
+
+ remote-endpoint: true
+
+required:
+ - reg
+
+ port@1:
+type: object
+additionalProperties: false
+
+description: |
+ Video port for DSI output (panel or connector).
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ endpoint:
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - vddc-supply
+ - vddmipi-supply
+ - vddio-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi_bridge: tc358768@0e {
+compatible = "toshiba,tc358768";
+reg = <0x0e>;
+
+clocks = <&tc358768_refclk>;
+clock-names = "refclk";
+
+/* GPIO line is inverted before going to the bridge */
+reset-gpios = <&pcf_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
+
+vddc-supply = <&v1_2d>;
+vddmipi-supply = <&v1_2d>;
+vddio-supply = <&v3_3d>;
+
+dsi_bridge_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+rgb_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ data-lines = <24>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+dsi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+};
+ };
+};
+ };
+};
+
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/3] drm/i915: Move the code to populate ACPI device ID into intel_acpi
On Fri, 20 Dec 2019, Rajat Jain wrote:
> Move the code that populates the ACPI device ID for devices, into
> more appripriate intel_acpi.c. This is done in preparation for more
> users of this code (in next patch).
Sorry for the delay, thanks for the patch, pushed to
drm-intel-next-queued.
BR,
Jani.
>
> Signed-off-by: Rajat Jain
> ---
> v5: same as v4
> v4: Same as v3
> v3: * Renamed the function to intel_acpi_*
> * Used forward declaration for structure instead of header file inclusion.
> * Fix a typo
> v2: v1 doesn't exist. Found existing code in i915 driver to assign the ACPI ID
> which is what I plan to re-use.
>
> drivers/gpu/drm/i915/display/intel_acpi.c | 89 +++
> drivers/gpu/drm/i915/display/intel_acpi.h | 5 ++
> drivers/gpu/drm/i915/display/intel_opregion.c | 80 +
> 3 files changed, 98 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 3456d33feb46..e21fb14d5e07 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -10,6 +10,7 @@
>
> #include "i915_drv.h"
> #include "intel_acpi.h"
> +#include "intel_display_types.h"
>
> #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
> #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
> @@ -156,3 +157,91 @@ void intel_register_dsm_handler(void)
> void intel_unregister_dsm_handler(void)
> {
> }
> +
> +/*
> + * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All
> Devices
> + * Attached to the Display Adapter).
> + */
> +#define ACPI_DISPLAY_INDEX_SHIFT 0
> +#define ACPI_DISPLAY_INDEX_MASK (0xf << 0)
> +#define ACPI_DISPLAY_PORT_ATTACHMENT_SHIFT 4
> +#define ACPI_DISPLAY_PORT_ATTACHMENT_MASK(0xf << 4)
> +#define ACPI_DISPLAY_TYPE_SHIFT 8
> +#define ACPI_DISPLAY_TYPE_MASK (0xf << 8)
> +#define ACPI_DISPLAY_TYPE_OTHER (0 << 8)
> +#define ACPI_DISPLAY_TYPE_VGA(1 << 8)
> +#define ACPI_DISPLAY_TYPE_TV (2 << 8)
> +#define ACPI_DISPLAY_TYPE_EXTERNAL_DIGITAL (3 << 8)
> +#define ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL (4 << 8)
> +#define ACPI_VENDOR_SPECIFIC_SHIFT 12
> +#define ACPI_VENDOR_SPECIFIC_MASK(0xf << 12)
> +#define ACPI_BIOS_CAN_DETECT (1 << 16)
> +#define ACPI_DEPENDS_ON_VGA (1 << 17)
> +#define ACPI_PIPE_ID_SHIFT 18
> +#define ACPI_PIPE_ID_MASK(7 << 18)
> +#define ACPI_DEVICE_ID_SCHEME(1ULL << 31)
> +
> +static u32 acpi_display_type(struct intel_connector *connector)
> +{
> + u32 display_type;
> +
> + switch (connector->base.connector_type) {
> + case DRM_MODE_CONNECTOR_VGA:
> + case DRM_MODE_CONNECTOR_DVIA:
> + display_type = ACPI_DISPLAY_TYPE_VGA;
> + break;
> + case DRM_MODE_CONNECTOR_Composite:
> + case DRM_MODE_CONNECTOR_SVIDEO:
> + case DRM_MODE_CONNECTOR_Component:
> + case DRM_MODE_CONNECTOR_9PinDIN:
> + case DRM_MODE_CONNECTOR_TV:
> + display_type = ACPI_DISPLAY_TYPE_TV;
> + break;
> + case DRM_MODE_CONNECTOR_DVII:
> + case DRM_MODE_CONNECTOR_DVID:
> + case DRM_MODE_CONNECTOR_DisplayPort:
> + case DRM_MODE_CONNECTOR_HDMIA:
> + case DRM_MODE_CONNECTOR_HDMIB:
> + display_type = ACPI_DISPLAY_TYPE_EXTERNAL_DIGITAL;
> + break;
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + case DRM_MODE_CONNECTOR_DSI:
> + display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
> + break;
> + case DRM_MODE_CONNECTOR_Unknown:
> + case DRM_MODE_CONNECTOR_VIRTUAL:
> + display_type = ACPI_DISPLAY_TYPE_OTHER;
> + break;
> + default:
> + MISSING_CASE(connector->base.connector_type);
> + display_type = ACPI_DISPLAY_TYPE_OTHER;
> + break;
> + }
> +
> + return display_type;
> +}
> +
> +void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
> +{
> + struct drm_device *drm_dev = &dev_priv->drm;
> + struct intel_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> + u8 display_index[16] = {};
> +
> + /* Populate the ACPI IDs for all connectors for a given drm_device */
> + drm_connector_list_iter_begin(drm_dev, &conn_iter);
> + for_each_intel_connector_iter(connector, &conn_iter) {
> + u32 device_id, type;
> +
> + device_id = acpi_display_type(connector);
> +
> + /* Use display type specific display index. */
> + type = (device_id & ACPI_DISPLAY_TYPE_MASK)
> + >> ACPI_DISPLAY_TYPE_SHIFT;
> + device_id |= display_index[type]++ << ACPI_DISPLAY_INDEX_SHIFT;
> +
> + connector->
Re: [PATCH] dma-buf: fix locking in sync_print_obj()
Quoting Dan Carpenter (2020-01-24 10:31:23)
> On Fri, Jan 24, 2020 at 10:20:56AM +, Chris Wilson wrote:
> > Quoting Dan Carpenter (2020-01-24 10:13:12)
> > > This is always called with IRQs disabled and we don't actually want to
> > > enable IRQs at the end.
> > >
> > > Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
> > > known context")
> > > Signed-off-by: Dan Carpenter
> > > ---
> > > drivers/dma-buf/sync_debug.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> > > index 101394f16930..952331344b1c 100644
> > > --- a/drivers/dma-buf/sync_debug.c
> > > +++ b/drivers/dma-buf/sync_debug.c
> > > @@ -107,15 +107,16 @@ static void sync_print_fence(struct seq_file *s,
> > > static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj)
> > > {
> > > struct list_head *pos;
> > > + unsigned long flags;
> > >
> > > seq_printf(s, "%s: %d\n", obj->name, obj->value);
> > >
> > > - spin_lock_irq(&obj->lock);
> > > + spin_lock_irqsave(&obj->lock, flags);
> >
> > Exactly, it can be just spin_lock() as the irq state is known.
> >
>
> I did consider that but I wasn't sure how this is going to be used in
> the future so I took a conservative approach.
Sure, it's debug so not critical (lists within lists to a seqfile, ouch)
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/3] drm/i915: Lookup and attach ACPI device node for connectors
On Fri, 20 Dec 2019, Rajat Jain wrote:
> Lookup and attach ACPI nodes for intel connectors. The lookup is done
> in compliance with ACPI Spec 6.3
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> (Ref: Pages 1119 - 1123).
>
> This can be useful for any connector specific platform properties. (This
> will be used for privacy screen in next patch).
>
> Signed-off-by: Rajat Jain
> ---
> v5: same as v4
> v4: Same as v3
> v3: fold the code into existing acpi_device_id_update() function
> v2: formed by splitting the original patch into ACPI lookup, and privacy
> screen property. Also move it into i915 now that I found existing code
> in i915 that can be re-used.
>
> drivers/gpu/drm/i915/display/intel_acpi.c | 24 +++
> .../drm/i915/display/intel_display_types.h| 3 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
> 3 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e21fb14d5e07..101a56c08996 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -222,11 +222,23 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
> return display_type;
> }
>
> +/*
> + * Ref: ACPI Spec 6.3
> + * https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> + * Pages 1119 - 1123 describe, what I believe, a standard way of
> + * identifying / addressing "display panels" in the ACPI. It provides
> + * a way for the ACPI to define devices for the display panels attached
> + * to the system. It thus provides a way for the BIOS to export any panel
> + * specific properties to the system via ACPI (like device trees).
> + */
> void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
> {
> struct drm_device *drm_dev = &dev_priv->drm;
> struct intel_connector *connector;
> struct drm_connector_list_iter conn_iter;
> + struct device *dev = &drm_dev->pdev->dev;
Hmm, already pushed patch 1 with the unfortunate "drm_dev" local. We use
"dev" for struct drm_device * and almost never use struct device.
> + struct acpi_device *conn_dev;
> + u64 conn_addr;
> u8 display_index[16] = {};
>
> /* Populate the ACPI IDs for all connectors for a given drm_device */
> @@ -242,6 +254,18 @@ void intel_acpi_device_id_update(struct drm_i915_private
> *dev_priv)
> device_id |= display_index[type]++ << ACPI_DISPLAY_INDEX_SHIFT;
>
> connector->acpi_device_id = device_id;
> +
> + /* Build the _ADR to look for */
> + conn_addr = device_id | ACPI_DEVICE_ID_SCHEME |
> + ACPI_BIOS_CAN_DETECT;
> +
> + DRM_DEV_INFO(dev, "Checking connector ACPI node at _ADR=%llX\n",
> + conn_addr);
This is more than a little verbose. One line of INFO level dmesg for
every connector at boot and at resume.
Please use the new drm_dbg_kms() macro for this.
> +
> + /* Look up the connector device, under the PCI device */
> + conn_dev = acpi_find_child_device(ACPI_COMPANION(dev),
> + conn_addr, false);
> + connector->acpi_handle = conn_dev ? conn_dev->handle : NULL;
acpi_device_handle(conn_dev)
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1a7334dbe802..0a4a04116091 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -407,6 +407,9 @@ struct intel_connector {
> /* ACPI device id for ACPI and driver cooperation */
> u32 acpi_device_id;
>
> + /* ACPI handle corresponding to this connector display, if found */
> + void *acpi_handle;
> +
The type is acpi_handle. It's none of our business to know what the
underlying type is.
> /* Reads out the current hw, returning true if the connector is enabled
>* and active (i.e. dpms ON state). */
> bool (*get_hw_state)(struct intel_connector *);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index b05b2191b919..93cece8e2516 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -45,6 +45,7 @@
> #include "i915_debugfs.h"
> #include "i915_drv.h"
> #include "i915_trace.h"
> +#include "intel_acpi.h"
> #include "intel_atomic.h"
> #include "intel_audio.h"
> #include "intel_connector.h"
> @@ -6623,6 +6624,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
>
> connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
>
> + /* Lookup the ACPI node corresponding to the connector */
> + intel_ac
Re: [PATCH v2] drm: Release filp before global lock
On 1/23/20 11:21 PM, Chris Wilson wrote: The file is not part of the global drm resource and can be released prior to take the global mutex to drop the open_count (and potentially close) the drm device. As the global mutex is indeed global, not only within the device but across devices, a slow file release mechanism can bottleneck the entire system. However, inside drm_close_helper() there are a number of dev->driver callbacks that take the drm_device as the first parameter... Worryingly some of those callbacks may be (implicitly) depending on the global mutex. From a quick audit, via, sis and vmwgfx are safe, so for those Acked-by: Thomas Hellstrom Savage appears to be unsafe, due to unprotected access in the dma device member. Haven't audited i810 or potential other drivers affected. Perhaps it makes sense to enable lockfree filp release on a per-driver basis to begin with? /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Release filp before global lock
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device. As the global mutex is indeed global, not only
within the device but across devices, a slow file release mechanism can
bottleneck the entire system.
However, inside drm_close_helper() there are a number of dev->driver
callbacks that take the drm_device as the first parameter... Worryingly
some of those callbacks may be (implicitly) depending on the global
mutex.
v2: Drop the debug message for the open-count, it's included with the
drm_file_free() debug message -- and for good measure make that up as
reading outside of the mutex.
v3: Separate the calling of the filp cleanup outside of
drm_global_mutex into a new drm_release_noglobal() hook, so that we can
phase the transition. drm/savage relies on the global mutex, and there
may be more, so be cautious.
Signed-off-by: Chris Wilson
Cc: Thomas Hellström (VMware)
Acked-by: Thomas Hellström (VMware)
---
drivers/gpu/drm/drm_file.c | 36 -
drivers/gpu/drm/i915/i915_drv.c | 2 +-
include/drm/drm_file.h | 1 +
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 92d16724f949..e25306c49cc6 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -220,7 +220,7 @@ void drm_file_free(struct drm_file *file)
DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
task_pid_nr(current),
(long)old_encode_dev(file->minor->kdev->devt),
- dev->open_count);
+ READ_ONCE(dev->open_count));
if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
dev->driver->preclose)
@@ -455,6 +455,40 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
+/**
+ * drm_release_noglobal - release method for DRM file
+ * @inode: device inode
+ * @filp: file pointer.
+ *
+ * This function may be used by drivers as their &file_operations.release
+ * method. It frees any resources associated with the open file prior to taking
+ * the drm_global_mutex, which then calls the &drm_driver.postclose driver
+ * callback. If this is the last open file for the DRM device also proceeds to
+ * call the &drm_driver.lastclose driver callback.
+ *
+ * RETURNS:
+ *
+ * Always succeeds and returns 0.
+ */
+int drm_release_noglobal(struct inode *inode, struct file *filp)
+{
+ struct drm_file *file_priv = filp->private_data;
+ struct drm_minor *minor = file_priv->minor;
+ struct drm_device *dev = minor->dev;
+
+ drm_close_helper(filp);
+
+ mutex_lock(&drm_global_mutex);
+ if (!--dev->open_count)
+ drm_lastclose(dev);
+ mutex_unlock(&drm_global_mutex);
+
+ drm_minor_release(minor);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_release_noglobal);
+
/**
* drm_read - read method for DRM file
* @filp: file pointer
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9b42e962032..5a5846d892f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2673,7 +2673,7 @@ const struct dev_pm_ops i915_pm_ops = {
static const struct file_operations i915_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
- .release = drm_release,
+ .release = drm_release_noglobal,
.unlocked_ioctl = drm_ioctl,
.mmap = i915_gem_mmap,
.poll = drm_poll,
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 8b099b347817..19df8028a6c4 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -374,6 +374,7 @@ int drm_open(struct inode *inode, struct file *filp);
ssize_t drm_read(struct file *filp, char __user *buffer,
size_t count, loff_t *offset);
int drm_release(struct inode *inode, struct file *filp);
+int drm_release_noglobal(struct inode *inode, struct file *filp);
__poll_t drm_poll(struct file *filp, struct poll_table_struct *wait);
int drm_event_reserve_init_locked(struct drm_device *dev,
struct drm_file *file_priv,
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from 0. Here, we tackle the
easy portion of delaying acquiring the drm_global_mutex for the final
release by using atomic_dec_and_mutex_lock(), leaving the global
serialisation across the device opens.
Signed-off-by: Chris Wilson
Cc: Thomas Hellström (VMware)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_file.c | 14 ++
drivers/gpu/drm/i915/i915_switcheroo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
include/drm/drm_device.h | 2 +-
6 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 53d882000101..c3c0356dfa61 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1136,7 +1136,7 @@ static bool amdgpu_switcheroo_can_switch(struct pci_dev
*pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return dev->open_count == 0;
+ return atomic_read(&dev->open_count) == 0;
}
static const struct vga_switcheroo_client_ops amdgpu_switcheroo_ops = {
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e25306c49cc6..c4e9ef86c589 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -220,7 +220,7 @@ void drm_file_free(struct drm_file *file)
DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
task_pid_nr(current),
(long)old_encode_dev(file->minor->kdev->devt),
- READ_ONCE(dev->open_count));
+ atomic_read(&dev->open_count));
if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
dev->driver->preclose)
@@ -379,7 +379,7 @@ int drm_open(struct inode *inode, struct file *filp)
return PTR_ERR(minor);
dev = minor->dev;
- if (!dev->open_count++)
+ if (!atomic_fetch_inc(&dev->open_count))
need_setup = 1;
/* share address_space across all char-devs of a single device */
@@ -398,7 +398,7 @@ int drm_open(struct inode *inode, struct file *filp)
return 0;
err_undo:
- dev->open_count--;
+ atomic_dec(&dev->open_count);
drm_minor_release(minor);
return retcode;
}
@@ -440,11 +440,11 @@ int drm_release(struct inode *inode, struct file *filp)
mutex_lock(&drm_global_mutex);
- DRM_DEBUG("open_count = %d\n", dev->open_count);
+ DRM_DEBUG("open_count = %d\n", atomic_read(&dev->open_count));
drm_close_helper(filp);
- if (!--dev->open_count)
+ if (atomic_dec_and_test(&dev->open_count))
drm_lastclose(dev);
mutex_unlock(&drm_global_mutex);
@@ -478,10 +478,8 @@ int drm_release_noglobal(struct inode *inode, struct file
*filp)
drm_close_helper(filp);
- mutex_lock(&drm_global_mutex);
- if (!--dev->open_count)
+ if (atomic_dec_and_mutex_lock(&dev->open_count, &drm_global_mutex))
drm_lastclose(dev);
- mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
diff --git a/drivers/gpu/drm/i915/i915_switcheroo.c
b/drivers/gpu/drm/i915/i915_switcheroo.c
index 39c79e1c5b52..ed69b5d4a375 100644
--- a/drivers/gpu/drm/i915/i915_switcheroo.c
+++ b/drivers/gpu/drm/i915/i915_switcheroo.c
@@ -43,7 +43,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return i915 && i915->drm.open_count == 0;
+ return i915 && atomic_read(&i915->drm.open_count) == 0;
}
static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index d865d8aeac3c..c85dd8afa3c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -72,7 +72,7 @@ nouveau_switcheroo_can_switch(struct pci_dev *pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return dev->open_count == 0;
+ return atomic_read(&dev->open_count) == 0;
}
static const struct vga_switcheroo_client_ops
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index a522e092038b..266e3cbbd09b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/
[PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from 0. Here, we tackle the
easy portion of delaying acquiring the drm_global_mutex for the final
release by using atomic_dec_and_mutex_lock(), leaving the global
serialisation across the device opens.
Signed-off-by: Chris Wilson
Cc: Thomas Hellström (VMware)
---
atomic_dec_and_mutex_lock needs pairing with mutex_unlock (you fool)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_file.c | 16
drivers/gpu/drm/i915/i915_switcheroo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
include/drm/drm_device.h | 2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 53d882000101..c3c0356dfa61 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1136,7 +1136,7 @@ static bool amdgpu_switcheroo_can_switch(struct pci_dev
*pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return dev->open_count == 0;
+ return atomic_read(&dev->open_count) == 0;
}
static const struct vga_switcheroo_client_ops amdgpu_switcheroo_ops = {
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e25306c49cc6..1075b3a8b5b1 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -220,7 +220,7 @@ void drm_file_free(struct drm_file *file)
DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
task_pid_nr(current),
(long)old_encode_dev(file->minor->kdev->devt),
- READ_ONCE(dev->open_count));
+ atomic_read(&dev->open_count));
if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
dev->driver->preclose)
@@ -379,7 +379,7 @@ int drm_open(struct inode *inode, struct file *filp)
return PTR_ERR(minor);
dev = minor->dev;
- if (!dev->open_count++)
+ if (!atomic_fetch_inc(&dev->open_count))
need_setup = 1;
/* share address_space across all char-devs of a single device */
@@ -398,7 +398,7 @@ int drm_open(struct inode *inode, struct file *filp)
return 0;
err_undo:
- dev->open_count--;
+ atomic_dec(&dev->open_count);
drm_minor_release(minor);
return retcode;
}
@@ -440,11 +440,11 @@ int drm_release(struct inode *inode, struct file *filp)
mutex_lock(&drm_global_mutex);
- DRM_DEBUG("open_count = %d\n", dev->open_count);
+ DRM_DEBUG("open_count = %d\n", atomic_read(&dev->open_count));
drm_close_helper(filp);
- if (!--dev->open_count)
+ if (atomic_dec_and_test(&dev->open_count))
drm_lastclose(dev);
mutex_unlock(&drm_global_mutex);
@@ -478,10 +478,10 @@ int drm_release_noglobal(struct inode *inode, struct file
*filp)
drm_close_helper(filp);
- mutex_lock(&drm_global_mutex);
- if (!--dev->open_count)
+ if (atomic_dec_and_mutex_lock(&dev->open_count, &drm_global_mutex)) {
drm_lastclose(dev);
- mutex_unlock(&drm_global_mutex);
+ mutex_unlock(&drm_global_mutex);
+ }
drm_minor_release(minor);
diff --git a/drivers/gpu/drm/i915/i915_switcheroo.c
b/drivers/gpu/drm/i915/i915_switcheroo.c
index 39c79e1c5b52..ed69b5d4a375 100644
--- a/drivers/gpu/drm/i915/i915_switcheroo.c
+++ b/drivers/gpu/drm/i915/i915_switcheroo.c
@@ -43,7 +43,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return i915 && i915->drm.open_count == 0;
+ return i915 && atomic_read(&i915->drm.open_count) == 0;
}
static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index d865d8aeac3c..c85dd8afa3c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -72,7 +72,7 @@ nouveau_switcheroo_can_switch(struct pci_dev *pdev)
* locking inversion with the driver load path. And the access here is
* completely racy anyway. So don't bother with locking for now.
*/
- return dev->open_count == 0;
+ return atomic_read(&dev->open_count) == 0;
}
static const struct vga_switcheroo_client_ops
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/
Re: [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
On 1/24/20 2:01 PM, Chris Wilson wrote: Since drm_global_mutex is a true global mutex across devices, we don't want to acquire it unless absolutely necessary. For maintaining the device local open_count, we can use atomic operations on the counter itself, except when making the transition to/from 0. Here, we tackle the easy portion of delaying acquiring the drm_global_mutex for the final release by using atomic_dec_and_mutex_lock(), leaving the global serialisation across the device opens. Signed-off-by: Chris Wilson Cc: Thomas Hellström (VMware) For the series: Reviewed-by: Thomas Hellström Now the only remaining (though pre-existing) problem I can see is that there is no corresponding mutex lock in drm_open() so that firstopen might race with lastclose.. Or I might be missing something.. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47) > On 1/24/20 2:01 PM, Chris Wilson wrote: > > Since drm_global_mutex is a true global mutex across devices, we don't > > want to acquire it unless absolutely necessary. For maintaining the > > device local open_count, we can use atomic operations on the counter > > itself, except when making the transition to/from 0. Here, we tackle the > > easy portion of delaying acquiring the drm_global_mutex for the final > > release by using atomic_dec_and_mutex_lock(), leaving the global > > serialisation across the device opens. > > > > Signed-off-by: Chris Wilson > > Cc: Thomas Hellström (VMware) > > For the series: > > Reviewed-by: Thomas Hellström > > Now the only remaining (though pre-existing) problem I can see is that > there is no corresponding mutex lock in drm_open() so that firstopen > might race with lastclose.. Or I might be missing something.. iirc, it's a complicated dance where it goes through drm_stub_open() first which acquires the drm_global_mutex. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #39 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) --- I did different tests and there is a real bug. With Dirt Rally in ultra, if I use 8mxsaa, I have miserable performance. If I set 0mxsaa in game, the performance is + ~60 fps. If I reactivate the 8mxsaa, the performances are very good between ~50 and ~70 fps. This is not normal. With the game Dawn of War II, the framerate is ~48 fps in ultra, high, normal, low. It is really very strange. I noticed that the performances are good after a big lag. This was the case with Dirt Rally, on a race, the game freeze for a few seconds then suddenly, the game run with than ~ 60fps. In the game Dead or Alive 5 (Proton), the performances were from ~ 40 to ~ 50fps. After a lag, the game worked very well at 60fps contant. -- 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 v2 2/2] drm/bridge: Add tc358768 driver
On 24.01.2020 11:55, Peter Ujfalusi wrote: > Add basic support for the Toshiba TC358768 RGB to DSI bridge. > Not all the features of the TC358768 is implemented by the initial driver: > MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested. > > Only write is implemented for mipi_dsi_host_ops.transfer. > > Signed-off-by: Peter Ujfalusi > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/tc358768.c | 992 ++ > 3 files changed, 1003 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/tc358768.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 0b9ca5862455..3fef3513bdd0 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767 > ---help--- > Toshiba TC358767 eDP bridge chip driver. > > +config DRM_TOSHIBA_TC358768 > + tristate "Toshiba TC358768 MIPI DSI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + select DRM_MIPI_DSI > + help > + Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > + > config DRM_TI_TFP410 > tristate "TI TFP410 DVI/HDMI bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index cd16ce830270..06fc265de0ef 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > +obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > diff --git a/drivers/gpu/drm/bridge/tc358768.c > b/drivers/gpu/drm/bridge/tc358768.c > new file mode 100644 > index ..5e12b1390254 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/tc358768.c > @@ -0,0 +1,992 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com > + * Author: Peter Ujfalusi > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Global (16-bit addressable) */ > +#define TC358768_CHIPID 0x > +#define TC358768_SYSCTL 0x0002 > +#define TC358768_CONFCTL 0x0004 > +#define TC358768_VSDLY 0x0006 > +#define TC358768_DATAFMT 0x0008 > +#define TC358768_GPIOEN 0x000E > +#define TC358768_GPIODIR 0x0010 > +#define TC358768_GPIOIN 0x0012 > +#define TC358768_GPIOOUT 0x0014 > +#define TC358768_PLLCTL0 0x0016 > +#define TC358768_PLLCTL1 0x0018 > +#define TC358768_CMDBYTE 0x0022 > +#define TC358768_PP_MISC 0x0032 > +#define TC358768_DSITX_DT0x0050 > +#define TC358768_FIFOSTATUS 0x00F8 > + > +/* Debug (16-bit addressable) */ > +#define TC358768_VBUFCTRL0x00E0 > +#define TC358768_DBG_WIDTH 0x00E2 > +#define TC358768_DBG_VBLANK 0x00E4 > +#define TC358768_DBG_DATA0x00E8 > + > +/* TX PHY (32-bit addressable) */ > +#define TC358768_CLW_DPHYCONTTX 0x0100 > +#define TC358768_D0W_DPHYCONTTX 0x0104 > +#define TC358768_D1W_DPHYCONTTX 0x0108 > +#define TC358768_D2W_DPHYCONTTX 0x010C > +#define TC358768_D3W_DPHYCONTTX 0x0110 > +#define TC358768_CLW_CNTRL 0x0140 > +#define TC358768_D0W_CNTRL 0x0144 > +#define TC358768_D1W_CNTRL 0x0148 > +#define TC358768_D2W_CNTRL 0x014C > +#define TC358768_D3W_CNTRL 0x0150 > + > +/* TX PPI (32-bit addressable) */ > +#define TC358768_STARTCNTRL 0x0204 > +#define TC358768_DSITXSTATUS 0x0208 > +#define TC358768_LINEINITCNT 0x0210 > +#define TC358768_LPTXTIMECNT 0x0214 > +#define TC358768_TCLK_HEADERCNT 0x0218 > +#define TC358768_TCLK_TRAILCNT 0x021C > +#define TC358768_THS_HEADERCNT 0x0220 > +#define TC358768_TWAKEUP 0x0224 > +#define TC358768_TCLK_POSTCNT0x0228 > +#define TC358768_THS_TRAILCNT0x022C > +#define TC358768_HSTXVREGCNT 0x0230 > +#define TC358768_HSTXVREGEN 0x0234 > +#define TC358768_TXOPTIONCNTRL 0x0238 > +#define TC358768_BTACNTRL1 0x023C > + > +/* TX CTRL (32-bit addressable) */ > +#define TC358768_DSI_CONTROL 0x040C > +#define TC358768_DSI_STATU
TTM/Nouveau cleanups
Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/ttm: remove io_reserve_lru handling
From: Christian König
That is not used any more.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++--
include/drm/ttm/ttm_bo_api.h | 5 --
include/drm/ttm/ttm_bo_driver.h | 5 --
5 files changed, 20 insertions(+), 174 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1fbc36f05d89..568329e517d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -311,13 +311,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
int ret = 0;
if (old_is_pci || new_is_pci ||
- ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
- ret = ttm_mem_io_lock(old_man, true);
- if (unlikely(ret != 0))
- goto out_err;
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(old_man);
- }
+ ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0))
+ ttm_bo_unmap_virtual(bo);
/*
* Create and bind a ttm if required.
@@ -646,15 +641,12 @@ static void ttm_bo_release(struct kref *kref)
struct ttm_buffer_object *bo =
container_of(kref, struct ttm_buffer_object, kref);
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_mem_type_manager *man = &bdev->man[bo->mem.mem_type];
if (bo->bdev->driver->release_notify)
bo->bdev->driver->release_notify(bo);
drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
- ttm_mem_io_lock(man, false);
- ttm_mem_io_free_vm(bo);
- ttm_mem_io_unlock(man);
+ ttm_mem_io_free(bdev, &bo->mem);
ttm_bo_cleanup_refs_or_queue(bo);
kref_put(&bo->list_kref, ttm_bo_release_list);
}
@@ -703,8 +695,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved_vm = false;
- evict_mem.bus.io_reserved_count = 0;
+ evict_mem.bus.base = 0;
ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx);
if (ret) {
@@ -1155,8 +1146,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
mem.num_pages = bo->num_pages;
mem.size = mem.num_pages << PAGE_SHIFT;
mem.page_alignment = bo->mem.page_alignment;
- mem.bus.io_reserved_vm = false;
- mem.bus.io_reserved_count = 0;
+ mem.bus.base = 0;
/*
* Determine where to move the buffer.
*/
@@ -1301,8 +1291,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
- bo->mem.bus.io_reserved_vm = false;
- bo->mem.bus.io_reserved_count = 0;
+ bo->mem.bus.base = 0;
bo->moving = NULL;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
bo->acc_size = acc_size;
@@ -1748,22 +1737,12 @@ bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
return true;
}
-void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo)
-{
- struct ttm_bo_device *bdev = bo->bdev;
-
- drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
- ttm_mem_io_free_vm(bo);
-}
-
void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_mem_type_manager *man = &bdev->man[bo->mem.mem_type];
- ttm_mem_io_lock(man, false);
- ttm_bo_unmap_virtual_locked(bo);
- ttm_mem_io_unlock(man);
+ drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
+ ttm_mem_io_free(bdev, &bo->mem);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2b0e5a088da0..ace31ad65997 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,124 +91,30 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_ttm);
-int ttm_mem_io_lock(struct ttm_mem_type_manager *man, bool interruptible)
-{
- if (likely(man->io_reserve_fastpath))
- return 0;
-
- if (interruptible)
- return mutex_lock_interruptible(&man->io_reserve_mutex);
-
- mutex_lock(&man->io_reserve_mutex);
- return 0;
-}
-
-void ttm_mem_io_unlock(struct ttm_mem_type_manager *man)
-{
- if (likely(man->io_reserve_fastpath))
- return;
-
- mutex_unlock(&man->io_reserve_mutex);
-}
-
-static int ttm_mem_io_evict(struct ttm_mem_type_manager *man)
-{
- struct ttm_buffer_object *bo;
-
- if (!man->use_io_reserve_lru || list_empty(&man->io_reserve_lru))
- return -EAGAIN;
-
- bo = list_first_entry(&man->io_reserve_lru,
-
[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch should be functional correct, but is only compile tested!
v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 107 --
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 43 ++-
4 files changed, 131 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 81668104595f..acee054f77ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -137,6 +137,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct nouveau_bo *nvbo = nouveau_bo(bo);
WARN_ON(nvbo->pin_refcnt > 0);
+ nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
/*
@@ -304,6 +305,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 flags,
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
+ INIT_LIST_HEAD(&nvbo->io_reserve_lru);
ret = ttm_bo_init(nvbo->bo.bdev, &nvbo->bo, size, type,
&nvbo->placement, align >> PAGE_SHIFT, false,
@@ -574,6 +576,26 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
}
+void nouveau_bo_add_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+ mutex_lock(&drm->ttm.io_reserve_mutex);
+ list_move_tail(&nvbo->io_reserve_lru, &drm->ttm.io_reserve_lru);
+ mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
+void nouveau_bo_del_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+ mutex_lock(&drm->ttm.io_reserve_mutex);
+ list_del_init(&nvbo->io_reserve_lru);
+ mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -675,8 +697,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
}
man->func = &nouveau_vram_manager;
- man->io_reserve_fastpath = false;
- man->use_io_reserve_lru = true;
} else {
man->func = &ttm_bo_manager_func;
}
@@ -1305,6 +1325,8 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool
evict,
if (bo->destroy != nouveau_bo_del_ttm)
return;
+ nouveau_bo_del_io_reserve_lru(bo);
+
if (mem && new_reg->mem_type != TTM_PL_SYSTEM &&
mem->mem.page == nvbo->page) {
list_for_each_entry(vma, &nvbo->vma_list, head) {
@@ -1427,6 +1449,30 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
filp->private_data);
}
+static void
+nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm, struct ttm_mem_reg
*reg)
+{
+ struct nouveau_mem *mem = nouveau_mem(reg);
+
+ if (!reg->bus.base)
+ return; /* already freed */
+
+ if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
+ switch (reg->mem_type) {
+ case TTM_PL_TT:
+ if (mem->kind)
+ nvif_object_unmap_handle(&mem->mem.object);
+ break;
+ case TTM_PL_VRAM:
+ nvif_object_unmap_handle(&mem->mem.object);
+ break;
+ default:
+ break;
+ }
+ }
+ reg->bus.base = 0;
+}
+
static int
nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *reg)
{
@@ -1434,18 +1480,26 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *reg)
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct nvkm_device *device = nvxx_device(&drm->client.device);
struct nouveau_mem *mem = nouveau_mem(reg);
+ struct nouveau_bo *nvbo;
+ int ret;
+
+ if (reg->bus.base)
+ return 0; /* already mapped */
reg->bus.addr = NULL;
reg->bus.offset = 0;
reg->bus.size = reg->num_pages << PAGE_SHIFT;
- reg->bus.base = 0;
reg->bus.is_iomem = false;
if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Thu, Jan 23, 2020 at 02:40:45PM -0800, Abhinav Kumar wrote:
> From: Uma Shankar
>
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
Why?
>
> This was posted by Uma Shankar at
> https://patchwork.kernel.org/patch/10861327/
>
> Modified by Abhinav Kumar:
> - Use macros to distinguish the bit fields for clarity
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/drm_edid.c | 54
> +
> include/drm/drm_connector.h | 3 +++
> include/drm/drm_edid.h | 11 +
> 3 files changed, 68 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6..148bfa4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3136,6 +3136,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> @@ -4199,6 +4200,57 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> +{
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 2)
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8
> *db)
> +{
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> +
> + /* As per CEA 861-G spec */
> + /* Byte 3 Bit 0: xvYCC_601 */
> + if (db[2] & BIT(0))
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> + /* Byte 3 Bit 1: xvYCC_709 */
> + if (db[2] & BIT(1))
> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> + /* Byte 3 Bit 2: sYCC_601 */
> + if (db[2] & BIT(2))
> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> + /* Byte 3 Bit 3: ADBYCC_601 */
> + if (db[2] & BIT(3))
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> + /* Byte 3 Bit 4: ADB_RGB */
> + if (db[2] & BIT(4))
> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> + /* Byte 3 Bit 5: BT2020_CYCC */
> + if (db[2] & BIT(5))
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> + /* Byte 3 Bit 6: BT2020_YCC */
> + if (db[2] & BIT(6))
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> + /* Byte 3 Bit 7: BT2020_RGB */
> + if (db[2] & BIT(7))
> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> + /* Byte 4 Bit 7: DCI-P3 */
> + if (db[3] & BIT(7))
> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> +
> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> +}
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -4877,6 +4929,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 2219109..a996ee3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
> };
>
> /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index f0b03d4..6168c1c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -224,6 +224,17 @@ struct detailed_timing {
> DRM_EDID_YCBCR420_DC_36 | \
> DRM_EDID_YCBCR420_DC_30)
>
> +/* Supported Colorimetry from colorimetry data block */
> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
> +#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
> +#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
> +
> /* ELD Heade
Re: [PATCH v2 2/2] drm/bridge: Add tc358768 driver
Hi Andrzej,
On 24/01/2020 16.27, Andrzej Hajda wrote:
>> +static void tc358768_write(struct tc358768_priv *priv, u32 reg, u32 val)
>> +{
>> +size_t count = 2;
>> +
>> +if (priv->error)
>> +return;
>> +
>> +/* 16-bit register? */
>> +if (reg < 0x100 || reg >= 0x600)
>> +count = 1;
>> +
>> +priv->error = regmap_bulk_write(priv->regmap, reg, &val, count);
>
>
> Maybe it would be good to log possible error here and after regmap*read,
> to have more precise info, unless such log is provided already by
> regmap, up to you.
Regmap will tell us if a transfer fail when debugging is enabled.
>> +}
>> +
>> +static void tc358768_read(struct tc358768_priv *priv, u32 reg, u32 *val)
>> +{
>> +size_t count = 2;
>> +
>> +if (priv->error)
>> +return;
>> +
>> +/* 16-bit register? */
>> +if (reg < 0x100 || reg >= 0x600) {
>> +*val = 0;
>> +count = 1;
>> +}
>> +
>> +priv->error = regmap_bulk_read(priv->regmap, reg, val, count);
>> +}
>> +
>> +static void tc358768_update_bits(struct tc358768_priv *priv, u32 reg, u32
>> mask,
>> + u32 val)
>> +{
>> +u32 tmp, orig;
>> +
>> +tc358768_read(priv, reg, &orig);
>> +tmp = orig & ~mask;
>> +tmp |= val & mask;
>> +if (tmp != orig)
>> +tc358768_write(priv, reg, tmp);
>> +}
>> +
>> +static int tc358768_sw_reset(struct tc358768_priv *priv)
>> +{
>> +/* Assert Reset */
>> +tc358768_write(priv, TC358768_SYSCTL, 1);
>> +/* Release Reset, Exit Sleep */
>> +tc358768_write(priv, TC358768_SYSCTL, 0);
>> +
>> +return tc358768_clear_error(priv);
>> +}
>> +
>> +static void tc358768_hw_enable(struct tc358768_priv *priv)
>> +{
>> +int ret;
>> +
>> +if (priv->enabled++ > 0)
>> +return;
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(priv->supplies), priv->supplies);
>> +if (ret < 0)
>> +dev_err(priv->dev, "error enabling regulators (%d)\n", ret);
>> +
>> +if (priv->reset_gpio)
>> +usleep_range(200, 300);
>> +
>> +/*
>> + * The RESX is active low (GPIO_ACTIVE_LOW).
>> + * DEASSERT (value = 0) the reset_gpio to enable the chip
>> + */
>> +gpiod_set_value_cansleep(priv->reset_gpio, 0);
>> +
>> +/* wait for encoder clocks to stabilize */
>> +usleep_range(1000, 2000);
>> +}
>> +
>> +static void tc358768_hw_disable(struct tc358768_priv *priv)
>> +{
>> +int ret;
>> +
>> +if (--priv->enabled != 0)
>> +return;
>> +
>> +/*
>> + * The RESX is active low (GPIO_ACTIVE_LOW).
>> + * ASSERT (value = 1) the reset_gpio to disable the chip
>> + */
>> +gpiod_set_value_cansleep(priv->reset_gpio, 1);
>> +
>> +ret = regulator_bulk_disable(ARRAY_SIZE(priv->supplies),
>> + priv->supplies);
>> +if (ret < 0)
>> +dev_err(priv->dev, "error disabling regulators (%d)\n", ret);
>> +}
>> +
>> +static u32 tc358768_pll_to_pclk(struct tc358768_priv *priv, u32 pll_clk)
>> +{
>> +return (u32)div_u64((u64)pll_clk * priv->dsi_lanes, priv->pd_lines);
>> +}
>> +
>> +static u32 tc358768_pclk_to_pll(struct tc358768_priv *priv, u32 pclk)
>> +{
>> +return (u32)div_u64((u64)pclk * priv->pd_lines, priv->dsi_lanes);
>> +}
>> +
>> +static int tc358768_calc_pll(struct tc358768_priv *priv,
>> + const struct drm_display_mode *mode,
>> + bool verify_only)
>> +{
>> +const u32 frs_limits[] = {
>> +10,
>> +5,
>> +25000,
>> +12500,
>> +6250
>> +};
>> +unsigned long refclk;
>> +u32 prd, target_pll, i, max_pll, min_pll;
>> +u32 frs, best_diff, best_pll, best_prd, best_fbd;
>> +
>> +target_pll = tc358768_pclk_to_pll(priv, mode->clock * 1000);
>> +
>> +/* pll_clk = RefClk * [(FBD + 1)/ (PRD + 1)] * [1 / (2^FRS)] */
>> +
>> +for (i = 0; i < ARRAY_SIZE(frs_limits); i++)
>> +if (target_pll >= frs_limits[i])
>> +break;
>> +
>> +if (i == ARRAY_SIZE(frs_limits) || i == 0)
>> +return -EINVAL;
>> +
>> +frs = i - 1;
>> +max_pll = frs_limits[i - 1];
>> +min_pll = frs_limits[i];
>> +
>> +refclk = clk_get_rate(priv->refclk);
>> +
>> +best_diff = UINT_MAX;
>> +best_pll = 0;
>> +best_prd = 0;
>> +best_fbd = 0;
>> +
>> +for (prd = 0; prd < 16; ++prd) {
>> +u32 divisor = (prd + 1) * (1 << frs);
>> +u32 fbd;
>> +
>> +for (fbd = 0; fbd < 512; ++fbd) {
>> +u32 pll, diff;
>> +
>> +pll = (u32)div_u64((u64)refclk * (fbd + 1), divisor);
>> +
>> +if (pll >= max_pll || pll < min_pll)
>> +continue;
>> +
>> +diff = max(pll, target_pll) - min(pll, target_pll);
>> +
>> +if (diff < best_diff) {
>> +
Re: [PATCH] drm/amdgpu: Stop using the DRIVER debugging flag for vblank debugging messages
On 2020-01-23 8:07 p.m., Lyude Paul wrote:
> These are some very loud debug statements that get printed on every
> vblank when driver level debug printing is enabled in DRM, and doesn't
> really tell us anything that isn't related to vblanks. So let's move
> this over to the proper debug flag to be a little less spammy with our
> debug output.
>
> Signed-off-by: Lyude Paul
Thanks. Great change.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 9402374d2466..3675e1c32707 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -407,8 +407,9 @@ static void dm_vupdate_high_irq(void *interrupt_params)
> if (acrtc) {
> acrtc_state = to_dm_crtc_state(acrtc->base.state);
>
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> - amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n",
> + acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
>
> /* Core vblank handling is done here after end of front-porch in
>* vrr mode, as vblank timestamping will give valid results
> @@ -458,8 +459,9 @@ static void dm_crtc_high_irq(void *interrupt_params)
> if (acrtc) {
> acrtc_state = to_dm_crtc_state(acrtc->base.state);
>
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> - amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n",
> + acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
>
> /* Core vblank handling at start of front-porch is only possible
>* in non-vrr mode, as only there vblank timestamping will give
> @@ -522,8 +524,8 @@ static void dm_dcn_crtc_high_irq(void *interrupt_params)
>
> acrtc_state = to_dm_crtc_state(acrtc->base.state);
>
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> - amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> + amdgpu_dm_vrr_active(acrtc_state));
>
> amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
> drm_crtc_handle_vblank(&acrtc->base);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #40 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- Yep. this looks like a real critical software and/or hardware bug. Like the one you did show it the tomb raider vid. If you could reproduce with a free game, that would be better for the amd devs. I'll fool around a bit more with dirt rally (don't forget to restart the game each time you change the settings...) -- 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: [Bug 206231] R9 280X low performance with all games
Yep. this looks like a real critical software and/or hardware bug. Like the one you did show it the tomb raider vid. If you could reproduce with a free game, that would be better for the amd devs. I'll fool around a bit more with dirt rally (don't forget to restart the game each time you change the settings...) -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable
On 2020-01-23 7:06 p.m., Lyude Paul wrote: > Disabling a display on MST can potentially happen after the entire MST > topology has been removed, which means that we can't communicate with > the topology at all in this scenario. Likewise, this also means that we > can't properly update payloads on the topology and as such, it's a good > idea to ignore payload update failures when disabling displays. > Currently, amdgpu makes the mistake of halting the payload update > process when any payload update failures occur, resulting in leaving > DC's local copies of the payload tables out of date. > > This ends up causing problems with hotplugging MST topologies, and > causes modesets on the second hotplug to fail like so: > > [drm] Failed to updateMST allocation table forpipe idx:1 > [ cut here ] > WARNING: CPU: 5 PID: 1511 at > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc > vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic > snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm > sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd > wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) > rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm > drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm > crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core > rtsx_pci pinctrl_amd > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O > 5.5.0-rc7Lyude-Test+ #4 > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 > 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 > RSP: 0018:ac428127f5b0 EFLAGS: 00010202 > RAX: 0002 RBX: 8d1e166eee80 RCX: > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 > RBP: ac428127f640 R08: c03d94a8 R09: > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 > R13: 8d1e1bea0b08 R14: 0002 R15: 0002 > FS: 7fab23ffcd80() GS:8d1e28b4() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 > Call Trace: > ? mutex_lock+0xe/0x30 > dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] > ? dm_read_reg_func+0x39/0xb0 [amdgpu] > ? core_link_enable_stream+0x656/0x730 [amdgpu] > core_link_enable_stream+0x656/0x730 [amdgpu] > dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] > ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] > ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] > dc_commit_state+0x292/0x770 [amdgpu] > ? add_timer+0x101/0x1f0 > ? ttm_bo_put+0x1a1/0x2f0 [ttm] > amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] > ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] > ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] > ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] > ? ttm_bo_validate+0x134/0x150 [ttm] > ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] > ? _cond_resched+0x15/0x30 > ? wait_for_completion_timeout+0x38/0x160 > ? _cond_resched+0x15/0x30 > ? wait_for_completion_interruptible+0x33/0x190 > commit_tail+0x94/0x130 [drm_kms_helper] > drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] > drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] > drm_mode_setcrtc+0x194/0x6a0 [drm] > ? _cond_resched+0x15/0x30 > ? mutex_lock+0xe/0x30 > ? drm_mode_getcrtc+0x180/0x180 [drm] > drm_ioctl_kernel+0xaa/0xf0 [drm] > drm_ioctl+0x208/0x390 [drm] > ? drm_mode_getcrtc+0x180/0x180 [drm] > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > do_vfs_ioctl+0x458/0x6d0 > ksys_ioctl+0x5e/0x90 > __x64_sys_ioctl+0x16/0x20 > do_syscall_64+0x55/0x1b0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7fab2121f87b > Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff > ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 > f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 > RSP: 002b:7ffd045f9068 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffd045f90a0 RCX: 7fab2121f87b > RDX: 7ffd045f90a0 RSI: c06864a2 RDI: 000b > RBP: 7ffd045f90a0 R08: R09: 55dbd2985d10 > R10: 55dbd2196280 R11: 0246 R
Re: [Freedreno] [PATCH] drm/msm/a6xx: Correct the highestbank configuration
On Fri, Jan 24, 2020 at 5:50 AM Akhil P Oommen wrote:
>
> Highest bank bit configuration is different for a618 gpu. Update
> it with the correct configuration which is the reset value incidentally.
>
> Signed-off-by: Akhil P Oommen
> Signed-off-by: Sharat Masetty
Thanks, this fixes the UBWC issues on a618
Fixes: e812744c5f95 ("drm: msm: a6xx: Add support for A618")
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index daf0780..536d196 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -470,10 +470,12 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> /* Select CP0 to always count cycles */
> gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
>
> - gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
> + if (adreno_is_a630(adreno_gpu)) {
> + gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
> + }
>
> /* Enable fault detection */
> gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL,
> --
> 2.7.4
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #41 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) --- The core version of Dead or Alive 5 is free : https://store.steampowered.com/app/311730/DEAD_OR_ALIVE_5_Last_Round_Core_Fighters/ The game works well, but as I reported, the framerate is very low during the first few minutes of play. I don't know if this is a problem with Proton or Mesa. I keep looking for free or popular Linux games, but there isn't much. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 01/12] drm/bridge: Add a drm_bridge_state object
On 23/01/2020 10:53, Boris Brezillon wrote:
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding a new
> drm_bridge_state object inheriting from drm_private_obj so we can
> re-use some of the existing state initialization/tracking logic.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Neil Armstrong
> ---
> Changes in v8:
> * Move bridge state helpers out of the CONFIG_DEBUGFS section
>
> Changes in v7:
> * Move helpers, struct-defs, ... to atomic helper files to avoid the
> drm -> drm_kms_helper -> drm circular dep
> * Stop providing default implementation for atomic state reset,
> duplicate and destroy hooks (has to do with the helper/core split)
> * Drop all R-b/T-b as helpers have now be moved to other places
> ---
> drivers/gpu/drm/drm_atomic.c | 116 +++
> drivers/gpu/drm/drm_atomic_helper.c | 20
> drivers/gpu/drm/drm_atomic_state_helper.c | 131 ++
> drivers/gpu/drm/drm_bridge.c | 29 -
> include/drm/drm_atomic.h | 34 ++
> include/drm/drm_atomic_state_helper.h | 13 +++
> include/drm/drm_bridge.h | 53 +
> 7 files changed, 391 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d33691512a8e..85f8d2218a94 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1017,6 +1018,121 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> connector->funcs->atomic_print_state(p, state);
> }
>
> +/**
> + * drm_atomic_get_bridge_state - get bridge state
> + * @state: global atomic state object
> + * @bridge: bridge to get state object for
> + *
> + * This function returns the bridge state for the given bridge, allocating it
> + * if needed. It will also grab the relevant bridge lock to make sure that
> the
> + * state is consistent.
> + *
> + * Returns:
> + *
> + * Either the allocated state or the error code encoded into the pointer.
> When
> + * the error is EDEADLK then the w/w mutex code has detected a deadlock and
> the
> + * entire atomic sequence must be restarted.
> + */
> +struct drm_bridge_state *
> +drm_atomic_get_bridge_state(struct drm_atomic_state *state,
> + struct drm_bridge *bridge)
> +{
> + struct drm_private_state *obj_state;
> +
> + obj_state = drm_atomic_get_private_obj_state(state, &bridge->base);
> + if (IS_ERR(obj_state))
> + return ERR_CAST(obj_state);
> +
> + return drm_priv_to_bridge_state(obj_state);
> +}
> +EXPORT_SYMBOL(drm_atomic_get_bridge_state);
> +
> +/**
> + * drm_atomic_get_old_bridge_state - get old bridge state, if it exists
> + * @state: global atomic state object
> + * @bridge: bridge to grab
> + *
> + * This function returns the old bridge state for the given bridge, or NULL
> if
> + * the bridge is not part of the global atomic state.
> + */
> +struct drm_bridge_state *
> +drm_atomic_get_old_bridge_state(struct drm_atomic_state *state,
> + struct drm_bridge *bridge)
> +{
> + struct drm_private_state *obj_state;
> +
> + obj_state = drm_atomic_get_old_private_obj_state(state, &bridge->base);
> + if (!obj_state)
> + return NULL;
> +
> + return drm_priv_to_bridge_state(obj_state);
> +}
> +EXPORT_SYMBOL(drm_atomic_get_old_bridge_state);
> +
> +/**
> + * drm_atomic_get_new_bridge_state - get new bridge state, if it exists
> + * @state: global atomic state object
> + * @bridge: bridge to grab
> + *
> + * This function returns the new bridge state for the given bridge, or NULL
> if
> + * the bridge is not part of the global atomic state.
> + */
> +struct drm_bridge_state *
> +drm_atomic_get_new_bridge_state(struct drm_atomic_state *state,
> + struct drm_bridge *bridge)
> +{
> + struct drm_private_state *obj_state;
> +
> + obj_state = drm_atomic_get_new_private_obj_state(state, &bridge->base);
> + if (!obj_state)
> + return NULL;
> +
> + return drm_priv_to_bridge_state(obj_state);
> +}
> +EXPORT_SYMBOL(drm_atomic_get_new_bridge_state);
> +
> +/**
> + * drm_atomic_add_encoder_bridges - add bridges attached to an encoder
> + * @state: atomic state
> + * @encoder: DRM encoder
> + *
> + * This function adds all bridges attached to @encoder. This is needed to add
> + * bridge states to @state and make them available when
> + * &bridge_funcs.atomic_{check,pre_enable,enable,disable_post_disable}() are
> + * called
> + *
> + * Returns:
> + * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is
> EDEADLK
> + * then the w/w mutex cod
Re: [PATCH v8 04/12] drm/bridge: analogix: Plug atomic state hooks to the default implementation
On 23/01/2020 10:53, Boris Brezillon wrote:
> This is needed to pass a bridge state to all atomic hooks, if we don't
> do that, the core can't duplicate/create bridge states.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v7:
> * New patch
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 6fab71985cd4..dfb59a5fefea 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1570,6 +1570,9 @@ static void analogix_dp_bridge_mode_set(struct
> drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> .atomic_pre_enable = analogix_dp_bridge_atomic_pre_enable,
> .atomic_enable = analogix_dp_bridge_atomic_enable,
> .atomic_disable = analogix_dp_bridge_atomic_disable,
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 10/12] drm/bridge: panel: Propage bus format/flags
On 23/01/2020 10:53, Boris Brezillon wrote:
> So that the previous bridge element in the chain knows which input
> format the panel bridge expects.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v7:
> * Set atomic state hooks explicitly
>
> Changes in v3:
> * Adjust things to match the new bus-format negotiation approach
> * Use drm_atomic_helper_bridge_propagate_bus_fmt
> * Don't implement ->atomic_check() (the core now takes care of bus
> flags propagation)
>
> Changes in v2:
> * Adjust things to match the new bus-format negotiation approach
> ---
> drivers/gpu/drm/bridge/panel.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index f66777e24968..dcc72bd7df30 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -127,6 +127,10 @@ static const struct drm_bridge_funcs
> panel_bridge_bridge_funcs = {
> .enable = panel_bridge_enable,
> .disable = panel_bridge_disable,
> .post_disable = panel_bridge_post_disable,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
> };
>
> /**
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
WOW: I did reproduce with dirt rally. I could not see it because the game must not be restarted to "uncripple" the renderer. I used the number or rendered frames and I go from an horrible 3000-5000 frames to a wooping 11000 frames, not to mention the game is now ~playable to max/ultra settings. I had to run 2 times in a row the benchmark to "uncripple" the renderer, or fool around with the msaa settings (without restarting). And I get ~11000 frames with msaax8 or msaaoff (and I can clearly see when it is on or off). Since you can reproduce with other games-->Yep, it is very probably a set driver/weird hardware critical bugs (modulo the numerous visual glitches and gpu vm faults). @alex: this one is nasty and probably will ruin the gaming experience (and benchmarks!) on many games. (@Jacques: Proton games do not do. Only native GL and/or vulkan, that to remove any proton bugs) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #42 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- WOW: I did reproduce with dirt rally. I could not see it because the game must not be restarted to "uncripple" the renderer. I used the number or rendered frames and I go from an horrible 3000-5000 frames to a wooping 11000 frames, not to mention the game is now ~playable to max/ultra settings. I had to run 2 times in a row the benchmark to "uncripple" the renderer, or fool around with the msaa settings (without restarting). And I get ~11000 frames with msaax8 or msaaoff (and I can clearly see when it is on or off). Since you can reproduce with other games-->Yep, it is very probably a set driver/weird hardware critical bugs (modulo the numerous visual glitches and gpu vm faults). @alex: this one is nasty and probably will ruin the gaming experience (and benchmarks!) on many games. (@Jacques: Proton games do not do. Only native GL and/or vulkan, that to remove any proton bugs) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 10/12] drm/bridge: panel: Propage bus format/flags
On Thu, Jan 23, 2020 at 10:53:31AM +0100, Boris Brezillon wrote:
> So that the previous bridge element in the chain knows which input
> format the panel bridge expects.
>
> Signed-off-by: Boris Brezillon
Subject: [PATCH v8 10/12] drm/bridge: panel: Propage bus format/flags
s/Propage/Propagate/
?
Sam
> ---
> Changes in v7:
> * Set atomic state hooks explicitly
>
> Changes in v3:
> * Adjust things to match the new bus-format negotiation approach
> * Use drm_atomic_helper_bridge_propagate_bus_fmt
> * Don't implement ->atomic_check() (the core now takes care of bus
> flags propagation)
>
> Changes in v2:
> * Adjust things to match the new bus-format negotiation approach
> ---
> drivers/gpu/drm/bridge/panel.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index f66777e24968..dcc72bd7df30 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -127,6 +127,10 @@ static const struct drm_bridge_funcs
> panel_bridge_bridge_funcs = {
> .enable = panel_bridge_enable,
> .disable = panel_bridge_disable,
> .post_disable = panel_bridge_post_disable,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
> };
>
> /**
> --
> 2.24.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 v8 10/12] drm/bridge: panel: Propage bus format/flags
On Fri, 24 Jan 2020 17:25:50 +0100 Sam Ravnborg wrote: > On Thu, Jan 23, 2020 at 10:53:31AM +0100, Boris Brezillon wrote: > > So that the previous bridge element in the chain knows which input > > format the panel bridge expects. > > > > Signed-off-by: Boris Brezillon > > Subject: [PATCH v8 10/12] drm/bridge: panel: Propage bus format/flags > s/Propage/Propagate/ > ? > Oops. I'll fix it when applying, unless there are other things to fix in the v8. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable
On 1/24/20 9:55 AM, Harry Wentland wrote: On 2020-01-23 7:06 p.m., Lyude Paul wrote: Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 [ cut here ] WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ac428127f5b0 EFLAGS: 00010202 RAX: 0002 RBX: 8d1e166eee80 RCX: RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 RBP: ac428127f640 R08: c03d94a8 R09: R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 R13: 8d1e1bea0b08 R14: 0002 R15: 0002 FS: 7fab23ffcd80() GS:8d1e28b4() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:7ffd045f9068 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffd045f90a0 RCX: 7fab2121f87b RDX: 7ffd045f90a0 RSI: c06864a2 RDI: 000b RBP: 7ffd045f90a0 R08: R09: 55dbd2985d10 R10: 55dbd2196280 R11: 0246 R12: c06864a2 R13: 000b R14: R15: 55dbd2196280 ---[ end trace 6
Re: [PATCH] drm/amd/display: do not allocate display_mode_lib unnecessarily
Sorry for the delay, change LGTM.
Reviewed-by: Leo Li
, and applied.
Thanks!
Leo
On 2020-01-24 5:18 a.m., Dor Askayo wrote:
> On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>>
>> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>>>
>>> This allocation isn't required and can fail when resuming from suspend.
>>>
>>> Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
>>> Signed-off-by: Dor Askayo >>> ---
>>> drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
>>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> index dd4731ab935c..83ebb716166b 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> @@ -2179,12 +2179,7 @@ void dc_set_power_state(
>>> enum dc_acpi_cm_power_state power_state)
>>> {
>>> struct kref refcount;
>>> - struct display_mode_lib *dml = kzalloc(sizeof(struct
>>> display_mode_lib),
>>> - GFP_KERNEL);
>>> -
>>> - ASSERT(dml);
>>> - if (!dml)
>>> - return;
>>> + struct display_mode_lib *dml;
>>>
>>> switch (power_state) {
>>> case DC_ACPI_CM_POWER_STATE_D0:
>>> @@ -2206,6 +2201,12 @@ void dc_set_power_state(
>>> * clean state, and dc hw programming optimizations will not
>>> * cause any trouble.
>>> */
>>> + dml = kzalloc(sizeof(struct display_mode_lib),
>>> + GFP_KERNEL);
>>> +
>>> + ASSERT(dml);
>>> + if (!dml)
>>> + return;
>>>
>>> /* Preserve refcount */
>>> refcount = dc->current_state->refcount;
>>> @@ -2219,10 +2220,10 @@ void dc_set_power_state(
>>> dc->current_state->refcount = refcount;
>>> dc->current_state->bw_ctx.dml = *dml;
>>>
>>> + kfree(dml);
>>> +
>>> break;
>>> }
>>> -
>>> - kfree(dml);
>>> }
>>>
>>> void dc_resume(struct dc *dc)
>>> --
>>> 2.24.1
>>>
>>
>> I've been running with this fix applied on top of Fedora's
>> 5.3.16-300.fc31.x86_64 kernel for the past two weeks, suspending
>> and resuming often. This the first time since I bought my RX 580 8GB
>> more than a year ago that I can suspend and resume reliably.
>>
>> I'd appreciate a quick review for the above, it really is a trivial change.
>>
>> Thanks,
>> Dor
>
> Bumping this up again. I've been running with this change for the past
> 20 days without issues.
>
> Thanks,
> Dor
>
> On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>>
>> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>>>
>>> This allocation isn't required and can fail when resuming from suspend.
>>>
>>> Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
>>> Signed-off-by: Dor Askayo
>>> ---
>>> drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
>>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> index dd4731ab935c..83ebb716166b 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> @@ -2179,12 +2179,7 @@ void dc_set_power_state(
>>> enum dc_acpi_cm_power_state power_state)
>>> {
>>> struct kref refcount;
>>> - struct display_mode_lib *dml = kzalloc(sizeof(struct
>>> display_mode_lib),
>>> - GFP_KERNEL);
>>> -
>>> - ASSERT(dml);
>>> - if (!dml)
>>> - return;
>>> + struct display_mode_lib *dml;
>>>
>>> switch (power_state) {
>>> case DC_ACPI_CM_POWER_STATE_D0:
>>> @@ -2206,6 +2201,12 @@ void dc_set_power_state(
>>> * clean state, and dc hw programming optimizations will not
>>> * cause any trouble.
>>> */
>>> + dml = kzalloc(sizeof(struct display_mode_lib),
>>> + GFP_KERNEL);
>>> +
>>> + ASSERT(dml);
>>> + if (!dml)
>>> + return;
>>>
>>> /* Preserve refcount */
>>> refcount = dc->current_state->refcount;
>>> @@ -2219,10 +2220,10 @@ void dc_set_power_state(
>>> dc->current_state->refcount = refcount;
>>> dc->current_state->bw_ctx.dml = *dml;
>>>
>>> + kfree(dml);
>>> +
>>> break;
>>> }
>>> -
>>> - kfree(dml);
>>> }
>>>
>>> void dc_resume(struct dc *dc)
>>> --
>>> 2.24.1
>>>
>>
>> I've been running with this fix applied on top of Fedora's
>> 5.3.16-300.fc31.x86_64 kernel for
>> the past two weeks, suspending and resuming often. This the first time
>> since I bought my
>> RX 580 8GB more than a year ago that I can suspend and resum
Re: [PATCH v1 1/4] drm/tiny/repaper: Make driver OF-independent
Hi Andy.
On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> There is one OF call in the driver that limits its area of use.
> Replace it to generic device_get_match_data() and get rid of OF dependency.
>
> While here, cast SPI driver data to certain enumerator type.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/tiny/repaper.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> index 76d179200775..fd9e95ce3201 100644
> --- a/drivers/gpu/drm/tiny/repaper.c
> +++ b/drivers/gpu/drm/tiny/repaper.c
> @@ -17,7 +17,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -40,6 +40,7 @@
> #define REPAPER_RID_G2_COG_ID0x12
>
> enum repaper_model {
> + ECSXXX = 0,
> E1144CS021 = 1,
> E1190CS021,
> E2200CS021,
The new enum value is not used in the following - is it necessary?
Sam
> @@ -995,21 +996,21 @@ static int repaper_probe(struct spi_device *spi)
> {
> const struct drm_display_mode *mode;
> const struct spi_device_id *spi_id;
> - const struct of_device_id *match;
> struct device *dev = &spi->dev;
> enum repaper_model model;
> const char *thermal_zone;
> struct repaper_epd *epd;
> size_t line_buffer_size;
> struct drm_device *drm;
> + const void *match;
> int ret;
>
> - match = of_match_device(repaper_of_match, dev);
> + match = device_get_match_data(dev);
> if (match) {
> - model = (enum repaper_model)match->data;
> + model = (enum repaper_model)match;
> } else {
> spi_id = spi_get_device_id(spi);
> - model = spi_id->driver_data;
> + model = (enum repaper_model)spi_id->driver_data;
> }
>
> /* The SPI device is used to allocate dma memory */
> --
> 2.24.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 v1 2/4] drm/tiny/repaper: No need to set ->owner for spi_register_driver()
Hi Andy.
On Wed, Jan 22, 2020 at 12:54:01PM +0200, Andy Shevchenko wrote:
> The spi_register_driver() will set the ->owner member to THIS_MODULE.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Sam Ravnborg
Any chance you will update the remaining 3 drivers in drm/tiny/
that has the same unessesary assignment?
Sam
> ---
> drivers/gpu/drm/tiny/repaper.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
> index fd9e95ce3201..4a497203923f 100644
> --- a/drivers/gpu/drm/tiny/repaper.c
> +++ b/drivers/gpu/drm/tiny/repaper.c
> @@ -1198,7 +1198,6 @@ static void repaper_shutdown(struct spi_device *spi)
> static struct spi_driver repaper_spi_driver = {
> .driver = {
> .name = "repaper",
> - .owner = THIS_MODULE,
> .of_match_table = repaper_of_match,
> },
> .id_table = repaper_id,
> --
> 2.24.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: [git pull] drm fixes for 5.5-rc8/final
The pull request you sent on Fri, 24 Jan 2020 16:03:04 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/274adbff45e3c26c65b2e103581d2ab5834b0b7c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] drm/tiny/repaper: Make driver OF-independent
Hi Andy.
On Fri, Jan 24, 2020 at 07:31:34PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> > On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > > There is one OF call in the driver that limits its area of use.
> > > Replace it to generic device_get_match_data() and get rid of OF
> > > dependency.
> > >
> > > While here, cast SPI driver data to certain enumerator type.
>
> > > enum repaper_model {
> > > + ECSXXX = 0,
> > > E1144CS021 = 1,
> > > E1190CS021,
> > > E2200CS021,
> > The new enum value is not used in the following - is it necessary?
>
> Yes. It explicitly prevents to use 0 for real device.
>
> This is due to device_get_match_data() returns content of data pointer and
> thus
> we may not distinguish 0 from NULL pointer.
A name that told this was not a valid name would be descriptive.
As it is now it looks like a wildcard that matches everythign else.
With a more descriptive name:
Reviewed-by: Sam Ravnborg
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: Correct the highestbank configuration
On Fri, Jan 24, 2020 at 05:50:11PM +0530, Akhil P Oommen wrote:
> Highest bank bit configuration is different for a618 gpu. Update
> it with the correct configuration which is the reset value incidentally.
>
> Signed-off-by: Akhil P Oommen
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index daf0780..536d196 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -470,10 +470,12 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
> /* Select CP0 to always count cycles */
> gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
>
> - gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
> - gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
> + if (adreno_is_a630(adreno_gpu)) {
> + gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
> + gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
> + }
it shouldn't come as a surprise that everything in the a6xx family is going to
have a highest bank bit setting. Even though the a618 uses the reset value, I
think it would be less confusing to future folks if we explicitly program it:
if (adreno_is_a630(adreno_dev))
hbb = 2;
else
hbb = 0;
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47) > On 1/24/20 2:01 PM, Chris Wilson wrote: > > Since drm_global_mutex is a true global mutex across devices, we don't > > want to acquire it unless absolutely necessary. For maintaining the > > device local open_count, we can use atomic operations on the counter > > itself, except when making the transition to/from 0. Here, we tackle the > > easy portion of delaying acquiring the drm_global_mutex for the final > > release by using atomic_dec_and_mutex_lock(), leaving the global > > serialisation across the device opens. > > > > Signed-off-by: Chris Wilson > > Cc: Thomas Hellström (VMware) > > For the series: > > Reviewed-by: Thomas Hellström Now being opt-in, it is fairly limited in scope and will not randomly break others (touch wood) and the close() racing in BAT didn't throw anything up, so pushed to drm-misc-next. Thanks for the review and suggestions, Next task is to suggest others might like to use it as well. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable
On Fri, 2020-01-24 at 11:39 -0500, Mikita Lipski wrote: > > On 1/24/20 9:55 AM, Harry Wentland wrote: > > On 2020-01-23 7:06 p.m., Lyude Paul wrote: > > > Disabling a display on MST can potentially happen after the entire MST > > > topology has been removed, which means that we can't communicate with > > > the topology at all in this scenario. Likewise, this also means that we > > > can't properly update payloads on the topology and as such, it's a good > > > idea to ignore payload update failures when disabling displays. > > > Currently, amdgpu makes the mistake of halting the payload update > > > process when any payload update failures occur, resulting in leaving > > > DC's local copies of the payload tables out of date. > > > > > > This ends up causing problems with hotplugging MST topologies, and > > > causes modesets on the second hotplug to fail like so: > > > > > > [drm] Failed to updateMST allocation table forpipe idx:1 > > > [ cut here ] > > > WARNING: CPU: 5 PID: 1511 at > > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 > > > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > > Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack > > > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 > > > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc > > > vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic > > > snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops > > > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul > > > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core > > > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm > > > sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd > > > wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) > > > rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm > > > drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm > > > crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core > > > rtsx_pci pinctrl_amd > > > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0- > > > rc7Lyude-Test+ #4 > > > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) > > > 01/31/2019 > > > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 > > > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 > > > 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 > > > RSP: 0018:ac428127f5b0 EFLAGS: 00010202 > > > RAX: 0002 RBX: 8d1e166eee80 RCX: > > > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 > > > RBP: ac428127f640 R08: c03d94a8 R09: > > > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 > > > R13: 8d1e1bea0b08 R14: 0002 R15: 0002 > > > FS: 7fab23ffcd80() GS:8d1e28b4() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 > > > Call Trace: > > > ? mutex_lock+0xe/0x30 > > > dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] > > > ? dm_read_reg_func+0x39/0xb0 [amdgpu] > > > ? core_link_enable_stream+0x656/0x730 [amdgpu] > > > core_link_enable_stream+0x656/0x730 [amdgpu] > > > dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] > > > ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] > > > ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] > > > dc_commit_state+0x292/0x770 [amdgpu] > > > ? add_timer+0x101/0x1f0 > > > ? ttm_bo_put+0x1a1/0x2f0 [ttm] > > > amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] > > > ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] > > > ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] > > > ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] > > > ? ttm_bo_validate+0x134/0x150 [ttm] > > > ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] > > > ? _cond_resched+0x15/0x30 > > > ? wait_for_completion_timeout+0x38/0x160 > > > ? _cond_resched+0x15/0x30 > > > ? wait_for_completion_interruptible+0x33/0x190 > > > commit_tail+0x94/0x130 [drm_kms_helper] > > > drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] > > > drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] > > > drm_mode_setcrtc+0x194/0x6a0 [drm] > > > ? _cond_resched+0x15/0x30 > > > ? mutex_lock+0xe/0x30 > > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > > drm_ioctl_kernel+0xaa/0xf0 [drm] > > > drm_ioctl+0x208/0x390 [drm] > > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > > > do_vfs_ioctl+0x458/0x6d0 > > > ksys_ioctl+0x5e/0x90 > > > __x64_sys_ioctl+0x16/0x20 > > > do_syscall_64+0x55/0x1b0 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > RIP: 0033:0x7fab2121f87b > > > Code: 0f 1e fa 48 8b
[PATCH v2] drm/amd/dm/mst: Ignore payload update failures
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 [ cut here ] WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ac428127f5b0 EFLAGS: 00010202 RAX: 0002 RBX: 8d1e166eee80 RCX: RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 RBP: ac428127f640 R08: c03d94a8 R09: R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 R13: 8d1e1bea0b08 R14: 0002 R15: 0002 FS: 7fab23ffcd80() GS:8d1e28b4() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:7ffd045f9068 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffd045f90a0 RCX: 7fab2121f87b RDX: 7ffd045f90a0 RSI: c06864a2 RDI: 000b RBP: 7ffd045f90a0 R08: R09: 55dbd2985d10 R10: 55dbd2196280 R11: 0246 R12: c06864a2 R13: 000b R14: R15: 55dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: *
Re: [PATCH v2] drm/amd/dm/mst: Ignore payload update failures
On 1/24/20 2:10 PM, Lyude Paul wrote: Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 [ cut here ] WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ac428127f5b0 EFLAGS: 00010202 RAX: 0002 RBX: 8d1e166eee80 RCX: RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 RBP: ac428127f640 R08: c03d94a8 R09: R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 R13: 8d1e1bea0b08 R14: 0002 R15: 0002 FS: 7fab23ffcd80() GS:8d1e28b4() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:7ffd045f9068 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffd045f90a0 RCX: 7fab2121f87b RDX: 7ffd045f90a0 RSI: c06864a2 RDI: 000b RBP: 7ffd045f90a0 R08: R09: 55dbd2985d10 R10: 55dbd2196280 R11: 0246 R12: c06864a2 R13: 000b R14: R15: 55dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only bee
[PATCH 8/8] drm/edid: Dump bogus 18 byte descriptors
From: Ville Syrjälä
I'm curious if there are any bogus 18 byte descriptors around.
Let's dump them out if we encounter them.
Not sure we'd actually want this, but at least I get to see
if our CI has anything that hits this :)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8e76efe1654d..4d8303e56536 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2202,6 +2202,12 @@ static bool is_display_descriptor(const u8 d[18], u8 tag)
d[2] == 0x00 && d[3] == tag;
}
+static bool is_any_display_descriptor(const u8 d[18])
+{
+ return d[0] == 0x00 && d[1] == 0x00 &&
+ d[2] == 0x00;
+}
+
static bool is_detailed_timing_descriptor(const u8 d[18])
{
return d[0] != 0x00 || d[1] != 0x00;
@@ -2209,6 +2215,15 @@ static bool is_detailed_timing_descriptor(const u8 d[18])
typedef void detailed_cb(const struct detailed_timing *timing, void *closure);
+static void do_detailed_block(const u8 d[18], detailed_cb *cb, void *closure)
+{
+ if (!is_detailed_timing_descriptor(d) &&
+ !is_any_display_descriptor(d))
+ DRM_WARN("Unrecognized 18 byte descriptor: %*ph\n", 18, d);
+
+ cb((const struct detailed_timing *)d, closure);
+}
+
static void
cea_for_each_detailed_block(const u8 *ext, detailed_cb *cb, void *closure)
{
@@ -2221,7 +2236,7 @@ cea_for_each_detailed_block(const u8 *ext, detailed_cb
*cb, void *closure)
n = (127 - d) / 18;
for (i = 0; i < n; i++)
- cb((const struct detailed_timing *)(det_base + 18 * i),
closure);
+ do_detailed_block(det_base + 18 * i, cb, closure);
}
static void
@@ -2234,7 +2249,7 @@ vtb_for_each_detailed_block(const u8 *ext, detailed_cb
*cb, void *closure)
return; /* unknown version */
for (i = 0; i < n; i++)
- cb((const struct detailed_timing *)(det_base + 18 * i),
closure);
+ do_detailed_block(det_base + 18 * i, cb, closure);
}
static void
@@ -2247,7 +2262,8 @@ drm_for_each_detailed_block(const u8 *raw_edid,
detailed_cb *cb, void *closure)
return;
for (i = 0; i < EDID_DETAILED_TIMINGS; i++)
- cb(&(edid->detailed_timings[i]), closure);
+ do_detailed_block((const u8 *)&edid->detailed_timings[i],
+ cb, closure);
for (i = 1; i <= raw_edid[0x7e]; i++) {
const u8 *ext = raw_edid + (i * EDID_LENGTH);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/edid: Constify lots of things
From: Ville Syrjälä
Let's try to make a lot more stuff const in the edid parser.
The "downside" is that we can no longer mangle the EDID in the
middle of the parsing to apply quirks (drm_mode_detailed()).
I don't really think mangling the blob itself is such a great
idea anyway so I won't miss that part. But if we do want it
back I guess we should do the mangling in one explicit place
before we otherwise parse the EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 4 +-
drivers/gpu/drm/drm_edid.c | 303 ++--
include/drm/drm_connector.h | 4 +-
3 files changed, 176 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f632ca05960e..92a5cd6ff6b1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2377,7 +2377,7 @@ EXPORT_SYMBOL(drm_mode_put_tile_group);
* tile group or NULL if not found.
*/
struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
- char topology[8])
+ const u8 topology[8])
{
struct drm_tile_group *tg;
int id;
@@ -2407,7 +2407,7 @@ EXPORT_SYMBOL(drm_mode_get_tile_group);
* new tile group or NULL.
*/
struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
- char topology[8])
+ const u8 topology[8])
{
struct drm_tile_group *tg;
int ret;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fd9b724067a7..8e76efe1654d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -88,7 +88,7 @@
struct detailed_mode_closure {
struct drm_connector *connector;
- struct edid *edid;
+ const struct edid *edid;
bool preferred;
u32 quirks;
int modes;
@@ -1584,8 +1584,8 @@ MODULE_PARM_DESC(edid_fixup,
"Minimum number of valid EDID header bytes (0-8, default 6)");
static void drm_get_displayid(struct drm_connector *connector,
- struct edid *edid);
-static int validate_displayid(u8 *displayid, int length, int idx);
+ const struct edid *edid);
+static int validate_displayid(const u8 *displayid, int length, int idx);
static int drm_edid_block_checksum(const u8 *raw_edid)
{
@@ -2207,41 +2207,41 @@ static bool is_detailed_timing_descriptor(const u8
d[18])
return d[0] != 0x00 || d[1] != 0x00;
}
-typedef void detailed_cb(struct detailed_timing *timing, void *closure);
+typedef void detailed_cb(const struct detailed_timing *timing, void *closure);
static void
-cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+cea_for_each_detailed_block(const u8 *ext, detailed_cb *cb, void *closure)
{
int i, n;
u8 d = ext[0x02];
- u8 *det_base = ext + d;
+ const u8 *det_base = ext + d;
if (d < 4 || d > 127)
return;
n = (127 - d) / 18;
for (i = 0; i < n; i++)
- cb((struct detailed_timing *)(det_base + 18 * i), closure);
+ cb((const struct detailed_timing *)(det_base + 18 * i),
closure);
}
static void
-vtb_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+vtb_for_each_detailed_block(const u8 *ext, detailed_cb *cb, void *closure)
{
unsigned int i, n = min((int)ext[0x02], 6);
- u8 *det_base = ext + 5;
+ const u8 *det_base = ext + 5;
if (ext[0x01] != 1)
return; /* unknown version */
for (i = 0; i < n; i++)
- cb((struct detailed_timing *)(det_base + 18 * i), closure);
+ cb((const struct detailed_timing *)(det_base + 18 * i),
closure);
}
static void
-drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
+drm_for_each_detailed_block(const u8 *raw_edid, detailed_cb *cb, void *closure)
{
+ const struct edid *edid = (struct edid *)raw_edid;
int i;
- struct edid *edid = (struct edid *)raw_edid;
if (edid == NULL)
return;
@@ -2250,7 +2250,7 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb
*cb, void *closure)
cb(&(edid->detailed_timings[i]), closure);
for (i = 1; i <= raw_edid[0x7e]; i++) {
- u8 *ext = raw_edid + (i * EDID_LENGTH);
+ const u8 *ext = raw_edid + (i * EDID_LENGTH);
switch (*ext) {
case CEA_EXT:
cea_for_each_detailed_block(ext, cb, closure);
@@ -2264,81 +2264,105 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb
*cb, void *closure)
}
}
+struct bool_closure {
+ bool ret;
+};
+
static void
-is_rb(struct detailed_timing *t, void *data)
+is_rb(const struct detailed_timing *t, void *c)
{
- u8 *r = (u8
[PATCH 2/8] drm/edid: Don't accept any old garbage as a display descriptor
From: Ville Syrjälä
Currently we assume any 18 byte descriptor to be a display descritor
if only the tag byte matches the expected value. But for detailed
timing descriptors that same byte is just the lower 8 bits of
hblank, and as such can match any display descriptor tag. To
properly validate that the 18 byte descriptor is in fact a
display descriptor we must also examine bytes 0-2 (just byte 1
should actually suffice but the spec does say that bytes 0 and
2 must also always be zero for display descriptors so we check
those too).
Unlike Allen's original proposed patch to just fix is_rb() we
roll this out across the board to fix everything.
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 65 --
1 file changed, 41 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1b6e544cf5c7..96ae1fde4ce2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2196,6 +2196,12 @@ struct drm_display_mode *drm_mode_find_dmt(struct
drm_device *dev,
}
EXPORT_SYMBOL(drm_mode_find_dmt);
+static bool is_display_descriptor(const u8 d[18], u8 tag)
+{
+ return d[0] == 0x00 && d[1] == 0x00 &&
+ d[2] == 0x00 && d[3] == tag;
+}
+
typedef void detailed_cb(struct detailed_timing *timing, void *closure);
static void
@@ -2257,9 +2263,12 @@ static void
is_rb(struct detailed_timing *t, void *data)
{
u8 *r = (u8 *)t;
- if (r[3] == EDID_DETAIL_MONITOR_RANGE)
- if (r[15] & 0x10)
- *(bool *)data = true;
+
+ if (!is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE))
+ return;
+
+ if (r[15] & 0x10)
+ *(bool *)data = true;
}
/* EDID 1.4 defines this explicitly. For EDID 1.3, we guess, badly. */
@@ -2279,7 +2288,11 @@ static void
find_gtf2(struct detailed_timing *t, void *data)
{
u8 *r = (u8 *)t;
- if (r[3] == EDID_DETAIL_MONITOR_RANGE && r[10] == 0x02)
+
+ if (!is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE))
+ return;
+
+ if (r[10] == 0x02)
*(u8 **)data = r;
}
@@ -2818,7 +2831,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
struct detailed_non_pixel *data = &timing->data.other_data;
struct detailed_data_monitor_range *range = &data->data.range;
- if (data->type != EDID_DETAIL_MONITOR_RANGE)
+ if (!is_display_descriptor((const u8 *)timing,
EDID_DETAIL_MONITOR_RANGE))
return;
closure->modes += drm_dmt_modes_for_range(closure->connector,
@@ -2897,10 +2910,11 @@ static void
do_established_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
- struct detailed_non_pixel *data = &timing->data.other_data;
- if (data->type == EDID_DETAIL_EST_TIMINGS)
- closure->modes += drm_est3_modes(closure->connector, timing);
+ if (!is_display_descriptor((const u8 *)timing, EDID_DETAIL_EST_TIMINGS))
+ return;
+
+ closure->modes += drm_est3_modes(closure->connector, timing);
}
/**
@@ -2949,19 +2963,19 @@ do_standard_modes(struct detailed_timing *timing, void
*c)
struct detailed_non_pixel *data = &timing->data.other_data;
struct drm_connector *connector = closure->connector;
struct edid *edid = closure->edid;
+ int i;
- if (data->type == EDID_DETAIL_STD_MODES) {
- int i;
- for (i = 0; i < 6; i++) {
- struct std_timing *std;
- struct drm_display_mode *newmode;
+ if (!is_display_descriptor((const u8 *)timing, EDID_DETAIL_STD_MODES))
+ return;
- std = &data->data.timings[i];
- newmode = drm_mode_std(connector, edid, std);
- if (newmode) {
- drm_mode_probed_add(connector, newmode);
- closure->modes++;
- }
+ for (i = 0; i < 6; i++) {
+ struct std_timing *std = &data->data.timings[i];
+ struct drm_display_mode *newmode;
+
+ newmode = drm_mode_std(connector, edid, std);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ closure->modes++;
}
}
}
@@ -3056,10 +3070,11 @@ static void
do_cvt_mode(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
- struct detailed_non_pixel *data = &timing->data.other_data;
- if (data->type == EDID_DETAIL_CVT_3BYTE)
- closure->modes += drm_cvt_modes(closure->connector, timing);
+ if (!is_display_descriptor((const u8 *)timing, EDID_DETAIL_CVT_3BYTE))
+ return;
+
+ closure->modes += drm_cvt_modes(closure->connector, timing);
}
[PATCH 1/8] drm/edid: Check the number of detailed timing descriptors in the CEA ext block
From: Ville Syrjälä
CEA-861 says :
"d = offset for the byte following the reserved data block.
If no data is provided in the reserved data block, then d=4.
If no DTDs are provided, then d=0."
So let's not look for DTDs when d==0. In fact let's just make that
<4 since those values would just mean that he DTDs overlap the block
header. And let's also check that d isn't so big as to declare
the descriptors to live past the block end, although the code
does already survive that case as we'd just end up with a negative
number of descriptors and the loop would not do anything.
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..1b6e544cf5c7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2201,10 +2201,13 @@ typedef void detailed_cb(struct detailed_timing
*timing, void *closure);
static void
cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
{
- int i, n = 0;
+ int i, n;
u8 d = ext[0x02];
u8 *det_base = ext + d;
+ if (d < 4 || d > 127)
+ return;
+
n = (127 - d) / 18;
for (i = 0; i < n; i++)
cb((struct detailed_timing *)(det_base + 18 * i), closure);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/edid: Document why we don't bounds check the DispID CEA block start/end
From: Ville Syrjälä
After much head scratching I managed to convince myself that
for_each_displayid_db() has already done the bounds checks for
the DispID CEA data block. Which is why we don't need to repeat
them in cea_db_offsets(). To avoid having to go through that
pain again in the future add a comment which explains this fact.
Cc: Andres Rodriguez
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3df5744026b0..0369a54e3d32 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4001,6 +4001,10 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
* no non-DTD data.
*/
if (cea[0] == DATA_BLOCK_CTA) {
+ /*
+* for_each_displayid_db() has already verified
+* that these stay within expected bounds.
+*/
*start = 3;
*end = *start + cea[2];
} else if (cea[0] == CEA_EXT) {
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/i915: Clear out spurious whitespace
From: Ville Syrjälä
Nuke some whitespace that shouldn't be there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d6bce58b27ac..3df5744026b0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2842,7 +2842,7 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
closure->modes += drm_dmt_modes_for_range(closure->connector,
closure->edid,
timing);
-
+
if (!version_greater(closure->edid, 1, 1))
return; /* GTF not defined yet */
@@ -3084,7 +3084,7 @@ do_cvt_mode(struct detailed_timing *timing, void *c)
static int
add_cvt_modes(struct drm_connector *connector, struct edid *edid)
-{
+{
struct detailed_mode_closure closure = {
.connector = connector,
.edid = edid,
@@ -4342,7 +4342,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char
*name, int bufsize)
{
int name_length;
char buf[13];
-
+
if (bufsize <= 0)
return;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data block revision
From: Ville Syrjälä
I don't understand what the DispID CEA data block revision
means. The spec doesn't say. I guess some DispID must have
a value of >= 3 in there or else we generally wouldn't
even parse the CEA data blocks. Or does all this code
actually not do anything?
Cc: Andres Rodriguez
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0369a54e3d32..fd9b724067a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3977,6 +3977,13 @@ cea_db_tag(const u8 *db)
static int
cea_revision(const u8 *cea)
{
+ /*
+* FIXME is this correct for the DispID variant?
+* The DispID spec doesn't really specify whether
+* this is the revision of the CEA extension or
+* the DispID CEA data block. And the only value
+* given as an example is 0.
+*/
return cea[1];
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/edid: Introduce is_detailed_timing_descritor()
From: Ville Syrjälä
Let's introduce is_detailed_timing_descritor() as the opposite
counterpart of is_display_descriptor().
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 42 ++
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96ae1fde4ce2..d6bce58b27ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2202,6 +2202,11 @@ static bool is_display_descriptor(const u8 d[18], u8 tag)
d[2] == 0x00 && d[3] == tag;
}
+static bool is_detailed_timing_descriptor(const u8 d[18])
+{
+ return d[0] != 0x00 || d[1] != 0x00;
+}
+
typedef void detailed_cb(struct detailed_timing *timing, void *closure);
static void
@@ -3101,27 +3106,28 @@ do_detailed_mode(struct detailed_timing *timing, void
*c)
struct detailed_mode_closure *closure = c;
struct drm_display_mode *newmode;
- if (timing->pixel_clock) {
- newmode = drm_mode_detailed(closure->connector->dev,
- closure->edid, timing,
- closure->quirks);
- if (!newmode)
- return;
+ if (!is_detailed_timing_descriptor((const u8 *)timing))
+ return;
+
+ newmode = drm_mode_detailed(closure->connector->dev,
+ closure->edid, timing,
+ closure->quirks);
+ if (!newmode)
+ return;
- if (closure->preferred)
- newmode->type |= DRM_MODE_TYPE_PREFERRED;
+ if (closure->preferred)
+ newmode->type |= DRM_MODE_TYPE_PREFERRED;
- /*
-* Detailed modes are limited to 10kHz pixel clock resolution,
-* so fix up anything that looks like CEA/HDMI mode, but the
clock
-* is just slightly off.
-*/
- fixup_detailed_cea_mode_clock(newmode);
+ /*
+* Detailed modes are limited to 10kHz pixel clock resolution,
+* so fix up anything that looks like CEA/HDMI mode, but the clock
+* is just slightly off.
+*/
+ fixup_detailed_cea_mode_clock(newmode);
- drm_mode_probed_add(closure->connector, newmode);
- closure->modes++;
- closure->preferred = false;
- }
+ drm_mode_probed_add(closure->connector, newmode);
+ closure->modes++;
+ closure->preferred = false;
}
/*
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
On 1/24/20 7:39 PM, Chris Wilson wrote: Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47) On 1/24/20 2:01 PM, Chris Wilson wrote: Since drm_global_mutex is a true global mutex across devices, we don't want to acquire it unless absolutely necessary. For maintaining the device local open_count, we can use atomic operations on the counter itself, except when making the transition to/from 0. Here, we tackle the easy portion of delaying acquiring the drm_global_mutex for the final release by using atomic_dec_and_mutex_lock(), leaving the global serialisation across the device opens. Signed-off-by: Chris Wilson Cc: Thomas Hellström (VMware) For the series: Reviewed-by: Thomas Hellström Now being opt-in, it is fairly limited in scope and will not randomly break others (touch wood) and the close() racing in BAT didn't throw anything up, so pushed to drm-misc-next. Thanks for the review and suggestions, Next task is to suggest others might like to use it as well. -Chris Thanks. I'll look at doing the same for those drivers I audited. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: Reduce global locking around filp release
For largely legacy reasons, a global mutex (drm_global_mutex) is taken
around open/close of the drm_device, including serialising the filp
release. For drivers with their own fine grained locking, such global
coordination is a hindrance, albeit off the common hot paths.
References: 7a2c65dd32b1 ("drm: Release filp before global lock")
Signed-off-by: Chris Wilson
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf..2d65a6c27456 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1092,7 +1092,7 @@ static const struct file_operations
nouveau_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
- .release = drm_release,
+ .release = drm_release_noglobal,
.unlocked_ioctl = nouveau_drm_ioctl,
.mmap = nouveau_ttm_mmap,
.poll = drm_poll,
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amdgpu: Reduce global locking around filp release
For largely legacy reasons, a global mutex (drm_global_mutex) is taken
around open/close of the drm_device, including serialising the filp
release. For drivers with their own fine grained locking, such global
coordination is a hindrance, albeit off the common hot paths.
References: 7a2c65dd32b1 ("drm: Release filp before global lock")
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 94e2fd758e01..9bce9cfa982e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1351,7 +1351,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.owner = THIS_MODULE,
.open = drm_open,
.flush = amdgpu_flush,
- .release = drm_release,
+ .release = drm_release_noglobal,
.unlocked_ioctl = amdgpu_drm_ioctl,
.mmap = amdgpu_mmap,
.poll = drm_poll,
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
Hi Ville
On 2020-01-24 06:36, Ville Syrjälä wrote:
On Thu, Jan 23, 2020 at 02:40:45PM -0800, Abhinav Kumar wrote:
From: Uma Shankar
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
Why?
[Abhinav] The display driver for MSM chipsets still replies on the
drm_edid.c for the parsing of
CEA extension blocks. Primarily we are using this information to know
the supported colorspaces of the sink
(BT2020/DCI-P3) for use-cases such as HDR. The parts of the MSM display
driver which use this block shall be posted
upstream a little bit later when our changes are ready to be posted.
Hence we would like drm_edid.c to be capable of parsing this block.
Thanks.
This was posted by Uma Shankar at
https://patchwork.kernel.org/patch/10861327/
Modified by Abhinav Kumar:
- Use macros to distinguish the bit fields for clarity
Signed-off-by: Uma Shankar
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_edid.c | 54
+
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 11 +
3 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6..148bfa4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3136,6 +3136,7 @@ static int drm_cvt_modes(struct drm_connector
*connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
@@ -4199,6 +4200,57 @@ static void
fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 2)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+ /* As per CEA 861-G spec */
+ /* Byte 3 Bit 0: xvYCC_601 */
+ if (db[2] & BIT(0))
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
+ /* Byte 3 Bit 1: xvYCC_709 */
+ if (db[2] & BIT(1))
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
+ /* Byte 3 Bit 2: sYCC_601 */
+ if (db[2] & BIT(2))
+ info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
+ /* Byte 3 Bit 3: ADBYCC_601 */
+ if (db[2] & BIT(3))
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
+ /* Byte 3 Bit 4: ADB_RGB */
+ if (db[2] & BIT(4))
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
+ /* Byte 3 Bit 5: BT2020_CYCC */
+ if (db[2] & BIT(5))
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
+ /* Byte 3 Bit 6: BT2020_YCC */
+ if (db[2] & BIT(6))
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
+ /* Byte 3 Bit 7: BT2020_RGB */
+ if (db[2] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
+ /* Byte 4 Bit 7: DCI-P3 */
+ if (db[3] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
+
+ DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
+}
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -4877,6 +4929,8 @@ static void drm_parse_cea_ext(struct
drm_connector *connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2219109..a996ee3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index f0b03d4..6168c1c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -224,6 +224,17 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* Supported Colorimetry from colorimetry data block */
+#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
+#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
+#defin
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) --- The first time you run the game the shaders are not cached and you may see large compile times. The next time you run the game the shaders are cached and you avoid the compiling delays. -- 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 v2] drm/amd/dm/mst: Ignore payload update failures
On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote: > On 1/24/20 2:10 PM, Lyude Paul wrote: > > Disabling a display on MST can potentially happen after the entire MST > > topology has been removed, which means that we can't communicate with > > the topology at all in this scenario. Likewise, this also means that we > > can't properly update payloads on the topology and as such, it's a good > > idea to ignore payload update failures when disabling displays. > > Currently, amdgpu makes the mistake of halting the payload update > > process when any payload update failures occur, resulting in leaving > > DC's local copies of the payload tables out of date. > > > > This ends up causing problems with hotplugging MST topologies, and > > causes modesets on the second hotplug to fail like so: > > > > [drm] Failed to updateMST allocation table forpipe idx:1 > > [ cut here ] > > WARNING: CPU: 5 PID: 1511 at > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 > > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack > > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 > > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc > > vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic > > snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops > > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul > > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core > > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm > > sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd > > wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) > > rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm > > drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm > > crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core > > rtsx_pci pinctrl_amd > > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0- > > rc7Lyude-Test+ #4 > > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) > > 01/31/2019 > > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 > > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 > > 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 > > RSP: 0018:ac428127f5b0 EFLAGS: 00010202 > > RAX: 0002 RBX: 8d1e166eee80 RCX: > > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 > > RBP: ac428127f640 R08: c03d94a8 R09: > > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 > > R13: 8d1e1bea0b08 R14: 0002 R15: 0002 > > FS: 7fab23ffcd80() GS:8d1e28b4() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 > > Call Trace: > > ? mutex_lock+0xe/0x30 > > dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] > > ? dm_read_reg_func+0x39/0xb0 [amdgpu] > > ? core_link_enable_stream+0x656/0x730 [amdgpu] > > core_link_enable_stream+0x656/0x730 [amdgpu] > > dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] > > ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] > > ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] > > dc_commit_state+0x292/0x770 [amdgpu] > > ? add_timer+0x101/0x1f0 > > ? ttm_bo_put+0x1a1/0x2f0 [ttm] > > amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] > > ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] > > ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] > > ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] > > ? ttm_bo_validate+0x134/0x150 [ttm] > > ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] > > ? _cond_resched+0x15/0x30 > > ? wait_for_completion_timeout+0x38/0x160 > > ? _cond_resched+0x15/0x30 > > ? wait_for_completion_interruptible+0x33/0x190 > > commit_tail+0x94/0x130 [drm_kms_helper] > > drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] > > drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] > > drm_mode_setcrtc+0x194/0x6a0 [drm] > > ? _cond_resched+0x15/0x30 > > ? mutex_lock+0xe/0x30 > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > drm_ioctl_kernel+0xaa/0xf0 [drm] > > drm_ioctl+0x208/0x390 [drm] > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > > do_vfs_ioctl+0x458/0x6d0 > > ksys_ioctl+0x5e/0x90 > > __x64_sys_ioctl+0x16/0x20 > > do_syscall_64+0x55/0x1b0 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x7fab2121f87b > > Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff > > ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 > > f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 > > RSP: 002b:7ffd045f9068 EFLAGS: 0246
Re: [Bug 206231] R9 280X low performance with all games
On Fri, Jan 24, 2020 at 09:24:57PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206231 > > --- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) --- > The first time you run the game the shaders are not cached and you may see > large compile times. The next time you run the game the shaders are cached > and > you avoid the compiling delays. I did not erazed the disk shader cache since the first time I did run the game. Then the game is loading the shaders straight from the disk cache. In other words, this presumes the shaders submitted for compilation by dirt rally engine are different each time the game is run ??? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #44 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Fri, Jan 24, 2020 at 09:24:57PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206231 > > --- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) --- > The first time you run the game the shaders are not cached and you may see > large compile times. The next time you run the game the shaders are cached > and > you avoid the compiling delays. I did not erazed the disk shader cache since the first time I did run the game. Then the game is loading the shaders straight from the disk cache. In other words, this presumes the shaders submitted for compilation by dirt rally engine are different each time the game is run ??? -- 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 v2] drm/amd/dm/mst: Ignore payload update failures
On Fri, 2020-01-24 at 16:46 -0500, Lyude Paul wrote: > On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote: > > On 1/24/20 2:10 PM, Lyude Paul wrote: > > > Disabling a display on MST can potentially happen after the entire MST > > > topology has been removed, which means that we can't communicate with > > > the topology at all in this scenario. Likewise, this also means that we > > > can't properly update payloads on the topology and as such, it's a good > > > idea to ignore payload update failures when disabling displays. > > > Currently, amdgpu makes the mistake of halting the payload update > > > process when any payload update failures occur, resulting in leaving > > > DC's local copies of the payload tables out of date. > > > > > > This ends up causing problems with hotplugging MST topologies, and > > > causes modesets on the second hotplug to fail like so: > > > > > > [drm] Failed to updateMST allocation table forpipe idx:1 > > > [ cut here ] > > > WARNING: CPU: 5 PID: 1511 at > > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 > > > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > > Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack > > > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 > > > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc > > > vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic > > > snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops > > > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul > > > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core > > > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm > > > sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd > > > wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) > > > rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm > > > drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm > > > crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core > > > rtsx_pci pinctrl_amd > > > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0- > > > rc7Lyude-Test+ #4 > > > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) > > > 01/31/2019 > > > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 > > > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 > > > 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 > > > RSP: 0018:ac428127f5b0 EFLAGS: 00010202 > > > RAX: 0002 RBX: 8d1e166eee80 RCX: > > > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 > > > RBP: ac428127f640 R08: c03d94a8 R09: > > > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 > > > R13: 8d1e1bea0b08 R14: 0002 R15: 0002 > > > FS: 7fab23ffcd80() GS:8d1e28b4() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: 7f151f1711e8 CR3: 0005997c CR4: 003406e0 > > > Call Trace: > > > ? mutex_lock+0xe/0x30 > > > dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] > > > ? dm_read_reg_func+0x39/0xb0 [amdgpu] > > > ? core_link_enable_stream+0x656/0x730 [amdgpu] > > > core_link_enable_stream+0x656/0x730 [amdgpu] > > > dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] > > > ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] > > > ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] > > > dc_commit_state+0x292/0x770 [amdgpu] > > > ? add_timer+0x101/0x1f0 > > > ? ttm_bo_put+0x1a1/0x2f0 [ttm] > > > amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] > > > ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] > > > ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] > > > ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] > > > ? ttm_bo_validate+0x134/0x150 [ttm] > > > ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] > > > ? _cond_resched+0x15/0x30 > > > ? wait_for_completion_timeout+0x38/0x160 > > > ? _cond_resched+0x15/0x30 > > > ? wait_for_completion_interruptible+0x33/0x190 > > > commit_tail+0x94/0x130 [drm_kms_helper] > > > drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] > > > drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] > > > drm_mode_setcrtc+0x194/0x6a0 [drm] > > > ? _cond_resched+0x15/0x30 > > > ? mutex_lock+0xe/0x30 > > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > > drm_ioctl_kernel+0xaa/0xf0 [drm] > > > drm_ioctl+0x208/0x390 [drm] > > > ? drm_mode_getcrtc+0x180/0x180 [drm] > > > amdgpu_drm_ioctl+0x49/0x80 [amdgpu] > > > do_vfs_ioctl+0x458/0x6d0 > > > ksys_ioctl+0x5e/0x90 > > > __x64_sys_ioctl+0x16/0x20 > > > do_syscall_64+0x55/0x1b0 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > RIP: 0033:0x7fab2121f87b > > > Code: 0f 1e fa 48 8b
Re: [PATCH v3] drm/dp_mst: Fix W=1 warnings
On Tue, 2020-01-07 at 14:11 +0100, Benjamin Gaignard wrote:
> Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
> a écrit :
> > Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> > a écrit :
> > > Le mer. 4 déc. 2019 à 17:47, Jani Nikula a
> > > écrit :
> > > > On Thu, 28 Nov 2019, Benjamin Gaignard
> > > > wrote:
> > > > > Fix the warnings that show up with W=1.
> > > > > They are all about unused but set variables.
> > > > > If functions returns are not used anymore make them void.
> > > > >
> > > > > Signed-off-by: Benjamin Gaignard
> > > > > ---
> > > > > CC: Jani Nikula
> > > > >
> > > > > changes in version 3:
> > > > > - remove the hunk that may conflict with c485e2c97dae
> > > > > ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
> > > > >
> > > > > changes in version 2:
> > > > > - fix indentations
> > > > > - when possible change functions prototype to void
> > > > >
> > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
> > > > >
> > > > > 1 file changed, 31 insertions(+), 52 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 1437bc46368b..d5cb5688b5dd 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > drm_dp_sideband_msg_rx *msg,
> > > > > u8 *replybuf, u8 replybuflen,
> > > > > bool hdr)
> > > > > {
> > > > > int ret;
> > > > > - u8 crc4;
> > > > >
> > > > > if (hdr) {
> > > > > u8 hdrlen;
> > > > > @@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > drm_dp_sideband_msg_rx *msg,
> > > > > }
> > > > >
> > > > > if (msg->curchunk_idx >= msg->curchunk_len) {
> > > > > - /* do CRC */
> > > > > - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg-
> > > > > >curchunk_len - 1);
> > > >
> > > > Again, someone needs to check if crc4 should be *used* instead of
> > > > thrown
> > > > away. Blindly throwing stuff out is not the way to go.
> > >
> > > Hi Dave,
> > >
> >
> > + Lyude who has been hacking in this code recently
>
> gentle ping for the reviewers,
>
hi-actually yes, we should probably be using this instead of just dropping
this. Also, I didn't write this code originally I just refactored a bunch of
it - Dave Airlied is the original author, but the original version of this
code was written ages ago. tbh, I think it's a safe bet to say that they
probably did mean to use this but forgot to and no one noticed until now.
> Thanks,
> Benjamin
> > > Your are the original writer of this code, could you tell us if we can
> > > drop crc4
> > > ao if there is something else that I have misunderstood ?
> > >
> > > Thanks,
> > > Benjamin
> > >
> > > > BR,
> > > > Jani.
> > > >
> > > > > /* copy chunk into bigger msg */
> > > > > memcpy(&msg->msg[msg->curlen], msg->chunk, msg-
> > > > > >curchunk_len - 1);
> > > > > msg->curlen += msg->curchunk_len - 1;
> > > > > @@ -1014,7 +1011,7 @@ static bool drm_dp_sideband_parse_req(struct
> > > > > drm_dp_sideband_msg_rx *raw,
> > > > > }
> > > > > }
> > > > >
> > > > > -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > {
> > > > > struct drm_dp_sideband_msg_req_body req;
> > > > >
> > > > > @@ -1024,17 +1021,14 @@ static int build_dpcd_write(struct
> > > > > drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> > > > > req.u.dpcd_write.num_bytes = num_bytes;
> > > > > req.u.dpcd_write.bytes = bytes;
> > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > -
> > > > > - return 0;
> > > > > }
> > > > >
> > > > > -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > {
> > > > > struct drm_dp_sideband_msg_req_body req;
> > > > >
> > > > > req.req_type = DP_LINK_ADDRESS;
> > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > - return 0;
> > > > > }
> > > > >
> > > > > static int build_enum_path_resources(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num)
> > > > > @@ -1048,7 +1042,7 @@ static int build_enum_path_resources(struct
> > > > > drm_dp_sideband_msg_tx *msg, int por
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static int build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num,
> > > > > +static void build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > *msg, int port_num,
> > > > > u8 vcpi, uint16_t pbn,
> > > > >
Re: [v3] arm64: dts: sc7180: add display dt nodes
Hi,
On Fri, Jan 24, 2020 at 4:07 AM Harigovindan P wrote:
>
> Add display, DSI hardware DT nodes for sc7180.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v1:
> -Added display DT nodes for sc7180
> Changes in v2:
> -Renamed node names
> -Corrected code alignments
> -Removed extra new line
> -Added DISP AHB clock for register access
> under display_subsystem node for global settings
> Changes in v3:
> -Modified node names
> -Modified hard coded values
> -Removed mdss reg entry
>
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 58 +++
> arch/arm64/boot/dts/qcom/sc7180.dtsi| 124
>
> 2 files changed, 182 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50a..c77aab7 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -7,6 +7,7 @@
>
> /dts-v1/;
>
> +#include
> #include
> #include "sc7180.dtsi"
> #include "pm6150.dtsi"
> @@ -232,6 +233,50 @@
> };
> };
>
> +&dsi_controller {
> + status = "okay";
> +
> + vdda-supply = <&vreg_l3c_1p2>;
> +
> + panel@0 {
> + compatible = "visionox,rm69299-1080p-display";
I don't think the bindings for this panel have landed anywhere, have
they? Maybe keep the IDP patch separate from the main sc7180 patch so
that we can land the main sc7180 patch even if the idp patch isn't
quite ready? ...and maybe ping whoever is supposed to add support for
this panel to tell them to get working on it.
> + reg = <0>;
> +
> + vdda-supply = <&vreg_l8c_1p8>;
> + vdd3p3-supply = <&vreg_l18a_2p8>;
> +
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <&disp_pins_default>;
> + pinctrl-1 = <&disp_pins_default>;
> +
> + reset-gpios = <&pm6150l_gpio 3 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&panel0_in>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +&dsi_phy {
> + status = "okay";
The above doesn't do anything because the dsi_phy you add to
sc7180.dtsi doesn't have a
status = "disabled";
...but probably it (and most of the other components that you're
adding) should. The idea is that if it ever makes sense that a board
might be built with this SoC but _not_ hook up a given component that
it should start out "disabled" in the main SoC dtsi file.
> +};
> +
> &qspi {
> status = "okay";
> pinctrl-names = "default";
> @@ -289,6 +334,19 @@
>
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> +&pm6150l_gpio {
> + disp_pins {
> + disp_pins_default: disp_pins_default{
As Bjorn mentioned, node name should use "-" instead of "_". Also add
a space before your "{"
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 3bc3f64..3ebc45b 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1184,6 +1184,130 @@
> #power-domain-cells = <1>;
> };
>
> + mdss: display_subsystem@ae0 {
> + compatible = "qcom,sc7180-mdss";
> + reg = <0 0x0ae0 0 0x1000>;
> + reg-names = "mdss";
> +
> + power-domains = <&dispcc MDSS_GDSC>;
You definitely can't land your patch until the "dispcc" node is added,
but it's not. You should be mentioning somewhere (after the cut?)
that you depend on the series to add dispcc.
...speaking of which, I just posted up a v2 of that. See:
https://lore.kernel.org/r/20200124144154.v2.10.I1a4b93fb005791e29a9dcf288fc8bd459a555a59@changeid
...speaking of which, can you please change your patch to replace the
bogus <0> in the dispcc for the DSI PHY, providing the clocks for
"dsi_phy_pll_byte" and "dsi_phy_pll_pixel"? See
> +
> + clocks = <&gcc GCC_DISP_AHB_CLK>,
> +<&gcc GCC_DISP_HF_AXI_CLK>,
> +<&dispcc DISP_CC_MDSS_AHB_CLK>,
> +<&dispcc DISP_CC_MDSS_MDP_CLK>;
> + clock-names = "iface", "gcc_
[Bug 206299] New: [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 Bug ID: 206299 Summary: [nouveau/xen] RTX 20XX instant reboot Product: Drivers Version: 2.5 Kernel Version: 5.4.X Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: frederic.epi...@orange.fr Regression: No Created attachment 286963 --> https://bugzilla.kernel.org/attachment.cgi?id=286963&action=edit Kernel log Hi, On several kernels 4.19.X and 5.3.X or latest one 5.4, I'm having an issue with a NVIDIA RTX 2080TI (also reported by another user with RTX 2070 https://groups.google.com/forum/#!msg/qubes-devel/ozOQrOHsUBQ/XtIQsGm3DgAJ) causing lot of instant reboots of machine. Specifically, the distribution is Qubes OS so Xen is under the hood. On a classical Fedora 31 livecd I don't succeeded to reproduce the crash which is easily reproducible in Qubes (e.g. massive and intensive resize of windows). Thanks to the help of Marek Marczykowski-Górecki, I obtained the following attached kernel log using netconsole. Any help would be very appreciated. Frédéric Pierret -- 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 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #1 from Ilia Mirkin (imir...@alum.mit.edu) --- Comment on attachment 286963 --> https://bugzilla.kernel.org/attachment.cgi?id=286963 Kernel log badf5040 = bad mmio read. Could there be some PCI situation? Can you include a full boot log? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: Fix boe,tv101wum-n53 htotal timing
The datasheet suggests 60 for tHFP, so let's adjust the number
accordingly.
This also makes the framerate be 60Hz as intended:
159916.0 * 1000 / ((1200 + 80 + 24 + 60)*(1920 + 20 + 4 + 10))
=> 60.00 Hz
Signed-off-by: Nicolas Boichat
---
This also matches the values that we use in our chromeos-4.19
vendor kernel.
Applies on top or drm-misc/drm-misc-next.
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 01faf859775..48a164257d18c35 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -645,7 +645,7 @@ static const struct drm_display_mode
boe_tv101wum_n53_default_mode = {
.hdisplay = 1200,
.hsync_start = 1200 + 80,
.hsync_end = 1200 + 80 + 24,
- .htotal = 1200 + 80 + 24 + 40,
+ .htotal = 1200 + 80 + 24 + 60,
.vdisplay = 1920,
.vsync_start = 1920 + 20,
.vsync_end = 1920 + 20 + 4,
--
2.25.0.341.g760bfbb309-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Fix boe,tv101wum-n53 htotal timing
Hi Nicolas.
On Sat, Jan 25, 2020 at 01:02:56PM +0800, Nicolas Boichat wrote:
> The datasheet suggests 60 for tHFP, so let's adjust the number
> accordingly.
>
> This also makes the framerate be 60Hz as intended:
> 159916.0 * 1000 / ((1200 + 80 + 24 + 60)*(1920 + 20 + 4 + 10))
> => 60.00 Hz
>
> Signed-off-by: Nicolas Boichat
Thanks. Added Fixes: tag and applied to drm-misc-next.
Sam
>
> ---
>
> This also matches the values that we use in our chromeos-4.19
> vendor kernel.
>
> Applies on top or drm-misc/drm-misc-next.
>
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> index 01faf859775..48a164257d18c35 100644
> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> @@ -645,7 +645,7 @@ static const struct drm_display_mode
> boe_tv101wum_n53_default_mode = {
> .hdisplay = 1200,
> .hsync_start = 1200 + 80,
> .hsync_end = 1200 + 80 + 24,
> - .htotal = 1200 + 80 + 24 + 40,
> + .htotal = 1200 + 80 + 24 + 60,
> .vdisplay = 1920,
> .vsync_start = 1920 + 20,
> .vsync_end = 1920 + 20 + 4,
> --
> 2.25.0.341.g760bfbb309-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
