dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH v2 0/3] clk: Implement a clock request API
by Maxime Ripard 14 Jan '22

14 Jan '22

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ This implements a mechanism to raise and lower clock rates based on consumer workloads, with an example of such an implementation for the RaspberryPi4 HDMI controller. There's a couple of things worth discussing: - The name is in conflict with clk_request_rate, and even though it feels like the right name to me, we should probably avoid any confusion - The code so far implements a policy of always going for the lowest rate possible. While we don't have an use-case for something else, this should maybe be made more flexible? Let me know what you think Maxime Changes from v1: - Return NULL in clk_request_start if clk pointer is NULL - Test for clk_req pointer in clk_request_done - Add another user in vc4 - Rebased on top of v5.15-rc1 Dom Cobley (1): drm/vc4: hvs: Convert to the new clock request API Maxime Ripard (2): clk: Introduce a clock request API drm/vc4: hdmi: Convert to the new clock request API drivers/clk/clk.c | 126 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 3 + drivers/gpu/drm/vc4/vc4_kms.c | 5 +- include/linux/clk.h | 4 ++ 5 files changed, 146 insertions(+), 7 deletions(-) -- 2.31.1

3 13

[Bug 210263] New: brightness device returns ENXIO (?) on brightness restore at boot, with bootoption "quiet"
by bugzilla-daemon＠bugzilla.kernel.org 12 Jan '22

12 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=210263 Bug ID: 210263 Summary: brightness device returns ENXIO (?) on brightness restore at boot, with bootoption "quiet" Product: Drivers Version: 2.5 Kernel Version: 5.9.8 Hardware: x86-64 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: plusfabi(a)gmail.com Regression: No Created attachment 293729 --> https://bugzilla.kernel.org/attachment.cgi?id=293729&action=edit dmesg Following: https://github.com/systemd/systemd/issues/17645 If I set kernel boot option "quiet", systemd fails to restore brightness level with error Failed to start Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0. At boot. full journal output is: journalctl -b -1 -u systemd-backlight@backlight:amdgpu_bl0.service -- Logs begin at Thu 2020-09-17 08:15:00 CEST, end at Tue 2020-11-17 14:19:18 CET. -- Nov 17 14:15:15 frigg systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0... Nov 17 14:15:15 frigg systemd-backlight[325]: amdgpu_bl0: Failed to write system 'brightness' attribute: No such device or address Nov 17 14:15:15 frigg systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, code=exited, status=1/FAILURE Nov 17 14:15:15 frigg systemd[1]: systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'. Nov 17 14:15:15 frigg systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:amdgpu_bl0. This is an AMD Renoir system, with AMD Ryzen 5 4500U APU, This happens only, if I set 'quiet' as boot option. If I remove it, brightness restore works fine. If I boot with quiet set, after login I can do systemctl start systemd-backlight@backlight:amdgpu_bl0.service And it will successfully restore my brightness level. -- You are receiving this mail because: You are watching the assignee of the bug.

1 8

[PATCH 1/3] drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly
by ville.syrjala＠linux.intel.com 12 Jan '22

12 Jan '22

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: stable(a)vger.kernel.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index bfd237c15e76..18cecd94acb6 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2515,8 +2515,8 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, int req_slots; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); port = drm_dp_get_validated_port_ref(mgr, port); if (port == NULL) @@ -2555,8 +2555,8 @@ int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_state *topology_state; topology_state = drm_atomic_get_mst_topology_state(state, mgr); - if (topology_state == NULL) - return -ENOMEM; + if (IS_ERR(topology_state)) + return PTR_ERR(topology_state); /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent -- 2.13.0

4 7

[Bug 206475] New: amdgpu under load drop signal to monitor until hard reset
by bugzilla-daemon＠bugzilla.kernel.org 06 Jan '22

06 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=206475 Bug ID: 206475 Summary: amdgpu under load drop signal to monitor until hard reset Product: Drivers Version: 2.5 Kernel Version: 5.5.2 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: rodomar705(a)protonmail.com Regression: No Created attachment 287265 --> https://bugzilla.kernel.org/attachment.cgi?id=287265&action=edit dmesg for the amdgpu hardware freeze While gaming the monitor goes blank randomly, only with this error in the logs of the system kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 200 ret is 65535 kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 282 ret is 65535 kernel: amdgpu: [powerplay] last message was failed ret is 65535 kernel: amdgpu: [powerplay] failed to send message 201 ret is 65535 with the occasional kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:47:crtc-0] flip_done timed out kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5275264, emitted seq=5275266 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Hand of Fate 2. pid 682062 thread Hand of Fa:cs0 pid 682064 kernel: amdgpu 0000:06:00.0: GPU reset begin! over and over again. If I reset the system no video output is seen until the system is fully shut off. B450 chipset + Ryzen 5 2600 + Radeon RX580 GPU Full log is attached to this post. Can anyone at AMD give me some pointers to what the problem is? Thanks, Marco. -- You are receiving this mail because: You are watching the assignee of the bug.

1 22

[Bug 212019] New: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out
by bugzilla-daemon＠bugzilla.kernel.org 28 Dec '21

28 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=212019 Bug ID: 212019 Summary: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Product: Drivers Version: 2.5 Kernel Version: 5.11.0 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: clemens(a)endorphin.org Regression: No Created attachment 295569 --> https://bugzilla.kernel.org/attachment.cgi?id=295569&action=edit Hardware I get the following display freeze on my T495 AMD Thinkpad: Mar 02 09:24:50 duncan kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Mar 02 09:25:02 duncan kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Mar 02 09:36:25 duncan kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:55:plane-3] flip_done timed out followed by this stack trace: Mar 02 09:36:25 duncan kernel: WARNING: CPU: 7 PID: 1636 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7754 amdgpu_dm_atomic_commit_tail+0x238b/0x2420 [amdgpu] Mar 02 09:36:25 duncan kernel: Modules linked in: fuse ctr ccm wireguard curve25519_x86_64 libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s blake2s_x86_64 ip6_udp_tunnel udp_tunnel libcurve25519_generic libchacha libblake2s_generic af_packet msr ip6table_nat iptable_nat nf_nat joydev mousedev xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip6t_rpfilter ipt_rpfilter amdgpu ip6table_raw iptable_raw xt_pkttype intel_rapl_msr nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp wmi_bmof iwlmvm snd_hda_codec_realtek iommu_v2 mac80211 snd_hda_codec_generic gpu_sched drm_ttm_helper snd_hda_codec_hdmi ttm btusb snd_hda_intel edac_mce_amd uvcvideo btrtl btbcm libarc4 btintel edac_core videobuf2_vmalloc drm_kms_helper nls_iso8859_1 intel_rapl_common deflate videobuf2_memops evdev crc32_pclmul nls_cp437 snd_intel_dspcfg mac_hid videobuf2_v4l2 iwlwifi bluetooth ip6table_filter vfat videobuf2_common snd_hda_codec ghash_clmulni_intel fat snd_hda_core ip6_tables thinkpad_acpi videodev Mar 02 09:36:25 duncan kernel: r8169 drm snd_hwdep efi_pstore nvram rapl psmouse realtek mdio_devres ledtrig_audio mc serio_raw snd_pcm pstore cfg80211 agpgart i2c_algo_bit fb_sys_fops ecdh_generic syscopyarea snd_timer sysfillrect ecc sch_fq_codel iptable_filter sysimgblt ipmi_devintf k10temp sp5100_tco watchdog snd_rn_pci_acp3x i2c_piix4 ucsi_acpi snd_pci_acp3x libphy ipmi_msghandler rfkill snd 8250_pci typec_ucsi soundcore ac typec battery wmi video i2c_scmi backlight i2c_core pinctrl_amd tiny_power_button acpi_cpufreq button loop tun tap macvlan bridge stp llc kvm_amd kvm irqbypass efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc sha256_ssse3 sha256_generic encrypted_keys trusted tpm rng_core rtsx_pci_sdmmc input_leds led_class mmc_core atkbd libps2 xhci_pci xhci_pci_renesas xhci_hcd crc32c_intel ehci_pci aesni_intel ehci_hcd libaes crypto_simd cryptd usbcore glue_helper nvme nvme_core rtsx_pci t10_pi usb_common crc_t10dif crct10dif_generic crct10dif_pclmul Mar 02 09:36:25 duncan kernel: crct10dif_common i8042 rtc_cmos serio dm_mod Mar 02 09:36:25 duncan kernel: CPU: 7 PID: 1636 Comm: X Not tainted 5.11.0 #1-NixOS Mar 02 09:36:25 duncan kernel: Hardware name: LENOVO 20NJCTO1WW/20NJCTO1WW, BIOS R12ET55W(1.25 ) 07/06/2020 Mar 02 09:36:25 duncan kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x238b/0x2420 [amdgpu] Mar 02 09:36:25 duncan kernel: Code: a8 fd ff ff 01 c7 85 a4 fd ff ff 37 00 00 00 c7 85 ac fd ff ff 20 00 00 00 e8 61 83 12 00 e9 e0 fa ff ff 0f 0b e9 30 f9 ff ff <0f> 0b e9 7f f9 ff ff 0f 0b 0f 0b e9 95 f9 ff ff 49 8b 06 41 0f b6 Mar 02 09:36:25 duncan kernel: RSP: 0018:ffffbd1043ae3928 EFLAGS: 00010002 Mar 02 09:36:25 duncan kernel: RAX: 0000000000000002 RBX: 000000000004bffc RCX: ffff976a603c9118 Mar 02 09:36:25 duncan kernel: RDX: 0000000000000001 RSI: 0000000000000297 RDI: ffff976a62660188 Mar 02 09:36:25 duncan kernel: RBP: ffffbd1043ae3c20 R08: 0000000000000005 R09: 0000000000000000 Mar 02 09:36:25 duncan kernel: R10: ffffbd1043ae3888 R11: ffffbd1043ae388c R12: 0000000000000297 Mar 02 09:36:25 duncan kernel: R13: ffff976e3132aa00 R14: ffff976a5dee9780 R15: ffff976a603c9000 Mar 02 09:36:25 duncan kernel: FS: 00007f993d92c980(0000) GS:ffff9772d8bc0000(0000) knlGS:0000000000000000 Mar 02 09:36:25 duncan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 02 09:36:25 duncan kernel: CR2: 00007f30c85b5ff8 CR3: 000000013e056000 CR4: 00000000003506e0 Mar 02 09:36:25 duncan kernel: Call Trace: Mar 02 09:36:25 duncan kernel: commit_tail+0x94/0x130 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_mode_setcrtc+0x1d3/0x6f0 [drm] Mar 02 09:36:25 duncan kernel: ? amdgpu_cs_wait_ioctl+0xd2/0x160 [amdgpu] Mar 02 09:36:25 duncan kernel: ? drm_mode_getcrtc+0x180/0x180 [drm] Mar 02 09:36:25 duncan kernel: drm_ioctl_kernel+0xaa/0xf0 [drm] Mar 02 09:36:25 duncan kernel: drm_ioctl+0x1ec/0x390 [drm] Mar 02 09:36:25 duncan kernel: ? drm_mode_getcrtc+0x180/0x180 [drm] Mar 02 09:36:25 duncan kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Mar 02 09:36:25 duncan kernel: __x64_sys_ioctl+0x83/0xb0 Mar 02 09:36:25 duncan kernel: do_syscall_64+0x33/0x40 Mar 02 09:36:25 duncan kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 02 09:36:25 duncan kernel: RIP: 0033:0x7f993dd37b07 Mar 02 09:36:25 duncan kernel: Code: c0 75 b5 48 8d 3c 2b e8 17 ff ff ff 85 c0 78 b6 48 89 d8 5b 5d 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 73 0c 00 f7 d8 64 89 01 48 Mar 02 09:36:25 duncan kernel: RSP: 002b:00007ffdd63e1ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Mar 02 09:36:25 duncan kernel: RAX: ffffffffffffffda RBX: 00007ffdd63e1f10 RCX: 00007f993dd37b07 Mar 02 09:36:25 duncan kernel: RDX: 00007ffdd63e1f10 RSI: 00000000c06864a2 RDI: 000000000000000f Mar 02 09:36:25 duncan kernel: RBP: 00000000c06864a2 R08: 0000000000000000 R09: 0000000002fad090 Mar 02 09:36:25 duncan kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Mar 02 09:36:25 duncan kernel: R13: 000000000000000f R14: 00000000021b4290 R15: 0000000000000000 Mar 02 09:36:25 duncan kernel: ---[ end trace 3bd64ee8f9aa76ff ]--- lshw and full kernel log attached. The first kernel that I saw this problem with was the 5.9. series. -- 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 3

[PATCH] drm/ast: Support 1600x900 with 108MHz PCLK
by KuoHsiang Chou 23 Dec '21

23 Dec '21

[New] Create the setting for 1600x900 @60Hz refresh rate by 108MHz pixel-clock. Signed-off-by: KuoHsiang Chou <kuohsiang_chou(a)aspeedtech.com> --- drivers/gpu/drm/ast/ast_tables.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h index d665dd5af5dd..8414e543f260 100644 --- a/drivers/gpu/drm/ast/ast_tables.h +++ b/drivers/gpu/drm/ast/ast_tables.h @@ -282,6 +282,8 @@ static const struct ast_vbios_enhtable res_1360x768[] = { }; static const struct ast_vbios_enhtable res_1600x900[] = { + {1800, 1600, 24, 80,1000, 900, 1, 3, VCLK108, /* 60Hz */ + (SyncPP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo), 60, 3, 0x3A }, {1760, 1600, 48, 32, 926, 900, 3, 5, VCLK97_75, /* 60Hz CVT RB */ (SyncNP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo | AST2500PreCatchCRT), 60, 1, 0x3A }, -- 2.18.4

5 6

[PATCH v3 0/2] Use "ref" clocks from firmware for DSI PLL VCO parent
by Marijn Suijten 21 Dec '21

21 Dec '21

All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirements of dsi-phy-common.yaml, but the clock is never used. This patchset puts that clock to use without relying on a global clock name, so that all dependencies are explicitly defined in DT (the firmware) in the end. [1]: https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1be96@… Changes since v2: - Added Stephen's a-b and Angelo's r-bs; - Added .name fallback in msm8974's dsi_phy_28nm for a more graceful transition period; - Documented possible breakage in 1/2 if firmware isn't updated in parallel with the kernel. Changes since v1: - Dropped "arm: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL reference" which has made its way into 5.15-fixes in advance of this patchset landing in 5.16; - Added Fixes: tags for commits that added missing "ref" clocks to DT while this firmware clock was never used (until this patchset); - Documented missing/wrong and later-added clocks (by aforementioned patches) in patch 1/2 more clearly. Marijn Suijten (2): drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent clk: qcom: gcc-sdm660: Remove transient global "xo" clock drivers/clk/qcom/gcc-sdm660.c | 14 -------------- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 4 +++- 6 files changed, 15 insertions(+), 19 deletions(-) -- 2.33.0

3 9

[PATCH v2 0/8] Host1x context isolation support
by Mikko Perttunen 17 Dec '21

17 Dec '21

Hi all, *** New in v2: Added support for Tegra194 Use standard iommu-map property instead of custom mechanism *** this series adds support for Host1x 'context isolation'. Since when programming engines through Host1x, userspace can program in any addresses it wants, we need some way to isolate the engines' memory spaces. Traditionally this has either been done imperfectly with a single shared IOMMU domain, or by copying and verifying the programming command stream at submit time (Host1x firewall). Since Tegra186 there is a privileged (only usable by kernel) Host1x opcode that allows setting the stream ID sent by the engine to the SMMU. So, by allocating a number of context banks and stream IDs for this purpose, and using this opcode at the beginning of each job, we can implement isolation. Due to the limited number of context banks only each process gets its own context, and not each channel. This feature also allows sharing engines among multiple VMs when used with Host1x's hardware virtualization support - up to 8 VMs can be configured with a subset of allowed stream IDs, enforced at hardware level. To implement this, this series adds a new host1x context bus, which will contain the 'struct device's corresponding to each context bank / stream ID, changes to device tree and SMMU code to allow registering the devices and using the bus, as well as the Host1x stream ID programming code and support in TegraDRM. Device tree bindings are not updated yet pending consensus that the proposed changes make sense. Thanks, Mikko Mikko Perttunen (8): gpu: host1x: Add context bus gpu: host1x: Add context device management code gpu: host1x: Program context stream ID on submission iommu/arm-smmu: Attach to host1x context device bus arm64: tegra: Add Host1x context stream IDs on Tegra186+ drm/tegra: falcon: Set DMACTX field on DMA transactions drm/tegra: vic: Implement get_streamid_offset drm/tegra: Support context isolation arch/arm64/boot/dts/nvidia/tegra186.dtsi | 12 ++ arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12 ++ drivers/gpu/Makefile | 3 +- drivers/gpu/drm/tegra/drm.h | 2 + drivers/gpu/drm/tegra/falcon.c | 8 + drivers/gpu/drm/tegra/falcon.h | 1 + drivers/gpu/drm/tegra/submit.c | 13 ++ drivers/gpu/drm/tegra/uapi.c | 34 ++++- drivers/gpu/drm/tegra/vic.c | 38 +++++ drivers/gpu/host1x/Kconfig | 5 + drivers/gpu/host1x/Makefile | 2 + drivers/gpu/host1x/context.c | 174 ++++++++++++++++++++++ drivers/gpu/host1x/context.h | 27 ++++ drivers/gpu/host1x/context_bus.c | 31 ++++ drivers/gpu/host1x/dev.c | 12 +- drivers/gpu/host1x/dev.h | 2 + drivers/gpu/host1x/hw/channel_hw.c | 52 ++++++- drivers/gpu/host1x/hw/host1x06_hardware.h | 10 ++ drivers/gpu/host1x/hw/host1x07_hardware.h | 10 ++ drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 ++ include/linux/host1x.h | 21 +++ include/linux/host1x_context_bus.h | 15 ++ 22 files changed, 488 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/host1x/context.c create mode 100644 drivers/gpu/host1x/context.h create mode 100644 drivers/gpu/host1x/context_bus.c create mode 100644 include/linux/host1x_context_bus.h -- 2.32.0

5 16

[RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
by Jagan Teki 15 Dec '21

15 Dec '21

This series supports common bridge support for Samsung MIPI DSIM which is used in Exynos and i.MX8MM SoC's. The final bridge supports both the Exynos and i.MX8MM DSI devices. Right now bridge offers two sets of implementations. A. With component_ops and exynos specific code exclusively for exynos dsi drivers and it's legacy bindings. B. Without componenet_ops for newly implemented bridges and its users like i.MX8MM. The future plan is to fix the implementation A) by dropping component_ops and fixing exynos specific code in order to make the bridge more mature to use and the same is mentioned in drivers TODO. Patch 0001 - 0006: Bridge conversion Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions Tested in Engicam i.Core MX8M Mini SoM. Anyone interest, please have a look on this repo https://github.com/openedev/linux/tree/070421-imx8mm-dsim Would appreciate anyone from the exynos team to test it on the exynos platform? Any inputs? Jagan. Jagan Teki (17): drm/exynos: dsi: Convert to bridge driver drm/exynos: dsi: Handle drm_device for bridge drm/exynos: dsi: Use the drm_panel_bridge API drm/exynos: dsi: Create bridge connector for encoder drm/exynos: dsi: Get the mode from bridge drm/exynos: dsi: Handle exynos specifics via driver_data drm: bridge: Move exynos_drm_dsi into bridges dt-bindings: display: bridge: Add Samsung MIPI DSIM bridge drm: bridge: samsung-dsim: Add module init, exit drm: bridge: samsung-dsim: Update the of_node for port(s) drm: bridge: samsung-dsim: Find the possible DSI devices dt-bindings: display: bridge: samsung,mipi-dsim: Add i.MX8MM support drm: bridge: samsung-dsim: Add i.MX8MM support drm: bridge: samsung-dsim: Add input_bus_flags drm: bridge: samsung-dsim: Move DSI init in bridge enable drm: bridge: samsung-dsim: Fix PLL_P offset drm: bridge: samsung-dsim: Add bridge mode_fixup .../display/bridge/samsung,mipi-dsim.yaml | 360 +++++++++ .../bindings/display/exynos/exynos_dsim.txt | 90 --- MAINTAINERS | 12 + drivers/gpu/drm/bridge/Kconfig | 15 + drivers/gpu/drm/bridge/Makefile | 1 + .../samsung-dsim.c} | 758 ++++++++++-------- drivers/gpu/drm/exynos/Kconfig | 9 - drivers/gpu/drm/exynos/Makefile | 1 - 8 files changed, 795 insertions(+), 451 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt rename drivers/gpu/drm/{exynos/exynos_drm_dsi.c => bridge/samsung-dsim.c} (69%) -- 2.25.1

11 46

[Bug 207763] New: Noisy Screen in Linux with kernel 5
by bugzilla-daemon＠bugzilla.kernel.org 12 Dec '21

12 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=207763 Bug ID: 207763 Summary: Noisy Screen in Linux with kernel 5 Product: Drivers Version: 2.5 Kernel Version: 5.0.0-23-generic Hardware: x86-64 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: xunilarium(a)gmail.com Regression: No Created attachment 289165 --> https://bugzilla.kernel.org/attachment.cgi?id=289165&action=edit My Noisy Screen As linux kernel was updated to version 5 my laptop screen become noisy, I have same problem with all linux distros with kernel 5 and above. The problem is available both in graphic and text mode. windows works fine so my graphic card is OK. Ubunut 18.04.02: -------------------------------------------------------------------------------- Kernel Ver: 4.18.0-15-generic VGA Driver: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] Subsystem: Sony Corporation RV620/M82 [Mobility Radeon HD 3450/3470] Kernel driver in use: radeon Kernel modules: radeon Screen Status: OK ________________________________________________________________________________ Ubuntu 18.04.03: -------------------------------------------------------------------------------- Kernel Ver: 5.0.0-23-generic VGA Driver: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] Subsystem: Sony Corporation RV620/M82 [Mobility Radeon HD 3450/3470] Kernel driver in use: radeon Kernel modules: radeon Screen Status: Noisy -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

← Newer
1
2
3
4
5
6
7
8
9
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021