Linaro-mm-sig December 2020

linaro-mm-sig@lists.linaro.org

9 participants
27 discussions

Re: [Linaro-mm-sig] [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)

by Daniel Vetter

On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote: > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote: > > Explicit synchronization is the future. At least, that seems to be what > > most userspace APIs are agreeing on at this point. However, most of our > > Linux APIs (both userspace and kernel UAPI) are currently built around > > implicit synchronization with dma-buf. While work is ongoing to change > > many of the userspace APIs and protocols to an explicit synchronization > > model, switching over piecemeal is difficult due to the number of > > potential components involved. On the kernel side, many drivers use > > dma-buf including GPU (3D/compute), display, v4l, and others. In > > userspace, we have X11, several Wayland compositors, 3D drivers, compute > > drivers (OpenCL etc.), media encode/decode, and the list goes on. > > > > This patch provides a path forward by allowing userspace to manually > > manage the fences attached to a dma-buf. Alternatively, one can think > > of this as making dma-buf's implicit synchronization simply a carrier > > for an explicit fence. This is accomplished by adding two IOCTLs to > > dma-buf for importing and exporting a sync file to/from the dma-buf. > > This way a userspace component which is uses explicit synchronization, > > such as a Vulkan driver, can manually set the write fence on a buffer > > before handing it off to an implicitly synchronized component such as a > > Wayland compositor or video encoder. In this way, each of the different > > components can be upgraded to an explicit synchronization model one at a > > time as long as the userspace pieces connecting them are aware of it and > > import/export fences at the right times. > > > > There is a potential race condition with this API if userspace is not > > careful. A typical use case for implicit synchronization is to wait for > > the dma-buf to be ready, use it, and then signal it for some other > > component. Because a sync_file cannot be created until it is guaranteed > > to complete in finite time, userspace can only signal the dma-buf after > > it has already submitted the work which uses it to the kernel and has > > received a sync_file back. There is no way to atomically submit a > > wait-use-signal operation. This is not, however, really a problem with > > this API so much as it is a problem with explicit synchronization > > itself. The way this is typically handled is to have very explicit > > ownership transfer points in the API or protocol which ensure that only > > one component is using it at any given time. Both X11 (via the PRESENT > > extension) and Wayland provide such ownership transfer points via > > explicit present and idle messages. > > > > The decision was intentionally made in this patch to make the import and > > export operations IOCTLs on the dma-buf itself rather than as a DRM > > IOCTL. This makes it the import/export operation universal across all > > components which use dma-buf including GPU, display, v4l, and others. > > It also means that a userspace component can do the import/export > > without access to the DRM fd which may be tricky to get in cases where > > the client communicates with DRM via a userspace API such as OpenGL or > > Vulkan. At a future date we may choose to add direct import/export APIs > > to components such as drm_syncobj to avoid allocating a file descriptor > > and going through two ioctls. However, that seems to be something of a > > micro-optimization as import/export operations are likely to happen at a > > rate of a few per frame of rendered or decoded video. > > > > v2 (Jason Ekstrand): > > - Use a wrapper dma_fence_array of all fences including the new one > > when importing an exclusive fence. > > > > v3 (Jason Ekstrand): > > - Lock around setting shared fences as well as exclusive > > - Mark SIGNAL_SYNC_FILE as a read-write ioctl. > > - Initialize ret to 0 in dma_buf_wait_sync_file > > > > v4 (Jason Ekstrand): > > - Use the new dma_resv_get_singleton helper > > > > v5 (Jason Ekstrand): > > - Rename the IOCTLs to import/export rather than wait/signal > > - Drop the WRITE flag and always get/set the exclusive fence > > > > Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> > > What's the status of this? DMA_BUF_IOCTL_EXPORT_SYNC_FILE would be useful > for Wayland compositors to wait for client buffers to become ready without > being prone to getting delayed by later HW access to them, so it would be > nice to merge that at least (if DMA_BUF_IOCTL_IMPORT_SYNC_FILE is still > controversial). I think the missing bits are just the usual stuff - igt testcases - userspace using the new ioctls - review of the entire pile I don't think there's any fundamental objections aside from "no one ever pushed this over the finish line". Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 1 month

Re: [Linaro-mm-sig] [PATCH] cma_heap: fix implicit function declaration

by John Stultz

On Thu, Dec 17, 2020 at 4:31 AM <siyanteng01(a)gmail.com> wrote: > > From: siyanteng <siyanteng01(a)gmail.com> > > When building cma_heap the following error shows up: > > drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] > 195 | vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL); > | ^~~~ > | kmap > > Use this include: linux-next/include/linux/vmalloc.h > > Signed-off-by: siyanteng <siyanteng01(a)gmail.com> Thanks for submitting this! My apologies for the trouble! We already have a similar patch queued here: https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-next-fixes&id=… so hopefully that will land upstream soon. thanks again! -john

3 years, 4 months

[PATCH 1/4] dma-buf: Remove kmap kerneldoc vestiges

by Daniel Vetter

Also try to clarify a bit when dma_buf_begin/end_cpu_access should be called. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 20 ++++++++++++++------ include/linux/dma-buf.h | 25 +++++++++---------------- 2 files changed, 23 insertions(+), 22 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index e63684d4cd90..a12fdffa130f 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1001,15 +1001,15 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify); * vmalloc space might be limited and result in vmap calls failing. * * Interfaces:: + * * void \*dma_buf_vmap(struct dma_buf \*dmabuf) * void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr) * * The vmap call can fail if there is no vmap support in the exporter, or if - * it runs out of vmalloc space. Fallback to kmap should be implemented. Note - * that the dma-buf layer keeps a reference count for all vmap access and - * calls down into the exporter's vmap function only when no vmapping exists, - * and only unmaps it once. Protection against concurrent vmap/vunmap calls is - * provided by taking the dma_buf->lock mutex. + * it runs out of vmalloc space. Note that the dma-buf layer keeps a reference + * count for all vmap access and calls down into the exporter's vmap function + * only when no vmapping exists, and only unmaps it once. Protection against + * concurrent vmap/vunmap calls is provided by taking the &dma_buf.lock mutex. * * - For full compatibility on the importer side with existing userspace * interfaces, which might already support mmap'ing buffers. This is needed in @@ -1098,6 +1098,11 @@ static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf, * dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is * it guaranteed to be coherent with other DMA access. * + * This function will also wait for any DMA transactions tracked through + * implicit synchronization in &dma_buf.resv. For DMA transactions with explicit + * synchronization this function will only ensure cache coherency, callers must + * ensure synchronization with such DMA transactions on their own. + * * Can return negative error values, returns 0 on success. */ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, @@ -1199,7 +1204,10 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap); * This call may fail due to lack of virtual mapping address space. * These calls are optional in drivers. The intended use for them * is for mapping objects linear in kernel space for high use objects. - * Please attempt to use kmap/kunmap before thinking about these interfaces. + * + * To ensure coherency users must call dma_buf_begin_cpu_access() and + * dma_buf_end_cpu_access() around any cpu access performed through this + * mapping. * * Returns 0 on success, or a negative errno code otherwise. */ diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index cf72699cb2bc..7eca37c8b10c 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -183,24 +183,19 @@ struct dma_buf_ops { * @begin_cpu_access: * * This is called from dma_buf_begin_cpu_access() and allows the - * exporter to ensure that the memory is actually available for cpu - * access - the exporter might need to allocate or swap-in and pin the - * backing storage. The exporter also needs to ensure that cpu access is - * coherent for the access direction. The direction can be used by the - * exporter to optimize the cache flushing, i.e. access with a different + * exporter to ensure that the memory is actually coherent for cpu + * access. The exporter also needs to ensure that cpu access is coherent + * for the access direction. The direction can be used by the exporter + * to optimize the cache flushing, i.e. access with a different * direction (read instead of write) might return stale or even bogus * data (e.g. when the exporter needs to copy the data to temporary * storage). * - * This callback is optional. + * Note that this is both called through the DMA_BUF_IOCTL_SYNC IOCTL + * command for userspace mappings established through @mmap, and also + * for kernel mappings established with @vmap. * - * FIXME: This is both called through the DMA_BUF_IOCTL_SYNC command - * from userspace (where storage shouldn't be pinned to avoid handing - * de-factor mlock rights to userspace) and for the kernel-internal - * users of the various kmap interfaces, where the backing storage must - * be pinned to guarantee that the atomic kmap calls can succeed. Since - * there's no in-kernel users of the kmap interfaces yet this isn't a - * real problem. + * This callback is optional. * * Returns: * @@ -216,9 +211,7 @@ struct dma_buf_ops { * * This is called from dma_buf_end_cpu_access() when the importer is * done accessing the CPU. The exporter can use this to flush caches and - * unpin any resources pinned in @begin_cpu_access. - * The result of any dma_buf kmap calls after end_cpu_access is - * undefined. + * undo anything else done in @begin_cpu_access. * * This callback is optional. * -- 2.29.2

3 years, 4 months

[PATCH] dmabuf: Add the capability to expose DMA-BUF stats in sysfs

by Hridya Valsaraju

This patch 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/<inode_number>/exporter_name /sys/kernel/dmabuf/<inode_number>/size /sys/kernel/dmabuf/<inode_number>/dev_map_info 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. Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs. This information is intended to help with root-causing low-memory kills and the debugging/analysis of other memory-related issues. It will also be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. [1]: https://lore.kernel.org/patchwork/patch/1088791/ Signed-off-by: Hridya Valsaraju <hridya(a)google.com> --- Documentation/ABI/testing/sysfs-kernel-dmabuf | 32 ++++ drivers/dma-buf/Kconfig | 11 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 162 ++++++++++++++++++ drivers/dma-buf/dma-buf-sysfs-stats.h | 37 ++++ drivers/dma-buf/dma-buf.c | 29 ++++ include/linux/dma-buf.h | 13 ++ 7 files changed, 285 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf 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 b/Documentation/ABI/testing/sysfs-kernel-dmabuf new file mode 100644 index 000000000000..02d407d57aaa --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf @@ -0,0 +1,32 @@ +What: /sys/kernel/dmabuf +Date: November 2020 +KernelVersion: v5.11 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: The /sys/kernel/dmabuf directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/<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/<inode_number>/exporter_name +Date: November 2020 +KernelVersion: v5.11 +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/<inode_number>/size +Dat: November 2020 +KernelVersion: v5.11 +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/<inode_number>/dev_map_info +Dat: November 2020 +KernelVersion: v5.11 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and lists the name of devices currently + mapping the DMA-BUF in a space-separated format. + diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4f8224a6ac95..2fed26f14548 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -64,6 +64,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. + + /sys/kernel/dmabuf/<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..bcbef81e0a5f --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -0,0 +1,162 @@ +// SPDX-License-Identifier: GPL-2.0-only + + +#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> + +#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 ssize_t dev_map_info_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + ssize_t ret; + struct dma_buf_attachment *attachment; + + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL); + if (ret) + return ret; + + list_for_each_entry(attachment, &dmabuf->attachments, node) { + if (attachment->map_counter) { + ret += sysfs_emit_at(buf, ret, "%s ", + dev_name(attachment->dev)); + } + } + dma_resv_unlock(dmabuf->resv); + + ret += sysfs_emit_at(buf, ret, "\n"); + return ret; +} + +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 dma_buf_stats_attribute dev_map_info_attribute = + __ATTR_RO(dev_map_info); + +static struct attribute *dma_buf_stats_default_attrs[] = { + &exporter_name_attribute.attr, + &size_attribute.attr, + &dev_map_info_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, +}; + +void dma_buf_sysfs_free(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = dmabuf->sysfs_entry; + if (!sysfs_entry) + return; + + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +static struct kset *dma_buf_stats_kset; +int dma_buf_init_sysfs_statistics(void) +{ + dma_buf_stats_kset = kset_create_and_add("dmabuf", NULL, kernel_kobj); + if (!dma_buf_stats_kset) + return -ENOMEM; + + return 0; +} + +void dma_buf_uninit_sysfs_statistics(void) +{ + kset_unregister(dma_buf_stats_kset); +} + +int dma_buf_init_stats_kobj(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + int ret; + + 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_stats_kset; + sysfs_entry->dmabuf = dmabuf; + + dmabuf->sysfs_entry = sysfs_entry; + + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino); + if (ret) + kobject_put(&sysfs_entry->kobj); + + 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..42fae7d1b11f --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h @@ -0,0 +1,37 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#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_init_stats_kobj(struct dma_buf *dmabuf); +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) +{ + attach->map_counter += delta; +} +void dma_buf_sysfs_free(struct dma_buf *dmabuf); + +#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_init_stats_kobj(struct dma_buf *dmabuf) +{ + return 0; +} +static inline void dma_buf_sysfs_free(struct dma_buf *dmabuf) {} +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) {} + +#endif +#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index e63684d4cd90..e93df0069bf8 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 { @@ -83,6 +85,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + dma_buf_sysfs_free(dmabuf); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); @@ -566,6 +569,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_init_stats_kobj(dmabuf); + if (ret) + goto err_sysfs; + mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); @@ -575,6 +582,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: @@ -732,6 +747,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; @@ -786,6 +802,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dma_resv_lock(attach->dmabuf->resv, NULL); dmabuf->ops->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); @@ -925,6 +942,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); @@ -962,6 +982,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); @@ -1399,6 +1421,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); @@ -1414,5 +1442,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 cf72699cb2bc..f5cab13afdfc 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -294,6 +294,7 @@ 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 * * This represents a shared buffer, created by calling dma_buf_export(). The * userspace representation is a normal file descriptor, which can be created by @@ -329,6 +330,13 @@ 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; + } *sysfs_entry; +#endif }; /** @@ -378,6 +386,8 @@ 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. + * @map_counter: Number of times the buffer has been mapped through this + * dma_buf_map_attachment. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -398,6 +408,9 @@ struct dma_buf_attachment { const struct dma_buf_attach_ops *importer_ops; void *importer_priv; void *priv; +#ifdef CONFIG_DMABUF_SYSFS_STATS + unsigned int map_counter; +#endif }; /** -- 2.29.2.576.ga3fc446d84-goog

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations

by Daniel Vetter

On Wed, Dec 09, 2020 at 03:25:22PM +0100, Thomas Zimmermann wrote: > The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are > allowed to pin the buffer or acquire the buffer's reservation object > lock. > > This is a problem for callers that only require a short-term mapping > of the buffer without the pinning, or callers that have special locking > requirements. These may suffer from unnecessary overhead or interfere > with regular pin operations. > > The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and > their rsp callbacks in struct dma_buf_ops provide an alternative without > pinning or reservation locking. Callers are responsible for these > operations. > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > --- > drivers/dma-buf/dma-buf.c | 80 +++++++++++++++++++++++++++++++++++++++ > include/linux/dma-buf.h | 34 +++++++++++++++++ > 2 files changed, 114 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index e63684d4cd90..be9f80190a66 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1265,6 +1265,86 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +/** > + * dma_buf_vmap_local - Create virtual mapping for the buffer object into kernel > + * address space. > + * @dmabuf: [in] buffer to vmap > + * @map: [out] returns the vmap pointer > + * > + * This call may fail due to lack of virtual mapping address space. > + * These calls are optional in drivers. The intended use for them > + * is for mapping objects linear in kernel space for high use objects. > + * Please attempt to use kmap/kunmap before thinking about these interfaces. We also need to specify whether callers need to call dma_buf_begin/end_cpu access around these or not. For current implementations it doesn't matter, but if you want to convert udl/gm12u320, it will. I think requiring an explicit call would be good, for more consistency with how normal vmap works. -Daniel > + * > + * Returns: > + * 0 on success, or a negative errno code otherwise. > + */ > +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map) > +{ > + struct dma_buf_map ptr; > + int ret = 0; > + > + dma_buf_map_clear(map); > + > + if (WARN_ON(!dmabuf)) > + return -EINVAL; > + > + dma_resv_assert_held(dmabuf->resv); > + > + if (!dmabuf->ops->vmap_local) > + return -EINVAL; > + > + mutex_lock(&dmabuf->lock); > + if (dmabuf->vmapping_counter) { > + dmabuf->vmapping_counter++; > + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr)); > + *map = dmabuf->vmap_ptr; > + goto out_unlock; > + } > + > + BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr)); > + > + ret = dmabuf->ops->vmap_local(dmabuf, &ptr); > + if (WARN_ON_ONCE(ret)) > + goto out_unlock; > + > + dmabuf->vmap_ptr = ptr; > + dmabuf->vmapping_counter = 1; > + > + *map = dmabuf->vmap_ptr; > + > +out_unlock: > + mutex_unlock(&dmabuf->lock); > + return ret; > +} > +EXPORT_SYMBOL_GPL(dma_buf_vmap_local); > + > +/** > + * dma_buf_vunmap_local - Unmap a vmap obtained by dma_buf_vmap_local. > + * @dmabuf: [in] buffer to vunmap > + * @map: [in] vmap pointer to vunmap > + */ > +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map) > +{ > + if (WARN_ON(!dmabuf)) > + return; > + > + dma_resv_assert_held(dmabuf->resv); > + > + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr)); > + BUG_ON(dmabuf->vmapping_counter == 0); > + BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map)); > + > + mutex_lock(&dmabuf->lock); > + if (--dmabuf->vmapping_counter == 0) { > + if (dmabuf->ops->vunmap_local) > + dmabuf->ops->vunmap_local(dmabuf, map); > + dma_buf_map_clear(&dmabuf->vmap_ptr); > + } > + mutex_unlock(&dmabuf->lock); > +} > +EXPORT_SYMBOL_GPL(dma_buf_vunmap_local); > + > #ifdef CONFIG_DEBUG_FS > static int dma_buf_debug_show(struct seq_file *s, void *unused) > { > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index cf72699cb2bc..f66580d23a9b 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -269,6 +269,38 @@ struct dma_buf_ops { > > int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); > void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); > + > + /** > + * @vmap_local: > + * > + * Creates a virtual mapping for the buffer into kernel address space. > + * > + * This callback establishes short-term mappings for situations where > + * callers only use the buffer for a bounded amount of time; such as > + * updates to the framebuffer or reading back contained information. > + * In contrast to the regular @vmap callback, vmap_local does never pin > + * the buffer to a specific domain or acquire the buffer's reservation > + * lock. > + * > + * This is called with the dmabuf->resv object locked. Callers must hold > + * the lock until after removing the mapping with @vunmap_local. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. > + */ > + int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > + > + /** > + * @vunmap_local: > + * > + * Removes a virtual mapping that wa sestablished by @vmap_local. > + * > + * This callback is optional. > + */ > + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > }; > > /** > @@ -506,4 +538,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, > unsigned long); > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > #endif /* __DMA_BUF_H__ */ > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker

by Daniel Vetter

On Fri, Dec 11, 2020 at 11:16:25AM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.12.20 um 11:01 schrieb Daniel Vetter: > > On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote: > > > Fbdev emulation has to lock the BO into place while flushing the shadow > > > buffer into the BO's memory. Remove any interference with pinning by > > > using vmap_local functionality (instead of full vmap). This requires > > > BO reservation locking in fbdev's damage worker. > > > > > > The new DRM client functions for locking and vmap_local functionality > > > are added for consistency with the existing style. > > > > > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > > > > The old vmap/vunmap in the client library aren't used anymore, please > > delete. That will also make it clearer in the diff what's going on and > > that it makes sense to have the client and fb-helper part in one patch. > > They are still around for perma-mapped BOs where HW supports it (really only > CMA-based drivers). See drm_fb_helper_generic_probe() and > drm_fbdev_cleanup(). Ah right I didn't grep this carefully enough. I guess in that case splitting this into the drm_client patch and fb-helper patch would be good I think. Also some kerneldoc commment addition for normal vmap that vmap_local is preferred for short-term mappings, and for vmap_local that _vmap() gives you the long term mapping. Just for more links and stuff in docs. With that: Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> -Daniel > > Best regards > Thomas > > > > > With that: Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > > > > > --- > > > drivers/gpu/drm/drm_client.c | 91 +++++++++++++++++++++++++++++++++ > > > drivers/gpu/drm/drm_fb_helper.c | 41 +++++++-------- > > > include/drm/drm_client.h | 4 ++ > > > 3 files changed, 116 insertions(+), 20 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c > > > index ce45e380f4a2..795f5cb052ba 100644 > > > --- a/drivers/gpu/drm/drm_client.c > > > +++ b/drivers/gpu/drm/drm_client.c > > > @@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, u > > > return ERR_PTR(ret); > > > } > > > +/** > > > + * drm_client_buffer_lock - Locks the DRM client buffer > > > + * @buffer: DRM client buffer > > > + * > > > + * This function locks the client buffer by acquiring the buffer > > > + * object's reservation lock. > > > + * > > > + * Unlock the buffer with drm_client_buffer_unlock(). > > > + * > > > + * Returns: > > > + * 0 on success, or a negative errno code otherwise. > > > + */ > > > +int > > > +drm_client_buffer_lock(struct drm_client_buffer *buffer) > > > +{ > > > + return dma_resv_lock(buffer->gem->resv, NULL); > > > +} > > > +EXPORT_SYMBOL(drm_client_buffer_lock); > > > + > > > +/** > > > + * drm_client_buffer_unlock - Unlock DRM client buffer > > > + * @buffer: DRM client buffer > > > + * > > > + * Unlocks a client buffer. See drm_client_buffer_lock(). > > > + */ > > > +void drm_client_buffer_unlock(struct drm_client_buffer *buffer) > > > +{ > > > + dma_resv_unlock(buffer->gem->resv); > > > +} > > > +EXPORT_SYMBOL(drm_client_buffer_unlock); > > > + > > > /** > > > * drm_client_buffer_vmap - Map DRM client buffer into address space > > > * @buffer: DRM client buffer > > > @@ -348,6 +379,66 @@ void drm_client_buffer_vunmap(struct drm_client_buffer *buffer) > > > } > > > EXPORT_SYMBOL(drm_client_buffer_vunmap); > > > +/** > > > + * drm_client_buffer_vmap_local - Map DRM client buffer into address space > > > + * @buffer: DRM client buffer > > > + * @map_copy: Returns the mapped memory's address > > > + * > > > + * This function maps a client buffer into kernel address space. If the > > > + * buffer is already mapped, it returns the existing mapping's address. > > > + * > > > + * Client buffer mappings are not ref'counted. Each call to > > > + * drm_client_buffer_vmap_local() should be followed by a call to > > > + * drm_client_buffer_vunmap_local(); or the client buffer should be mapped > > > + * throughout its lifetime. > > > + * > > > + * The returned address is a copy of the internal value. In contrast to > > > + * other vmap interfaces, you don't need it for the client's vunmap > > > + * function. So you can modify it at will during blit and draw operations. > > > + * > > > + * Returns: > > > + * 0 on success, or a negative errno code otherwise. > > > + */ > > > +int > > > +drm_client_buffer_vmap_local(struct drm_client_buffer *buffer, struct dma_buf_map *map_copy) > > > +{ > > > + struct dma_buf_map *map = &buffer->map; > > > + int ret; > > > + > > > + /* > > > + * FIXME: The dependency on GEM here isn't required, we could > > > + * convert the driver handle to a dma-buf instead and use the > > > + * backend-agnostic dma-buf vmap_local support instead. This would > > > + * require that the handle2fd prime ioctl is reworked to pull the > > > + * fd_install step out of the driver backend hooks, to make that > > > + * final step optional for internal users. > > > + */ > > > + ret = drm_gem_vmap_local(buffer->gem, map); > > > + if (ret) > > > + return ret; > > > + > > > + *map_copy = *map; > > > + > > > + return 0; > > > +} > > > +EXPORT_SYMBOL(drm_client_buffer_vmap_local); > > > + > > > +/** > > > + * drm_client_buffer_vunmap_local - Unmap DRM client buffer > > > + * @buffer: DRM client buffer > > > + * > > > + * This function removes a client buffer's memory mapping. Calling this > > > + * function is only required by clients that manage their buffer mappings > > > + * by themselves. > > > + */ > > > +void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer) > > > +{ > > > + struct dma_buf_map *map = &buffer->map; > > > + > > > + drm_gem_vunmap_local(buffer->gem, map); > > > +} > > > +EXPORT_SYMBOL(drm_client_buffer_vunmap_local); > > > + > > > static void drm_client_buffer_rmfb(struct drm_client_buffer *buffer) > > > { > > > int ret; > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > > > index e82db0f4e771..a56a7d9f7e35 100644 > > > --- a/drivers/gpu/drm/drm_fb_helper.c > > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > > @@ -399,28 +399,34 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper *fb_helper, > > > int ret; > > > /* > > > - * We have to pin the client buffer to its current location while > > > - * flushing the shadow buffer. In the general case, concurrent > > > - * modesetting operations could try to move the buffer and would > > > - * fail. The modeset has to be serialized by acquiring the reservation > > > - * object of the underlying BO here. > > > - * > > > * For fbdev emulation, we only have to protect against fbdev modeset > > > * operations. Nothing else will involve the client buffer's BO. So it > > > * is sufficient to acquire struct drm_fb_helper.lock here. > > > */ > > > mutex_lock(&fb_helper->lock); > > > - ret = drm_client_buffer_vmap(buffer, &map); > > > + /* > > > + * We have to keep the client buffer at its current location while > > > + * flushing the shadow buffer. Concurrent operations could otherwise > > > + * try to move the buffer. Therefore acquiring the reservation > > > + * object of the underlying BO here. > > > + */ > > > + ret = drm_client_buffer_lock(buffer); > > > + if (ret) > > > + goto out_mutex_unlock; > > > + > > > + ret = drm_client_buffer_vmap_local(buffer, &map); > > > if (ret) > > > - goto out; > > > + goto out_drm_client_buffer_unlock; > > > dst = map; > > > drm_fb_helper_damage_blit_real(fb_helper, clip, &dst); > > > - drm_client_buffer_vunmap(buffer); > > > + drm_client_buffer_vunmap_local(buffer); > > > -out: > > > +out_drm_client_buffer_unlock: > > > + drm_client_buffer_unlock(buffer); > > > +out_mutex_unlock: > > > mutex_unlock(&fb_helper->lock); > > > return ret; > > > @@ -946,15 +952,11 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct fb_info *info) > > > drm_modeset_lock_all(fb_helper->dev); > > > drm_client_for_each_modeset(modeset, &fb_helper->client) { > > > crtc = modeset->crtc; > > > - if (!crtc->funcs->gamma_set || !crtc->gamma_size) { > > > - ret = -EINVAL; > > > - goto out; > > > - } > > > + if (!crtc->funcs->gamma_set || !crtc->gamma_size) > > > + return -EINVAL; > > > - if (cmap->start + cmap->len > crtc->gamma_size) { > > > - ret = -EINVAL; > > > - goto out; > > > - } > > > + if (cmap->start + cmap->len > crtc->gamma_size) > > > + return -EINVAL; > > > r = crtc->gamma_store; > > > g = r + crtc->gamma_size; > > > @@ -967,9 +969,8 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct fb_info *info) > > > ret = crtc->funcs->gamma_set(crtc, r, g, b, > > > crtc->gamma_size, NULL); > > > if (ret) > > > - goto out; > > > + return ret; > > > } > > > -out: > > > drm_modeset_unlock_all(fb_helper->dev); > > > return ret; > > > diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h > > > index f07f2fb02e75..df61e339a11c 100644 > > > --- a/include/drm/drm_client.h > > > +++ b/include/drm/drm_client.h > > > @@ -156,8 +156,12 @@ struct drm_client_buffer * > > > drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32 height, u32 format); > > > void drm_client_framebuffer_delete(struct drm_client_buffer *buffer); > > > int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct drm_rect *rect); > > > +int drm_client_buffer_lock(struct drm_client_buffer *buffer); > > > +void drm_client_buffer_unlock(struct drm_client_buffer *buffer); > > > int drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map *map); > > > void drm_client_buffer_vunmap(struct drm_client_buffer *buffer); > > > +int drm_client_buffer_vmap_local(struct drm_client_buffer *buffer, struct dma_buf_map *map); > > > +void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer); > > > int drm_client_modeset_create(struct drm_client_dev *client); > > > void drm_client_modeset_free(struct drm_client_dev *client); > > > -- > > > 2.29.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates

by Daniel Vetter

On Fri, Dec 11, 2020 at 11:49:48AM +0100, Thomas Zimmermann wrote: > > > Am 11.12.20 um 11:18 schrieb Daniel Vetter: > > On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote: > > > The HW cursor's BO used to be mapped permanently into the kernel's > > > address space. GEM's vmap operation will be protected by locks, and > > > we don't want to lock the BO's for an indefinate period of time. > > > > > > Change the cursor code to map the HW BOs only during updates. The > > > vmap operation in VRAM helpers is cheap, as a once estabished mapping > > > is being reused until the BO actually moves. As the HW cursor BOs are > > > permanently pinned, they never move at all. > > > > > > v2: > > > * fix typos in commit description > > > > > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > > > Acked-by: Christian König <christian.koenig(a)amd.com> > > > > Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > > > > Now there's a pretty big issue here though: We can't take dma_resv_lock in > > commit_tail, because of possible deadlocks on at least gpus that do real > > async rendering because of the dma_fences. Unfortunately my annotations > > patches got stuck a bit, I need to refresh them. > > > > Rules are you can pin and unpin stuff in prepare/cleanup_plane, and also > > take dma_resv_lock there, but not in commit_tail in-between. So I think > > our vmap_local needs to loose the unconditional assert_locked and require > > either that or a pin count. > > I guess my commit description is misleading when it speaks of updates. > ast_cursor_blit() is actually called from the cursor plane's prepare_fb > function. [1] The vmap code in ast_cursor_show() could be moved into blit() > as well, I think. Oh I failed to check this properly. Even better. > I guess the clean solution is to integrate the cursor code with the > modesetting code in ast_mode. From there, locks and mappings can be > established in prepare_fb and the HW state can be updated in atomic_commit. Yup. I'll still refresh my series with lockdep annotations, keeps paranoid me at peace :-) -Daniel > > Best regards > Thomas > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… > > > -Daniel > > > > > --- > > > drivers/gpu/drm/ast/ast_cursor.c | 51 ++++++++++++++++++-------------- > > > drivers/gpu/drm/ast/ast_drv.h | 2 -- > > > 2 files changed, 28 insertions(+), 25 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c > > > index 68bf3d33f1ed..fac1ee79c372 100644 > > > --- a/drivers/gpu/drm/ast/ast_cursor.c > > > +++ b/drivers/gpu/drm/ast/ast_cursor.c > > > @@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast) > > > for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) { > > > gbo = ast->cursor.gbo[i]; > > > - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]); > > > drm_gem_vram_unpin(gbo); > > > drm_gem_vram_put(gbo); > > > } > > > @@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void *ptr) > > > } > > > /* > > > - * Allocate cursor BOs and pins them at the end of VRAM. > > > + * Allocate cursor BOs and pin them at the end of VRAM. > > > */ > > > int ast_cursor_init(struct ast_private *ast) > > > { > > > struct drm_device *dev = &ast->base; > > > size_t size, i; > > > struct drm_gem_vram_object *gbo; > > > - struct dma_buf_map map; > > > int ret; > > > size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE); > > > @@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast) > > > drm_gem_vram_put(gbo); > > > goto err_drm_gem_vram_put; > > > } > > > - ret = drm_gem_vram_vmap(gbo, &map); > > > - if (ret) { > > > - drm_gem_vram_unpin(gbo); > > > - drm_gem_vram_put(gbo); > > > - goto err_drm_gem_vram_put; > > > - } > > > - > > > ast->cursor.gbo[i] = gbo; > > > - ast->cursor.map[i] = map; > > > } > > > return drmm_add_action_or_reset(dev, ast_cursor_release, NULL); > > > @@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast) > > > while (i) { > > > --i; > > > gbo = ast->cursor.gbo[i]; > > > - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]); > > > drm_gem_vram_unpin(gbo); > > > drm_gem_vram_put(gbo); > > > } > > > @@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int h > > > int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb) > > > { > > > struct drm_device *dev = &ast->base; > > > - struct drm_gem_vram_object *gbo; > > > - struct dma_buf_map map; > > > - int ret; > > > - void *src; > > > + struct drm_gem_vram_object *dst_gbo = ast->cursor.gbo[ast->cursor.next_index]; > > > + struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]); > > > + struct dma_buf_map src_map, dst_map; > > > void __iomem *dst; > > > + void *src; > > > + int ret; > > > if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) || > > > drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT)) > > > return -EINVAL; > > > - gbo = drm_gem_vram_of_gem(fb->obj[0]); > > > - > > > - ret = drm_gem_vram_vmap(gbo, &map); > > > + ret = drm_gem_vram_vmap(src_gbo, &src_map); > > > if (ret) > > > return ret; > > > - src = map.vaddr; /* TODO: Use mapping abstraction properly */ > > > + src = src_map.vaddr; /* TODO: Use mapping abstraction properly */ > > > - dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem; > > > + ret = drm_gem_vram_vmap(dst_gbo, &dst_map); > > > + if (ret) > > > + goto err_drm_gem_vram_vunmap; > > > + dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */ > > > /* do data transfer to cursor BO */ > > > update_cursor_image(dst, src, fb->width, fb->height); > > > - drm_gem_vram_vunmap(gbo, &map); > > > + drm_gem_vram_vunmap(dst_gbo, &dst_map); > > > + drm_gem_vram_vunmap(src_gbo, &src_map); > > > return 0; > > > + > > > +err_drm_gem_vram_vunmap: > > > + drm_gem_vram_vunmap(src_gbo, &src_map); > > > + return ret; > > > } > > > static void ast_cursor_set_base(struct ast_private *ast, u64 address) > > > @@ -243,17 +239,26 @@ static void ast_cursor_set_location(struct ast_private *ast, u16 x, u16 y, > > > void ast_cursor_show(struct ast_private *ast, int x, int y, > > > unsigned int offset_x, unsigned int offset_y) > > > { > > > + struct drm_device *dev = &ast->base; > > > + struct drm_gem_vram_object *gbo = ast->cursor.gbo[ast->cursor.next_index]; > > > + struct dma_buf_map map; > > > u8 x_offset, y_offset; > > > u8 __iomem *dst; > > > u8 __iomem *sig; > > > u8 jreg; > > > + int ret; > > > - dst = ast->cursor.map[ast->cursor.next_index].vaddr; > > > + ret = drm_gem_vram_vmap(gbo, &map); > > > + if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", ret)) > > > + return; > > > + dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */ > > > sig = dst + AST_HWC_SIZE; > > > writel(x, sig + AST_HWC_SIGNATURE_X); > > > writel(y, sig + AST_HWC_SIGNATURE_Y); > > > + drm_gem_vram_vunmap(gbo, &map); > > > + > > > if (x < 0) { > > > x_offset = (-x) + offset_x; > > > x = 0; > > > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > > > index ccaff81924ee..f871fc36c2f7 100644 > > > --- a/drivers/gpu/drm/ast/ast_drv.h > > > +++ b/drivers/gpu/drm/ast/ast_drv.h > > > @@ -28,7 +28,6 @@ > > > #ifndef __AST_DRV_H__ > > > #define __AST_DRV_H__ > > > -#include <linux/dma-buf-map.h> > > > #include <linux/i2c.h> > > > #include <linux/i2c-algo-bit.h> > > > #include <linux/io.h> > > > @@ -133,7 +132,6 @@ struct ast_private { > > > struct { > > > struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM]; > > > - struct dma_buf_map map[AST_DEFAULT_HWC_NUM]; > > > unsigned int next_index; > > > } cursor; > > > -- > > > 2.29.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates

by Daniel Vetter

On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote: > The HW cursor's BO used to be mapped permanently into the kernel's > address space. GEM's vmap operation will be protected by locks, and > we don't want to lock the BO's for an indefinate period of time. > > Change the cursor code to map the HW BOs only during updates. The > vmap operation in VRAM helpers is cheap, as a once estabished mapping > is being reused until the BO actually moves. As the HW cursor BOs are > permanently pinned, they never move at all. > > v2: > * fix typos in commit description > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > Acked-by: Christian König <christian.koenig(a)amd.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Now there's a pretty big issue here though: We can't take dma_resv_lock in commit_tail, because of possible deadlocks on at least gpus that do real async rendering because of the dma_fences. Unfortunately my annotations patches got stuck a bit, I need to refresh them. Rules are you can pin and unpin stuff in prepare/cleanup_plane, and also take dma_resv_lock there, but not in commit_tail in-between. So I think our vmap_local needs to loose the unconditional assert_locked and require either that or a pin count. -Daniel > --- > drivers/gpu/drm/ast/ast_cursor.c | 51 ++++++++++++++++++-------------- > drivers/gpu/drm/ast/ast_drv.h | 2 -- > 2 files changed, 28 insertions(+), 25 deletions(-) > > diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c > index 68bf3d33f1ed..fac1ee79c372 100644 > --- a/drivers/gpu/drm/ast/ast_cursor.c > +++ b/drivers/gpu/drm/ast/ast_cursor.c > @@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast) > > for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) { > gbo = ast->cursor.gbo[i]; > - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]); > drm_gem_vram_unpin(gbo); > drm_gem_vram_put(gbo); > } > @@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void *ptr) > } > > /* > - * Allocate cursor BOs and pins them at the end of VRAM. > + * Allocate cursor BOs and pin them at the end of VRAM. > */ > int ast_cursor_init(struct ast_private *ast) > { > struct drm_device *dev = &ast->base; > size_t size, i; > struct drm_gem_vram_object *gbo; > - struct dma_buf_map map; > int ret; > > size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE); > @@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast) > drm_gem_vram_put(gbo); > goto err_drm_gem_vram_put; > } > - ret = drm_gem_vram_vmap(gbo, &map); > - if (ret) { > - drm_gem_vram_unpin(gbo); > - drm_gem_vram_put(gbo); > - goto err_drm_gem_vram_put; > - } > - > ast->cursor.gbo[i] = gbo; > - ast->cursor.map[i] = map; > } > > return drmm_add_action_or_reset(dev, ast_cursor_release, NULL); > @@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast) > while (i) { > --i; > gbo = ast->cursor.gbo[i]; > - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]); > drm_gem_vram_unpin(gbo); > drm_gem_vram_put(gbo); > } > @@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int h > int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb) > { > struct drm_device *dev = &ast->base; > - struct drm_gem_vram_object *gbo; > - struct dma_buf_map map; > - int ret; > - void *src; > + struct drm_gem_vram_object *dst_gbo = ast->cursor.gbo[ast->cursor.next_index]; > + struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]); > + struct dma_buf_map src_map, dst_map; > void __iomem *dst; > + void *src; > + int ret; > > if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) || > drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT)) > return -EINVAL; > > - gbo = drm_gem_vram_of_gem(fb->obj[0]); > - > - ret = drm_gem_vram_vmap(gbo, &map); > + ret = drm_gem_vram_vmap(src_gbo, &src_map); > if (ret) > return ret; > - src = map.vaddr; /* TODO: Use mapping abstraction properly */ > + src = src_map.vaddr; /* TODO: Use mapping abstraction properly */ > > - dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem; > + ret = drm_gem_vram_vmap(dst_gbo, &dst_map); > + if (ret) > + goto err_drm_gem_vram_vunmap; > + dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */ > > /* do data transfer to cursor BO */ > update_cursor_image(dst, src, fb->width, fb->height); > > - drm_gem_vram_vunmap(gbo, &map); > + drm_gem_vram_vunmap(dst_gbo, &dst_map); > + drm_gem_vram_vunmap(src_gbo, &src_map); > > return 0; > + > +err_drm_gem_vram_vunmap: > + drm_gem_vram_vunmap(src_gbo, &src_map); > + return ret; > } > > static void ast_cursor_set_base(struct ast_private *ast, u64 address) > @@ -243,17 +239,26 @@ static void ast_cursor_set_location(struct ast_private *ast, u16 x, u16 y, > void ast_cursor_show(struct ast_private *ast, int x, int y, > unsigned int offset_x, unsigned int offset_y) > { > + struct drm_device *dev = &ast->base; > + struct drm_gem_vram_object *gbo = ast->cursor.gbo[ast->cursor.next_index]; > + struct dma_buf_map map; > u8 x_offset, y_offset; > u8 __iomem *dst; > u8 __iomem *sig; > u8 jreg; > + int ret; > > - dst = ast->cursor.map[ast->cursor.next_index].vaddr; > + ret = drm_gem_vram_vmap(gbo, &map); > + if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", ret)) > + return; > + dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */ > > sig = dst + AST_HWC_SIZE; > writel(x, sig + AST_HWC_SIGNATURE_X); > writel(y, sig + AST_HWC_SIGNATURE_Y); > > + drm_gem_vram_vunmap(gbo, &map); > + > if (x < 0) { > x_offset = (-x) + offset_x; > x = 0; > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > index ccaff81924ee..f871fc36c2f7 100644 > --- a/drivers/gpu/drm/ast/ast_drv.h > +++ b/drivers/gpu/drm/ast/ast_drv.h > @@ -28,7 +28,6 @@ > #ifndef __AST_DRV_H__ > #define __AST_DRV_H__ > > -#include <linux/dma-buf-map.h> > #include <linux/i2c.h> > #include <linux/i2c-algo-bit.h> > #include <linux/io.h> > @@ -133,7 +132,6 @@ struct ast_private { > > struct { > struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM]; > - struct dma_buf_map map[AST_DEFAULT_HWC_NUM]; > unsigned int next_index; > } cursor; > > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 1/8] drm/ast: Don't pin cursor source BO explicitly during update

by Daniel Vetter

On Wed, Dec 09, 2020 at 03:25:20PM +0100, Thomas Zimmermann wrote: > Vmapping the cursor source BO contains an implicit pin operation, > so there's no need to do this manually. > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > --- > drivers/gpu/drm/ast/ast_cursor.c | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c > index 742d43a7edf4..68bf3d33f1ed 100644 > --- a/drivers/gpu/drm/ast/ast_cursor.c > +++ b/drivers/gpu/drm/ast/ast_cursor.c > @@ -180,12 +180,9 @@ int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb) > > gbo = drm_gem_vram_of_gem(fb->obj[0]); > > - ret = drm_gem_vram_pin(gbo, 0); > - if (ret) > - return ret; > ret = drm_gem_vram_vmap(gbo, &map); > if (ret) > - goto err_drm_gem_vram_unpin; > + return ret; > src = map.vaddr; /* TODO: Use mapping abstraction properly */ > > dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem; > @@ -194,13 +191,8 @@ int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb) > update_cursor_image(dst, src, fb->width, fb->height); > > drm_gem_vram_vunmap(gbo, &map); > - drm_gem_vram_unpin(gbo); > > return 0; > - > -err_drm_gem_vram_unpin: > - drm_gem_vram_unpin(gbo); > - return ret; > } > > static void ast_cursor_set_base(struct ast_private *ast, u64 address) > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

Re: [Linaro-mm-sig] [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings

by Daniel Vetter

On Wed, Dec 09, 2020 at 03:25:24PM +0100, Thomas Zimmermann wrote: > Implementations of the vmap/vunmap GEM callbacks may perform pinning > of the BO and may acquire the associated reservation object's lock. > Callers that only require a mapping of the contained memory can thus > interfere with other tasks that require exact pinning, such as scanout. > This is less of an issue with private CMA buffers, but may happen > with imported ones. > > Therefore provide the new interface drm_gem_cma_vmap_local(), which only > performs the vmap operations. Callers have to hold the reservation lock > while the mapping persists. > > This patch also connects GEM CMA helpers to the GEM object function with > equivalent functionality. > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > --- > drivers/gpu/drm/drm_gem_cma_helper.c | 35 ++++++++++++++++++++++++++++ > drivers/gpu/drm/vc4/vc4_bo.c | 13 +++++++++++ > drivers/gpu/drm/vc4/vc4_drv.h | 1 + > include/drm/drm_gem_cma_helper.h | 1 + > 4 files changed, 50 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c > index 7942cf05cd93..40b3e8e3fc42 100644 > --- a/drivers/gpu/drm/drm_gem_cma_helper.c > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c > @@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = { > .print_info = drm_gem_cma_print_info, > .get_sg_table = drm_gem_cma_get_sg_table, > .vmap = drm_gem_cma_vmap, > + .vmap_local = drm_gem_cma_vmap_local, > .mmap = drm_gem_cma_mmap, > .vm_ops = &drm_gem_cma_vm_ops, > }; > @@ -471,6 +472,40 @@ int drm_gem_cma_vmap(struct drm_gem_object *obj, struct dma_buf_map *map) > } > EXPORT_SYMBOL_GPL(drm_gem_cma_vmap); > > +/** > + * drm_gem_cma_vmap_local - map a CMA GEM object into the kernel's virtual > + * address space > + * @obj: GEM object > + * @map: Returns the kernel virtual address of the CMA GEM object's backing > + * store. > + * > + * This function maps a buffer into the kernel's > + * virtual address space. Since the CMA buffers are already mapped into the > + * kernel virtual address space this simply returns the cached virtual > + * address. Drivers using the CMA helpers should set this as their DRM > + * driver's &drm_gem_object_funcs.vmap_local callback. > + * > + * Returns: > + * 0 on success, or a negative error code otherwise. > + */ > +int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map) > +{ > + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj); > + > + /* > + * TODO: The code in drm_gem_cma_prime_import_sg_table_vmap() > + * establishes this mapping. The correct solution would > + * be to call dma_buf_vmap_local() here. > + * > + * If we find a case where we absolutely have to call > + * dma_buf_vmap_local(), the code needs to be restructured. dma_buf_vmap_local is only relevant for dynamic importers, pinning at import time is actually what you get anyway. That's what Christian meant with his comments for the ->pin hook. So the TODO here doesn't make sense imo, just delete it. We're very far away from making cma dynamic :-) > + */ > + dma_buf_map_set_vaddr(map, cma_obj->vaddr); > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(drm_gem_cma_vmap_local); > + > /** > * drm_gem_cma_mmap - memory-map an exported CMA GEM object > * @obj: GEM object > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c > index dc316cb79e00..ec57326c69c4 100644 > --- a/drivers/gpu/drm/vc4/vc4_bo.c > +++ b/drivers/gpu/drm/vc4/vc4_bo.c > @@ -387,6 +387,7 @@ static const struct drm_gem_object_funcs vc4_gem_object_funcs = { > .export = vc4_prime_export, > .get_sg_table = drm_gem_cma_get_sg_table, > .vmap = vc4_prime_vmap, > + .vmap_local = vc4_prime_vmap_local, > .vm_ops = &vc4_vm_ops, > }; > > @@ -797,6 +798,18 @@ int vc4_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map) > return drm_gem_cma_vmap(obj, map); > } > > +int vc4_prime_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map) > +{ > + struct vc4_bo *bo = to_vc4_bo(obj); > + > + if (bo->validated_shader) { This freaks me out. It should be impossible to export a validated shader as a dma-buf, and indeed the check exists already. All the wrapper functions here are imo pointless. Either we should remove them, or replace the if with a BUG_ON here since if that ever happens we have a security bug already. I'd go with removing, less code. Maybe throw a patch on top? Anyway this patch looks good, with the todo deleted: Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > + DRM_DEBUG("mmaping of shader BOs not allowed.\n"); > + return -EINVAL; > + } > + > + return drm_gem_cma_vmap_local(obj, map); > +} > + > struct drm_gem_object * > vc4_prime_import_sg_table(struct drm_device *dev, > struct dma_buf_attachment *attach, > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h > index 43a1af110b3e..efb6c47d318f 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.h > +++ b/drivers/gpu/drm/vc4/vc4_drv.h > @@ -812,6 +812,7 @@ struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev, > struct dma_buf_attachment *attach, > struct sg_table *sgt); > int vc4_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map); > +int vc4_prime_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map); > int vc4_bo_cache_init(struct drm_device *dev); > int vc4_bo_inc_usecnt(struct vc4_bo *bo); > void vc4_bo_dec_usecnt(struct vc4_bo *bo); > diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h > index 0a9711caa3e8..05122e71bc6d 100644 > --- a/include/drm/drm_gem_cma_helper.h > +++ b/include/drm/drm_gem_cma_helper.h > @@ -99,6 +99,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev, > struct dma_buf_attachment *attach, > struct sg_table *sgt); > int drm_gem_cma_vmap(struct drm_gem_object *obj, struct dma_buf_map *map); > +int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map); > int drm_gem_cma_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma); > > /** > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig December 2020