dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[Bug 106428] reported VDDGFX GPU voltage jumps above set limits in pp_od_clk_voltage when UVD is used for VAAPI/VDPAU
by bugzilla-daemon＠freedesktop.org 29 Nov '18

29 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=106428 Bug ID: 106428 Summary: reported VDDGFX GPU voltage jumps above set limits in pp_od_clk_voltage when UVD is used for VAAPI/VDPAU Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: tempel.julian(a)gmail.com I adjusted my pstates in "/sys/class/drm/card0/device/pp_od_clk_voltage" that the GPU voltage should never be above 900 mV: (...) 5: 1126Mhz 880 mV 6: 1180Mhz 890 mV 7: 1209Mhz 900 mV And in normal 3D applications "watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info" accordingly never reports more than 900 mV for VDDGFX. But when I play a video in mpv with VAAPI/VDPAU, reported VDDGFX often jumps to 1100 mV, which clearly is undesired behavior. It sticks again to normal 900 mV as soon as I disable hardware decoding. Now the question is, if the reported voltage is correct (then adjusting pp_od_clk_voltage has a bug) or if the real voltage is just reported wrong (than information in amdgpu_pm_info would be wrong). Happens with both 4.17rc2 and drm-next-4.18-wip. GPU is RX 560. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 106287] 18.0.1 introduced glitches in Dying Light
by bugzilla-daemon＠freedesktop.org 29 Nov '18

29 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=106287 Bug ID: 106287 Summary: 18.0.1 introduced glitches in Dying Light Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: henrik.holst2(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Upgrading from 18.0.0 to 18.0.1 introduced graphical glitches in Dying Light. There is usually a black box in the center of the screen where the sight should be and if one is looking at areas with water the entire screen glitches like crazy. Tried to rebuild the shader cache by removing .cache/mesa_shader_cache but that didn't help. Some info from glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.19.0 / 4.14.37, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.1 - padoka PPA OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.1 - padoka PPA OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.1 - padoka PPA OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 199619] New: screen stays dark for long on bootup since kernel 4.17.0-rc2+
by bugzilla-daemon＠bugzilla.kernel.org 28 Nov '18

28 Nov '18

https://bugzilla.kernel.org/show_bug.cgi?id=199619 Bug ID: 199619 Summary: screen stays dark for long on bootup since kernel 4.17.0-rc2+ Product: Drivers Version: 2.5 Kernel Version: 4.17.0-rc2+ 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: estellnb(a)elstel.org Regression: No When I boot with kernel 4.17.0-rc2+ the screen stays dark for more than 2 minutes before the GUI appears. This is a regression towards 4.16.0-rc3+ where the GUI had appeared immediately when Xorg had started up. -- You are receiving this mail because: You are watching the assignee of the bug.

1 14

[Bug 93649] [radeonsi] Graphics lockup while playing tf2
by bugzilla-daemon＠freedesktop.org 27 Nov '18

27 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=93649 Bug ID: 93649 Summary: [radeonsi] Graphics lockup while playing tf2 Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: matthew(a)mjdsystems.ca QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120925 --> https://bugs.freedesktop.org/attachment.cgi?id=120925&action=edit Kernel dmesg around the time of the lockup. After a period of time playing the latest version of TF2, my GPU locks up. After the kernel tries to reset, the X becomes stuck and won't work. The rest of the system is fine however. Sometimes, the GPU will reset successfully and continue working, only to lockup later, eventually freezing X. Hardware: GPU: Gigabyte Radeon HD 7970 Ghz edition OC CPU: AMD Phenom ii X6 1100T MB: Asus Crosshair IV Formula Software: Mesa: 11.1.0 DRM: 2.4.65 LLVM: 3.7.0 X: 1.17.4 DDX: 7.6.1 Kernel: 4.3.3 I have a dmesg with debug turned on and a strace of X from around the time it crashes (attached). I reduced the log file to the relevant bits, as they are quite large. I'll retry with latest git, see if it helps anywhere. -- You are receiving this mail because: You are the assignee for the bug.

1 81

[Bug 200645] New: 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
by bugzilla-daemon＠bugzilla.kernel.org 25 Nov '18

25 Nov '18

https://bugzilla.kernel.org/show_bug.cgi?id=200645 Bug ID: 200645 Summary: 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two Product: Drivers Version: 2.5 Kernel Version: 4.18-rc1-4.18-rc6+ 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: 1i5t5.duncan(a)cox.net Regression: No Created attachment 277487 --> https://bugzilla.kernel.org/attachment.cgi?id=277487&action=edit dmesg booting with the bad commit I have a dual-monitor setup connected to my polaris11/rx460, both actually TVs, an older 48" full-HD 1920x1080 connected to DVI-D-0, and a newer 65" 4k 3840x2160 connected to HDMI-A-0 (outputs as reported by xrandr). In drmfb mode I want them both at 1920x1080 resolution, so I have this set as part of the kernel-config built-in commandline to force 1920x1080 on the 4k: video=HDMI-A-1:1920x1080 (note that here it's HDMI-A-1, while X calls it HDMI-A-0) On 4.17.0, both outputs/monitors work well. On 4.18-rcs, only the 4k monitor (on the HDMI output) works. The full-HD on the DVI output displays the BIOS messages, grub, and early-pre-fb-kernel messages, but gets no signal when the framebuffer loads. If I start X/kde/plasma and run xrandr, it lists the output as connected but with no modes. If I try to activate it via xrandr, it says there's no modes. Bisecting gets me this: commit e03fd3f300f6184c1264186a4c815e93bf658abb (refs/bisect/bad) Author: Mikita Lipski <mikita.lipski(a)amd.com> Date: Wed May 16 16:46:18 2018 -0400 drm/amd/display: Do not limit color depth to 8bpc Delete if statement that would force any display's color depth higher than 8 bpc to 8 Signed-off-by: Mikita Lipski <mikita.lipski(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 1ce10bc2d..52e57b52c 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2095,12 +2095,6 @@ convert_color_depth_from_display_info(const struct drm_connector *connector) { uint32_t bpc = connector->display_info.bpc; - /* Limited color depth to 8bit - * TODO: Still need to handle deep color - */ - if (bpc > 8) - bpc = 8; - switch (bpc) { case 0: /* Temporary Work around, DRM don't parse color depth for --- snip --- So presumably the full-HD on the DVI has the wrong color depth for some reason and forcing it to 8bpc works, while allowing it to run what it has without that if breaks it. dmesg booting the bad commit is attached. -- You are receiving this mail because: You are watching the assignee of the bug.

1 14

[Bug 105982] Plugging HDMI cable hits [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout
by bugzilla-daemon＠freedesktop.org 19 Nov '18

19 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=105982 Bug ID: 105982 Summary: Plugging HDMI cable hits [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: jian-hong(a)endlessm.com Created attachment 138748 --> https://bugs.freedesktop.org/attachment.cgi?id=138748&action=edit the dmesg I have an AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx laptop. After system is booted and plugged the HDMI cable, the laptop's display had been blurred a while than came back again, and the extended display also worked. However, I can see the amdgpu module hits the error in dmesg: "[drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 10 tries - optc1_lock line:553" and the warning message. [ 70.999928] amdgpu 0000:03:00.0: ring 12(vcn_enc0) uses VM inv eng 6 on hub 1 [ 70.999964] amdgpu 0000:03:00.0: ring 13(vcn_enc1) uses VM inv eng 7 on hub 1 [ 71.005998] [drm] Initialized amdgpu 3.23.0 20150101 for 0000:03:00.0 on minor 0 [ 88.313107] Bluetooth: RFCOMM TTY layer initialized [ 88.313115] Bluetooth: RFCOMM socket layer initialized [ 88.313120] Bluetooth: RFCOMM ver 1.11 [ 99.918971] rfkill: input handler disabled [ 129.028256] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 10 tries - optc1_lock line:553 [ 129.028302] WARNING: CPU: 0 PID: 943 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195 generic_reg_wait+0xeb/0x160 [amdgpu] [ 129.028303] Modules linked in: rfcomm amdkfd amd_iommu_v2 amdgpu chash gpu_sched ttm drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt ccm cmac bnep zram arc4 snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep iwlmvm snd_pcm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 edac_mce_amd snd_timer mac80211 videobuf2_common videodev media asus_nb_wmi asus_wmi wmi_bmof kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd btusb btrtl r8169 btbcm pcbc btintel mii aesni_intel sparse_keymap soundcore iwlwifi bluetooth ecdh_generic cfg80211 joydev input_leds shpchp aes_x86_64 crypto_simd glue_helper cryptd i2c_piix4 wmi mac_hid tpm_crb asus_wireless ip_tables x_tables uas usb_storage hid_multitouch hid_generic [ 129.028342] serio_raw ahci libahci video i2c_hid hid [ 129.028348] CPU: 0 PID: 943 Comm: Xorg Not tainted 4.16.0 #9 [ 129.028349] Hardware name: ASUSTeK COMPUTER INC. VivoBook 15 X505ZA/X505ZA, BIOS X505ZA.200.T08 02/03/2018 [ 129.028380] RIP: 0010:generic_reg_wait+0xeb/0x160 [amdgpu] [ 129.028382] RSP: 0018:ffffafa98204b840 EFLAGS: 00010297 [ 129.028383] RAX: 0000000000000229 RBX: 000000000000000b RCX: 0000000000000000 [ 129.028385] RDX: 0000000000000000 RSI: ffff8b5e536164b8 RDI: ffff8b5e536164b8 [ 129.028386] RBP: ffffafa98204b880 R08: 0000000000006e60 R09: 00000000000003ad [ 129.028387] R10: 0000000000000001 R11: ffffffffa43527ed R12: 0000000000000001 [ 129.028388] R13: ffff8b5e50f1b880 R14: 0000000000000100 R15: 0000000000000001 [ 129.028390] FS: 00007ff314432a40(0000) GS:ffff8b5e53600000(0000) knlGS:0000000000000000 [ 129.028391] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 129.028392] CR2: 0000564dbd755970 CR3: 00000002f45d8000 CR4: 00000000003406f0 [ 129.028393] Call Trace: [ 129.028429] optc1_lock+0xa2/0xb0 [amdgpu] [ 129.028463] dcn10_apply_ctx_for_surface+0xed/0x510 [amdgpu] [ 129.028494] dc_commit_state+0x266/0x5d0 [amdgpu] [ 129.028523] ? set_freesync_on_streams.part.5+0xa6/0x2a0 [amdgpu] [ 129.028552] ? mod_freesync_set_user_enable+0x15f/0x1a0 [amdgpu] [ 129.028586] amdgpu_dm_atomic_commit_tail+0x348/0xf80 [amdgpu] [ 129.028611] ? amdgpu_bo_pin_restricted+0x1fe/0x2b0 [amdgpu] [ 129.028614] ? _cond_resched+0x1a/0x50 [ 129.028617] ? wait_for_completion_timeout+0x3a/0x140 [ 129.028619] ? _cond_resched+0x1a/0x50 [ 129.028621] ? wait_for_completion_interruptible+0x37/0x180 [ 129.028622] ? ww_mutex_unlock+0x26/0x30 [ 129.028630] commit_tail+0x42/0x70 [drm_kms_helper] [ 129.028636] drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper] [ 129.028669] amdgpu_dm_atomic_commit+0x87/0xa0 [amdgpu] [ 129.028681] drm_atomic_commit+0x51/0x60 [drm] [ 129.028686] drm_atomic_helper_set_config+0x6e/0x90 [drm_kms_helper] [ 129.028695] __drm_mode_set_config_internal+0x6b/0x120 [drm] [ 129.028704] drm_mode_setcrtc+0x4f1/0x680 [drm] [ 129.028713] ? drm_mode_getcrtc+0x190/0x190 [drm] [ 129.028721] drm_ioctl_kernel+0x6b/0xb0 [drm] [ 129.028729] drm_ioctl+0x33c/0x3f0 [drm] [ 129.028737] ? drm_mode_getcrtc+0x190/0x190 [drm] [ 129.028760] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [ 129.028763] do_vfs_ioctl+0xa6/0x610 [ 129.028766] ? recalc_sigpending+0x1b/0x50 [ 129.028768] ? _copy_from_user+0x36/0x70 [ 129.028770] SyS_ioctl+0x79/0x90 [ 129.028772] ? exit_to_usermode_loop+0xa7/0xd0 [ 129.028774] do_syscall_64+0x73/0x130 [ 129.028777] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 129.028778] RIP: 0033:0x7ff3118f1dd7 [ 129.028779] RSP: 002b:00007fffaba215a8 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [ 129.028781] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 00007ff3118f1dd7 [ 129.028782] RDX: 00007fffaba215e0 RSI: 00000000c06864a2 RDI: 000000000000000e [ 129.028783] RBP: 00007fffaba215e0 R08: 0000000000000000 R09: 000056528d76ac40 [ 129.028784] R10: 00007fffaba21780 R11: 0000000000003246 R12: 00000000c06864a2 [ 129.028785] R13: 000000000000000e R14: 000056528d25d9e0 R15: 000056528d129380 [ 129.028787] Code: 44 8b 45 10 44 89 e1 48 c7 c2 00 74 e0 c0 48 c7 c7 b3 f0 e0 c0 44 89 55 d4 50 e8 91 cf c0 ff 41 83 7d 20 01 44 8b 55 d4 58 74 02 <0f> 0b 48 8d 65 d8 44 89 d0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 41 [ 129.028810] ---[ end trace d73192e5e8ac0713 ]--- The kernel that I used is Linux 4.16.0. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers
by bugzilla-daemon＠freedesktop.org 14 Nov '18

14 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=99195 Bug ID: 99195 Summary: Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers Product: Mesa Version: 13.0 Hardware: All OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: johnrory.odwyer(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 128649 --> https://bugs.freedesktop.org/attachment.cgi?id=128649&action=edit Extract from journalctl show attempts to boot I have recently started getting random GPU lockups. I have the following GPU: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] I use the opensource driver on Wayland. Ithink the beginning of the random lockups coincided with upgrade from Mesa 12 to 13 on Fedora 25 but I never experienced any lock up on Fedora 24 with Wayland nor X. It happens with X as well Wayland on Fedora 25. It can happen at boot just when I get past the GDM log in screen or a couple of minutes after. Generally if I get past the first 15 minutes of a session it is stable. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[PATCH v2 0/7] tda998x: allow use with bridge based devices
by Russell King - ARM Linux 12 Nov '18

12 Nov '18

Hi, This is a re-posting of the series I responded to Peter Rosin's May posting, with a few bugs fixed, and the bridge registered outside of the component helper. This should allow Peter to use the driver while maintaining armada drm and tilcdc support. No comments (other than 0-day test results) were received on the previous posting. This is independent of the component helper vs bridge safety issues. drivers/gpu/drm/i2c/tda998x_drv.c | 288 ++++++++++++++++++++------------------ 1 file changed, 151 insertions(+), 137 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up

6 39

[Bug 106757] Qt's QOpenGLWidget renders a blank screen under XWayland
by bugzilla-daemon＠freedesktop.org 12 Nov '18

12 Nov '18

https://bugs.freedesktop.org/show_bug.cgi?id=106757 Bug ID: 106757 Summary: Qt's QOpenGLWidget renders a blank screen under XWayland Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel(a)lists.freedesktop.org Reporter: myk321(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 139886 --> https://bugs.freedesktop.org/attachment.cgi?id=139886&action=edit Qt Application renders correctly using MESA software rendering With intel integrated graphics, the Qt Surface example, that uses QOpenGLWidget, on Fedora 28 under an wayland session and then run under xwayland by starting the Qt application using the command: ./surface -platform xcb results in the Qt application being displayed correctly, but the 3D data visualization is shown incorrectly as blank panel (see attached). The same Qt application in a Wayland session with MESA software rendering also under xwayland as follows: LIBGL_ALWAYS_SOFTWARE=1 ./surface -platform xcb results in the application and 3D data visualization being displayed correctly (see attached). The same Qt application in a XOrg session results in the application and 3D data visualization being displayed correctly. The same Qt application in a Wayland session run under wayland results in the application and 3D data visualization being displayed correctly. This issue is logged as a Qt defect here: https://bugreports.qt.io/browse/QTBUG-68263 A similar issue is described for GNU Octave here: https://savannah.gnu.org/bugs/?51442 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[RFC PATCHv2 0/9] drm/tidss: new display driver for TI's DSS6 & DSS7
by Tomi Valkeinen 07 Nov '18

07 Nov '18

Hi, This is a new DRM driver for Texas Instruments' Keystone K2G and AM6 SoCs. K2G has DSS6 IP, which is related to the OMAP DSS IPs handled by the omapdrm driver. While on higher level the DSS6 resembles the older DSS versions, the registers and the internal pipelines differ a lot. DSS6 IP on K2G is a "ultra-light" version, and has only a single plane and a single output. AM6 has DSS7 IP, which is an evolution of DSS6. AM6 DSS is a "light" version, having two planes and two outputs (OLDI and DPI). Compared to the RFC series sent a few weeks ago, this series contains the DSS7 driver and a lot of cleanups on the internal dispc_ops API. I'm still calling this an RFC, as AM6 board support is not in mainline, so we're missing the DT changes, but also because the K2G DT changes most likely should be implemented as DT overlays. I think the driver itself is more or less ready to be reviewed and merged. Tomi Jyri Sarha (1): drm/tidss: Add dispc7 for DSS7 support Peter Ujfalusi (1): drm: Add support for extracting sync signal drive edge from videomode Tomi Valkeinen (7): dt-bindings: display/ti: add k2g-dss bindings dt-bindings: display/ti: add am65x-dss bindings drm/tidss: add new driver for TI Keystone platforms MAINTAINERS: add entry for tidss drm/panel: simple: add newhaven,nhd-4.3-480272ef-atxl LCD ARM: dts: keystone-k2g: add DSS node ARM: dts: keystone-k2g-evm: add LCD and HDMI displays .../panel/newhaven,nhd-4.3-480272ef-atxl.txt | 7 + .../bindings/display/ti/ti,am6-dss.txt | 16 + .../bindings/display/ti/ti,k2g-dss.txt | 15 + MAINTAINERS | 9 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/keystone-k2g-evm-lcd.dts | 80 + arch/arm/boot/dts/keystone-k2g-evm.dts | 87 + arch/arm/boot/dts/keystone-k2g.dtsi | 21 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_modes.c | 15 +- drivers/gpu/drm/panel/panel-simple.c | 29 + drivers/gpu/drm/tidss/Kconfig | 10 + drivers/gpu/drm/tidss/Makefile | 12 + drivers/gpu/drm/tidss/tidss_crtc.c | 390 ++++ drivers/gpu/drm/tidss/tidss_crtc.h | 49 + drivers/gpu/drm/tidss/tidss_dispc.h | 146 ++ drivers/gpu/drm/tidss/tidss_dispc6.c | 1450 ++++++++++++++ drivers/gpu/drm/tidss/tidss_dispc6.h | 109 ++ drivers/gpu/drm/tidss/tidss_dispc7.c | 1708 +++++++++++++++++ drivers/gpu/drm/tidss/tidss_dispc7.h | 185 ++ drivers/gpu/drm/tidss/tidss_drv.c | 338 ++++ drivers/gpu/drm/tidss/tidss_drv.h | 41 + drivers/gpu/drm/tidss/tidss_encoder.c | 101 + drivers/gpu/drm/tidss/tidss_encoder.h | 22 + drivers/gpu/drm/tidss/tidss_irq.c | 193 ++ drivers/gpu/drm/tidss/tidss_irq.h | 25 + drivers/gpu/drm/tidss/tidss_kms.c | 85 + drivers/gpu/drm/tidss/tidss_kms.h | 14 + drivers/gpu/drm/tidss/tidss_plane.c | 186 ++ drivers/gpu/drm/tidss/tidss_plane.h | 25 + include/drm/drm_connector.h | 4 + 32 files changed, 5372 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,am6-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt create mode 100644 arch/arm/boot/dts/keystone-k2g-evm-lcd.dts create mode 100644 drivers/gpu/drm/tidss/Kconfig create mode 100644 drivers/gpu/drm/tidss/Makefile create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.c create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc7.c create mode 100644 drivers/gpu/drm/tidss/tidss_dispc7.h create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

8 31

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018