dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[Bug 51381] New: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
by bugzilla-daemon＠bugzilla.kernel.org 11 May '21

11 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=51381 Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo Product: Drivers Version: 2.5 Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4 08:04:10 CET 2012 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: a(a)anrd.net Regression: Yes Created an attachment (id=88591) --> (https://bugzilla.kernel.org/attachment.cgi?id=88591) journald log After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD 5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card at boot. On resume the computer almost hangs (I can press power button and wait 5 minutes for a proper shutdown, but no other interaction is possible). It logs a lot of messages saying: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72, WS 0, PS 0) @ 0xD0C7 Steps to reproduce: echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch [suspend and resume] Actual results: Almost freeze. Expected results: Resume and work as normal. Log is attached, but if you need anything else just ask. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 62

[Bug 207833] New: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti)
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=207833 Bug ID: 207833 Summary: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti) Product: Drivers Version: 2.5 Kernel Version: 5.6.12-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: julen.pardo(a)outlook.es Regression: No Hello, I've just bought an ASUS TUF FA506IU with and AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti setup. Even if this is quite new hardware, I'd say that the only thing that is not working at all is the brightness control. It's not working with the function keys, nor from the energy settings, nor with xbacklight. Actually, it's working a little; I can find a subtle difference between the max value and the last 5 values, but that's it. Setting it to the minimum still makes it way too bright. I've noticed that this could be a range mismatch between "brightness" and "max_brightness", and "actual_brightness". First are in 8 bit ranges, whereas the actual brightness is in 16 bit range. I've tried some luck patching the kernel to return an 8-bit value (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/d…), but doing just that doesn't work (even if the "actual_brightness" was showing an 8 bit value). In my case, the full path is "/sys/class/backlight/amdgpu_bl1/". I've also tried different acpi_backlight parameters with no luck. I leave the output of lsmod | grep asus: asus_wmi 40960 0 sparse_keymap 16384 1 asus_wmi rfkill 28672 9 asus_wmi,bluetooth,cfg80211 battery 24576 1 asus_wmi wmi 36864 2 asus_wmi,wmi_bmof asus_wireless 20480 0 inxi -F: System: Host: TUF-FA506IU Kernel: 5.6.12-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.18.5 Distro: Manjaro Linux Machine: Type: Laptop System: ASUSTeK product: TUF Gaming FA506IU_FA506IU v: 1.0 serial: <root required> Mobo: ASUSTeK model: FA506IU v: 1.0 serial: <root required> UEFI: American Megatrends v: FA506IU.302 date: 03/04/2020 Battery: ID-1: BAT1 charge: 47.9 Wh condition: 47.9/48.1 Wh (100%) CPU: Topology: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP L2 cache: 4096 KiB Speed: 2405 MHz min/max: 1400/2900 MHz Core speeds (MHz): 1: 1875 2: 2497 3: 1397 4: 1397 5: 1397 6: 1397 7: 1397 8: 1397 9: 1397 10: 1396 11: 2963 12: 1673 13: 1800 14: 1548 15: 1397 16: 1396 Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.82 Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.8 driver: amdgpu,nvidia resolution: 1920x1080~144Hz, 2560x1440~60Hz OpenGL: renderer: AMD RENOIR (DRM 3.36.0 5.6.12-1-MANJARO LLVM 10.0.0) v: 4.6 Mesa 20.0.6 Audio: Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel Device-3: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A Device-4: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server: ALSA v: k5.6.12-1-MANJARO Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0 state: down mac: a8:5e:45:36:94:32 Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_pci IF: wlp3s0 state: up mac: 70:66:55:09:8c:e3 Drives: Local Storage: total: 476.94 GiB used: 32.41 GiB (6.8%) ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AB size: 476.94 GiB Partition: ID-1: / size: 48.97 GiB used: 25.95 GiB (53.0%) fs: ext4 dev: /dev/nvme0n1p5 ID-2: /home size: 108.67 GiB used: 6.46 GiB (5.9%) fs: ext4 dev: /dev/nvme0n1p7 ID-3: swap-1 size: 3.03 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 349 Uptime: 27m Memory: 7.20 GiB used: 3.04 GiB (42.2%) Shell: zsh inxi: 3.0.37 -- You are receiving this mail because: You are watching the assignee of the bug.

1 6

[Bug 203905] New: amdgpu:actual_brightness has unreal/wrong value
by bugzilla-daemon＠bugzilla.kernel.org 06 May '21

06 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=203905 Bug ID: 203905 Summary: amdgpu:actual_brightness has unreal/wrong value Product: Drivers Version: 2.5 Kernel Version: 5.1.9 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: bjo(a)nord-west.org Regression: No Radeon R5/R6/R7 Graphics in a Thinkpad A275 has wrong values on actual_brightness of amdgpu_bl0. While max_brightness is 255 and it can be set to 255, actual_brightness reports a 5 digit number like 12470. As a result, tools which want to change the brightness related to actual_brightness fail, as brightness does not accept any 5 digit number, -- You are receiving this mail because: You are watching the assignee of the bug.

1 33

[PATCH 1/2] mm: cma: export functions to get CMA base and size
by Lucas Stach 03 May '21

03 May '21

Make them usable in modules. Some drivers want to know where their device CMA area is located to make better decisions about the DMA programming. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- mm/cma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/cma.c b/mm/cma.c index 3340ef34c154..191c89bf038d 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -44,11 +44,13 @@ phys_addr_t cma_get_base(const struct cma *cma) { return PFN_PHYS(cma->base_pfn); } +EXPORT_SYMBOL_GPL(cma_get_base); unsigned long cma_get_size(const struct cma *cma) { return cma->count << PAGE_SHIFT; } +EXPORT_SYMBOL_GPL(cma_get_size); const char *cma_get_name(const struct cma *cma) { -- 2.20.1

2 2

[PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
by Shengjiu Wang 22 Apr '21

22 Apr '21

There are two requirements that we need to move the request of dma channel from probe to open. - When dma device binds with power-domains, the power will be enabled when we request dma channel. If the request of dma channel happen on probe, then the power-domains will be always enabled after kernel boot up, which is not good for power saving, so we need to move the request of dma channel to .open(); - With FE-BE case, if the dma channel is requested in probe, then there will be below issue, which is caused by that the dma channel will be requested duplicately [ 638.906268] sysfs: cannot create duplicate filename '/devices/soc0/soc/2000000.bus/2000000.spba-bus/2024000.esai/dma:tx' [ 638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted 5.7.0-rc1-12956-gfc64b2585593 #287 [ 638.927113] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 638.933690] [<c0110dd8>] (unwind_backtrace) from [<c010b8ec>] (show_stack+0x10/0x14) [ 638.941464] [<c010b8ec>] (show_stack) from [<c0557fc0>] (dump_stack+0xe4/0x118) [ 638.948808] [<c0557fc0>] (dump_stack) from [<c032aeb4>] (sysfs_warn_dup+0x50/0x64) [ 638.956406] [<c032aeb4>] (sysfs_warn_dup) from [<c032b1a8>] (sysfs_do_create_link_sd+0xc8/0xd4) [ 638.965134] [<c032b1a8>] (sysfs_do_create_link_sd) from [<c05dc668>] (dma_request_chan+0xb0/0x210) [ 638.974120] [<c05dc668>] (dma_request_chan) from [<c05dc7d0>] (dma_request_slave_channel+0x8/0x14) [ 638.983111] [<c05dc7d0>] (dma_request_slave_channel) from [<c09d5548>] (fsl_asrc_dma_hw_params+0x1e0/0x438) [ 638.992881] [<c09d5548>] (fsl_asrc_dma_hw_params) from [<c09c1654>] (soc_pcm_hw_params+0x4a0/0x6a8) [ 639.001952] [<c09c1654>] (soc_pcm_hw_params) from [<c09c39d4>] (dpcm_fe_dai_hw_params+0x70/0xe4) [ 639.010765] [<c09c39d4>] (dpcm_fe_dai_hw_params) from [<c099b274>] (snd_pcm_hw_params+0x158/0x418) [ 639.019750] [<c099b274>] (snd_pcm_hw_params) from [<c099c5a0>] (snd_pcm_ioctl+0x734/0x183c) [ 639.028129] [<c099c5a0>] (snd_pcm_ioctl) from [<c029ff94>] (ksys_ioctl+0x2ac/0xb98) [ 639.035812] [<c029ff94>] (ksys_ioctl) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [ 639.043490] Exception stack(0xec529fa8 to 0xec529ff0) [ 639.048565] 9fa0: bee84650 01321870 00000004 c25c4111 bee84650 0002000f [ 639.056766] 9fc0: bee84650 01321870 01321820 00000036 00001f40 00000000 0002c2f8 00000003 [ 639.064964] 9fe0: b6f483fc bee8451c b6ee2655 b6e1dcf8 [ 639.070339] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/imx-pcm-dma.c | 173 +++++++++++++++++++++++++++++++++--- 1 file changed, 159 insertions(+), 14 deletions(-) diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c index 04a9bc749016..dae53b384df4 100644 --- a/sound/soc/fsl/imx-pcm-dma.c +++ b/sound/soc/fsl/imx-pcm-dma.c @@ -11,6 +11,7 @@ #include <linux/dmaengine.h> #include <linux/types.h> #include <linux/module.h> +#include <linux/dma-mapping.h> #include <sound/core.h> #include <sound/pcm.h> @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void *param) return true; } -static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = { - .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config, - .compat_filter_fn = filter, -}; +static int imx_pcm_hw_params(struct snd_soc_component *component, + struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0); + struct snd_dmaengine_dai_dma_data *dma_data; + struct dma_slave_config config; + struct dma_chan *chan; + int ret = 0; -int imx_pcm_dma_init(struct platform_device *pdev, size_t size) + snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer); + runtime->dma_bytes = params_buffer_bytes(params); + + chan = snd_dmaengine_pcm_get_chan(substream); + if (!chan) + return -EINVAL; + + ret = snd_hwparams_to_dma_slave_config(substream, params, &config); + if (ret) + return ret; + + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); + if (!dma_data) + return -EINVAL; + + snd_dmaengine_pcm_set_config_from_dai_data(substream, + dma_data, + &config); + return dmaengine_slave_config(chan, &config); +} + +static int imx_pcm_hw_free(struct snd_soc_component *component, + struct snd_pcm_substream *substream) { - struct snd_dmaengine_pcm_config *config; + snd_pcm_set_runtime_buffer(substream, NULL); + return 0; +} + +static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + return snd_dmaengine_pcm_pointer(substream); +} + +static int imx_pcm_trigger(struct snd_soc_component *component, + struct snd_pcm_substream *substream, int cmd) +{ + return snd_dmaengine_pcm_trigger(substream, cmd); +} + +static int imx_pcm_open(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0); + struct snd_dmaengine_dai_dma_data *dma_data; + struct device *dev = component->dev; + struct snd_pcm_hardware hw; + struct dma_chan *chan; + int ret; + + ret = snd_pcm_hw_constraint_integer(substream->runtime, + SNDRV_PCM_HW_PARAM_PERIODS); + if (ret < 0) { + dev_err(dev, "failed to set pcm hw params periods\n"); + return ret; + } + + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); + if (!dma_data) + return -EINVAL; + + chan = dma_request_slave_channel(cpu_dai->dev, tx ? "tx" : "rx"); + if (!chan) { + /* Try to request channel using compat_filter_fn */ + chan = snd_dmaengine_pcm_request_channel(filter, + dma_data->filter_data); + if (!chan) + return -ENXIO; + } - config = devm_kzalloc(&pdev->dev, - sizeof(struct snd_dmaengine_pcm_config), GFP_KERNEL); - if (!config) - return -ENOMEM; - *config = imx_dmaengine_pcm_config; + ret = snd_dmaengine_pcm_open(substream, chan); + if (ret) + goto pcm_open_fail; - return devm_snd_dmaengine_pcm_register(&pdev->dev, - config, - SND_DMAENGINE_PCM_FLAG_COMPAT); + memset(&hw, 0, sizeof(hw)); + hw.info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | + SNDRV_PCM_INFO_INTERLEAVED; + hw.periods_min = 2; + hw.periods_max = UINT_MAX; + hw.period_bytes_min = 256; + hw.period_bytes_max = dma_get_max_seg_size(chan->device->dev); + hw.buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE; + hw.fifo_size = dma_data->fifo_size; + + /* Refine the hw according to caps of DMA. */ + ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream, + dma_data, + &hw, + chan); + if (ret < 0) + goto refine_runtime_hwparams_fail; + + snd_soc_set_runtime_hwparams(substream, &hw); + + /* Support allocate memory from IRAM */ + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_IRAM, + chan->device->dev, + hw.buffer_bytes_max, + &substream->dma_buffer); + if (ret < 0) + goto alloc_pagas_fail; + + return 0; + +alloc_pagas_fail: +refine_runtime_hwparams_fail: + snd_dmaengine_pcm_close(substream); +pcm_open_fail: + dma_release_channel(chan); + + return ret; +} + +static int imx_pcm_close(struct snd_soc_component *component, + struct snd_pcm_substream *substream) +{ + if (substream) { + snd_dma_free_pages(&substream->dma_buffer); + substream->dma_buffer.area = NULL; + substream->dma_buffer.addr = 0; + } + + return snd_dmaengine_pcm_close_release_chan(substream); +} + +static int imx_pcm_new(struct snd_soc_component *component, + struct snd_soc_pcm_runtime *rtd) +{ + struct snd_card *card = rtd->card->snd_card; + + return dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32)); +} + +static const struct snd_soc_component_driver imx_pcm_component = { + .name = "imx-pcm-dma", + .pcm_construct = imx_pcm_new, + .open = imx_pcm_open, + .close = imx_pcm_close, + .hw_params = imx_pcm_hw_params, + .hw_free = imx_pcm_hw_free, + .trigger = imx_pcm_trigger, + .pointer = imx_pcm_pointer, +}; + +int imx_pcm_dma_init(struct platform_device *pdev, size_t size) +{ + return devm_snd_soc_register_component(&pdev->dev, + &imx_pcm_component, NULL, 0); } EXPORT_SYMBOL_GPL(imx_pcm_dma_init); -- 2.21.0

5 17

KASAN: use-after-free Read in bit_putcs
by syzbot 12 Apr '21

12 Apr '21

Hello, syzbot found the following crash on: HEAD commit: 0a44cac8 Merge tag 'dma-mapping-5.6' of git://git.infradea.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11bfb74ee00000 kernel config: https://syzkaller.appspot.com/x/.config?x=a61f2164c515c07f dashboard link: https://syzkaller.appspot.com/bug?extid=b308f5fd049fbbc6e74f compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b308f5fd049fbbc6e74f(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: use-after-free in __fb_pad_aligned_buffer include/linux/fb.h:655 [inline] BUG: KASAN: use-after-free in bit_putcs_aligned drivers/video/fbdev/core/bitblit.c:96 [inline] BUG: KASAN: use-after-free in bit_putcs+0x13ee/0x1cc0 drivers/video/fbdev/core/bitblit.c:185 Read of size 1 at addr ffff8880a8087c10 by task syz-executor.2/5278 CPU: 1 PID: 5278 Comm: syz-executor.2 Not tainted 5.6.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 __fb_pad_aligned_buffer include/linux/fb.h:655 [inline] bit_putcs_aligned drivers/video/fbdev/core/bitblit.c:96 [inline] bit_putcs+0x13ee/0x1cc0 drivers/video/fbdev/core/bitblit.c:185 fbcon_putcs+0x7b4/0xad0 drivers/video/fbdev/core/fbcon.c:1360 do_update_region+0x462/0x600 drivers/tty/vt/vt.c:677 redraw_screen+0xcc5/0x1830 drivers/tty/vt/vt.c:1011 vc_do_resize+0x12af/0x1af0 drivers/tty/vt/vt.c:1284 vc_resize+0x4f/0x60 drivers/tty/vt/vt.c:1304 vt_ioctl+0x2fa8/0x3a70 drivers/tty/vt/vt_ioctl.c:887 tty_ioctl+0xee6/0x15c0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl fs/ioctl.c:763 [inline] __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770 __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45c449 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f74261f2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f74261f36d4 RCX: 000000000045c449 RDX: 0000000020000080 RSI: 000000000000560a RDI: 0000000000000003 RBP: 000000000076bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000066b R14: 00000000004c8fe0 R15: 000000000076bf2c Allocated by task 2919: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 __do_kmalloc_node mm/slab.c:3616 [inline] __kmalloc_node_track_caller+0x4d/0x60 mm/slab.c:3630 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0xe8/0x500 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1051 [inline] _sctp_make_chunk+0x60/0x460 net/sctp/sm_make_chunk.c:1394 sctp_make_data net/sctp/sm_make_chunk.c:1426 [inline] sctp_make_datafrag_empty+0xa3/0x5b0 net/sctp/sm_make_chunk.c:740 sctp_datamsg_from_user+0x7a8/0x1020 net/sctp/chunk.c:262 sctp_sendmsg_to_asoc+0x7a9/0x1500 net/sctp/socket.c:1844 sctp_sendmsg+0x15a1/0x3570 net/sctp/socket.c:2016 inet_sendmsg+0x147/0x310 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x4f7/0x7f0 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmsg+0x1ed/0x290 net/socket.c:2430 __do_sys_sendmsg net/socket.c:2439 [inline] __se_sys_sendmsg net/socket.c:2437 [inline] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2437 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2919: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 skb_free_head net/core/skbuff.c:592 [inline] skb_release_data+0x72f/0x8c0 net/core/skbuff.c:612 skb_release_all net/core/skbuff.c:666 [inline] __kfree_skb+0x59/0x1c0 net/core/skbuff.c:680 consume_skb+0x72/0x110 net/core/skbuff.c:839 sctp_chunk_destroy net/sctp/sm_make_chunk.c:1454 [inline] sctp_chunk_put+0x17b/0x200 net/sctp/sm_make_chunk.c:1481 sctp_chunk_free+0x59/0x60 net/sctp/sm_make_chunk.c:1468 sctp_outq_sack+0x1169/0x16a0 net/sctp/outqueue.c:1352 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:798 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1354 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1185 [inline] sctp_do_sm+0x18f3/0x5840 net/sctp/sm_sideeffect.c:1156 sctp_assoc_bh_rcv+0x494/0x770 net/sctp/associola.c:1044 sctp_inq_push+0x1ab/0x1d0 net/sctp/inqueue.c:80 sctp_backlog_rcv+0x16c/0x4b0 net/sctp/input.c:344 sk_backlog_rcv include/net/sock.h:938 [inline] __release_sock+0x1c1/0x4b0 net/core/sock.c:2437 release_sock+0x65/0x1c0 net/core/sock.c:2953 sctp_wait_for_connect+0x2f6/0x590 net/sctp/socket.c:9280 sctp_sendmsg_to_asoc+0x11ba/0x1500 net/sctp/socket.c:1870 sctp_sendmsg+0x15a1/0x3570 net/sctp/socket.c:2016 inet_sendmsg+0x147/0x310 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x4f7/0x7f0 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmsg+0x1ed/0x290 net/socket.c:2430 __do_sys_sendmsg net/socket.c:2439 [inline] __se_sys_sendmsg net/socket.c:2437 [inline] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2437 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a8087c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 16 bytes inside of 512-byte region [ffff8880a8087c00, ffff8880a8087e00) The buggy address belongs to the page: page:ffffea0002a021c0 refcount:1 mapcount:0 mapping:ffff8880aa400a80 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002431688 ffffea000259d648 ffff8880aa400a80 raw: 0000000000000000 ffff8880a8087000 0000000100000004 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a8087b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880a8087b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880a8087c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880a8087c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a8087d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

8 17

[Bug 200695] New: Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
by bugzilla-daemon＠bugzilla.kernel.org 06 Apr '21

06 Apr '21

https://bugzilla.kernel.org/show_bug.cgi?id=200695 Bug ID: 200695 Summary: Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected) Product: Drivers Version: 2.5 Kernel Version: 4.18.0-rc7 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: claude(a)mathr.co.uk Regression: No Created attachment 277633 --> https://bugzilla.kernel.org/attachment.cgi?id=277633&action=edit dmesg after boot with amdgpu.dc=1 amdgpu.dc_log=1 drm.debug=6 When amdgpu.dc=1 is initialized at boot, the console goes blank as it thinks all displays are disconnected. Xorg is not able to enable the display either. With amdgpu.dc=0 all is fine. Tried with various (mostly Debian) kernels from 4.16 through 4.18~rc4, all have the issue. I built a 4.18~rc7 from kernel.org to rule out Debian patches being the issue and will provide logs. -- You are receiving this mail because: You are watching the assignee of the bug.

1 50

[PATCH] RFC: dma-buf: Add an API for importing and exporting sync files
by Jason Ekstrand 23 Mar '21

23 Mar '21

Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on. This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times. There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages. The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> --- This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-) --Jason drivers/dma-buf/dma-buf.c | 115 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 +++- 2 files changed, 126 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..3845b87e209e 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,114 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; } +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + dma_resv_add_excl_fence(dmabuf->resv, fence); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + return 0; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + struct dma_fence **fences = NULL; + unsigned i, num_fences = 0; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + goto err_put_fd; + + if (num_fences == 0) { + fence = dma_fence_get_stub(); + } else if (num_fences == 1) { + fence = fences[0]; + kfree(fences); + } else { + struct dma_fence_array *fence_arr; + + fence_arr = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!fence_arr) { + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[i]); + kfree(fences); + ret = -ENOMEM; + goto err_put_fd; + } + + /* The fence array now owns fences_arr and our + * references to each of the individual fences. We + * only own a reference to the one array fence. + */ + fence = &fence_arr->base; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +499,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg); + case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..825b9a913c89 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync { #define DMA_BUF_NAME_LEN 32 +struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_sync) #endif -- 2.24.1

9 52

[PATCH] RFC: i915: Drop relocation support on Gen12+
by Jason Ekstrand 12 Mar '21

12 Mar '21

The Vulkan driver in Mesa for Intel hardware never uses relocations if it's running on a version of i915 that supports at least softpin which all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is only supported by iris which never uses relocations. The older i965 driver in Mesa does use relocations but it only supports Intel hardware through Gen11 and has been deprecated for all hardware Gen9+. The entire relocation UAPI and related infrastructure, therefore, doesn't have any open-source userspace consumer starting with Gen12. Rejecting relocations starting with Gen12 has the benefit that we don't have to bother supporting it on platforms with local memory. Given how much CPU touching of memory is required for relocations, not having to do so on platforms where not all memory is directly CPU-accessible carries significant advantages. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 4f9c1f5a4dedb..e10c93aff945d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct i915_vma *vma) return err; } -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) +static int check_relocations(const struct i915_execbuffer *eb, + const struct drm_i915_gem_exec_object2 *entry) { const char __user *addr, *end; unsigned long size; @@ -1543,6 +1544,9 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) if (size == 0) return 0; + if (size && eb->reloc_cache.gen >= 12) + return -EINVAL; + if (size > N_RELOC(ULONG_MAX)) return -EINVAL; @@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb) if (nreloc == 0) continue; - err = check_relocations(&eb->exec[i]); + err = check_relocations(eb, &eb->exec[i]); if (err) goto err; -- 2.26.2

9 23

[PATCH v5 0/7] drm: add simpledrm driver
by David Herrmann 12 Mar '21

12 Mar '21

Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, please let me know. Thanks David David Herrmann (7): x86/sysfb: add support for 64bit EFI lfb_base x86/sysfb: fix lfb_size calculation of/platform: expose of_platform_device_destroy() video: add generic framebuffer eviction drm: switch to sysfb_evict_conflicts() drm: add SimpleDRM driver drm/simpledrm: add fbdev fallback support MAINTAINERS | 6 + arch/x86/kernel/sysfb_simplefb.c | 39 ++- drivers/gpu/drm/Kconfig | 3 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- drivers/gpu/drm/bochs/bochs_drv.c | 19 +- drivers/gpu/drm/i915/i915_drv.c | 73 +--- drivers/gpu/drm/mgag200/mgag200_drv.c | 27 +- drivers/gpu/drm/mgag200/mgag200_main.c | 9 - drivers/gpu/drm/nouveau/nouveau_drm.c | 33 +- drivers/gpu/drm/radeon/radeon_drv.c | 24 +- drivers/gpu/drm/simpledrm/Kconfig | 19 ++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 91 +++++ drivers/gpu/drm/simpledrm/simpledrm_damage.c | 194 +++++++++++ drivers/gpu/drm/simpledrm/simpledrm_drv.c | 477 +++++++++++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 143 ++++++++ drivers/gpu/drm/simpledrm/simpledrm_gem.c | 109 ++++++ drivers/gpu/drm/simpledrm/simpledrm_kms.c | 270 +++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_of.c | 265 +++++++++++++++ drivers/gpu/drm/sun4i/sun4i_drv.c | 24 +- drivers/gpu/drm/vc4/vc4_drv.c | 25 +- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +- drivers/of/platform.c | 35 +- drivers/video/Kconfig | 4 + drivers/video/Makefile | 1 + drivers/video/sysfb.c | 327 ++++++++++++++++++ include/linux/of_platform.h | 1 + include/linux/sysfb.h | 34 ++ 29 files changed, 2054 insertions(+), 256 deletions(-) create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_of.c create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h -- 2.9.3

5 28

← Newer
1
2
3
4
5
6
7
...
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