dri-devel November 2020

dri-devel@lists.freedesktop.org

316 participants
811 discussions

[PATCH 0/3] drm/v3d: CL/CSD job timeout fixes
by Yukimasa Sugizaki 11 Feb '21

11 Feb '21

From: Yukimasa Sugizaki <ysugi(a)idein.jp> Hi, The current V3D scheduler has two issues where CSD jobs are resubmitted regardless of the previous timed-out flag, and where the timer is not restarted for timed-out CL/CSD jobs (which we wish to continue running). The second one is due to the DRM scheduler API change and fixed in a similar way to [1]. A kernel command-line option to set the default timeout value is also added. I tested this patchset with Piglit and our CSD programs in [2]… [View More]

3 9

[RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
by Thomas Zimmermann 10 Feb '21

10 Feb '21

This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the … [View More]kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. One cosmetical issue is that simplekms's device file is card0 and the native driver's device file is card1. After simplekms has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover * provide bootsplash DRM client * make simplekms usable with ARM-EFI fbs Thomas Zimmermann (9): drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() drm/format-helper: Add blitter functions drm: Add simplekms driver drm/simplekms: Add fbdev emulation drm/simplekms: Initialize framebuffer data from device-tree node drm/simplekms: Acquire clocks from DT device node drm/simplekms: Acquire regulators from DT device node drm: Add infrastructure for platform devices drm/simplekms: Acquire memory aperture for framebuffer MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 6 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_format_helper.c | 96 ++- drivers/gpu/drm/drm_platform.c | 118 ++++ drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/tiny/Kconfig | 17 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/tiny/simplekms.c | 906 +++++++++++++++++++++++++ include/drm/drm_fb_helper.h | 18 +- include/drm/drm_format_helper.h | 10 +- include/drm/drm_platform.h | 42 ++ 13 files changed, 1217 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/drm_platform.c create mode 100644 drivers/gpu/drm/tiny/simplekms.c create mode 100644 include/drm/drm_platform.h -- 2.27.0 [View Less]

10 54

[Bug 204241] New: amdgpu fails to resume from suspend
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=204241 Bug ID: 204241 Summary: amdgpu fails to resume from suspend Product: Drivers Version: 2.5 Kernel Version: 5.2.1-arch1-1-ARCH Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org … [View More]

1 77

[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(… [View More]

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: … [View More]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 > [View Less]

3 2

[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.… [View More]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 [View Less]

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.… [View More]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 [View Less]

7 31

[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 … [View More]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 [View Less]

10 21

[PATCH] drm/lima: fix reference leak in lima_pm_busy
by Qinglang Miao 30 Jan '21

30 Jan '21

pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. A new function pm_runtime_resume_and_get is introduced in [0] to keep usage counter balanced. So We fix the reference leak by replacing it with new funtion. [0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Fixes: 50de2e9ebbc0 ("drm/lima: enable runtime pm") Reported-by: Hulk Robot <hulkci(a)huawei.com> … [View More]

2 1

[PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
by John Stultz 29 Jan '21

29 Jan '21

Hey All, So this is another revision of my patch series to performance optimizations to the dma-buf system heap. Unfortunately, in working these up, I realized the heap-helpers infrastructure we tried to add to miniimize code duplication is not as generic as we intended. For some heaps it makes sense to deal with page lists, for other heaps it makes more sense to track things with sgtables. So this series reworks the system heap to use sgtables, and then consolidates the pagelist method … [View More]from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. After this, the series introduces an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Next, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION code. Unfortunately, after submitting the last round, I realized that part of the reason the page-pooling patch I had included was providing such great performance numbers, was because the network page-pool implementation doesn't zero pages that it pulls from the cache. This is very inappropriate for buffers we pass to userland and was what gave it an unfair advantage (almost constant time performance) relative to ION's allocation performance numbers. I added some patches to zero the buffers manually similar to how ION does it, but I found this resulted in basically no performance improvement from the standard page allocator. Thus I've dropped that patch in this series for now. Unfortunately this means we still have a performance delta from the ION system heap as measured by my microbenchmark, and this delta comes from ION system_heap's use of deferred freeing of pages. So less work is done in the measured interval of the microbenchmark. I'll be looking at adding similar code eventually but I don't want to hold the rest of the patches up on this, as it is still a good improvement over the current code. I've updated the chart I shared earlier with current numbers (including with the unsubmitted net pagepool implementation, and with a different unsubmitted pagepool implementation borrowed from ION) here: https://docs.google.com/spreadsheets/d/1-1C8ZQpmkl_0DISkI6z4xelE08MlNAN7oEu… I did add to this series a reworked version of my uncached system heap implementation I was submitting a few weeks back. Since it duplicated a lot of the now reworked system heap code, I realized it would be much simpler to add the functionality to the system_heap implementaiton itself. While not improving the core allocation performance, the uncached heap allocations do result in *much* improved performance on HiKey960 as it avoids a lot of flushing and invalidating buffers that the cpu doesn't touch often. Feedback on these would be great! thanks -john New in v3: * Dropped page-pool patches as after correcting the code to zero buffers, they provided no net performance gain. * Added system-uncached implementation ontop of reworked system-heap. * Use the new sgtable mapping functions, in the system and cma code as Suggested-by: Daniel Mentz <danielmentz(a)google.com> * Cleanup: Use page_size() rather then open-coding it Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(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: Chris Goldsworthy <cgoldswo(a)codeaurora.org> 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 John Stultz (7): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 +- drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 327 +++++++++++++++--- drivers/dma-buf/heaps/heap-helpers.c | 271 --------------- drivers/dma-buf/heaps/heap-helpers.h | 53 --- drivers/dma-buf/heaps/system_heap.c | 480 ++++++++++++++++++++++++--- include/linux/dma-heap.h | 9 + 7 files changed, 741 insertions(+), 433 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1 [View Less]

3 13

← Newer
1
...
6
7
8
9
10
11
12
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2020