dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH v3 1/2] dt-bindings: panel: Add Samsung S6E3FA2 panel
by Iskren Chernev 26 Jul '21

26 Jul '21

The Samsung S6E3FA2 AMOLED cmd LCD panel is used on the Samsung Galaxy S5 (klte). Signed-off-by: Iskren Chernev <iskren.chernev(a)gmail.com> --- Add a simple generated panel driver that supports on/off and the corresponding binding documentation. Changes in v3: - fix dt_binding_check issue with missing include - fix panel type (cmd) in kconfig description Changes in v2: - move bindings to separate file, add 2 regulators - add standalone panel driver v1: https://lkml.org/lkml/2020/12/30/293 v2: https://lkml.org/lkml/2021/2/1/313 .../display/panel/samsung,s6e3fa2.yaml | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.yaml diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.yaml new file mode 100644 index 000000000000..c751ad589480 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fa2.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6e3fa2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung s6e3fa2 AMOLED CMD LCD panel + +maintainers: + - Iskren Chernev <iskren.chernev(a)gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6e3fa2 + + reg: true + reset-gpios: true + port: true + + iovdd-supply: + description: IOVDD regulator + + vddr-supply: + description: VDDR regulator + +required: + - compatible + - reset-gpios + - iovdd-supply + - vddr-supply + - port + +unevaluatedProperties: false + +examples: + - | + /* from Samsung Galaxy S5 klte */ + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6e3fa2"; + reg = <0>; + + reset-gpios = <&pma8084_gpios 17 GPIO_ACTIVE_LOW>; + + iovdd-supply = <&pma8084_lvs4>; + vddr-supply = <&vreg_panel>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; + +... base-commit: fd821bf0ed9a7db09d2e007df697f4d9ecfda99a -- 2.30.0

3 5

[PATCH -next] drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker()
by Wei Yongjun 26 Jul '21

26 Jul '21

Add the missing unlock before return from function g2d_runqueue_worker() in the error handling case. Fixes: 445d3bed75de ("drm/exynos: use pm_runtime_resume_and_get()") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index cab4d2c370a7..0ed665501ac4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c @@ -897,13 +897,14 @@ static void g2d_runqueue_worker(struct work_struct *work) ret = pm_runtime_resume_and_get(g2d->dev); if (ret < 0) { dev_err(g2d->dev, "failed to enable G2D device.\n"); - return; + goto out; } g2d_dma_start(g2d, g2d->runqueue_node); } } +out: mutex_unlock(&g2d->runqueue_mutex); }

2 1

[PATCH v2 0/6] Support second Image Signal Processor on rk3399
by Heiko Stuebner 25 Jul '21

25 Jul '21

The rk3399 has two ISPs and right now only the first one is usable. The second ISP is connected to the TXRX dphy on the soc. The phy of ISP1 is only accessible through the DSI controller's io-memory, so this series adds support for simply using the dsi controller is a phy if needed. That solution is needed at least on rk3399 and rk3288 but no-one has looked at camera support on rk3288 at all, so right now only implement the rk3399 specifics. changes in v2: - enable grf-clock also for init callback to not break if for example hdmi is connected on boot and disabled the grf clock during its probe - add Sebastian's Tested-by - add Rob's Ack for the phy-cells property Heiko Stuebner (6): drm/rockchip: dsi: add own additional pclk handling dt-bindings: display: rockchip-dsi: add optional #phy-cells property drm/rockchip: dsi: add ability to work as a phy instead of full dsi arm64: dts: rockchip: add #phy-cells to mipi-dsi1 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 arm64: dts: rockchip: add isp1 node on rk3399 .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 349 ++++++++++++++++++ 4 files changed, 391 insertions(+) -- 2.29.2

4 11

[Bug 213053] New: WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD Radeon 6700XT
by bugzilla-daemon＠bugzilla.kernel.org 22 Jul '21

22 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=213053 Bug ID: 213053 Summary: WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD Radeon 6700XT Product: Drivers Version: 2.5 Kernel Version: 5.12.3 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: andrewd18(a)gmail.com Regression: No Created attachment 296743 --> https://bugzilla.kernel.org/attachment.cgi?id=296743&action=edit Full dmesg 2021-05-13 I recently managed to snag a Gigabyte "Eagle 12G" Radeon 6700 XT. I am running latest Debian Testing with a 5.12.3 kernel (config based off Debian defaults) and latest linux-firmware from git. Upon installing the card into my system and booting, it outputs the warning below into kern.log. The UI is 3D accellerated, there are no errors or warnings in Xorg.log, but there is some graphical corruption and tearing in some games or on KDE's panels that disappears when the object is repainted. Neither this WARNING nor the corruption occurs when when I plug in my previous video card, a Radeon Vega 64. Please let me know if I can provide more information or test something. [ 5.481569] ------------[ cut here ]------------ [ 5.481570] WARNING: CPU: 6 PID: 165 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c:959 dcn30_set_hubp_blank+0x214/0x220 [amdgpu] [ 5.481725] Modules linked in: hid_generic(E) usbhid(E) hid(E) sd_mod(E) t10_pi(E) amdgpu(E+) gpu_sched(E) drm_ttm_helper(E) ttm(E) drm_kms_helper(E) xhci_pci(E) ahci(E) cec(E) xhci_pci_renesas(E) mxm_wmi(E) crc32_pclmul(E) crc32c_intel(E) igb(E) libahci(E) xhci_hcd(E) i2c_piix4(E) dca(E) drm(E) libata(E) i2c_algo_bit(E) usbcore(E) scsi_mod(E) wmi(E) gpio_amdpt(E) gpio_generic(E) button(E) [ 5.481736] CPU: 6 PID: 165 Comm: systemd-udevd Tainted: G E 5.12.3 #69 [ 5.481738] Hardware name: System manufacturer System Product Name/PRIME X470-PRO, BIOS 5837 02/01/2021 [ 5.481739] RIP: 0010:dcn30_set_hubp_blank+0x214/0x220 [amdgpu] [ 5.481879] Code: 31 f6 48 8b 07 48 8b 40 50 e8 58 c5 ea ed 48 8b 9b d0 02 00 00 48 85 db 75 df eb 8c 0f 0b e9 46 ff ff ff 0f 0b e9 be fe ff ff <0f> 0b e9 42 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 41 57 41 56 45 [ 5.481880] RSP: 0018:ffffae8d8126b328 EFLAGS: 00010246 [ 5.481882] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000003 [ 5.481882] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ec790180000 [ 5.481883] RBP: ffff9ec791ee01e8 R08: ffffae8d8126b314 R09: ffffae8d8126b270 [ 5.481884] R10: 0000000000000002 R11: 343a656e696c2063 R12: ffff9ec791ee01e8 [ 5.481884] R13: ffff9ec792980000 R14: 0000000000000000 R15: ffff9ec791ee01e8 [ 5.481885] FS: 00007ff744baf8c0(0000) GS:ffff9eca9e980000(0000) knlGS:0000000000000000 [ 5.481886] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.481887] CR2: 00007ff744b9b50f CR3: 00000001100a2000 CR4: 00000000003506e0 [ 5.481888] Call Trace: [ 5.481890] dcn10_wait_for_mpcc_disconnect+0x116/0x190 [amdgpu] [ 5.482034] dcn20_plane_atomic_disable+0x3e/0x150 [amdgpu] [ 5.482178] dcn20_disable_plane+0x24/0x40 [amdgpu] [ 5.482320] dcn10_init_pipes+0x307/0x3f0 [amdgpu] [ 5.482460] dce110_enable_accelerated_mode+0x9c/0x260 [amdgpu] [ 5.482599] dc_commit_state+0x942/0xa40 [amdgpu] [ 5.482736] amdgpu_dm_atomic_commit_tail+0x585/0x2610 [amdgpu] [ 5.482878] ? kfree+0xc3/0x410 [ 5.482881] ? dcn30_validate_bandwidth+0x11f/0x270 [amdgpu] [ 5.483019] ? dcn30_validate_bandwidth+0x11f/0x270 [amdgpu] [ 5.483155] ? __bpf_trace_amdgpu_dm_plane_state_template+0x10/0x10 [amdgpu] [ 5.483295] ? dm_plane_helper_prepare_fb+0x1f1/0x250 [amdgpu] [ 5.483434] ? drm_atomic_helper_setup_commit+0x74d/0x810 [drm_kms_helper] [ 5.483446] commit_tail+0x94/0x130 [drm_kms_helper] [ 5.483457] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] [ 5.483467] drm_client_modeset_commit_atomic+0x1e4/0x220 [drm] [ 5.483488] drm_client_modeset_commit_locked+0x56/0x150 [drm] [ 5.483506] drm_client_modeset_commit+0x24/0x40 [drm] [ 5.483524] drm_fb_helper_set_par+0xa5/0xd0 [drm_kms_helper] [ 5.483533] fbcon_init+0x264/0x4f0 [ 5.483536] visual_init+0xce/0x130 [ 5.483539] do_bind_con_driver.isra.0+0x1db/0x2e0 [ 5.483541] do_take_over_console+0x116/0x180 [ 5.483542] do_fbcon_takeover+0x5c/0xc0 [ 5.483543] register_framebuffer+0x1e4/0x300 [ 5.483546] __drm_fb_helper_initial_config_and_unlock+0x321/0x4a0 [drm_kms_helper] [ 5.483556] amdgpu_fbdev_init+0xb9/0xf0 [amdgpu] [ 5.483664] amdgpu_device_init.cold+0x1625/0x1ad5 [amdgpu] [ 5.483805] ? pci_conf1_read+0xa4/0x100 [ 5.483807] ? pci_bus_read_config_word+0x49/0x70 [ 5.483810] amdgpu_driver_load_kms+0x64/0x260 [amdgpu] [ 5.483919] amdgpu_pci_probe+0x10a/0x190 [amdgpu] [ 5.484021] local_pci_probe+0x42/0x80 [ 5.484023] ? __cond_resched+0x16/0x40 [ 5.484025] pci_device_probe+0xfa/0x1b0 [ 5.484027] really_probe+0xf2/0x440 [ 5.484029] driver_probe_device+0xe1/0x150 [ 5.484031] device_driver_attach+0xa1/0xb0 [ 5.484032] __driver_attach+0x8a/0x150 [ 5.484034] ? device_driver_attach+0xb0/0xb0 [ 5.484035] ? device_driver_attach+0xb0/0xb0 [ 5.484037] bus_for_each_dev+0x78/0xc0 [ 5.484038] bus_add_driver+0x12b/0x1e0 [ 5.484040] driver_register+0x8b/0xe0 [ 5.484042] ? 0xffffffffc0f14000 [ 5.484043] do_one_initcall+0x44/0x1d0 [ 5.484045] ? do_init_module+0x23/0x260 [ 5.484047] ? kmem_cache_alloc_trace+0xfd/0x200 [ 5.484049] do_init_module+0x5c/0x260 [ 5.484050] __do_sys_finit_module+0xb1/0x110 [ 5.484052] do_syscall_64+0x33/0x80 [ 5.484054] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 5.484056] RIP: 0033:0x7ff7450689b9 [ 5.484057] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [ 5.484058] RSP: 002b:00007ffff1849268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 5.484059] RAX: ffffffffffffffda RBX: 000055a1d6cd79f0 RCX: 00007ff7450689b9 [ 5.484060] RDX: 0000000000000000 RSI: 00007ff7451f3e2d RDI: 0000000000000011 [ 5.484061] RBP: 0000000000020000 R08: 0000000000000000 R09: 000055a1d6cd4e40 [ 5.484061] R10: 0000000000000011 R11: 0000000000000246 R12: 00007ff7451f3e2d [ 5.484062] R13: 0000000000000000 R14: 000055a1d6cd7950 R15: 000055a1d6cd79f0 [ 5.484063] ---[ end trace d62e2afb8d38cfd0 ]--- -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 4

[v2 0/3] drm/msm/dsi: Add display DSI support for SC7280 target
by Rajeev Nandan 21 Jul '21

21 Jul '21

Changes in this series add support for MSM display DSI CTRL & PHY drivers for the SC7280 SoC, which has DSI controller v2.5.0 and DSI PHY v4.1. Changes in v2: - Dropped patch #1 (dt-bindings: msm/dsi: Add yaml schema for 7nm DSI PHY) and reused Jonathan's patch [1] (dt-bindings: msm: dsi: add missing 7nm bindings) - Added new patch (dt-bindings: msm/dsi: Add sc7280 7nm dsi phy) Now using <vendor>,<soc>-<block> format for "compatible" property (Rob) - Fixed clang warning for max_pll_rate as per [2] (Dmitry Baryshkov) - Fixed num_dsi_phy and io_start (Dmitry Baryshkov) [1] https://lore.kernel.org/linux-arm-msm/20210617144349.28448-2-jonathan@marek… [2] https://lore.kernel.org/linux-arm-msm/20210514213032.575161-1-arnd@kernel.o… Rajeev Nandan (3): dt-bindings: msm/dsi: Add sc7280 7nm dsi phy drm/msm/dsi: Add PHY configuration for SC7280 drm/msm/dsi: Add DSI support for SC7280 .../bindings/display/msm/dsi-phy-7nm.yaml | 1 + drivers/gpu/drm/msm/Kconfig | 6 ++--- drivers/gpu/drm/msm/dsi/dsi_cfg.c | 20 +++++++++++++++++ drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 26 ++++++++++++++++++++++ 7 files changed, 54 insertions(+), 3 deletions(-) -- 2.7.4

3 7

[PATCH] drm/ttm: remove special handling for non GEM drivers
by Christian König 21 Jul '21

21 Jul '21

vmwgfx is the only driver actually using this. Move the handling into the driver instead. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 11 ----------- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++++++++++ include/drm/ttm/ttm_bo_api.h | 19 ------------------- 3 files changed, 10 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 80831df0ef61..38183e227116 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -460,8 +460,6 @@ static void ttm_bo_release(struct kref *kref) atomic_dec(&ttm_glob.bo_count); dma_fence_put(bo->moving); - if (!ttm_bo_uses_embedded_gem_object(bo)) - dma_resv_fini(&bo->base._resv); bo->destroy(bo); } @@ -1056,15 +1054,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev, } else { bo->base.resv = &bo->base._resv; } - if (!ttm_bo_uses_embedded_gem_object(bo)) { - /* - * bo.base is not initialized, so we have to setup the - * struct elements we want use regardless. - */ - bo->base.size = size; - dma_resv_init(&bo->base._resv); - drm_vma_node_reset(&bo->base.vma_node); - } atomic_inc(&ttm_glob.bo_count); /* diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index 50e529a01677..587314d57991 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -460,6 +460,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo) WARN_ON(vmw_bo->dirty); WARN_ON(!RB_EMPTY_ROOT(&vmw_bo->res_tree)); vmw_bo_unmap(vmw_bo); + dma_resv_fini(&bo->base._resv); kfree(vmw_bo); } @@ -512,6 +513,11 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, unsigned long size, if (unlikely(ret)) goto error_free; + + bo->base.size = size; + dma_resv_init(&bo->base._resv); + drm_vma_node_reset(&bo->base.vma_node); + ret = ttm_bo_init_reserved(&dev_priv->bdev, bo, size, ttm_bo_type_device, placement, 0, &ctx, NULL, NULL, NULL); @@ -570,6 +576,10 @@ int vmw_bo_init(struct vmw_private *dev_priv, if (unlikely(ret)) return ret; + vmw_bo->base.base.size = size; + dma_resv_init(&vmw_bo->base.base._resv); + drm_vma_node_reset(&vmw_bo->base.base.vma_node); + ret = ttm_bo_init_reserved(bdev, &vmw_bo->base, size, ttm_bo_type_device, placement, 0, &ctx, NULL, NULL, bo_free); diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index 3587f660e8f4..e88da481a976 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -562,25 +562,6 @@ ssize_t ttm_bo_io(struct ttm_device *bdev, struct file *filp, int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, gfp_t gfp_flags); -/** - * ttm_bo_uses_embedded_gem_object - check if the given bo uses the - * embedded drm_gem_object. - * - * Most ttm drivers are using gem too, so the embedded - * ttm_buffer_object.base will be initialized by the driver (before - * calling ttm_bo_init). It is also possible to use ttm without gem - * though (vmwgfx does that). - * - * This helper will figure whenever a given ttm bo is a gem object too - * or not. - * - * @bo: The bo to check. - */ -static inline bool ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object *bo) -{ - return bo->base.dev != NULL; -} - /** * ttm_bo_pin - Pin the buffer object. * @bo: The buffer object to pin -- 2.25.1

5 7

[PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms
by Javier Martinez Canillas 21 Jul '21

21 Jul '21

The simplefb and simpledrm drivers match against a "simple-framebuffer" device, but for aarch64 this is only registered when using Device Trees and there's a node with a "simple-framebuffer" compatible string. There is no code to register a "simple-framebuffer" platform device when using EFI instead. In fact, the only platform device that's registered in this case is an "efi-framebuffer", which means that the efifb driver is the only driver supported to have an early console with EFI on aarch64. The x86 architecture platform has a Generic System Framebuffers (sysfb) support, that register a system frambuffer platform device. It either registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy VGA/EFI FB devices for the vgafb/efifb drivers. The sysfb is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory to drivers/firmware, allowing the EFI logic used by non-x86 architectures to be folded into sysfb as well. Patch #1 in this series do the former while patch #2 do the latter. It has been tested on x86_64 and aarch64 machines using the efifb, simplefb and simpledrm drivers. But more testing will be highly appreciated, to make sure that no regressions are being introduced by these changes. The series touches different subystems and will need coordination between maintainers but the patches have already been acked by the x86 folks. Ard Biesheuvel said that these could be merged through the EFI tree if needed. Best regards, Javier Changes in v3: - Add Borislav and Greg Acked-by tags. - Also update the SYSFB_SIMPLEFB symbol name in drivers/gpu/drm/tiny/Kconfig. - We have a a max 100 char limit now, use it to avoid multi-line statements. - Figure out the platform device name before allocating the platform device. Changes in v2: - Use default y and depends on X86 instead doing a select in arch/x86/Kconfig. - Also enable the SYSFB Kconfig option when COMPILE_TEST. - Improve commit message to explain why is useful for other arches to use this. - Use "depends on" for the supported architectures instead of selecting it. - Improve commit message to explain the benefits of reusing sysfb for !X86. Javier Martinez Canillas (2): drivers/firmware: move x86 Generic System Framebuffers support drivers/firmware: consolidate EFI framebuffer setup for all arches arch/arm/include/asm/efi.h | 5 +- arch/arm64/include/asm/efi.h | 5 +- arch/riscv/include/asm/efi.h | 5 +- arch/x86/Kconfig | 26 ------ arch/x86/kernel/Makefile | 3 - drivers/firmware/Kconfig | 32 +++++++ drivers/firmware/Makefile | 2 + drivers/firmware/efi/Makefile | 2 + drivers/firmware/efi/efi-init.c | 90 ------------------- .../firmware/efi}/sysfb_efi.c | 78 +++++++++++++++- {arch/x86/kernel => drivers/firmware}/sysfb.c | 37 +++++--- .../firmware}/sysfb_simplefb.c | 33 ++++--- drivers/gpu/drm/tiny/Kconfig | 4 +- .../x86/include/asm => include/linux}/sysfb.h | 32 +++---- 14 files changed, 180 insertions(+), 174 deletions(-) rename {arch/x86/kernel => drivers/firmware/efi}/sysfb_efi.c (84%) rename {arch/x86/kernel => drivers/firmware}/sysfb.c (75%) rename {arch/x86/kernel => drivers/firmware}/sysfb_simplefb.c (81%) rename {arch/x86/include/asm => include/linux}/sysfb.h (70%) -- 2.31.1

5 13

understanding virtio-gpu
by Enrico Weigelt, metux IT consult 21 Jul '21

21 Jul '21

Hello folks, I'm currently trying to understand how the virtio-gpu driver actually works and got a few noob questions: 1. virtio_gpu_pci_quirk(): * what is the explicit framebuffer removal about ? Do virtio-gpu devices support several framebuffer types (but only one at a time) ? How does it happen that we can have that vga framebuffer standing in our way in the first place ? * why is it necessary to rename the device with "pci:" prefix ? since (IMHO) virtio is an actual bus, that may even exist in HW, but there're also several different virtio transports (got word that somebody's also working on an socket-based one), it smells very strange to me, making it look like a pci device. does it only work w/ pci transport ? what's the background of this ? 2. features[] array: * virgl seems only supported on little endian, and the comment tells that's because virgl is sending the command stream in native endian. * IMHO, this approach isn't entirely correct, since here we're just looking whether the driver/guest side is LE, but looking at the host/device side. otoh, it should still work if both sides are BE. * shouldn't we add some endianess handshake to the protocol ? maybe both should announce what's their native endianess and whether they're capable of doing the conversion, so they can aggree on what to do exactly ? I'm currently trying to find ways for using virgl in containers instead of VMs, so the container workload doesn't need to have any gpu specific (userland) drivers anymore. Not sure whether I'll need special kernel support for this at all. thx, --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

2 1

[PATCH 0/3] Add support for querying hw info that UMDs need
by John.C.Harrison＠Intel.com 20 Jul '21

20 Jul '21

From: John Harrison <John.C.Harrison(a)Intel.com> Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Further information can be calculated dynamically from fuse registers. Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> John Harrison (2): drm/i915/guc: Add fetch of hwconfig table drm/i915/uapi: Add query for L3 bank count Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_gt.c | 15 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 1 + .../gpu/drm/i915/gt/intel_hwconfig_types.h | 102 +++++++++++ .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 167 ++++++++++++++++++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 ++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 45 +++++ drivers/gpu/drm/i915/i915_reg.h | 1 + include/uapi/drm/i915_drm.h | 2 + 14 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_hwconfig_types.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1

8 16

[RFC PATCH 0/4] Add a RPMsg driver to support AI Processing Unit (APU)
by Alexandre Bailon 20 Jul '21

20 Jul '21

This adds a RPMsg driver that implements communication between the CPU and an APU. This uses VirtIO buffer to exchange messages but for sharing data, this uses a dmabuf, mapped to be shared between CPU (userspace) and APU. The driver is relatively generic, and should work with any SoC implementing hardware accelerator for AI if they use support remoteproc and VirtIO. For the people interested by the firmware or userspace library, the sources are available here: https://github.com/BayLibre/open-amp/tree/v2020.01-mtk/apps/examples/apu Alexandre Bailon (3): Add a RPMSG driver for the APU in the mt8183 rpmsg: apu_rpmsg: update the way to store IOMMU mapping rpmsg: apu_rpmsg: Add an IOCTL to request IOMMU mapping Julien STEPHAN (1): rpmsg: apu_rpmsg: Add support for async apu request drivers/rpmsg/Kconfig | 9 + drivers/rpmsg/Makefile | 1 + drivers/rpmsg/apu_rpmsg.c | 752 +++++++++++++++++++++++++++++++++ drivers/rpmsg/apu_rpmsg.h | 52 +++ include/uapi/linux/apu_rpmsg.h | 47 +++ 5 files changed, 861 insertions(+) create mode 100644 drivers/rpmsg/apu_rpmsg.c create mode 100644 drivers/rpmsg/apu_rpmsg.h create mode 100644 include/uapi/linux/apu_rpmsg.h -- 2.26.2

3 10

← Newer
1
...
10
11
12
13
14
15
16
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021