dri-devel December 2020

dri-devel@lists.freedesktop.org

278 participants
659 discussions

[Bug 202043] New: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=202043 Bug ID: 202043 Summary: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20.0-rc6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: antifermion(a)protonmail.com Regression: No When undervolting my Sapphire Pulse Vega 56 by just 1mV, SCLK immediately drops down to 700 Mhz and pstate 1-2 under load (`gputest /test=fur /width=1920 /height=1080`). Script to undervolt: ``` echo "s 7 1630 1199" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage ``` Stock voltage would be 1200 on the Vega 64 Bios. The same behavior can be observed with the stock Vega 56 Bios. Undervolting the memory by 1mV results in similar behavior. Overvolting by 1mV has no discernable effect. `echo r > pp_od_clk_voltage` does not work to go back to the normal behavior. Instead, I need to use `echo "s 7 1630 1200" > pp_od_clk_voltage` as above. Without undervolting, SCLK is around 1330 Mhz, which matches the behavior on Windows, where undervolting by around 150 mV is no problem and increases clock. With an increased power limit of 300W, the clocks increase to around 1100 Mhz while the card uses the full 300W. It even maxes that limit with a significant underclock/undervolt which would pull around 200W on Windows. I tested with current Manjaro (4.19.8-2-MANJARO), as well as Kubuntu 18.10 with stock (4.18) and 4.20 from https://github.com/M-Bab/linux-kernel-amdgpu-binaries. -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

Re: [Nouveau] [PATCH] drm/nouveau: bail out of nouveau_channel_new if channel init fails
by Karol Herbst 07 Feb '21

07 Feb '21

On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso <carnil(a)debian.org> wrote: > > Hi, > > On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote: > > Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC > > ioctl. This was reported by trinity[1] fuzzer. > > > > [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 > > [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 > > [ 71.088928] #PF: supervisor read access in kernel mode > > [ 71.094059] #PF: error_code(0x0000) - not-present page > > [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0 > > [ 71.104842] Oops: 0000 [#1] SMP NOPTI > > [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2 > > [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014 > > [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau] > > [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41 > > [ 71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246 > > [ 71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf > > [ 71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160 > > [ 71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000 > > [ 71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08 > > [ 71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0 > > [ 71.188339] FS: 00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000 > > [ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0 > > [ 71.209297] Call Trace: > > [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] > > [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm] > > [ 71.222421] drm_ioctl+0x211/0x3c0 [drm] > > [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] > > [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau] > > [ 71.237285] ksys_ioctl+0x86/0xc0 > > [ 71.240595] __x64_sys_ioctl+0x16/0x20 > > [ 71.244340] do_syscall_64+0x4c/0x90 > > [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [ 71.253162] RIP: 0033:0x7fd925d4b88b > > [ 71.256731] Code: Bad RIP value. > > [ 71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 > > [ 71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b > > [ 71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003 > > [ 71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0 > > [ 71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620 > > [ 71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000 > > [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod > > [ 71.365269] CR2: 00000000000000a0 > > > > simplified reproducer > > ---------------------------------8<---------------------------------------- > > /* > > * gcc -o crashme crashme.c > > * ./crashme /dev/dri/renderD128 > > */ > > > > struct drm_nouveau_channel_alloc { > > uint32_t fb_ctxdma_handle; > > uint32_t tt_ctxdma_handle; > > > > int channel; > > uint32_t pushbuf_domains; > > > > /* Notifier memory */ > > uint32_t notifier_handle; > > > > /* DRM-enforced subchannel assignments */ > > struct { > > uint32_t handle; > > uint32_t grclass; > > } subchan[8]; > > uint32_t nr_subchan; > > }; > > > > static struct drm_nouveau_channel_alloc channel; > > > > int main(int argc, char *argv[]) { > > int fd; > > int rv; > > > > if (argc != 2) > > die("usage: %s <dev>", 0, argv[0]); > > > > if ((fd = open(argv[1], O_RDONLY)) == -1) > > die("open %s", errno, argv[1]); > > > > if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 && > > errno == EACCES) > > die("ioctl %s", errno, argv[1]); > > > > close(fd); > > > > printf("PASS\n"); > > > > return 0; > > } > > ---------------------------------8<---------------------------------------- > > > > [1] https://github.com/kernelslacker/trinity > > > > Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory") > > Signed-off-by: Frantisek Hrbata <frantisek at hrbata.com> > > --- > > drivers/gpu/drm/nouveau/nouveau_chan.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c b/drivers/gpu/drm/nouveau/nouveau_chan.c > > index b80e4ebf1..a7a47b325 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_chan.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c > > @@ -533,6 +533,7 @@ nouveau_channel_new(struct nouveau_drm *drm, struct nvif_device *device, > > if (ret) { > > NV_PRINTK(err, cli, "channel failed to initialise, %d\n", ret); > > nouveau_channel_del(pchan); > > + goto done; > > } > > > > ret = nouveau_svmm_join((*pchan)->vmm->svmm, (*pchan)->inst); > > -- > > Frantisek Hrbata > > Is this still planned to be applied? AFAICS this is the fix for > CVE-2020-25639. > If it's urgent to get it fixed, I suggest going through the Linux kernel or drm stable path. CCing dri-devel, Dave, Daniel and Ben. > Regards, > Salvatore > _______________________________________________ > Nouveau mailing list > Nouveau(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau >

3 2

[PATCH v16 0/4] RDMA: Add dma-buf support
by Jianxin Xiong 05 Feb '21

05 Feb '21

This is the sixteenth version of the patch set. Changelog: v16: * Add "select DMA_SHARED_BUFFER" to Kconfig when IB UMEM is enabled. This fixes the auto build test error with a random config. v15: https://www.spinics.net/lists/linux-rdma/msg98369.html * Rebase to the latest linux-rdma 'for-next' branch (commit 0583531bb9ef) to pick up RDMA core and mlx5 updates * Let ib_umem_dmabuf_get() return 'struct ib_umem_dmabuf *' instead of 'struct ib_umem *' * Move the check of on demand paging support to mlx5_ib_reg_user_mr_dmabuf() * Check iova alignment at the entry point of the uverb command so that mlx5_umem_dmabuf_default_pgsz() can always succeed v14: https://www.spinics.net/lists/linux-rdma/msg98265.html * Check return value of dma_fence_wait() * Fix a dma-buf leak in ib_umem_dmabuf_get() * Fix return value type cast for ib_umem_dmabuf_get() * Return -EOPNOTSUPP instead of -EINVAL for unimplemented functions * Remove an unnecessary use of unlikely() * Remove left-over commit message resulted from rebase v13: https://www.spinics.net/lists/linux-rdma/msg98227.html * Rebase to the latest linux-rdma 'for-next' branch (5.10.0-rc6+) * Check for device on-demand paging capability at the entry point of the new verbs command to avoid calling device's reg_user_mr_dmabuf() method when CONFIG_INFINIBAND_ON_DEMAND_PAGING is diabled. v12: https://www.spinics.net/lists/linux-rdma/msg97943.html * Move the prototype of function ib_umem_dmabuf_release() to ib_umem.h and remove umem_dmabuf.h * Break a line that is too long v11: https://www.spinics.net/lists/linux-rdma/msg97860.html * Rework the parameter checking code inside ib_umem_dmabuf_get() * Fix incorrect error handling in the new verbs command handler * Put a duplicated code sequence for checking iova and setting page size into a function * In the invalidation callback, check for if the buffer has been mapped and thus the presence of a valid driver mr is ensured * The patch that checks for dma_virt_ops is dropped because it is no longer needed * The patch that documents that dma-buf size is fixed has landed at: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=476b485be03c and thus is no longer included here * The matching user space patch set is sent separately v10: https://www.spinics.net/lists/linux-rdma/msg97483.html * Don't map the pages in ib_umem_dmabuf_get(); use the size information of the dma-buf object to validate the umem size instead * Use PAGE_SIZE directly instead of use ib_umem_find_best_pgsz() when the MR is created since the pages have not been mapped yet and dma-buf requires PAGE_SIZE anyway * Always call mlx5_umem_find_best_pgsz() after mapping the pages to verify that the page size requirement is satisfied * Add a patch to document that dma-buf size is fixed v9: https://www.spinics.net/lists/linux-rdma/msg97432.html * Clean up the code for sg list in-place modification * Prevent dma-buf pages from being mapped multiple times * Map the pages in ib_umem_dmabuf_get() so that inproper values of address/length/iova can be caught early * Check for unsupported flags in the new uverbs command * Add missing uverbs_finalize_uobj_create() * Sort uverbs objects by name * Fix formating issue -- unnecessary alignment of '=' * Unmap pages in mlx5_ib_fence_dmabuf_mr() * Remove address range checking from pagefault_dmabuf_mr() v8: https://www.spinics.net/lists/linux-rdma/msg97370.html * Modify the dma-buf sg list in place to get a proper umem sg list and restore it before calling dma_buf_unmap_attachment() * Validate the umem sg list with ib_umem_find_best_pgsz() * Remove the logic for slicing the sg list at runtime v7: https://www.spinics.net/lists/linux-rdma/msg97297.html * Rebase on top of latest mlx5 MR patch series * Slice dma-buf sg list at runtime instead of creating a new list * Preload the buffer page mapping when the MR is created * Move the 'dma_virt_ops' check into dma_buf_dynamic_attach() v6: https://www.spinics.net/lists/linux-rdma/msg96923.html * Move the dma-buf invalidation callback from the core to the device driver * Move mapping update from work queue to pagefault handler * Add dma-buf based MRs to the xarray of mmkeys so that the pagefault handler can be reached * Update the new driver method and uverbs command signature by changing the paramter 'addr' to 'offset' * Modify the sg list returned from dma_buf_map_attachment() based on the parameters 'offset' and 'length' * Don't import dma-buf if 'dma_virt_ops' is used by the dma device * The patch that clarifies dma-buf sg lists alignment has landed at https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac80cd17a615 and thus is no longer included with this set v5: https://www.spinics.net/lists/linux-rdma/msg96786.html * Fix a few warnings reported by kernel test robot: - no previous prototype for function 'ib_umem_dmabuf_release' - no previous prototype for function 'ib_umem_dmabuf_map_pages' - comparison of distinct pointer types in 'check_add_overflow' * Add comment for the wait between getting the dma-buf sg tagle and updating the NIC page table v4: https://www.spinics.net/lists/linux-rdma/msg96767.html * Add a new ib_device method reg_user_mr_dmabuf() instead of expanding the existing method reg_user_mr() * Use a separate code flow for dma-buf instead of adding special cases to the ODP memory region code path * In invalidation callback, new mapping is updated as whole using work queue instead of being updated in page granularity in the page fault handler * Use dma_resv_get_excl() and dma_fence_wait() to ensure the content of the pages have been moved to the new location before the new mapping is programmed into the NIC * Add code to the ODP page fault handler to check the mapping status * The new access flag added in v3 is removed. * The checking for on-demand paging support in the new uverbs command is removed because it is implied by implementing the new ib_device method * Clarify that dma-buf sg lists are page aligned v3: https://www.spinics.net/lists/linux-rdma/msg96330.html * Use dma_buf_dynamic_attach() instead of dma_buf_attach() * Use on-demand paging mechanism to avoid pinning the GPU memory * Instead of adding a new parameter to the device method for memory registration, pass all the attributes including the file descriptor as a structure * Define a new access flag for dma-buf based memory region * Check for on-demand paging support in the new uverbs command v2: https://www.spinics.net/lists/linux-rdma/msg93643.html * The Kconfig option is removed. There is no dependence issue since dma-buf driver is always enabled. * The declaration of new data structure and functions is reorganized to minimize the visibility of the changes. * The new uverbs command now goes through ioctl() instead of write(). * The rereg functionality is removed. * Instead of adding new device method for dma-buf specific registration, existing method is extended to accept an extra parameter. * The correct function is now used for address range checking. v1: https://www.spinics.net/lists/linux-rdma/msg90720.html * The initial patch set * Implement core functions for importing and mapping dma-buf * Use dma-buf static attach interface * Add two ib_device methods reg_user_mr_fd() and rereg_user_mr_fd() * Add two uverbs commands via the write() interface * Add Kconfig option * Add dma-buf support to mlx5 device When enabled, an RDMA capable NIC can perform peer-to-peer transactions over PCIe to access the local memory located on another device. This can often lead to better performance than using a system memory buffer for RDMA and copying data between the buffer and device memory. Current kernel RDMA stack uses get_user_pages() to pin the physical pages backing the user buffer and uses dma_map_sg_attrs() to get the dma addresses for memory access. This usually doesn't work for peer device memory due to the lack of associated page structures. Several mechanisms exist today to facilitate device memory access. ZONE_DEVICE is a new zone for device memory in the memory management subsystem. It allows pages from device memory being described with specialized page structures, but what can be done with these page structures may be different from system memory. ZONE_DEVICE is further specialized into multiple memory types, such as one type for PCI p2pmem/p2pdma and one type for HMM. PCI p2pmem/p2pdma uses ZONE_DEVICE to represent device memory residing in a PCI BAR and provides a set of calls to publish, discover, allocate, and map such memory for peer-to-peer transactions. One feature of the API is that the buffer is allocated by the side that does the DMA transfer. This works well with the storage usage case, but is awkward with GPU-NIC communication, where typically the buffer is allocated by the GPU driver rather than the NIC driver. Heterogeneous Memory Management (HMM) utilizes mmu_interval_notifier and ZONE_DEVICE to support shared virtual address space and page migration between system memory and device memory. HMM doesn't support pinning device memory because pages located on device must be able to migrate to system memory when accessed by CPU. Peer-to-peer access is currently not supported by HMM. Dma-buf is a standard mechanism for sharing buffers among different device drivers. The buffer to be shared is exported by the owning driver and imported by the driver that wants to use it. The exporter provides a set of ops that the importer can call to pin and map the buffer. In addition, a file descriptor can be associated with a dma- buf object as the handle that can be passed to user space. This patch series adds dma-buf importer role to the RDMA driver in attempt to support RDMA using device memory such as GPU VRAM. Dma-buf is chosen for a few reasons: first, the API is relatively simple and allows a lot of flexibility in implementing the buffer manipulation ops. Second, it doesn't require page structure. Third, dma-buf is already supported in many GPU drivers. However, we are aware that existing GPU drivers don't allow pinning device memory via the dma-buf interface. Pinning would simply cause the backing storage to migrate to system RAM. True peer-to-peer access is only possible using dynamic attach, which requires on-demand paging support from the NIC to work. For this reason, this series only works with ODP capable NICs. This series consists of four patches. The first patch adds the common code for importing dma-buf from a file descriptor and mapping the dma-buf pages. Patch 2 add the new driver method reg_user_mr_dmabuf(). Patch 3 adds a new uverbs command for registering dma-buf based memory region. Patch 4 adds dma-buf support to the mlx5 driver. Related user space RDMA library changes are provided as a separate patch series. Jianxin Xiong (4): RDMA/umem: Support importing dma-buf as user memory region RDMA/core: Add device method for registering dma-buf based memory region RDMA/uverbs: Add uverbs command for dma-buf based MR registration RDMA/mlx5: Support dma-buf based userspace memory region drivers/infiniband/Kconfig | 1 + drivers/infiniband/core/Makefile | 2 +- drivers/infiniband/core/device.c | 1 + drivers/infiniband/core/umem.c | 3 + drivers/infiniband/core/umem_dmabuf.c | 174 ++++++++++++++++++++++++++ drivers/infiniband/core/uverbs_std_types_mr.c | 117 ++++++++++++++++- drivers/infiniband/hw/mlx5/main.c | 2 + drivers/infiniband/hw/mlx5/mlx5_ib.h | 18 +++ drivers/infiniband/hw/mlx5/mr.c | 112 ++++++++++++++++- drivers/infiniband/hw/mlx5/odp.c | 89 ++++++++++++- include/rdma/ib_umem.h | 48 ++++++- include/rdma/ib_verbs.h | 6 +- include/uapi/rdma/ib_user_ioctl_cmds.h | 14 +++ 13 files changed, 573 insertions(+), 14 deletions(-) create mode 100644 drivers/infiniband/core/umem_dmabuf.c -- 1.8.3.1

8 23

[PATCH v3 1/4] dp/dp_mst: Add support for sink event notify messages
by Sam McNally 05 Feb '21

05 Feb '21

Sink event notify messages are used for MST CEC IRQs. Add parsing support for sink event notify messages in preparation for handling MST CEC IRQs. Signed-off-by: Sam McNally <sammc(a)chromium.org> --- (no changes since v1) drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++++++++++++++++++++++++++- include/drm/drm_dp_mst_helper.h | 14 ++++++++++ 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 17dbed0a9800..15b6cc39a754 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1027,6 +1027,30 @@ static bool drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_ return false; } +static bool drm_dp_sideband_parse_sink_event_notify( + struct drm_dp_sideband_msg_rx *raw, + struct drm_dp_sideband_msg_req_body *msg) +{ + int idx = 1; + + msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4; + idx++; + if (idx > raw->curlen) + goto fail_len; + + memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16); + idx += 16; + if (idx > raw->curlen) + goto fail_len; + + msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]); + idx++; + return true; +fail_len: + DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx, raw->curlen); + return false; +} + static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw, struct drm_dp_sideband_msg_req_body *msg) { @@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw, return drm_dp_sideband_parse_connection_status_notify(raw, msg); case DP_RESOURCE_STATUS_NOTIFY: return drm_dp_sideband_parse_resource_status_notify(raw, msg); + case DP_SINK_EVENT_NOTIFY: + return drm_dp_sideband_parse_sink_event_notify(raw, msg); default: DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type, drm_dp_mst_req_type_str(msg->req_type)); @@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr, guid = msg->u.conn_stat.guid; else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY) guid = msg->u.resource_stat.guid; + else if (msg->req_type == DP_SINK_EVENT_NOTIFY) + guid = msg->u.sink_event.guid; if (guid) mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid); @@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg); if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY && - up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) { + up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY && + up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) { DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n", up_req->msg.req_type); kfree(up_req); @@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n", res_stat->port_number, res_stat->available_pbn); + } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) { + const struct drm_dp_sink_event_notify *sink_event = + &up_req->msg.u.sink_event; + + DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n", + sink_event->port_number, sink_event->event_id); } up_req->hdr = mgr->up_req_recv.initial_hdr; diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 6ae5860d8644..c7c79e0ced18 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify { u16 available_pbn; }; +#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR BIT(0) +#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR BIT(1) +#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUN BIT(2) +#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW BIT(3) +#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR BIT(4) +#define DP_SINK_EVENT_CEC_IRQ_EVENT BIT(5) + +struct drm_dp_sink_event_notify { + u8 port_number; + u8 guid[16]; + u16 event_id; +}; + struct drm_dp_query_payload_ack_reply { u8 port_number; u16 allocated_pbn; @@ -413,6 +426,7 @@ struct drm_dp_sideband_msg_req_body { struct drm_dp_connection_status_notify conn_stat; struct drm_dp_port_number_req port_num; struct drm_dp_resource_status_notify resource_stat; + struct drm_dp_sink_event_notify sink_event; struct drm_dp_query_payload query_payload; struct drm_dp_allocate_payload allocate_payload; -- 2.28.0.681.g6f77f65b4e-goog

4 20

[PATCH v7 00/17] follow_pfn and other iomap races
by Daniel Vetter 04 Feb '21

04 Feb '21

Hi all Another update of my patch series to clamp down a bunch of races and gaps around follow_pfn and other access to iomem mmaps. Previous version: v1: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@ff… v2: https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vetter@ff… v3: https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vetter@ff… v4: https://lore.kernel.org/dri-devel/20201026105818.2585306-1-daniel.vetter@ff… v5: https://lore.kernel.org/dri-devel/20201030100815.2269-1-daniel.vetter@ffwll… v6: https://lore.kernel.org/dri-devel/20201119144146.1045202-1-daniel.vetter@ff… And the discussion that sparked this journey: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@ff… I think the first 12 patches are ready for landing. The parts starting with "mm: Add unsafe_follow_pfn" probably need more baking time. Andrew, can you please pick these up, or do you prefer I do a topic branch and send them to Linus directly in the next merge window? Changes in v7: - more acks/reviews - reordered with the ready pieces at the front - simplified the new follow_pfn function as Jason suggested Changes in v6: - Tested v4l userptr as Tomasz suggested. No boom observed - Added RFC for locking down follow_pfn, per discussion with Christoph and Jason. - Explain why pup_fast is safe in relevant patches, there was a bit a confusion when discussing v5. - Fix up the resource patch, with CONFIG_IO_STRICT_DEVMEM it crashed on boot due to an unintended change (reported by John) Changes in v5: - Tomasz found some issues in the media patches - Polish suggested by Christoph for the unsafe_follow_pfn patch Changes in v4: - Drop the s390 patch, that was very stand-alone and now queued up to land through s390 trees. - Comment polish per Dan's review. Changes in v3: - Bunch of polish all over, no functional changes aside from one barrier in the resource code, for consistency. - A few more r-b tags. Changes in v2: - tons of small polish&fixes all over, thanks to all the reviewers who spotted issues - I managed to test at least the generic_access_phys and pci mmap revoke stuff with a few gdb sessions using our i915 debug tools (hence now also the drm/i915 patch to properly request all the pci bar regions) - reworked approach for the pci mmap revoke: Infrastructure moved into kernel/resource.c, address_space mapping is now set up at open time for everyone (which required some sysfs changes). Does indeed look a lot cleaner and a lot less invasive than I feared at first. Coments and review on the remaining bits very much welcome, especially from the kvm and vfio side. Cheers, Daniel Daniel Vetter (17): drm/exynos: Stop using frame_vector helpers drm/exynos: Use FOLL_LONGTERM for g2d cmdlists misc/habana: Stop using frame_vector helpers misc/habana: Use FOLL_LONGTERM for userptr mm/frame-vector: Use FOLL_LONGTERM media: videobuf2: Move frame_vector into media subsystem mm: Close race in generic_access_phys PCI: Obey iomem restrictions for procfs mmap /dev/mem: Only set filp->f_mapping resource: Move devmem revoke code to resource framework sysfs: Support zapping of binary attr mmaps PCI: Revoke mappings like devmem mm: Add unsafe_follow_pfn media/videobuf1|2: Mark follow_pfn usage as unsafe vfio/type1: Mark follow_pfn as unsafe kvm: pass kvm argument to follow_pfn callsites mm: add mmu_notifier argument to follow_pfn arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +- arch/powerpc/kvm/e500_mmu_host.c | 2 +- arch/x86/kvm/mmu/mmu.c | 8 +- drivers/char/mem.c | 86 +------------- drivers/gpu/drm/exynos/Kconfig | 1 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 ++++---- drivers/media/common/videobuf2/Kconfig | 1 - drivers/media/common/videobuf2/Makefile | 1 + .../media/common/videobuf2}/frame_vector.c | 57 ++++----- .../media/common/videobuf2/videobuf2-memops.c | 3 +- drivers/media/platform/omap/Kconfig | 1 - drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- drivers/misc/habanalabs/Kconfig | 1 - drivers/misc/habanalabs/common/habanalabs.h | 6 +- drivers/misc/habanalabs/common/memory.c | 52 +++----- drivers/pci/pci-sysfs.c | 4 + drivers/pci/proc.c | 6 + drivers/vfio/vfio_iommu_type1.c | 4 +- fs/sysfs/file.c | 11 ++ include/linux/ioport.h | 6 +- include/linux/kvm_host.h | 9 +- include/linux/mm.h | 50 +------- include/linux/sysfs.h | 2 + include/media/frame_vector.h | 47 ++++++++ include/media/videobuf2-core.h | 1 + kernel/resource.c | 98 ++++++++++++++- mm/Kconfig | 3 - mm/Makefile | 1 - mm/memory.c | 112 +++++++++++++++--- mm/nommu.c | 16 ++- security/Kconfig | 13 ++ virt/kvm/kvm_main.c | 56 +++++---- 33 files changed, 413 insertions(+), 299 deletions(-) rename {mm => drivers/media/common/videobuf2}/frame_vector.c (84%) create mode 100644 include/media/frame_vector.h -- 2.29.2

7 31

[RFC][PATCH 1/3] dma-buf: heaps: Add deferred-free-helper library code
by John Stultz 03 Feb '21

03 Feb '21

This patch provides infrastructure for deferring buffer frees. This is a feature ION provided which when used with some form of a page pool, provides a nice performance boost in an allocation microbenchmark. The reason it helps is it allows the page-zeroing to be done out of the normal allocation/free path, and pushed off to a kthread. As not all heaps will find this useful, its implemented as a optional helper library that heaps can utilize. Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Chris Goldsworthy <cgoldswo(a)codeaurora.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: Ørjan Eide <orjan.eide(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Ezequiel Garcia <ezequiel(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: James Jones <jajones(a)nvidia.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/dma-buf/heaps/Kconfig | 3 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/deferred-free-helper.c | 136 +++++++++++++++++++ drivers/dma-buf/heaps/deferred-free-helper.h | 15 ++ 4 files changed, 155 insertions(+) create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index a5eef06c4226..ecf65204f714 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -1,3 +1,6 @@ +config DMABUF_HEAPS_DEFERRED_FREE + bool + config DMABUF_HEAPS_SYSTEM bool "DMA-BUF System Heap" depends on DMABUF_HEAPS diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index 974467791032..4e7839875615 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c b/drivers/dma-buf/heaps/deferred-free-helper.c new file mode 100644 index 000000000000..b8f54860454f --- /dev/null +++ b/drivers/dma-buf/heaps/deferred-free-helper.c @@ -0,0 +1,136 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Deferred dmabuf freeing helper + * + * Copyright (C) 2020 Linaro, Ltd. + * + * Based on the ION page pool code + * Copyright (C) 2011 Google, Inc. + */ + +#include <linux/freezer.h> +#include <linux/list.h> +#include <linux/slab.h> +#include <linux/swap.h> +#include <linux/sched/signal.h> + +#include "deferred-free-helper.h" + +static LIST_HEAD(free_list); +static size_t list_size; +wait_queue_head_t freelist_waitqueue; +struct task_struct *freelist_task; +static DEFINE_MUTEX(free_list_lock); + +enum { + USE_POOL = 0, + SKIP_POOL = 1, +}; + +void deferred_free(struct deferred_freelist_item *item, + void (*free)(struct deferred_freelist_item*, bool), + size_t size) +{ + INIT_LIST_HEAD(&item->list); + item->size = size; + item->free = free; + + mutex_lock(&free_list_lock); + list_add(&item->list, &free_list); + list_size += size; + mutex_unlock(&free_list_lock); + wake_up(&freelist_waitqueue); +} + +static size_t free_one_item(bool nopool) +{ + size_t size = 0; + struct deferred_freelist_item *item; + + mutex_lock(&free_list_lock); + if (list_empty(&free_list)) { + mutex_unlock(&free_list_lock); + return 0; + } + item = list_first_entry(&free_list, struct deferred_freelist_item, list); + list_del(&item->list); + size = item->size; + list_size -= size; + mutex_unlock(&free_list_lock); + + item->free(item, nopool); + return size; +} + +static unsigned long get_freelist_size(void) +{ + unsigned long size; + + mutex_lock(&free_list_lock); + size = list_size; + mutex_unlock(&free_list_lock); + return size; +} + +static unsigned long freelist_shrink_count(struct shrinker *shrinker, + struct shrink_control *sc) +{ + return get_freelist_size(); +} + +static unsigned long freelist_shrink_scan(struct shrinker *shrinker, + struct shrink_control *sc) +{ + int total_freed = 0; + + if (sc->nr_to_scan == 0) + return 0; + + while (total_freed < sc->nr_to_scan) { + int freed = free_one_item(SKIP_POOL); + + if (!freed) + break; + + total_freed += freed; + } + + return total_freed; +} + +static struct shrinker freelist_shrinker = { + .count_objects = freelist_shrink_count, + .scan_objects = freelist_shrink_scan, + .seeks = DEFAULT_SEEKS, + .batch = 0, +}; + +static int deferred_free_thread(void *data) +{ + while (true) { + wait_event_freezable(freelist_waitqueue, + get_freelist_size() > 0); + + free_one_item(USE_POOL); + } + + return 0; +} + +static int deferred_freelist_init(void) +{ + list_size = 0; + + init_waitqueue_head(&freelist_waitqueue); + freelist_task = kthread_run(deferred_free_thread, NULL, + "%s", "dmabuf-deferred-free-worker"); + if (IS_ERR(freelist_task)) { + pr_err("%s: creating thread for deferred free failed\n", + __func__); + return -1; + } + sched_set_normal(freelist_task, 19); + + return register_shrinker(&freelist_shrinker); +} +device_initcall(deferred_freelist_init); diff --git a/drivers/dma-buf/heaps/deferred-free-helper.h b/drivers/dma-buf/heaps/deferred-free-helper.h new file mode 100644 index 000000000000..09a2274a897c --- /dev/null +++ b/drivers/dma-buf/heaps/deferred-free-helper.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef DEFERRED_FREE_HELPER_H +#define DEFERRED_FREE_HELPER_H + +struct deferred_freelist_item { + size_t size; + void (*free)(struct deferred_freelist_item *i, bool no_pool); + struct list_head list; +}; + +void deferred_free(struct deferred_freelist_item *item, + void (*free)(struct deferred_freelist_item *i, bool no_pool), + size_t size); +#endif -- 2.17.1

4 11

[PATCH 00/29] treewide: Convert comma separated statements
by Joe Perches 02 Feb '21

02 Feb '21

There are many comma separated statements in the kernel. See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@had… Convert the comma separated statements that are in if/do/while blocks to use braces and semicolons. Many comma separated statements still exist but those are changes for another day. Joe Perches (29): coding-style.rst: Avoid comma statements alpha: Avoid comma separated statements ia64: Avoid comma separated statements sparc: Avoid comma separated statements ata: Avoid comma separated statements drbd: Avoid comma separated statements lp: Avoid comma separated statements dma-buf: Avoid comma separated statements drm/gma500: Avoid comma separated statements drm/i915: Avoid comma separated statements hwmon: (scmi-hwmon): Avoid comma separated statements Input: MT - Avoid comma separated statements bcache: Avoid comma separated statements media: Avoid comma separated statements mtd: Avoid comma separated statements 8390: Avoid comma separated statements fs_enet: Avoid comma separated statements wan: sbni: Avoid comma separated statements s390/tty3270: Avoid comma separated statements scai/arm: Avoid comma separated statements media: atomisp: Avoid comma separated statements video: fbdev: Avoid comma separated statements fuse: Avoid comma separated statements reiserfs: Avoid comma separated statements lib/zlib: Avoid comma separated statements lib: zstd: Avoid comma separated statements ipv6: fib6: Avoid comma separated statements sunrpc: Avoid comma separated statements tools: Avoid comma separated statements Documentation/process/coding-style.rst | 17 + arch/alpha/kernel/pci_iommu.c | 8 +- arch/alpha/oprofile/op_model_ev4.c | 22 +- arch/alpha/oprofile/op_model_ev5.c | 8 +- arch/ia64/kernel/smpboot.c | 7 +- arch/sparc/kernel/smp_64.c | 7 +- drivers/ata/pata_icside.c | 21 +- drivers/block/drbd/drbd_receiver.c | 6 +- drivers/char/lp.c | 6 +- drivers/dma-buf/st-dma-fence.c | 7 +- drivers/gpu/drm/gma500/mdfld_intel_display.c | 44 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c | 6 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +- drivers/hwmon/scmi-hwmon.c | 6 +- drivers/input/input-mt.c | 11 +- drivers/md/bcache/bset.c | 12 +- drivers/md/bcache/sysfs.c | 6 +- drivers/media/i2c/msp3400-kthreads.c | 12 +- drivers/media/pci/bt8xx/bttv-cards.c | 6 +- drivers/media/pci/saa7134/saa7134-video.c | 7 +- drivers/mtd/devices/lart.c | 10 +- drivers/net/ethernet/8390/axnet_cs.c | 19 +- drivers/net/ethernet/8390/lib8390.c | 14 +- drivers/net/ethernet/8390/pcnet_cs.c | 6 +- .../ethernet/freescale/fs_enet/fs_enet-main.c | 11 +- drivers/net/wan/sbni.c | 101 +++--- drivers/s390/char/tty3270.c | 6 +- drivers/scsi/arm/cumana_2.c | 19 +- drivers/scsi/arm/eesox.c | 9 +- drivers/scsi/arm/powertec.c | 9 +- .../media/atomisp/pci/atomisp_subdev.c | 6 +- drivers/video/fbdev/tgafb.c | 12 +- fs/fuse/dir.c | 24 +- fs/reiserfs/fix_node.c | 36 ++- lib/zlib_deflate/deftree.c | 49 ++- lib/zstd/compress.c | 120 ++++--- lib/zstd/fse_compress.c | 24 +- lib/zstd/huf_compress.c | 6 +- net/ipv6/ip6_fib.c | 12 +- net/sunrpc/sysctl.c | 6 +- tools/lib/subcmd/help.c | 10 +- tools/power/cpupower/utils/cpufreq-set.c | 14 +- tools/testing/selftests/vm/gup_benchmark.c | 18 +- tools/testing/selftests/vm/userfaultfd.c | 296 +++++++++++------- 46 files changed, 694 insertions(+), 382 deletions(-) -- 2.26.0

10 21

[PATCH v7 00/15] Add support for DP-HDMI2.1 PCON
by Ankit Nautiyal 02 Feb '21

02 Feb '21

This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid… The details are mentioned in: VESA DP-to-HDMI PCON Specification Standalone Document https://groups.vesa.org/wg/DP/document/15651 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Addressed review comments and re-organized patches as suggested in comments on RFC patches. v3: Addressed review comments on previous version. v4: Added support for RGB->YCBCR conversion through PCON v5: Addressed review comments on previous version. v6: Fix typo in one of the patch. v7: Rebased on latest drm-tip and addressed the review comments. Ankit Nautiyal (11): drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding drm/i915/display: Let PCON convert from RGB to YCbCr if it can Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link failure detection drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 566 ++++++++++++++++++ drivers/gpu/drm/drm_edid.c | 103 ++++ drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- .../drm/i915/display/intel_display_types.h | 10 + drivers/gpu/drm/i915/display/intel_dp.c | 442 +++++++++++++- drivers/gpu/drm/i915/display/intel_dp.h | 7 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 233 +++++++ drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 49 ++ include/drm/drm_dp_helper.h | 218 +++++++ include/drm/drm_edid.h | 30 + 11 files changed, 1652 insertions(+), 19 deletions(-) -- 2.17.1

5 23

[PATCH v2, 0/3] support gce on mt8192 platform
by Yongqiang Niu 31 Jan '21

31 Jan '21

Change since v1: - move out shit jump patch - rmove usless patch Yongqiang Niu (3): dt-binding: gce: add gce header file for mt8192 arm64: dts: mt8192: add gce node mailbox: cmdq: add mt8192 support .../devicetree/bindings/mailbox/mtk-gce.txt | 7 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c | 1 + include/dt-bindings/gce/mt8192-gce.h | 419 +++++++++++++++++++++ 4 files changed, 434 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h -- 1.8.1.1.dirty

4 7

[PATCH] soc: mediatek: cmdq: Remove cmdq_pkt_flush()
by Chun-Kuang Hu 31 Jan '21

31 Jan '21

rx_callback is a standard mailbox callback mechanism and could cover the function of proprietary cmdq_task_cb, so it is better to use the standard one instead of the proprietary one. But register rx_callback should before mbox_request_channel(), so remove cmdq_pkt_flush() and let client driver implement its own synchronous flush. Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> --- drivers/soc/mediatek/mtk-cmdq-helper.c | 32 -------------------------- include/linux/soc/mediatek/mtk-cmdq.h | 12 ---------- 2 files changed, 44 deletions(-) diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c index 505651b0d715..fd3bc39538a1 100644 --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -502,36 +502,4 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb, } EXPORT_SYMBOL(cmdq_pkt_flush_async); -struct cmdq_flush_completion { - struct completion cmplt; - bool err; -}; - -static void cmdq_pkt_flush_cb(struct cmdq_cb_data data) -{ - struct cmdq_flush_completion *cmplt; - - cmplt = (struct cmdq_flush_completion *)data.data; - if (data.sta != CMDQ_CB_NORMAL) - cmplt->err = true; - else - cmplt->err = false; - complete(&cmplt->cmplt); -} - -int cmdq_pkt_flush(struct cmdq_pkt *pkt) -{ - struct cmdq_flush_completion cmplt; - int err; - - init_completion(&cmplt.cmplt); - err = cmdq_pkt_flush_async(pkt, cmdq_pkt_flush_cb, &cmplt); - if (err < 0) - return err; - wait_for_completion(&cmplt.cmplt); - - return cmplt.err ? -EFAULT : 0; -} -EXPORT_SYMBOL(cmdq_pkt_flush); - MODULE_LICENSE("GPL v2"); diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h index 960704d75994..2c6aa84c0e80 100644 --- a/include/linux/soc/mediatek/mtk-cmdq.h +++ b/include/linux/soc/mediatek/mtk-cmdq.h @@ -288,16 +288,4 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt); int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb, void *data); -/** - * cmdq_pkt_flush() - trigger CMDQ to execute the CMDQ packet - * @pkt: the CMDQ packet - * - * Return: 0 for success; else the error code is returned - * - * Trigger CMDQ to execute the CMDQ packet. Note that this is a - * synchronous flush function. When the function returned, the recorded - * commands have been done. - */ -int cmdq_pkt_flush(struct cmdq_pkt *pkt); - #endif /* __MTK_CMDQ_H__ */ -- 2.17.1

2 3

← Newer
1
...
8
9
10
11
12
13
14
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2020