dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH] drm/amd/display: remove variable active_disp
by Colin King 03 Jun '21

03 Jun '21

From: Colin Ian King <colin.king(a)canonical.com> The variable active_disp is being initialized with a value that is never read, it is being re-assigned immediately afterwards. Clean up the code by removing the need for variable active_disp. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c index 53d7513b5083..adc710fe4a45 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c @@ -82,9 +82,6 @@ void bios_set_scratch_critical_state( uint32_t bios_get_vga_enabled_displays( struct dc_bios *bios) { - uint32_t active_disp = 1; - - active_disp = REG_READ(BIOS_SCRATCH_3) & 0XFFFF; - return active_disp; + return REG_READ(BIOS_SCRATCH_3) & 0XFFFF; } -- 2.31.1

2 1

[PATCH v5] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
by Hridya Valsaraju 03 Jun '21

03 Jun '21

Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Use Cases ========= The interface provides a way to gather DMA-BUF per-buffer statistics from production devices. These statistics will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. Background ========== Currently, there are two existing interfaces that provide information about DMA-BUFs. 1) /sys/kernel/debug/dma_buf/bufinfo debugfs is however unsuitable to be mounted in production systems and cannot be considered as an alternative to the sysfs interface being proposed. 2) proc/<pid>/fdinfo/<fd> The proc/<pid>/fdinfo/<fd> files expose information about DMA-BUF fds. However, the existing procfs interfaces can only provide information about the buffers for which processes hold fds or have the buffers mmapped into their address space. Since the procfs interfaces alone cannot provide a full picture of all DMA-BUFs in the system, there is the need for an alternate interface to provide this information on production systems. The patch contains the following major improvements over v1: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:… [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo… Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hridya Valsaraju <hridya(a)google.com> Reported-by: kernel test robot <lkp(a)intel.com> --- Hi Daniel, I rewrote the commit message and added a new section to Documentation/driver-api/dma-buf.rst as per your suggestions. Please do take another look when you get a chance. Thanks again for the guidance. Regards, Hridya Change in v5: -Added a section on DMA-BUF statistics to Documentation/driver-api/dma-buf.rst. Organized the commit message to clearly state the need for the new interface and provide the background on why the existing means of DMA-BUF accounting will not suffice. Based on feedback from Daniel Vetter. Changes in v4: -Suppress uevents from kset creation to avoid waking up uevent listeners on DMA-BUF export/release. Changes in v3: -Fix a warning reported by the kernel test robot. Changes in v2: -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition of other DMA-BUF-related sysfs stats in future. Based on feedback from Daniel Vetter. -Each attachment has its own directory to represent attached devices as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. Thank you both! -Commit messages updated to point to userspace code in AOSP that will read the DMA-BUF sysfs stats. .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 +++ Documentation/driver-api/dma-buf.rst | 34 ++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 300 ++++++++++++++++++ drivers/dma-buf/dma-buf-sysfs-stats.h | 62 ++++ drivers/dma-buf/dma-buf.c | 37 +++ include/linux/dma-buf.h | 20 ++ 8 files changed, 517 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index 000000000000..a243984ed420 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/<inode_number> will contain the + statistics for the DMA-BUF with the unique inode number + <inode_number> +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/size +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid> +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This directory will contain information on the attached device + and the number of current distinct device mappings. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/device +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and is a symlink to the attached device's + sysfs entry. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/map_counter +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and contains a map_counter indicating the + number of distinct device mappings of the attachment. diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f37ec30d9fd..4027762a824a 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -106,6 +106,40 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling +DMA-BUF statistics +~~~~~~~~~~~~~~~~~~ + +``/sys/kernel/debug/dma_buf/bufinfo`` provides an overview of every DMA-BUF in the +system. However, since debugfs is not safe to be mounted in production, +procfs and sysfs can be used to gather DMA-BUF statistics on production systems. + +The ``/proc/<pid>/fdinfo/<fd>`` files in procfs can be used to gather information +about DMA-BUF fds. Detailed documentation about the interface is present in +Documentation/filesystems/proc.rst. +Unfortunately, the existing procfs interfaces can only provide information about +the DMA-BUFs for which processes hold fds or have the buffers mmapped into their +address space. This necessitated the creation of the DMA-BUF sysfs statistics +interface to provide per-buffer information on production systems. + +The interface at ``/sys/kernel/dma-buf/buffers`` exposes information about +every DMA-BUF when ``CONFIG_DMABUF_SYSFS_STATS`` is enabled. + +The following stats are exposed by the interface: + +* ``/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name`` +* ``/sys/kernel/dmabuf/buffers/<inode_number>/size`` +* ``/sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device`` +* ``/sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter`` + +The information in the interface can also be used to derive per-exporter and +per-device usage statistics. The data from the interface can be gathered +on error conditions or other important events to provide a snapshot of +DMA-BUF usage. It can also be collected periodically by telemetry to monitor +various metrics. + +Detailed documentation about the interface is present in +Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4e16c71c24b7..9561e3d2d428 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -72,6 +72,17 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. +menuconfig DMABUF_SYSFS_STATS + bool "DMA-BUF sysfs statistics" + select DMA_SHARED_BUFFER + help + Choose this option to enable DMA-BUF sysfs statistics + in location /sys/kernel/dmabuf/buffers. + + /sys/kernel/dmabuf/buffers/<inode_number> will contain + statistics for the DMA-BUF with the unique inode number + <inode_number>. + source "drivers/dma-buf/heaps/Kconfig" endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 995e05f609ff..40d81f23cacf 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o +obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o dmabuf_selftests-y := \ selftest.o \ diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c new file mode 100644 index 000000000000..45717c8108c8 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -0,0 +1,300 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#include <linux/dma-buf.h> +#include <linux/dma-resv.h> +#include <linux/kobject.h> +#include <linux/printk.h> +#include <linux/slab.h> +#include <linux/sysfs.h> + +#include "dma-buf-sysfs-stats.h" + +#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) + +struct dma_buf_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr) + +static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_stats_attribute *attribute; + struct dma_buf_sysfs_entry *sysfs_entry; + struct dma_buf *dmabuf; + + attribute = to_dma_buf_stats_attr(attr); + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + dmabuf = sysfs_entry->dmabuf; + + if (!dmabuf || !attribute->show) + return -EIO; + + return attribute->show(dmabuf, attribute, buf); +} + +static const struct sysfs_ops dma_buf_stats_sysfs_ops = { + .show = dma_buf_stats_attribute_show, +}; + +static ssize_t exporter_name_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%s\n", dmabuf->exp_name); +} + +static ssize_t size_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%zu\n", dmabuf->size); +} + +static struct dma_buf_stats_attribute exporter_name_attribute = + __ATTR_RO(exporter_name); +static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size); + +static struct attribute *dma_buf_stats_default_attrs[] = { + &exporter_name_attribute.attr, + &size_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_stats_default); + +static void dma_buf_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_ktype = { + .sysfs_ops = &dma_buf_stats_sysfs_ops, + .release = dma_buf_sysfs_release, + .default_groups = dma_buf_stats_default_groups, +}; + +#define to_dma_buf_attach_entry_from_kobj(x) container_of(x, struct dma_buf_attach_sysfs_entry, kobj) + +struct dma_buf_attach_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_attach_stats_attr(x) container_of(x, struct dma_buf_attach_stats_attribute, attr) + +static ssize_t dma_buf_attach_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_attach_stats_attribute *attribute; + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + attribute = to_dma_buf_attach_stats_attr(attr); + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + + if (!attribute->show) + return -EIO; + + return attribute->show(sysfs_entry, attribute, buf); +} + +static const struct sysfs_ops dma_buf_attach_stats_sysfs_ops = { + .show = dma_buf_attach_stats_attribute_show, +}; + +static ssize_t map_counter_show(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%u\n", sysfs_entry->map_counter); +} + +static struct dma_buf_attach_stats_attribute map_counter_attribute = + __ATTR_RO(map_counter); + +static struct attribute *dma_buf_attach_stats_default_attrs[] = { + &map_counter_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_attach_stats_default); + +static void dma_buf_attach_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_attach_ktype = { + .sysfs_ops = &dma_buf_attach_stats_sysfs_ops, + .release = dma_buf_attach_sysfs_release, + .default_groups = dma_buf_attach_stats_default_groups, +}; + +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = attach->sysfs_entry; + if (!sysfs_entry) + return; + + sysfs_delete_link(&sysfs_entry->kobj, &attach->dev->kobj, "device"); + + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + int ret; + struct dma_buf *dmabuf; + + if (!attach) + return -EINVAL; + + dmabuf = attach->dmabuf; + + sysfs_entry = kzalloc(sizeof(struct dma_buf_attach_sysfs_entry), + GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dmabuf->sysfs_entry->attach_stats_kset; + + attach->sysfs_entry = sysfs_entry; + + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_attach_ktype, + NULL, "%u", uid); + if (ret) + goto kobj_err; + + ret = sysfs_create_link(&sysfs_entry->kobj, &attach->dev->kobj, + "device"); + if (ret) + goto link_err; + + return 0; + +link_err: + kobject_del(&sysfs_entry->kobj); +kobj_err: + kobject_put(&sysfs_entry->kobj); + attach->sysfs_entry = NULL; + + return ret; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = dmabuf->sysfs_entry; + if (!sysfs_entry) + return; + + kset_unregister(sysfs_entry->attach_stats_kset); + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + + +/* Statistics files do not need to send uevents. */ +static int dmabuf_sysfs_uevent_filter(struct kset *kset, struct kobject *kobj) +{ + return 0; +} + +static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { + .filter = dmabuf_sysfs_uevent_filter, +}; + +static struct kset *dma_buf_stats_kset; +static struct kset *dma_buf_per_buffer_stats_kset; +int dma_buf_init_sysfs_statistics(void) +{ + dma_buf_stats_kset = kset_create_and_add("dmabuf", + &dmabuf_sysfs_no_uevent_ops, + kernel_kobj); + if (!dma_buf_stats_kset) + return -ENOMEM; + + dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", + &dmabuf_sysfs_no_uevent_ops, + &dma_buf_stats_kset->kobj); + if (!dma_buf_per_buffer_stats_kset) { + kset_unregister(dma_buf_stats_kset); + return -ENOMEM; + } + + return 0; +} + +void dma_buf_uninit_sysfs_statistics(void) +{ + kset_unregister(dma_buf_per_buffer_stats_kset); + kset_unregister(dma_buf_stats_kset); +} + +int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + int ret; + struct kset *attach_stats_kset; + + if (!dmabuf || !dmabuf->file) + return -EINVAL; + + if (!dmabuf->exp_name) { + pr_err("exporter name must not be empty if stats needed\n"); + return -EINVAL; + } + + sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; + sysfs_entry->dmabuf = dmabuf; + + dmabuf->sysfs_entry = sysfs_entry; + + /* create the directory for buffer stats */ + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino); + if (ret) + goto err_sysfs_dmabuf; + + /* create the directory for attachment stats */ + attach_stats_kset = kset_create_and_add("attachments", + &dmabuf_sysfs_no_uevent_ops, + &sysfs_entry->kobj); + if (!attach_stats_kset) { + ret = -ENOMEM; + goto err_sysfs_attach; + } + + sysfs_entry->attach_stats_kset = attach_stats_kset; + + return 0; + +err_sysfs_attach: + kobject_del(&sysfs_entry->kobj); +err_sysfs_dmabuf: + kobject_put(&sysfs_entry->kobj); + dmabuf->sysfs_entry = NULL; + return ret; +} diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h new file mode 100644 index 000000000000..5f4703249117 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#ifndef _DMA_BUF_SYSFS_STATS_H +#define _DMA_BUF_SYSFS_STATS_H + +#ifdef CONFIG_DMABUF_SYSFS_STATS + +int dma_buf_init_sysfs_statistics(void); +void dma_buf_uninit_sysfs_statistics(void); + +int dma_buf_stats_setup(struct dma_buf *dmabuf); +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid); +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) +{ + struct dma_buf_attach_sysfs_entry *entry = attach->sysfs_entry; + + entry->map_counter += delta; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf); +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach); +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *entry = dmabuf->sysfs_entry; + + return entry->attachment_uid++; +} +#else + +static inline int dma_buf_init_sysfs_statistics(void) +{ + return 0; +} + +static inline void dma_buf_uninit_sysfs_statistics(void) {} + +static inline int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + return 0; +} +static inline int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + return 0; +} + +static inline void dma_buf_stats_teardown(struct dma_buf *dmabuf) {} +static inline void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) {} +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) {} +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + return 0; +} +#endif +#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f264b70c383e..184dd7acb1ed 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -29,6 +29,8 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> +#include "dma-buf-sysfs-stats.h" + static inline int is_dma_buf_file(struct file *); struct dma_buf_list { @@ -79,6 +81,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + dma_buf_stats_teardown(dmabuf); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); @@ -580,6 +583,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file->f_mode |= FMODE_LSEEK; dmabuf->file = file; + ret = dma_buf_stats_setup(dmabuf); + if (ret) + goto err_sysfs; + mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); @@ -589,6 +596,14 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return dmabuf; +err_sysfs: + /* + * Set file->f_path.dentry->d_fsdata to NULL so that when + * dma_buf_release() gets invoked by dentry_ops, it exits + * early before calling the release() dma_buf op. + */ + file->f_path.dentry->d_fsdata = NULL; + fput(file); err_dmabuf: kfree(dmabuf); err_module: @@ -723,6 +738,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, { struct dma_buf_attachment *attach; int ret; + unsigned int attach_uid; if (WARN_ON(!dmabuf || !dev)) return ERR_PTR(-EINVAL); @@ -748,8 +764,13 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, } dma_resv_lock(dmabuf->resv, NULL); list_add(&attach->node, &dmabuf->attachments); + attach_uid = dma_buf_update_attach_uid(dmabuf); dma_resv_unlock(dmabuf->resv); + ret = dma_buf_attach_stats_setup(attach, attach_uid); + if (ret) + goto err_sysfs; + /* When either the importer or the exporter can't handle dynamic * mappings we cache the mapping here to avoid issues with the * reservation object lock. @@ -776,6 +797,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, dma_resv_unlock(attach->dmabuf->resv); attach->sgt = sgt; attach->dir = DMA_BIDIRECTIONAL; + dma_buf_update_attachment_map_count(attach, 1 /* delta */); } return attach; @@ -792,6 +814,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); +err_sysfs: dma_buf_detach(dmabuf, attach); return ERR_PTR(ret); } @@ -841,6 +864,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dma_resv_lock(attach->dmabuf->resv, NULL); __unmap_dma_buf(attach, attach->sgt, attach->dir); + dma_buf_update_attachment_map_count(attach, -1 /* delta */); if (dma_buf_is_dynamic(attach->dmabuf)) { dma_buf_unpin(attach); @@ -854,6 +878,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (dmabuf->ops->detach) dmabuf->ops->detach(dmabuf, attach); + dma_buf_attach_stats_teardown(attach); kfree(attach); } EXPORT_SYMBOL_GPL(dma_buf_detach); @@ -993,6 +1018,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, } #endif /* CONFIG_DMA_API_DEBUG */ + if (!IS_ERR(sg_table)) + dma_buf_update_attachment_map_count(attach, 1 /* delta */); + return sg_table; } EXPORT_SYMBOL_GPL(dma_buf_map_attachment); @@ -1030,6 +1058,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (dma_buf_is_dynamic(attach->dmabuf) && !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) dma_buf_unpin(attach); + + dma_buf_update_attachment_map_count(attach, -1 /* delta */); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); @@ -1480,6 +1510,12 @@ static inline void dma_buf_uninit_debugfs(void) static int __init dma_buf_init(void) { + int ret; + + ret = dma_buf_init_sysfs_statistics(); + if (ret) + return ret; + dma_buf_mnt = kern_mount(&dma_buf_fs_type); if (IS_ERR(dma_buf_mnt)) return PTR_ERR(dma_buf_mnt); @@ -1495,5 +1531,6 @@ static void __exit dma_buf_deinit(void) { dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); + dma_buf_uninit_sysfs_statistics(); } __exitcall(dma_buf_deinit); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index efdc56b9d95f..342585bd6dff 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -295,6 +295,9 @@ struct dma_buf_ops { * @poll: for userspace poll support * @cb_excl: for userspace poll support * @cb_shared: for userspace poll support + * @sysfs_entry: for exposing information about this buffer in sysfs. + * The attachment_uid member of @sysfs_entry is protected by dma_resv lock + * and is incremented on each attach. * * This represents a shared buffer, created by calling dma_buf_export(). The * userspace representation is a normal file descriptor, which can be created by @@ -330,6 +333,15 @@ struct dma_buf { __poll_t active; } cb_excl, cb_shared; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_sysfs_entry { + struct kobject kobj; + struct dma_buf *dmabuf; + unsigned int attachment_uid; + struct kset *attach_stats_kset; + } *sysfs_entry; +#endif }; /** @@ -379,6 +391,7 @@ struct dma_buf_attach_ops { * @importer_ops: importer operations for this attachment, if provided * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. * @importer_priv: importer specific attachment data. + * @sysfs_entry: For exposing information about this attachment in sysfs. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -399,6 +412,13 @@ struct dma_buf_attachment { const struct dma_buf_attach_ops *importer_ops; void *importer_priv; void *priv; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_attach_sysfs_entry { + struct kobject kobj; + unsigned int map_counter; + } *sysfs_entry; +#endif }; /** -- 2.32.0.rc0.204.g9fa02ecfa5-goog

2 2

[PATCH v3 0/7] drm/i915: Finish conversion to GRAPHICS_VER
by Lucas De Marchi 03 Jun '21

03 Jun '21

v3 is a resend from v2 (https://patchwork.freedesktop.org/series/90693/) now with dri-devel Cc'ed. Notice that this patch series can be applied splitting it up through the trees, it's not necessary to apply them together. The intention is to apply first 3 patches on drm-intel-gt-next and the remaining on drm-intel-next. I'm intentionally _not_ removing the INTEL_GEN/IS_GEN/IS_GEN_RANGE macros now. A few days/weeks after this is applied and when drm-intel-gt-next and drm-intel-next is back in sync, we can remove any leftovers that went in and remove the macros via a topic branch. Latest version of previous series "drm/i915: Extend GEN renames to the rest of the driver" (https://patchwork.freedesktop.org/series/88825/) dropped one patch converting all the instances of IS_GEN() and INTEL_GEN() to GRAPHICS_VER() due to the patches changing the meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of IS_GRAPHICS_RANGE(). I couldn't find a way to convince coccinelle to fix all places, so I just did it manually in separate commits the places that were not updated. Finish the conversion splitting the changes so it can go to the different branches (drm-intel-gt-next and drm-intel-next). I also split the gvt changes, but I think it would be easier to take this directly on drm-intel-next. v2: update commit messages with the proper semantic patch (Matt Roper) and regenerate the patches to also convert changes that got added in between. v3: resend with dri-devel Cc'ed since we are touching gt/gem/core. Also, let's get an ack on merge strategy Cc: intel-gvt-dev(a)lists.freedesktop.org Cc: Zhenyu Wang <zhenyuw(a)linux.intel.com> Lucas De Marchi (7): drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gt: Add remaining conversions to GRAPHICS_VER drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER drm/i915: replace IS_GEN and friends with GRAPHICS_VER drm/i915: Add remaining conversions to GRAPHICS_VER drm/i915/display: replace IS_GEN() in commented code drivers/gpu/drm/i915/display/intel_tv.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- .../gpu/drm/i915/gem/i915_gem_object_blt.c | 8 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 16 ++-- drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 12 +-- .../i915/gem/selftests/i915_gem_client_blt.c | 10 +-- .../i915/gem/selftests/i915_gem_coherency.c | 4 +- .../drm/i915/gem/selftests/i915_gem_context.c | 16 ++-- .../drm/i915/gem/selftests/i915_gem_mman.c | 14 ++-- .../drm/i915/gem/selftests/igt_gem_utils.c | 10 +-- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 40 +++++----- drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 ++++++------- drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +- .../drm/i915/gt/intel_execlists_submission.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 ++++---- drivers/gpu/drm/i915/gt/intel_gt.c | 27 ++++--- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 12 +-- drivers/gpu/drm/i915/gt/intel_gt_irq.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_llc.c | 6 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +++++------ drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++-- .../gpu/drm/i915/gt/intel_ring_submission.c | 64 +++++++-------- drivers/gpu/drm/i915/gt/intel_rps.c | 60 +++++++------- drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +++++++-------- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +- drivers/gpu/drm/i915/gt/selftest_llc.c | 4 +- drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_rc6.c | 4 +- .../drm/i915/gt/selftest_ring_submission.c | 6 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 16 ++-- drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-- drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +- drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 6 +- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +- drivers/gpu/drm/i915/gvt/vgpu.c | 4 +- drivers/gpu/drm/i915/i915_cmd_parser.c | 10 +-- drivers/gpu/drm/i915/i915_debugfs.c | 32 ++++---- drivers/gpu/drm/i915/i915_drv.c | 20 ++--- drivers/gpu/drm/i915/i915_drv.h | 37 +++++---- drivers/gpu/drm/i915/i915_gem.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 80 +++++++++---------- drivers/gpu/drm/i915/i915_irq.c | 34 ++++---- drivers/gpu/drm/i915/i915_perf.c | 44 +++++----- drivers/gpu/drm/i915/i915_pmu.c | 8 +- drivers/gpu/drm/i915/i915_reg.h | 26 +++--- drivers/gpu/drm/i915/i915_request.c | 4 +- drivers/gpu/drm/i915/i915_suspend.c | 16 ++-- drivers/gpu/drm/i915/i915_sysfs.c | 2 +- drivers/gpu/drm/i915/i915_vgpu.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 22 ++--- drivers/gpu/drm/i915/intel_dram.c | 14 ++-- drivers/gpu/drm/i915/intel_pch.c | 10 +-- drivers/gpu/drm/i915/intel_pm.c | 14 ++-- drivers/gpu/drm/i915/intel_sideband.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 26 +++--- drivers/gpu/drm/i915/intel_wopcm.c | 10 +-- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/gpu/drm/i915/selftests/i915_perf.c | 6 +- drivers/gpu/drm/i915/selftests/i915_request.c | 8 +- drivers/gpu/drm/i915/selftests/igt_spinner.c | 12 +-- drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +- 93 files changed, 634 insertions(+), 634 deletions(-) -- 2.31.1

1 7

[PATCH 00/29] drm/i915/gem: ioctl clean-ups (v6)
by Jason Ekstrand 03 Jun '21

03 Jun '21

Overview: --------- This patch series attempts to clean up some of the IOCTL mess we've created over the last few years. The most egregious bit being context mutability. In summary, this series: 1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP 2. Drops the entire CONTEXT_CLONE API 3. Implements SINGLE_TIMELINE with a syncobj instead of actually sharing intel_timeline between engines. 4. Adds a few sanity restrictions to the balancing/bonding API. 5. Implements a proto-ctx mechanism so that the engine set and VM can only be set early on in the lifetime of a context, before anything ever executes on it. This effectively makes the VM and engine set immutable. This series has been tested with IGT as well as the Iris, ANV, and the Intel media driver doing an 8K decode (this uses bonding/balancing). I've also done quite a bit of git archeology to ensure that nothing in here will break anything that's already shipped at some point in history. It's possible I've missed something, but I've dug quite a bit. Details and motivation: ----------------------- In very broad strokes, there's an effort going on right now within Intel to try and clean up and simplify i915 anywhere we can. We obviously don't want to break any shipping userspace but, as can be seen by this series, there's a lot i915 theoretically supports which userspace doesn't actually need. Some of this, like the two context params used here, were simply oversights where we went through the usual API review process and merged the i915 bits but the userspace bits never landed for some reason. Not all are so innocent, however. For instance, there's an entire context cloning API which allows one to create a context with certain parameters "cloned" from some other context. This entire API has never been used by any userspace except IGT and there were never patches to any other userspace to use it. It never should have landed. Also, when we added support for setting explicit engine sets and sharing VMs across contexts, people decided to do so via SET_CONTEXT_PARAM. While this allowed them to re-use existing API, it did so at the cost of making those states mutable which leads to a plethora of potential race conditions. There were even IGT tests merged to cover some of theses: - gem_vm_create@async-destroy and gem_vm_create@destroy-race which test swapping out the VM on a running context. - gem_ctx_persistence@replace* which test whether a client can escape a non-persistent context by submitting a hanging batch and then swapping out the engine set before the hang is detected. - api_intel_bb@bb-with-vm which tests the that intel_bb_assign_vm works properly. This API is never used by any other IGT test. There is also an entire deferred flush and set state framework in i915_gem_cotnext.c which exists for safely swapping out the VM while there is work in-flight on a context. So, clearly people knew that this API was inherently racy and difficult to implement but they landed it anyway. Why? The best explanation I've been given is because it makes the API more "unified" or "symmetric" for this stuff to go through SET_CONTEXT_PARAM. It's not because any userspace actually wants to be able to swap out the VM or the set of engines on a running context. That would be utterly insane. This patch series cleans up this particular mess by introducing the concept of a i915_gem_proto_context data structure which contains context creation information. When you initially call GEM_CONTEXT_CREATE, a proto-context in created instead of an actual context. Then, the first time something is done on the context besides SET_CONTEXT_PARAM, an actual context is created. This allows us to keep the old drivers which use SET_CONTEXT_PARAM to set up the engine set (see also media) while ensuring that, once you have an i915_gem_context, the VM and the engine set are immutable state. Eventually, there are more clean-ups I'd like to do on top of this which should make working with contexts inside i915 simpler and safer: 1. Move the GEM handle -> vma LUT from i915_gem_context into either i915_ppgtt or drm_i915_file_private depending on whether or not the hardware has a full PPGTT. 2. Move the delayed context destruction code into intel_context or a per-engine wrapper struct rather than i915_gem_context. 3. Get rid of the separation between context close and context destroy 4. Get rid of the RCU on i915_gem_context However, these should probably be done as a separate patch series as this one is already starting to get longish, especially if you consider the 89 IGT patches that go along with it. Test-with: 20210423033253.792669-1-jason(a)jlekstrand.net Jason Ekstrand (29): drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE drm/i915: Stop storing the ring size in the ring pointer (v2) drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2) drm/i915/gem: Return void from context_apply_all drm/i915: Drop the CONTEXT_CLONE API (v2) drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES drm/i915/gem: Disallow bonding of virtual engines (v3) drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2) drm/i915/request: Remove the hook from await_execution drm/i915/gem: Disallow creating contexts with too many engines drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2) drm/i915/gem: Add a separate validate_priority helper drm/i915: Add gem/i915_gem_context.h to the docs drm/i915/gem: Add an intermediate proto_context struct drm/i915/gem: Rework error handling in default_engines drm/i915/gem: Optionally set SSEU in intel_context_set_gem drm/i915: Add an i915_gem_vm_lookup helper drm/i915/gem: Make an alignment check more sensible drm/i915/gem: Use the proto-context to handle create parameters (v2) drm/i915/gem: Return an error ptr from context_lookup drm/i915/gt: Drop i915_address_space::file (v2) drm/i915/gem: Delay context creation drm/i915/gem: Don't allow changing the VM on running contexts (v2) drm/i915/gem: Don't allow changing the engine set on running contexts (v2) drm/i915/selftests: Take a VM in kernel_context() i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec drm/i915/gem: Roll all of context creation together Documentation/gpu/i915.rst | 2 + drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/gem/i915_gem_context.c | 3006 ++++++++--------- drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 198 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 31 +- .../drm/i915/gem/selftests/i915_gem_context.c | 127 +- .../gpu/drm/i915/gem/selftests/mock_context.c | 67 +- .../gpu/drm/i915/gem/selftests/mock_context.h | 4 +- drivers/gpu/drm/i915/gt/intel_context.c | 3 +- drivers/gpu/drm/i915/gt/intel_context.h | 5 - drivers/gpu/drm/i915/gt/intel_context_param.c | 63 - drivers/gpu/drm/i915/gt/intel_context_param.h | 6 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 1 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 - .../drm/i915/gt/intel_execlists_submission.c | 114 - .../drm/i915/gt/intel_execlists_submission.h | 7 - drivers/gpu/drm/i915/gt/intel_gtt.h | 11 - drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 251 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 30 +- drivers/gpu/drm/i915/i915_perf.c | 4 +- drivers/gpu/drm/i915/i915_request.c | 42 +- drivers/gpu/drm/i915/i915_request.h | 4 +- .../drm/i915/selftests/i915_mock_selftests.h | 1 - drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 - include/uapi/drm/i915_drm.h | 40 +- 31 files changed, 1656 insertions(+), 2388 deletions(-) delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c -- 2.31.1

2 46

[PATCH 0/1] Introduce i915_sched_engine object
by Matthew Brost 03 Jun '21

03 Jun '21

As discussed in [1] we are breaking that large series into a several smaller ones. This series is stand alone patch part of step #4 which has no other dependencies or patches relevant to it. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> [1] https://patchwork.freedesktop.org/series/89844/ Matthew Brost (1): drm/i915: Introduce i915_sched_engine object drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine.h | 16 - drivers/gpu/drm/i915/gt/intel_engine_cs.c | 77 ++-- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 10 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 42 +-- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../drm/i915/gt/intel_execlists_submission.c | 350 +++++++++++------- .../gpu/drm/i915/gt/intel_ring_submission.c | 13 +- drivers/gpu/drm/i915/gt/mock_engine.c | 17 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 36 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 75 ++-- drivers/gpu/drm/i915/i915_gpu_error.c | 7 +- drivers/gpu/drm/i915/i915_request.c | 50 +-- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/i915_scheduler.c | 168 ++++----- drivers/gpu/drm/i915/i915_scheduler.h | 65 +++- drivers/gpu/drm/i915/i915_scheduler_types.h | 63 ++++ 21 files changed, 575 insertions(+), 440 deletions(-) -- 2.28.0

3 7

[PATCH 0/5] drm/i915: Get rid of fence error propagation (v2)
by Jason Ekstrand 03 Jun '21

03 Jun '21

Fence error propagation is sketchy at best. Instead of explicitly handling fences which might have errors set in the code which is aware of errors, we just kick them down the line and hope that userspace knows what to do when a wait eventually fails. This is sketchy at best because most userspace isn't prepared to handle errors in those places. To make things worse, it allows errors to propagate across processes in unpredictable ways. This is causing hangs in one client to kill X11. Unfortunately, there's no quick path from here to there thanks to the fact that we're now running the command parser asynchronously and relying on fence errors for when it fails. This series first gets rid of asynchronous command parsing and then cleans up from there. There was never any real use-case for asynchronous parsing and the platforms that rely heavily on the command parser are old enough (Gen7) that, when we changed the way the command parser works, it wasn't really a change anyone was asking for anyway. I think we probably want this whole mess back-ported. I'm happy to take suggestions on the strategy there because the history there is a bit annoying and I'm not 100% sure where the Linux release cuts land. In any case, I'm happy to make a version of this series per-release if needed for Greg to back-port. v2 (Daniel Vetter): - Re-order to put the reverts first - Add ACKs from Daniel - Add better CC and Fixes tags Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Jason Ekstrand (5): drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" Revert "drm/i915: Propagate errors on awaiting already signaled fences" drm/i915: Remove allow_alloc from i915_gem_object_get_sg* drm/i915: Drop error handling from dma_fence_work Revert "drm/i915: Skip over MI_NOOP when parsing" drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 227 +----------------- drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +- .../i915/gem/selftests/i915_gem_execbuffer.c | 4 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- drivers/gpu/drm/i915/i915_cmd_parser.c | 199 ++++++++------- drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_request.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 +- drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +- drivers/gpu/drm/i915/i915_vma.c | 3 +- 12 files changed, 141 insertions(+), 351 deletions(-) -- 2.31.1

1 5

[PATCH 0/5] drm/i915: Get rid of fence error propagation
by Jason Ekstrand 03 Jun '21

03 Jun '21

Fence error propagation is sketchy at best. Instead of explicitly handling fences which might have errors set in the code which is aware of errors, we just kick them down the line and hope that userspace knows what to do when a wait eventually fails. This is sketchy at best because most userspace isn't prepared to handle errors in those places. To make things worse, it allows errors to propagate across processes in unpredictable ways. This is causing hangs in one client to kill X11. Unfortunately, there's no quick path from here to there thanks to the fact that we're now running the command parser asynchronously and relying on fence errors for when it fails. This series first gets rid of asynchronous command parsing and then cleans up from there. There was never any real use-case for asynchronous parsing and the platforms that rely heavily on the command parser are old enough (Gen7) that, when we changed the way the command parser works, it wasn't really a change anyone was asking for anyway. I think we probably want this whole mess back-ported. I'm happy to take suggestions on the strategy there because the history there is a bit annoying and I'm not 100% sure where the Linux release cuts land. In any case, I'm happy to make a version of this series per-release if needed for Greg to back-port. Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Jason Ekstrand (5): drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" drm/i915: Remove allow_alloc from i915_gem_object_get_sg* drm/i915: Drop error handling from dma_fence_work Revert "drm/i915: Propagate errors on awaiting already signaled fences" Revert "drm/i915: Skip over MI_NOOP when parsing" drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 227 +----------------- drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +- .../i915/gem/selftests/i915_gem_execbuffer.c | 4 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- drivers/gpu/drm/i915/i915_cmd_parser.c | 199 ++++++++------- drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_request.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 +- drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +- drivers/gpu/drm/i915/i915_vma.c | 3 +- 12 files changed, 141 insertions(+), 351 deletions(-) -- 2.31.1

2 13

[GIT PULL] drm/tegra: Fixes for v5.13-rc5
by Thierry Reding 03 Jun '21

03 Jun '21

Hi Dave, The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5: Linux 5.13-rc1 (2021-05-09 14:17:44 -0700) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.13-rc5 for you to fetch changes up to 671cc352acd3e2b2832b59787ed8027d9f80ccc9: drm/tegra: Correct DRM_FORMAT_MOD_NVIDIA_SECTOR_LAYOUT (2021-05-31 14:29:44 +0200) Thanks, Thierry ---------------------------------------------------------------- drm/tegra: Fixes for v5.13-rc5 The most important change here fixes a race condition that causes either HDA or (more frequently) display to malfunction because they race for enabling the SOR power domain at probe time. Other than that, there's a couple of build warnings for issues introduced in v5.13 as well as some minor fixes, such as reference leak plugs. ---------------------------------------------------------------- Dmitry Osipenko (1): drm/tegra: Correct DRM_FORMAT_MOD_NVIDIA_SECTOR_LAYOUT Lyude Paul (1): drm/tegra: Get ref for DP AUX channel, not its ddc adapter Nathan Chancellor (1): drm/tegra: Fix shift overflow in tegra_shared_plane_atomic_update Pavel Machek (CIP) (1): drm/tegra: sor: Do not leak runtime PM reference Thierry Reding (3): gpu: host1x: Split up client initalization and registration drm/tegra: sor: Fully initialize SOR before registration drm/tegra: sor: Fix AUX device reference leak drivers/gpu/drm/tegra/drm.h | 2 +- drivers/gpu/drm/tegra/hub.c | 2 +- drivers/gpu/drm/tegra/sor.c | 70 +++++++++++++++++++++++++++------------------ drivers/gpu/host1x/bus.c | 30 +++++++++++++++---- include/linux/host1x.h | 30 +++++++++++++++---- 5 files changed, 92 insertions(+), 42 deletions(-)

1 0

[PATCH 0/5] drm/i915: Move system memory to TTM for discrete
by Thomas Hellström 03 Jun '21

03 Jun '21

Early implementation of moving system memory for discrete cards over to TTM. We first add the notion of objects being migratable under the object lock to i915 gem, and add some asserts to verify that objects are either locked or pinned when the placement is checked by the gem code. Patch 2 and 3 deals with updating the i915 gem bookkeeping after a TTM move, Patch 4 moves system over from shmem to TTM for discrete and finally the last patch is more to be considered an RFC for migration implementation. Much of this code is not testing covered, so we might have to add some selftests as well. Meanwhile this should not be merged but may well be reviewed. Note that the mock device doesn't consider itself discrete so the TTM system path is not checked by the mock selftests. Also testing if CI can handle base-commit: and prerequisite-patch-id: Thomas Hellström (5): drm/i915: Update object placement flags to be mutable drm/i915/ttm: Adjust gem flags and caching settings after a move drm/i915/ttm: Calculate the object placement at get_pages time drm/i915/ttm: Use TTM for system memory drm/i915/ttm: Implement object migration drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 138 +++++++++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 24 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 +++++++++++++++--- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +- .../drm/i915/gem/selftests/huge_gem_object.c | 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 5 +- .../drm/i915/gem/selftests/i915_gem_mman.c | 4 +- .../drm/i915/gem/selftests/i915_gem_phys.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/i915/intel_memory_region.c | 7 +- drivers/gpu/drm/i915/intel_memory_region.h | 8 + drivers/gpu/drm/i915/intel_region_ttm.c | 8 +- drivers/gpu/drm/i915/intel_region_ttm.h | 2 + 19 files changed, 437 insertions(+), 92 deletions(-) base-commit: cd6eb5f605478f2fff85ec7ac39b7cf445d3deb9 prerequisite-patch-id: b3e7766bc492d04a5ace71fd0d4259689f3bd749 prerequisite-patch-id: 7978430e513e204addd7bc9bef63fd3a9ea25d7c prerequisite-patch-id: f6aa8d141b22b8e532f8152e53f9c913f98458df prerequisite-patch-id: 6486c9db619d88a3e9a4ffc01a89bdc722941a67 prerequisite-patch-id: b71878b47e3be71748aacb5d1b3955853bf80de5 prerequisite-patch-id: 1b67c82c32c02dfdb1217f224652276e044fb549 prerequisite-patch-id: 5229db39ec27eb77a8417ed7c9d54af40e0e9f33 prerequisite-patch-id: b66b1893401cc526b4466ea3c427512261d33dfd prerequisite-patch-id: 706521b6f4858cf4d9ecd83102b347e695b96bb7 prerequisite-patch-id: 686dc7cfea6361c4adabc963996dc3d0d41b28b1 prerequisite-patch-id: 7be87140130a9c2d62a190ceafdacdebd51c5196 -- 2.31.1

2 12

[PATCH -next] drm/etnaviv: Remove unneeded if-null-free check
by Zheng Yongjun 03 Jun '21

03 Jun '21

Eliminate the following coccicheck warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Zheng Yongjun <zhengyongjun3(a)huawei.com> --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index b390dd4d60b7..d741b1d735f7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(&etnaviv_obj->base, etnaviv_obj->sgt); } -- 2.25.1

2 1

← Newer
1
...
79
80
81
82
83
84
85
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021