dri-devel January 2021

dri-devel@lists.freedesktop.org

322 participants
737 discussions

[PATCH v2 1/2] drm/msm: Call shutdown conditionally
by Fabio Estevam 15 Feb '21

15 Feb '21

Issuing a 'reboot' command in i.MX5 leads to the following flow: [ 24.557742] [<c0769b78>] (msm_atomic_commit_tail) from [<c06db0b4>] (commit_tail+0xa4/0x1b0) [ 24.566349] [<c06db0b4>] (commit_tail) from [<c06dbed0>] (drm_atomic_helper_commit+0x154/0x188) [ 24.575193] [<c06dbed0>] (drm_atomic_helper_commit) from [<c06db604>] (drm_atomic_helper_disable_all+0x154/0x1c0) [ 24.585599] [<c06db604>] (drm_atomic_helper_disable_all) from [<c06db704>] (drm_atomic_helper_shutdown+0x94/0x12c) [ 24.596094] [<c06db704>] (drm_atomic_helper_shutdown) from In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any of the Qualcomm display controllers), causing a NULL pointer dereference in msm_atomic_commit_tail(): [ 24.268964] 8<--- cut here --- [ 24.274602] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 24.283434] pgd = (ptrval) [ 24.286387] [00000000] *pgd=ca212831 [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM [ 24.295609] Modules linked in: [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111 #333 [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support) [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c [ 24.317743] LR is at commit_tail+0xa4/0x1b0 Fix the problem by calling drm_atomic_helper_shutdown() conditionally. Cc: <stable(a)vger.kernel.org> Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Suggested-by: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- Changes since v1: - Explain in the commit log that the problem happens after a 'reboot' command. drivers/gpu/drm/msm/msm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 108c405e03dd..c082b72b9e3b 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -1311,7 +1311,8 @@ static void msm_pdev_shutdown(struct platform_device *pdev) { struct drm_device *drm = platform_get_drvdata(pdev); - drm_atomic_helper_shutdown(drm); + if (get_mdp_ver(pdev)) + drm_atomic_helper_shutdown(drm); } static const struct of_device_id dt_match[] = { -- 2.25.1

1 3

soc: mediatek: cmdq: add address shift in jump
by Yongqiang Niu 15 Feb '21

15 Feb '21

Change since v1: -move out from mt8192 seri series Yongqiang Niu (1): soc: mediatek: cmdq: add address shift in jump drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.8.1.1.dirty

3 4

[PATCH 0/3] Experimental freesync video mode optimization
by Aurabindo Pillai 12 Feb '21

12 Feb '21

Changes in V5 ============= * More info in commit messages on the rationale of changes being added to the kernel. * Minor fixes Changes in V4 ============= 1) Add module parameter for freesync video mode * Change module parameter name to freesync_video 2) Add freesync video modes based on preferred modes: * Cosmetic fixes * Added comments about all modes being added by the driver. 3) Skip modeset for front porch change * Added more conditions for checking freesync video mode Changes in V3 ============= 1) Add freesync video modes based on preferred modes: * Cache base freesync video mode during the first iteration to avoid iterating over modelist again later. * Add mode for 60 fps videos 2) Skip modeset for front porch change * Fixes for bug exposed by caching of modes. Changes in V2 ============= 1) Add freesync video modes based on preferred modes: * Remove check for connector type before adding freesync compatible modes as VRR support is being checked, and there is no reason to block freesync video support on eDP. * use drm_mode_equal() instead of creating same functionality. * Additional null pointer deference check * Removed unnecessary variables. * Cosmetic fixes. 2) Skip modeset for front porch change * Remove _FSV string being appended to freesync video modes so as to not define new policies or break existing application that might use the mode name to figure out mode resolution. * Remove unnecessary variables * Cosmetic fixes. -- This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking. This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes. -- Aurabindo Pillai (3): drm/amd/display: Add module parameter for freesync video mode drm/amd/display: Add freesync video modes based on preferred modes drm/amd/display: Skip modeset for front porch change drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 ++++++++++++++++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 + 4 files changed, 382 insertions(+), 35 deletions(-) -- 2.30.0

5 12

[PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings
by Marek Vasut 12 Feb '21

12 Feb '21

Add DT binding document for TI SN65DSI83 DSI to LVDS bridge. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Stephen Boyd <swboyd(a)chromium.org> Cc: devicetree(a)vger.kernel.org To: dri-devel(a)lists.freedesktop.org --- .../bindings/display/bridge/ti,sn65dsi83.yaml | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..77e1bafd8cd8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI83 DSI to LVDS bridge chip + +maintainers: + - Marek Vasut <marex(a)denx.de> + +description: | + The Texas Instruments SN65DSI83 bridge takes MIPI DSI in and outputs LVDS. + https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn6… + +properties: + compatible: + const: ti,sn65dsi83 + + reg: + const: 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + ports: + type: object + additionalProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + additionalProperties: false + + description: + Video port for MIPI DSI input + + properties: + reg: + const: 0 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + data-lanes: + description: array of physical DSI data lane indexes. + + required: + - reg + + port@1: + type: object + additionalProperties: false + + description: + Video port for LVDS output (panel or bridge). + + properties: + reg: + const: 1 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + + required: + - reg + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi83"; + reg = <0x2d>; + + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; -- 2.29.2

4 13

[Bug 206987] New: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
by bugzilla-daemon＠bugzilla.kernel.org 11 Feb '21

11 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=206987 Bug ID: 206987 Summary: [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration Product: Drivers Version: 2.5 Kernel Version: 5.5.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: evvke(a)hotmail.com Regression: No Whole system crashes with this error message : simd exception: 0000 [#1] PREEMPT SMP NOPTI Only giving a REISUB treatment works. And cause is amdgpu driver. --- Mar 26 20:47:13 shodan kernel: simd exception: 0000 [#1] PREEMPT SMP NOPTI Mar 26 20:47:13 shodan kernel: CPU: 7 PID: 1344 Comm: Xorg Tainted: G W OE 5.5.11-arch1-1 #1 Mar 26 20:47:13 shodan kernel: Hardware name: Micro-Star International Co., Ltd. MS-7B78/X470 GAMING PRO CARBON (MS-7B78), BIOS 2.80 03/06/2019 Mar 26 20:47:13 shodan kernel: RIP: 0010:mode_support_and_system_configuration+0x30a3/0x4d90 [amdgpu] Mar 26 20:47:13 shodan kernel: Code: 00 0f 28 c3 e8 7e c9 ff ff f3 41 0f 11 87 40 19 00 00 e9 12 fd ff ff 41 83 be a8 00 00 00 06 75 93 f3 41 0f 10 86 40 1b 00 00 <f3> 41 0f 5e 86 f8 17 00 00 e8 4f c9 ff ff 41 8b 87 80 04 00 00 f3 Mar 26 20:47:13 shodan kernel: RSP: 0018:ffffb216c1f3b978 EFLAGS: 00010246 Mar 26 20:47:13 shodan kernel: RAX: 0000000000000006 RBX: ffff9c120bbfadc4 RCX: 0000000000000004 Mar 26 20:47:13 shodan kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9c120bbfb008 Mar 26 20:47:13 shodan kernel: RBP: ffff9c120bbfadc4 R08: ffff9c120bbfc164 R09: 0000000000000120 Mar 26 20:47:13 shodan kernel: R10: ffff9c120bbfaee4 R11: ffff9c120bbf0248 R12: ffff9c120bbfc63c Mar 26 20:47:13 shodan kernel: R13: 0000000000000000 R14: ffff9c120bbfaf5c R15: ffff9c120bbfadc4 Mar 26 20:47:13 shodan kernel: FS: 00007f1c9f336dc0(0000) GS:ffff9c19009c0000(0000) knlGS:0000000000000000 Mar 26 20:47:13 shodan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 26 20:47:13 shodan kernel: CR2: 00001f82bfec7fe0 CR3: 00000007cbe4a000 CR4: 00000000003406e0 Mar 26 20:47:13 shodan kernel: Call Trace: Mar 26 20:47:13 shodan kernel: dcn_validate_bandwidth+0xfe5/0x1f20 [amdgpu] Mar 26 20:47:13 shodan kernel: dc_validate_global_state+0x28a/0x310 [amdgpu] Mar 26 20:47:13 shodan kernel: amdgpu_dm_atomic_check+0x5d8/0x870 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_check_only+0x578/0x800 [drm] Mar 26 20:47:13 shodan kernel: ? dm_crtc_duplicate_state+0x6b/0x1f0 [amdgpu] Mar 26 20:47:13 shodan kernel: drm_atomic_commit+0x13/0x50 [drm] Mar 26 20:47:13 shodan kernel: drm_atomic_helper_legacy_gamma_set+0x123/0x180 [drm_kms_helper] Mar 26 20:47:13 shodan kernel: drm_mode_gamma_set_ioctl+0x171/0x220 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl_kernel+0xb2/0x100 [drm] Mar 26 20:47:13 shodan kernel: drm_ioctl+0x209/0x360 [drm] Mar 26 20:47:13 shodan kernel: ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm] Mar 26 20:47:13 shodan kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Mar 26 20:47:13 shodan kernel: do_vfs_ioctl+0x4b7/0x730 Mar 26 20:47:13 shodan kernel: ksys_ioctl+0x5e/0x90 Mar 26 20:47:13 shodan kernel: __x64_sys_ioctl+0x16/0x20 Mar 26 20:47:13 shodan kernel: do_syscall_64+0x4e/0x150 Mar 26 20:47:13 shodan kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 26 20:47:13 shodan kernel: RIP: 0033:0x7f1ca01892eb Mar 26 20:47:13 shodan kernel: Code: 0f 1e fa 48 8b 05 a5 8b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 8b 0c 00 f7 d8 64 89 01 48 Mar 26 20:47:13 shodan kernel: RSP: 002b:00007ffc60ff5648 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 Mar 26 20:47:13 shodan kernel: RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f1ca01892eb Mar 26 20:47:13 shodan kernel: RDX: 00007ffc60ff5700 RSI: 00000000c02064a5 RDI: 000000000000000a Mar 26 20:47:13 shodan kernel: RBP: 00007ffc60ff5680 R08: 0000562bb635c080 R09: 0000562bb635c280 Mar 26 20:47:13 shodan kernel: R10: 0000562bb635be80 R11: 0000000000000206 R12: 0000000000000100 Mar 26 20:47:13 shodan kernel: R13: 0000562bb6ab4f70 R14: 0000562bb635b9c0 R15: 0000000000000100 Mar 26 20:47:13 shodan kernel: Modules linked in: snd_seq_dummy snd_seq bluetooth ecdh_generic rfkill ecc veth fuse iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tun ip6table_mangle xt_MASQUERADE iptable_nat nf_nat xt_connmark iptable_mangle xt_helper xt_NFLOG xt_limit xt_conntrack xt_tcpudp nf_conntrack_ftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_irc nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) pktcdvd nfnetlink_log nfnetlink ip6table_filter nct6775 ip6_tables hwmon_vid iptable_filter edac_mce_amd kvm_amd ccp ext4 rng_core kvm snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi crc16 mbcache irqbypass mxm_wmi jbd2 snd_hda_intel wmi_bmof snd_intel_dspcfg snd_hda_codec snd_usb_audio crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_core uvcvideo snd_usbmidi_lib snd_rawmidi videobuf2_vmalloc videobuf2_memops snd_seq_device videobuf2_v4l2 aesni_intel snd_hwdep videobuf2_common crypto_simd snd_pcm mousedev cryptd glue_helper Mar 26 20:47:13 shodan kernel: input_leds sp5100_tco snd_timer igb k10temp pcspkr i2c_piix4 snd soundcore dca wmi evdev mac_hid gpio_amdpt pinctrl_amd acpi_cpufreq xt_mark v4l2loopback(OE) videodev mc usbmon nbd msr vhba(OE) sr_mod cdrom sg br_netfilter bridge stp llc ip_tables x_tables dm_mod btrfs blake2b_generic libcrc32c crc32c_generic xor raid6_pq sd_mod hid_generic usbhid hid crc32c_intel ahci libahci libata xhci_pci xhci_hcd scsi_mod amdgpu gpu_sched i2c_algo_bit ttm drm_kms_helper serio_raw syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart i8042 atkbd libps2 serio Mar 26 20:47:13 shodan kernel: ---[ end trace e34593e526e29a3d ]--- Mar 26 20:47:13 shodan kernel: RIP: 0010:mode_support_and_system_configuration+0x30a3/0x4d90 [amdgpu] Mar 26 20:47:13 shodan kernel: Code: 00 0f 28 c3 e8 7e c9 ff ff f3 41 0f 11 87 40 19 00 00 e9 12 fd ff ff 41 83 be a8 00 00 00 06 75 93 f3 41 0f 10 86 40 1b 00 00 <f3> 41 0f 5e 86 f8 17 00 00 e8 4f c9 ff ff 41 8b 87 80 04 00 00 f3 Mar 26 20:47:13 shodan kernel: RSP: 0018:ffffb216c1f3b978 EFLAGS: 00010246 Mar 26 20:47:13 shodan kernel: RAX: 0000000000000006 RBX: ffff9c120bbfadc4 RCX: 0000000000000004 Mar 26 20:47:13 shodan kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9c120bbfb008 Mar 26 20:47:13 shodan kernel: RBP: ffff9c120bbfadc4 R08: ffff9c120bbfc164 R09: 0000000000000120 Mar 26 20:47:13 shodan kernel: R10: ffff9c120bbfaee4 R11: ffff9c120bbf0248 R12: ffff9c120bbfc63c Mar 26 20:47:13 shodan kernel: R13: 0000000000000000 R14: ffff9c120bbfaf5c R15: ffff9c120bbfadc4 Mar 26 20:47:13 shodan kernel: FS: 00007f1c9f336dc0(0000) GS:ffff9c19009c0000(0000) knlGS:0000000000000000 Mar 26 20:47:13 shodan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 26 20:47:13 shodan kernel: CR2: 00001f82bfec7fe0 CR3: 00000007cbe4a000 CR4: 00000000003406e0 -- You are receiving this mail because: You are watching the assignee of the bug.

1 48

[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]. Because it is hard to get the current upstream kernel to work on BCM2711, I used the kernel from rpi-5.8.y tree [3]. There still are problems where some Piglit tests get longer time to finish running (3610 minutes to 3650 minutes in total), and some ones result in the invalid memory read errors with unknown reasons: [17086.230959] v3d fec00000.v3d: MMU error from client CLE (4) at 0xac1000, pte invalid [17086.238722] v3d fec00000.v3d: MMU error from client CLE (4) at 0x1b61000, pte invalid [18643.303188] v3d fec00000.v3d: MMU error from client L2T (0) at 0x15bff00, pte invalid [18655.933748] v3d fec00000.v3d: MMU error from client L2T (0) at 0x15bff00, pte invalid However, most of the CL/CSD programs are now working happily without kernel warnings and errors. Regards, Sugizaki [1] https://patchwork.kernel.org/patch/11732895/ [2] https://github.com/Idein/py-videocore6 [3] https://github.com/raspberrypi/linux/tree/rpi-5.8.y Yukimasa Sugizaki (3): drm/v3d: Don't resubmit guilty CSD jobs drm/v3d: Correctly restart the timer when progress is made drm/v3d: Add job timeout module param drivers/gpu/drm/v3d/v3d_sched.c | 62 +++++++++++++++++++++++++++++++++-------- 1 file changed, 51 insertions(+), 11 deletions(-) -- 2.7.4

3 9

Some HDMI deep color output fixes for DC on DCE 6-11
by Mario Kleiner 10 Feb '21

10 Feb '21

Hi, these two patches fix non-working HDMI deep color output on DCE-8.3, AMD Mullins when amdgpu-kms is used with Displaycore force-enabled, ie. for radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1: I suspect they might fix similar problems on other older asics of DCE-11.0 and earlier. Patch 1/2 is a fix for some oddity i found while hunting for the HDMI deep color bug. It fixes what looks like an obvious mistake, but the fix did not improve or degrade anything, so maybe the hw doesn't care all too much about the wrong clamping/truncation mask? Anyway, it makes the code less confusing. Patch 2/2 fixes HDMI deep color output at 10 bpc or 12 bpc output on AMD Mullins, DCE-8.3, where at output_bpc 10 or 12 the display would be scrambled. With the patch, the display looks correct, and photometer measurements on a HDR-10 monitor suggest we probably get the correct output signal. I found the fix by comparing DC against the classic amdgpu-kms and radeon-kms modesetting path, readding missing stuff. Given other encoder/pixelclock setup functions than the ones used on DCE-8.3 showed the same omissions, i added missing code there as well, but i couldn't test it due to lack of hw, so i hope that fixes instead of breaks things on asic's other than DCE-8.3. I also created a similar patch for DCE-11.2 and later, not included here, but during testing on a Raven Ridge DCN-1, the patch neither helped nor hurt. Output was correct without the patch, and adding the patch didn't change or break anything on DCN-1. Looking at disassembled AtomBios tables for DCN-1 and a DCE-11.2, i think AtomBios may not do much with the info that was missing, which would explain why the current upstream code seems to work fine without it? At least as verified on DCN-1. I can't test on DCE-11.2 or DCE-12 due to lack of hw with actual HDMI output. But it would be interesting for me to know what changed wrt. Atombios in later asic versions to make some of this setup apparently redundant in DC? Do you test DC wrt. HDMI deep color starting at a specific DCE revision, given that the bug went unnoticed in DCE-8.3, but things seem to be fine on at least DCN-1? Thanks, -mario

3 6

[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 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

10 54

[PATCH v5 0/2] Implement DE2.0 and DE3.0 per-plane alpha support
by Roman Stratiienko 10 Feb '21

10 Feb '21

Please review/merge. v2: Initial patch v3: - Skip adding & applying alpha property if VI count > 1 (v3s case) v4: Resend (author's email changed) v5: Resend drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 29 +++++++++++++++++++++++++++++ drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 5 +++++ drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 48 ++++++++++++++++++++++++++++++++++++++++-------- drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 +++++++++++ 4 files changed, 85 insertions(+), 8 deletions(-)

2 3

[PATCH 1/3] dt-bindings: Add vendor prefix for Displaytech
by Marek Vasut 09 Feb '21

09 Feb '21

The Displaytech Ltd. is an LCD panel manufacturer. Signed-off-by: Marek Vasut <marex(a)denx.de> To: dri-devel(a)lists.freedesktop.org Cc: Eric Anholt <eric(a)anholt.net> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: devicetree(a)vger.kernel.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..866295dcb730 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -279,6 +279,8 @@ patternProperties: description: Diglent, Inc. "^dioo,.*": description: Dioo Microcircuit Co., Ltd + "^displaytech,.*": + description: Displaytech Ltd. "^dlc,.*": description: DLC Display Co., Ltd. "^dlg,.*": -- 2.29.2

2 4

← Newer
1
...
12
13
14
15
16
17
18
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2021