dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[PATCH] drm/fb-helper: Fix vt restore
by Daniel Vetter 10 Jul '20

10 Jul '20

In the past we had a pile of hacks to orchestrate access between fbdev emulation and native kms clients. We've tried to streamline this, by always preferring the kms side above fbdev calls when a drm master exists, because drm master controls access to the display resources. Unfortunately this breaks existing userspace, specifically Xorg. When exiting Xorg first restores the console to text mode using the KDSET ioctl on the vt. This does nothing, because a drm master is still around. Then it drops the drm master status, which again does nothing, because logind is keeping additional drm fd open to be able to orchestrate vt switches. In the past this is the point where fbdev was restored, as part of the ->lastclose hook on the drm side. Now to fix this regression we don't want to go back to letting fbdev restore things whenever it feels like, or to the pile of hacks we've had before. Instead try and go with a minimal exception to make the KDSET case work again, and nothing else. This means that if userspace does a KDSET call when switching between graphical compositors, there will be some flickering with fbcon showing up for a bit. But a) that's not a regression and b) userspace can fix it by improving the vt switching dance - logind should have all the information it needs. While pondering all this I'm also wondering wheter we should have a SWITCH_MASTER ioctl to allow race-free master status handover. But that's for another day. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179 Cc: shlomo(a)fastmail.com Reported-and-Tested-by: shlomo(a)fastmail.com Cc: Michel Dänzer <michel(a)daenzer.net> Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores") Cc: Noralf Trønnes <noralf(a)tronnes.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.7+ Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_fb_helper.c | 63 +++++++++++++++++++++++++------- drivers/video/fbdev/core/fbcon.c | 3 +- include/uapi/linux/fb.h | 1 + 3 files changed, 52 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 170aa7689110..ae69bf8e9bcc 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -227,18 +227,9 @@ int drm_fb_helper_debug_leave(struct fb_info *info) } EXPORT_SYMBOL(drm_fb_helper_debug_leave); -/** - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration - * @fb_helper: driver-allocated fbdev helper, can be NULL - * - * This should be called from driver's drm &drm_driver.lastclose callback - * when implementing an fbcon on top of kms using this helper. This ensures that - * the user isn't greeted with a black screen when e.g. X dies. - * - * RETURNS: - * Zero if everything went ok, negative error code otherwise. - */ -int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) +static int +__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper, + bool force) { bool do_delayed; int ret; @@ -250,7 +241,16 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) return 0; mutex_lock(&fb_helper->lock); - ret = drm_client_modeset_commit(&fb_helper->client); + if (force) { + /* + * Yes this is the _locked version which expects the master lock + * to be held. But for forced restores we're intentionally + * racing here, see drm_fb_helper_set_par(). + */ + ret = drm_client_modeset_commit_locked(&fb_helper->client); + } else { + ret = drm_client_modeset_commit(&fb_helper->client); + } do_delayed = fb_helper->delayed_hotplug; if (do_delayed) @@ -262,6 +262,22 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) return ret; } + +/** + * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration + * @fb_helper: driver-allocated fbdev helper, can be NULL + * + * This should be called from driver's drm &drm_driver.lastclose callback + * when implementing an fbcon on top of kms using this helper. This ensures that + * the user isn't greeted with a black screen when e.g. X dies. + * + * RETURNS: + * Zero if everything went ok, negative error code otherwise. + */ +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) +{ + return __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper, false); +} EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked); #ifdef CONFIG_MAGIC_SYSRQ @@ -1318,6 +1334,7 @@ int drm_fb_helper_set_par(struct fb_info *info) { struct drm_fb_helper *fb_helper = info->par; struct fb_var_screeninfo *var = &info->var; + bool force; if (oops_in_progress) return -EBUSY; @@ -1327,7 +1344,25 @@ int drm_fb_helper_set_par(struct fb_info *info) return -EINVAL; } - drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper); + /* + * Normally we want to make sure that a kms master takes + * precedence over fbdev, to avoid fbdev flickering and + * occasionally stealing the display status. But Xorg first sets + * the vt back to text mode using the KDSET IOCTL with KD_TEXT, + * and only after that drops the master status when exiting. + * + * In the past this was caught by drm_fb_helper_lastclose(), but + * on modern systems where logind always keeps a drm fd open to + * orchestrate the vt switching, this doesn't work. + * + * To no break the userspace ABI we have this special case here, + * which is only used for the above case. Everything else uses + * the normal commit function, which ensures that we never steal + * the display from an active drm master. + */ + force = var->activate & FB_ACTIVATE_KD_TEXT; + + __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper, force); return 0; } diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 9d28a8e3328f..e2a490c5ae08 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2402,7 +2402,8 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch) ops->graphics = 1; if (!blank) { - var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE; + var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE | + FB_ACTIVATE_KD_TEXT; fb_set_var(info, &var); ops->graphics = 0; ops->var = info->var; diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h index b6aac7ee1f67..4c14e8be7267 100644 --- a/include/uapi/linux/fb.h +++ b/include/uapi/linux/fb.h @@ -205,6 +205,7 @@ struct fb_bitfield { #define FB_ACTIVATE_ALL 64 /* change all VCs on this fb */ #define FB_ACTIVATE_FORCE 128 /* force apply even when no change*/ #define FB_ACTIVATE_INV_MODE 256 /* invalidate videomode */ +#define FB_ACTIVATE_KD_TEXT 512 /* for KDSET vt ioctl */ #define FB_ACCELF_TEXT 1 /* (OBSOLETE) see fb_info.flags and vc_mode */ -- 2.27.0

3 5

[PATCH] staging: android: ion: Skip sync if not mapped
by Ørjan Eide 10 Jul '20

10 Jul '20

Only sync the sg-list of an Ion dma-buf attachment when the attachment is actually mapped on the device. dma-bufs may be synced at any time. It can be reached from user space via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when syncs may be attempted, and dma_buf_end_cpu_access() and dma_buf_begin_cpu_access() may not be paired. Since the sg_list's dma_address isn't set up until the buffer is used on the device, and dma_map_sg() is called on it, the dma_address will be NULL if sync is attempted on the dma-buf before it's mapped on a device. Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")) this was a problem as the dma-api (at least the swiotlb_dma_ops on arm64) would use the potentially invalid dma_address. How that failed depended on how the device handled physical address 0. If 0 was a valid address to physical ram, that page would get flushed a lot, while the actual pages in the buffer would not get synced correctly. While if 0 is an invalid physical address it may cause a fault and trigger a crash. In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code"), as this moved the dma-api to use the page pointer in the sg_list, and (for Ion buffers at least) this will always be valid if the sg_list exists at all. But, this issue is re-introduced in v5.3 with commit 449fa54d6815 ("dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old behaviour and picks the dma_address that may be invalid. dma-buf core doesn't ensure that the buffer is mapped on the device, and thus have a valid sg_list, before calling the exporter's begin_cpu_access. Signed-off-by: Ørjan Eide <orjan.eide(a)arm.com> --- drivers/staging/android/ion/ion.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) This seems to be part of a bigger issue where dma-buf exporters assume that their dma-buf begin_cpu_access and end_cpu_access callbacks have a certain guaranteed behavior, which isn't ensured by dma-buf core. This patch fixes this in ion only, but it also needs to be fixed for other exporters, either handled like this in each exporter, or in dma-buf core before calling into the exporters. diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 38b51eace4f9..7b752ba0cb6d 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -173,6 +173,7 @@ struct ion_dma_buf_attachment { struct device *dev; struct sg_table *table; struct list_head list; + bool mapped:1; }; static int ion_dma_buf_attach(struct dma_buf *dmabuf, @@ -195,6 +196,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf, a->table = table; a->dev = attachment->dev; INIT_LIST_HEAD(&a->list); + a->mapped = false; attachment->priv = a; @@ -231,6 +233,8 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment, direction)) return ERR_PTR(-ENOMEM); + a->mapped = true; + return table; } @@ -238,6 +242,10 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *table, enum dma_data_direction direction) { + struct ion_dma_buf_attachment *a = attachment->priv; + + a->mapped = false; + dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction); } @@ -297,6 +305,8 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents, direction); } @@ -320,6 +330,8 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents, direction); } -- 2.17.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 17

[PATCH v6 0/4] driver core: add probe error check helper
by Andrzej Hajda 10 Jul '20

10 Jul '20

Hi All, Thanks for multiple comments. Changes since v5: - removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be used instead, - added dev_dbg logging in case of -EPROBE_DEFER, - renamed functions and vars according to comments, - extended docs, - cosmetics. Original message (with small adjustments): Recently I took some time to re-check error handling in drivers probe code, and I have noticed that number of incorrect resource acquisition error handling increased and there are no other propositions which can cure the situation. So I have decided to resend my old proposition of probe_err helper which should simplify resource acquisition error handling, it also extend it with adding defer probe reason to devices_deferred debugfs property, which should improve debugging experience for developers/testers. I have also added two patches showing usage and benefits of the helper. My dirty/ad-hoc cocci scripts shows that this helper can be used in at least 2700 places saving about 3500 lines of code. Regards Andrzej Andrzej Hajda (4): driver core: add device probe log helper driver core: add deferring probe reason to devices_deferred property drm/bridge/sii8620: fix resource acquisition error handling drm/bridge: lvds-codec: simplify error handling drivers/base/base.h | 3 ++ drivers/base/core.c | 46 ++++++++++++++++++++++++++++ drivers/base/dd.c | 23 +++++++++++++- drivers/gpu/drm/bridge/lvds-codec.c | 10 ++---- drivers/gpu/drm/bridge/sil-sii8620.c | 21 ++++++------- include/linux/device.h | 3 ++ 6 files changed, 86 insertions(+), 20 deletions(-) -- 2.17.1

7 19

[PATCHv3 0/7] System Cache support for GPU and required SMMU support
by Sai Prakash Ranjan 09 Jul '20

09 Jul '20

Some hardware variants contain a system cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices perallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. Patch 1 adds a init_context_bank implementation hook to set SCTLR.HUPCF. Patch 2,3,6,7 adds system cache support in SMMU and GPU driver. Patch 4 and 5 are minor cleanups for arm-smmu impl. Changes in v3: * Fix domain attribute setting to before iommu_attach_device() * Fix few code style and checkpatch warnings * Rebase on top of Jordan's latest split pagetables and per-instance pagetables support [1][2] Changes in v2: * Addressed review comments and rebased on top of Jordan's split pagetables series [1] https://lore.kernel.org/patchwork/cover/1264446/ [2] https://lore.kernel.org/patchwork/cover/1264460/ Jordan Crouse (1): iommu/arm-smmu: Add a init_context_bank implementation hook Sai Prakash Ranjan (4): iommu/io-pgtable-arm: Add support to use system cache iommu/arm-smmu: Add domain attribute for system cache iommu: arm-smmu-impl: Remove unwanted extra blank lines iommu: arm-smmu-impl: Convert to use of_match_node() for qcom impl Sharat Masetty (2): drm/msm: rearrange the gpu_rmw() function drm/msm/a6xx: Add support for using system cache(LLC) drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 82 +++++++++++++++++++++++++ drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 3 + drivers/gpu/drm/msm/adreno/adreno_gpu.c | 23 ++++++- drivers/gpu/drm/msm/msm_drv.c | 8 +++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gpu.h | 5 +- drivers/gpu/drm/msm/msm_iommu.c | 3 + drivers/gpu/drm/msm/msm_mmu.h | 4 ++ drivers/iommu/arm-smmu-impl.c | 13 ++-- drivers/iommu/arm-smmu-qcom.c | 13 ++++ drivers/iommu/arm-smmu.c | 46 +++++++++----- drivers/iommu/arm-smmu.h | 13 ++++ drivers/iommu/io-pgtable-arm.c | 7 ++- include/linux/io-pgtable.h | 4 ++ include/linux/iommu.h | 1 + 15 files changed, 198 insertions(+), 28 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

4 13

[PATCH] drm/panfrost: fix ref count leak in panfrost_job_hw_submit
by Navid Emamdoost 09 Jul '20

09 Jul '20

in panfrost_job_hw_submit, pm_runtime_get_sync is called which increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning. Signed-off-by: Navid Emamdoost <navid.emamdoost(a)gmail.com> --- drivers/gpu/drm/panfrost/panfrost_job.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 7914b1570841..89ac84667eb1 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -147,11 +147,10 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) ret = pm_runtime_get_sync(pfdev->dev); if (ret < 0) - return; + goto out; if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js)))) { - pm_runtime_put_sync_autosuspend(pfdev->dev); - return; + goto out; } cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu); @@ -184,6 +183,9 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) job, js, jc_head); job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START); +out: + pm_runtime_put_sync_autosuspend(pfdev->dev); + return; } static void panfrost_acquire_object_fences(struct drm_gem_object **bos, -- 2.17.1

4 3

[RESEND PATCH 0/3] Convert mtk-dpi to drm_bridge API
by Enric Balletbo i Serra 09 Jul '20

09 Jul '20

The reason for this resend is because I forget to add some bridge maintainers. So adding them and collect the actual tags. The mtk-dpi driver still uses the drm_encoder API which is now somewhat deprecated. We started to move all the Mediatek drivers to the drm_bridge API, like we did for the mtk-dsi driver [1], this is another small step to be able to fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver. [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559 Enric Balletbo i Serra (3): drm/mediatek: mtk_dpi: Rename bridge to next_bridge drm/mediatek: mtk_dpi: Convert to bridge driver drm/mediatek: mtk_dpi: Use simple encoder drivers/gpu/drm/mediatek/mtk_dpi.c | 84 ++++++++++++++---------------- 1 file changed, 39 insertions(+), 45 deletions(-) -- 2.26.2

2 11

[RFC] Host1x/TegraDRM UAPI
by Mikko Perttunen 09 Jul '20

09 Jul '20

# Host1x/TegraDRM UAPI proposal This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in many ways. I haven't written any implementation yet -- I'll do that once there is some agreement on the high-level design. Current open items: * The syncpoint UAPI allows userspace to create sync_file FDs with arbitrary syncpoint fences. dma_fence code currently seems to assume all fences will be signaled, which would not necessarily be the case with this interface. * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present. Not sure if they are still needed. ## Introduction to the hardware Tegra Host1x is a hardware block providing the following capabilities: * Syncpoints, a unified whole-system synchronization primitive, allowing synchronization of work between graphics, compute and multimedia engines, CPUs including cross-VM synchronization, and devices on the PCIe bus, without incurring CPU overhead. * Channels, a command DMA mechanism allowing asynchronous programming of various engines, integrating with syncpoints. * Hardware virtualization support for syncpoints and channels. (On Tegra186 and newer) This proposal defines APIs for userspace access to syncpoints and channels. Kernel drivers can additionally use syncpoints and channels internally, providing other userspace interfaces (e.g. V4L2). Syncpoint and channel interfaces are split into separate parts, as syncpoints are useful as a system synchronization primitive even without using the engine drivers provided through TegraDRM. For example, a computer vision pipeline consisting of video capture, CPU processing and GPU processing would not necessarily use the engines provided by TegraDRM. See the Example workflows section for more details. ## Syncpoint interface Syncpoints are a set of 32-bit values providing the following operations: * Atomically increment value by one * Read current value * Wait until value reaches specified threshold. For waiting, the 32-bit value space is treated modulo 2^32; e.g. if the current value is 0xffffffff, then value 0x0 is considered to be one increment in the future. Each syncpoint is identified by a system-global ID ranging between [0, number of syncpoints supported by hardware). The entire system has read-only access to all syncpoints based on their ID. Syncpoints are managed through the device node /dev/host1x provided by the gpu/host1x driver. ### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x) Allocates a free syncpoint, returning a file descriptor representing it. Only the owner of the file descriptor is allowed to mutate the value of the syncpoint. ``` struct host1x_ctrl_allocate_syncpoint { /** * @fd: * * [out] New file descriptor representing the allocated syncpoint. */ __s32 fd; __u32 reserved[3]; }; ``` ### IOCTL HOST1X_SYNCPOINT_INFO (on syncpoint file descriptor) Allows retrieval of system-global syncpoint ID corresponding to syncpoint. Use cases: * Passing ID to other system components that identify syncpoints by ID * Debugging and testing ``` struct host1x_syncpoint_info { /** * @id: * * [out] System-global ID of the syncpoint. */ __u32 id; __u32 reserved[3]; }; ``` ### IOCTL HOST1X_SYNCPOINT_INCREMENT (on syncpoint file descriptor) Allows incrementing of the syncpoint value. Use cases: * Signalling work completion when executing a pipeline step on the CPU * Debugging and testing ``` struct host1x_syncpoint_increment { /** * @count: * * [in] Number of times to increment syncpoint. Value can be * observed in in-between values, but increments are atomic. */ __u32 count; }; ``` ### IOCTL HOST1X_READ_SYNCPOINT (on /dev/host1x) Read the value of a syncpoint based on its ID. Use cases: * Allows more fine-grained tracking of task progression for debugging purposes ``` struct host1x_ctrl_read_syncpoint { /** * @id: * * [in] ID of syncpoint to read. */ __u32 id; /** * @value: * * [out] Value of the syncpoint. */ __u32 value; }; ``` ### IOCTL HOST1X_CREATE_FENCE (on /dev/host1x) Creates a new SYNC_FILE fence file descriptor for the specified syncpoint ID and threshold. Use cases: * Creating a fence when receiving ID/threshold pair from another system component * Creating a postfence when executing a pipeline step on the CPU * Creating a postfence when executing a pipeline step controlled by userspace (e.g. GPU userspace submission) ``` struct host1x_ctrl_create_fence { /** * @id: * * [in] ID of the syncpoint for which to create a fence. */ __u32 id; /** * @threshold: * * [in] Threshold value for fence. */ __u32 threshold; /** * @fence_fd: * * [out] New sync_file FD corresponding to the ID and threshold. */ __s32 fence_fd; __u32 reserved[1]; }; ``` ### IOCTL HOST1X_GET_FENCE_INFO (on /dev/host1x) Allows retrieval of the ID/threshold pairs corresponding to a SYNC_FILE fence or fence array. Use cases: * Debugging and testing * Transmitting a fence to another system component requiring ID/threshold * Getting ID/threshold for prefence when programming a pipeline step controlled by userspace (e.g. GPU userspace submission) ``` /* If set, corresponding fence is backed by Host1x syncpoints. */ #define HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE (1 << 0) struct host1x_ctrl_fence_info { /** * @flags: * * [out] HOST1X_CTRL_FENCE_INFO flags. */ __u32 flags; /** * @id: * * [out] ID of the syncpoint corresponding to this fence. * Only set if HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE is set. */ __u32 id; /** * @threshold: * * [out] Signalling threshold of the fence. * Only set if HOST1X_CTRL_FENCE_INFO_SYNCPOINT_FENCE is set. */ __u32 threshold; __u32 reserved[1]; }; struct host1x_ctrl_get_fence_info { /** * @fence_fd: * * [in] Syncpoint-backed sync_file FD for which to retrieve info. */ __s32 fence_fd; /** * @num_fences: * * [in] Size of `fence_info` array in elements. * [out] Number of fences held by the FD. */ __u32 num_fences; /** * @fence_info: * * [in] Pointer to array of 'struct host1x_ctrl_fence_info' where info will be stored. */ __u64 fence_info; __u32 reserved[1]; }; ``` ## Channel interface ### DRM_TEGRA_OPEN_CHANNEL ``` struct drm_tegra_open_channel { /** * @class: * * [in] Host1x class (engine) the channel will target. */ __u32 host1x_class; /** * @flags: * * [in] Flags. Currently none are specified. */ __u32 flags; /** * @channel_id: * * [out] Process-specific identifier corresponding to opened * channel. Not the hardware channel ID. */ __u32 channel_id; /** * @hardware_version: * * [out] Hardware version of the engine targeted by the channel. * Userspace can use this to select appropriate programming * sequences. */ __u32 hardware_version; /** * @mode: * * [out] Mode the hardware is executing in. Some engines can be * configured with different firmware supporting different * functionality depending on the system configuration. This * value allows userspace to detect if the engine is configured * for the intended use case. */ __u32 mode; __u32 reserved[3]; }; ``` ### DRM_TEGRA_CLOSE_CHANNEL ``` struct drm_tegra_close_channel { /** * @channel_id: * * [in] ID of channel to close. */ __u32 channel_id; __u32 reserved[3]; }; ``` ### DRM_TEGRA_CHANNEL_MAP Make memory accessible by the engine while executing work on the channel. ``` #define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0) struct drm_tegra_channel_map { /* * [in] ID of the channel for which to map memory to. */ __u32 channel_id; /* * [in] GEM handle of the memory to map. */ __u32 handle; /* * [in] Offset in GEM handle of the memory area to map. * * Must be aligned by 4K. */ __u64 offset; /* * [in] Length of memory area to map in bytes. * * Must be aligned by 4K. */ __u64 length; /* * [out] IOVA of mapped memory. Userspace can use this IOVA * directly to refer to the memory to skip using relocations. * Only available if hardware memory isolation is enabled. * * Will be set to 0xffff_ffff_ffff_ffff if unavailable. */ __u64 iova; /* * [out] ID corresponding to the mapped memory to be used for * relocations or unmapping. */ __u32 mapping_id; /* * [in] Flags. */ __u32 flags; __u32 reserved[6]; }; ``` ### DRM_TEGRA_CHANNEL_UNMAP Unmap previously mapped memory. Userspace shall do this only after it has determined the channel will no longer access the memory. ``` struct drm_tegra_channel_unmap { /* * [in] ID of the mapping to remove. */ __u32 mapping_id; __u32 reserved[3]; }; ``` ### DRM_TEGRA_CHANNEL_SUBMIT Submit a job to the engine/class targeted by the channel. ``` struct drm_tegra_submit_syncpt_incr { /* * [in] Syncpoint FD of the syncpoint that the job will * increment. */ __s32 syncpt_fd; /* * [in] Number of increments that the job will do. */ __u32 num_incrs; /* * [out] Value the syncpoint will have once all increments have * executed. */ __u32 fence_value; __u32 reserved[1]; }; /* Sets paddr/IOVA bit 39 on T194 to enable MC swizzling */ #define DRM_TEGRA_SUBMIT_RELOCATION_BLOCKLINEAR (1<<0) struct drm_tegra_submit_relocation { /* [in] Index of GATHER or GATHER_UPTR command in commands. */ __u32 gather_command_index; /* * [in] Mapping handle (obtained through CHANNEL_MAP) of the memory * the address of which will be patched in. */ __u32 mapping_id; /* * [in] Offset in the gather that will be patched. */ __u64 gather_offset; /* * [in] Offset in target buffer whose paddr/IOVA will be written * to the gather. */ __u64 target_offset; /* * [in] Number of bits the resulting address will be logically * shifted right before writing to gather. */ __u32 shift; __u32 reserved[1]; }; /* Command is an opcode gather from a GEM handle */ #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0 /* Command is an opcode gather from a user pointer */ #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1 /* Command is a wait for syncpt fence completion */ #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCPT 2 /* Command is a wait for SYNC_FILE FD completion */ #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNC_FILE 3 /* Command is a wait for DRM syncobj completion */ #define DRM_TEGRA_SUBMIT_COMMAND_WAIT_SYNCOBJ 4 /* * Allow driver to skip command execution if engine * was not accessed by another channel between * submissions. */ #define DRM_TEGRA_SUBMIT_CONTEXT_SETUP (1<<0) struct drm_tegra_submit_command { __u16 type; __u16 flags; union { struct { /* GEM handle */ __u32 handle; /* * Offset into GEM object in bytes. * Must be aligned by 4. */ __u64 offset; /* * Length of gather in bytes. * Must be aligned by 4. */ __u64 length; } gather; struct { __u32 reserved[1]; /* * Pointer to gather data. * Must be aligned by 4 bytes. */ __u64 base; /* * Length of gather in bytes. * Must be aligned by 4. */ __u64 length; } gather_uptr; struct { __u32 syncpt_id; __u32 threshold; __u32 reserved[1]; } wait_syncpt; struct { __s32 fd; } wait_sync_file; struct { __u32 handle; } wait_syncobj; }; }; #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0) #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1) struct drm_tegra_channel_submit { __u32 channel_id; __u32 flags; /** * [in] Timeout in microseconds after which the kernel may * consider the job to have hung and may reap it and * fast-forward its syncpoint increments. * * The value may be capped by the kernel. */ __u32 timeout; __u32 num_syncpt_incrs; __u32 num_relocations; __u32 num_commands; __u64 syncpt_incrs; __u64 relocations; __u64 commands; /** * [out] Invalid, SYNC_FILE FD or syncobj handle, depending on * if DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE, * DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ, or neither are passed. * Passing both is an error. * * The created fence object is signaled when all syncpoint * increments specified in `syncpt_incrs' have executed. */ __u32 post_fence; __u32 reserved[3]; }; ``` ## Example workflows ### Image processing with TegraDRM/VIC This example is a simple single-step operation using VIC through TegraDRM. For example, assume we have a dma-buf fd with an image we want to convert from YUV to RGB. This can occur for example as part of video decoding. Syncpoint initialization 1. Allocate syncpoint (HOST1X_ALLOCATE_SYNCPOINT) 1. This is used to track VIC submission completion. 2. Retrieve syncpoint ID (HOST1X_SYNCPOINT_INFO) 1. The ID is required to program the increment as part of the submission. Buffer allocation 3. Allocate memory for configuration buffers (DMA Heaps) 4. Import configuration buffer dma-buf as GEM object 5. Import input image dma-buf as GEM object Channel initialization 6. Open VIC channel (DRM_TEGRA_OPEN_CHANNEL) 7. Map buffers for access by VIC (DRM_TEGRA_CHANNEL_MAP) 8. Create Host1x opcode buffer as userspace memory 1. If buffer mapping returned an IOVA, that IOVA can be placed directly into the buffer. Otherwise, a relocation has to be passed as part of the submission 2. The buffer should contain a syncpoint increment for the syncpoint allocated earlier. 9. Submit work, passing in the syncpoint file descriptor allocated in the beginning. The submit optionally returns a syncfd/syncobj that can be used to wait for submission completion. 1. If more fine-grained syncpoint waiting is required, the 'fence' out-parameter of 'drm_tegra_submit_syncpt_incr' can be used in conjunction with HOST1X_CREATE_FENCE to create specific fences. ### Camera-GPU-CPU pipeline without TegraDRM This example shows a pipeline with image input from a camera being processed using the GPU programmed from userspace, and then finally analyzed by CPU. This kind of usecase can occur e.g. as part of a computer vision usecase. Syncpoint initialization 1. Camera V4L2 driver allocates a syncpoint internally within the kernel. 2. For CPU job tracking, allocate a syncpoint as in "Image processing with TegraDRM/VIC". 3. For GPU job tracking, the GPU kernel driver would allocate a syncpoint and assign it such that the GPU channel can access it. Camera pipeline step 4. Allocate a dma-buf to store the captured image. 5. Trigger camera capture and store the resulting sync_file fd. GPU pipeline step 6. Use HOST1X_GET_FENCE_INFO to extract syncpoint ID/threshold pair(s) from camera step's post-fence sync_file FD. If the sync_file FD is not backed by syncpoints, wait for the sync_file FD to signal otherwise (e.g. through polling it). 7. Use HOST1X_CREATE_FENCE to create a postfence that is signaled when the GPU step is complete. 8. Program the GPU to 1. Wait for the syncpoint thresholds extracted from the camera postfence, if we were able to do so. 2. Execute image processing on GPU. 3. Increment GPU's job tracking syncpoint, causing the GPU post-fence FD to get signaled. CPU pipeline step 9. Wait for GPU's post-fence sync_file FD 10. Map the dma-buf containing the image and retrieve results. In place of the GPU pipeline step, a similar workflow would apply for a step executed on the CPU. -- thanks, Mikko

5 49

[PATCH 00/18] dma-fence lockdep annotations, round 2
by Daniel Vetter 09 Jul '20

09 Jul '20

Hi all, Still very much early stuff, still very much looking for initial thoughts and maybe some ideas how this could all be rolled out across drivers. Full intro probably best from the RFC cover letter: https://lore.kernel.org/amd-gfx/20200512085944.222637-1-daniel.vetter@ffwll… Changes since last time around: - might_sleep annotation has landed already, I split that out as a stand-alone - now with an mm patch to improve direct reclaim annotations for mmu notifiers. This allows us to very easily catch issues in that area, no more need for exaustive testing and luck to make sure we're not leaving a GFP_NOFS or GPF_NOIO around which should be a GFP_ATOMIC - kerneldoc that explains all the reasoning behind the annotations and priming, hopefully Driver patches still largely just meant as examples to illustrate usage, but from various irc chats I think discussing them is really useful to gain clarity on the exact places the annotations should be put. Cheers, Daniel Daniel Vetter (18): mm: Track mmu notifiers in fs_reclaim_acquire/release dma-buf: minor doc touch-ups dma-fence: basic lockdep annotations dma-fence: prime lockdep annotations drm/vkms: Annotate vblank timer drm/vblank: Annotate with dma-fence signalling section drm/atomic-helper: Add dma-fence annotations drm/amdgpu: add dma-fence annotations to atomic commit path drm/scheduler: use dma-fence annotations in main thread drm/amdgpu: use dma-fence annotations in cs_submit() drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code drm/amdgpu: DC also loves to allocate stuff where it shouldn't drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail drm/scheduler: use dma-fence annotations in tdr work drm/amdgpu: use dma-fence annotations for gpu reset code Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" drm/amdgpu: gpu recovery does full modesets drm/i915: Annotate dma_fence_work Documentation/driver-api/dma-buf.rst | 18 +- drivers/dma-buf/dma-buf.c | 6 +- drivers/dma-buf/dma-fence.c | 202 ++++++++++++++++++ drivers/dma-buf/dma-resv.c | 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 22 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- drivers/gpu/drm/amd/amdgpu/atom.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c | 16 ++ drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 3 + drivers/gpu/drm/scheduler/sched_main.c | 11 + drivers/gpu/drm/vkms/vkms_crtc.c | 8 +- include/linux/dma-fence.h | 13 ++ mm/mmu_notifier.c | 7 - mm/page_alloc.c | 23 +- 20 files changed, 341 insertions(+), 35 deletions(-) -- 2.26.2

15 107

[PATCH v2 0/6] iommu-arm-smmu: Add auxiliary domains and per-instance pagetables
by Jordan Crouse 08 Jul '20

08 Jul '20

This is a new refresh of support for auxiliary domains for arm-smmu-v2 and per-instance pagetables for drm/msm. The big change here from past efforts is that outside of creating a single aux-domain to enable TTBR0 all of the per-instance pagetables are created and managed exclusively in drm/msm without involving the arm-smmu driver. This fits in with the suggested model of letting the GPU hardware do what it needs and leave the arm-smmu driver blissfully unaware. Almost. In order to set up the io-pgtable properly in drm/msm we need to query the pagetable configuration from the current active domain and we need to rely on the iommu API to flush TLBs after a unmap. In the future we can optimize this in the drm/msm driver to track the state of the TLBs but for now the big hammer lets us get off the ground. This series is built on the split pagetable support [1]. [1] https://patchwork.kernel.org/patch/11628543/ v2: Remove unneeded cruft in the a6xx page switch sequence Jordan Crouse (6): iommu/arm-smmu: Add auxiliary domain support for arm-smmuv2 iommu/io-pgtable: Allow a pgtable implementation to skip TLB operations iommu/arm-smmu: Add a domain attribute to pass the pagetable config drm/msm: Add support to create a local pagetable drm/msm: Add support for address space instances drm/msm/a6xx: Add support for per-instance pagetables drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++++ drivers/gpu/drm/msm/msm_drv.c | 15 +- drivers/gpu/drm/msm/msm_drv.h | 4 + drivers/gpu/drm/msm/msm_gem_vma.c | 9 + drivers/gpu/drm/msm/msm_gpu.c | 17 ++ drivers/gpu/drm/msm/msm_gpu.h | 5 + drivers/gpu/drm/msm/msm_gpummu.c | 2 +- drivers/gpu/drm/msm/msm_iommu.c | 180 +++++++++++++++++++- drivers/gpu/drm/msm/msm_mmu.h | 16 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 1 + drivers/iommu/arm-smmu.c | 231 ++++++++++++++++++++++++-- drivers/iommu/arm-smmu.h | 1 + include/linux/io-pgtable.h | 11 +- include/linux/iommu.h | 1 + 14 files changed, 507 insertions(+), 29 deletions(-) -- 2.17.1

3 9

[PATCH 0/2] drm/probe_helper, i915: Validate MST modes against PBN limits
by Lyude Paul 08 Jul '20

08 Jul '20

Something we've been missing for a while with drivers that support MST is being able to prune modes that can't be set due to bandwidth limitations. So, let's go ahead and add that. This also adds a new hook that was needed, mode_valid_ctx, so that we can grab additional locks as needed when validating modes. Lee Shawn C (1): drm/i915/mst: filter out the display mode exceed sink's capability Lyude Paul (1): drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx drivers/gpu/drm/drm_crtc_helper_internal.h | 6 +- drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++------- drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 +++++++++++-- include/drm/drm_modeset_helper_vtables.h | 41 +++++++++++++ 4 files changed, 123 insertions(+), 28 deletions(-) -- 2.26.2

2 7

← Newer
1
...
15
16
17
18
19
20
21
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020