dri-devel February 2019

dri-devel@lists.freedesktop.org

256 participants
1976 discussions

[PATCH] Make the "Reducing compressed framebufer size" message be DRM_INFO_ONCE()
by Peter Jones 07 Apr '20

07 Apr '20

This was sort of annoying me: random:~$ dmesg | tail -1 [523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. random:~$ dmesg | grep -c "Reducing the compressed" 47 This patch makes it DRM_INFO_ONCE() just like the similar message farther down in that function is pr_info_once(). Signed-off-by: Peter Jones <pjones(a)redhat.com> --- drivers/gpu/drm/i915/intel_fbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index b431b6733cc..88b013758da 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -585,7 +585,7 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc) if (!ret) goto err_llb; else if (ret > 1) { - DRM_INFO("Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.\n"); + DRM_INFO_ONCE("Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.\n"); } -- 2.17.1

3 2

[PATCH] RFC: drm/atomic-helpers: remove legacy_cursor_update hacks
by Daniel Vetter 06 Mar '20

06 Mar '20

The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: mikita.lipski(a)amd.com Cc: Michel Dänzer <michel(a)daenzer.net> Cc: harry.wentland(a)amd.com Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 130da5195f3b..5a576cdf26dd 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1330,13 +1330,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, int i, ret; unsigned crtc_mask = 0; - /* - * Legacy cursor ioctls are completely unsynced, and userspace - * relies on that (by doing tons of cursor updates). - */ - if (old_state->legacy_cursor_update) - return; - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) { if (!new_crtc_state->active) continue; @@ -1884,12 +1877,6 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, continue; } - /* Legacy cursor updates are fully unsynced. */ - if (state->legacy_cursor_update) { - complete_all(&commit->flip_done); - continue; - } - if (!new_crtc_state->event) { commit->event = kzalloc(sizeof(*commit->event), GFP_KERNEL); -- 2.18.0.rc2

1 1

[Bug 196247] New: AMD FirePro W5130M (Dell 3510 notebook) - radeon driver - ring 0 stalled
by bugzilla-daemon＠bugzilla.kernel.org 28 Feb '20

28 Feb '20

https://bugzilla.kernel.org/show_bug.cgi?id=196247 Bug ID: 196247 Summary: AMD FirePro W5130M (Dell 3510 notebook) - radeon driver - ring 0 stalled Product: Drivers Version: 2.5 Kernel Version: 4.10. Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: mat42x(a)yahoo.de Regression: No Created attachment 257289 --> https://bugzilla.kernel.org/attachment.cgi?id=257289&action=edit dmesg output Hardware: Dell 3510 notebook (i5 CPU - HD 530) & Discrete AMD Radeon FirePro W5130M GPU. The discrete AMD GPU has no connections to any monitor. Steps to reproduce: $ DRI_PRIME=1 glmark2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD CAPE VERDE (DRM 2.49.0 / 4.10.0-26-generic, LLVM 4.0.0) GL_VERSION: 3.0 Mesa 17.1.2 ======================================================= [build] use-vbo=false:radeon: The kernel rejected CS, see dmesg for more information (-16). radeon: The kernel rejected CS, see dmesg for more information (-16). radeon: The kernel rejected CS, see dmesg for more information (-16). FPS: 10 FrameTime: 100.000 ms radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000001070000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x1070000 radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000001070000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x1070000 radeonsi: Failed to create a context. Segmentation fault (core dumped) -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[Bug 58981] New: Bisected regression; boot failure with Radeon 9250 PCI 256MB + KMS
by bugzilla-daemon＠bugzilla.kernel.org 28 Jan '20

28 Jan '20

https://bugzilla.kernel.org/show_bug.cgi?id=58981 Summary: Bisected regression; boot failure with Radeon 9250 PCI 256MB + KMS Product: Drivers Version: 2.5 Kernel Version: 2.6.35,3.2.45,3.10-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: jdietrch(a)fastmail.fm Regression: Yes I have a Radeon 9250 PCI 256MB video card in my machine. I discovered that this machine would not boot with 3.2.45 when KMS was enabled by default in the kernel config. Immediately after the grub menu, the screen would go black and nothing more would happen. Or sometimes columns of character-sized "marks" would appear on the screen. In either case, though, the machine would not boot. So I went back to 2.6.33 and found that booting with KMS did work just fine there. So I used git bisect to find where the problem arose, and that pointed to this commit which was merged for 2.6.35: commit 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 Author: Jerome Glisse <jglisse(a)redhat.com> Date: Wed Apr 7 10:21:31 2010 +0000 drm/radeon/kms: enable use of unmappable VRAM V2 I confirmed this result of git bisect by checking out 2.6.35 final and reverting that one commit, and the resulting kernel booted fine with KMS enabled by default. I also tried 3.10-rc2 and that booted fine when I added radeon.modeset=0 to the kernel commandline. I will attach files with dmesg output and lspci. Please let me know if there is anything else I can do. I'll be happy to test a proposed fix if that would be helpful. Thank you, James Dietrich -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 6

[RFC PATCH v1 0/5] Add pardata bus + tinydrm driver
by Sam Ravnborg 20 Jan '20

20 Jan '20

This is an RFC - to get some responses on the overall design. The code builds but has not yet been tested on any HW. Before investing more time into this I would like some feedback if this is the right way forward or a different design should be pursued. The problem to solve is that I have a propriatary ARM based board with a display that is connected using a parallel bus. The display is capable of showing graphics so it is more advanced than what is found in auxdisplay/ I know there are others using a display connected usign a parallel data bus, so this is not a unique problem for my board alone. But I do not expect many users as any modern design likely uses SPI or similar. The old (proprietary) approach was to implement a char driver and then let some 3rd party lib use the char driver to write to the display. The goal is to move to a more modern world where I expect to have a simple Qt based program running that can be used for a few simple things. (I do not expect any high performance and do not need it). Implementation: A pardata bus is implemented. It uses a platform_driver to hook into the DT. When probed the pardatabus driver creates pardata devices for all child nodes in the tree. Within tinydrm the pardata support is used to implement a driver for the display I have (Winstar wg160160). A library module is used to implement the more basic things allowing us to have a more simple driver, and thus making it simpler to add new drivers. The implmentation uses array support in gpiolib to try to have some performance on screen updates. TODO: - Test on HW - Add locking so there can be more than one user on the bus - Improve pardata.rst documentation - Add support for a sparkfun parallel data display (To verify that the library is generic) - I may add a class if I see the need - Likewise I may add sysfs attributes if there is a need for it Any comments appreciated! Sam Sam Ravnborg (5): dt-bindings: add parallel data bus (pardata) pardata: new bus for parallel data access tinydrm: add support for parallel data displays dt-bindings: add winstar,wg160160 display bindings tinydrm: add winstar wg160160 driver .../bindings/display/winstar,wg160160.txt | 53 +++ .../bindings/pardata/parallel-data-bus.txt | 60 +++ Documentation/driver-api/index.rst | 1 + Documentation/driver-api/pardata.rst | 60 +++ MAINTAINERS | 14 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/gpu/drm/tinydrm/Kconfig | 13 + drivers/gpu/drm/tinydrm/Makefile | 2 + drivers/gpu/drm/tinydrm/pardata-dbi.c | 417 +++++++++++++++++++++ drivers/gpu/drm/tinydrm/wg160160.c | 298 +++++++++++++++ drivers/pardata/Kconfig | 17 + drivers/pardata/Makefile | 5 + drivers/pardata/pardata.c | 282 ++++++++++++++ include/drm/tinydrm/pardata-dbi.h | 257 +++++++++++++ include/linux/pardata.h | 138 +++++++ 16 files changed, 1620 insertions(+)

5 18

[Bug 194731] New: drm general protection fault in drm_atomic_init
by bugzilla-daemon＠bugzilla.kernel.org 09 Jan '20

09 Jan '20

https://bugzilla.kernel.org/show_bug.cgi?id=194731 Bug ID: 194731 Summary: drm general protection fault in drm_atomic_init Product: Drivers Version: 2.5 Kernel Version: 4.10.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: janpieter.sollie(a)dommel.be Regression: No I modified the drm_atomic.c a bit to be more verbose. the drm_init calls a general protection fault when allocating my second GPU(does it work this way?) of the amdgpu module. afterwards, the system is unable to allocate more kernel memory. init does not even manage to reboot, I can not do sudo without segfault dmesg: [ 77.946291] [drm] Cannot find any crtc or sizes - going 1024x768 [ 77.946575] [drm] fb mappable at 0xC0CCB000 [ 77.946576] [drm] vram apper at 0xC0000000 [ 77.946577] [drm] size 786432 [ 77.946578] [drm] fb depth is 24 [ 77.946578] [drm] pitch is 1024 [ 77.950389] kcalloc called [ 77.950390] kcalloc2 called [ 77.950433] kcalloc called [ 77.950444] general protection fault: 0000 [#1] SMP [ 77.950445] Modules linked in: amdkfd amdgpu(O+) amdttm(O) amdkcl(O) ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 nf_nat l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc deflate cmac af_key w83627ehf hwmon_vid k10temp fam15h_power i2c_piix4 pcspkr [ 77.950462] CPU: 16 PID: 5094 Comm: kworker/16:2 Tainted: G O 4.10.0-rc8 #12 [ 77.950463] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 2.0a 01/09/2012 [ 77.950470] Workqueue: events work_for_cpu_fn [ 77.950471] task: ffff88183c027000 task.stack: ffffc90020cfc000 [ 77.950476] RIP: 0010:__kmalloc+0x6f/0x100 [ 77.950477] RSP: 0018:ffffc90020cff6b0 EFLAGS: 00010286 [ 77.950478] RAX: 0000000000000000 RBX: ffff8818362628ff RCX: 0000000000000897 [ 77.950479] RDX: 0000000000000896 RSI: 0000000000000000 RDI: 0000000000019b70 [ 77.950479] RBP: ffffc90020cff6d0 R08: ffff88183fc19b70 R09: ffffffff81417df1 [ 77.950480] R10: 0000000000000300 R11: 0000000000000000 R12: ff88183626296000 [ 77.950481] R13: ffff88083f803a00 R14: 00000000014080c0 R15: ffff88183602b238 [ 77.950483] FS: 0000000000000000(0000) GS:ffff88183fc00000(0000) knlGS:0000000000000000 [ 77.950484] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.950485] CR2: 00005590d5ce93d8 CR3: 0000000001c11000 CR4: 00000000000406e0 [ 77.950485] Call Trace: [ 77.950492] drm_atomic_state_init+0x81/0xf0 [ 77.950494] drm_atomic_state_alloc+0x53/0x80 [ 77.950497] drm_fb_helper_pan_display+0xf4/0x2a0 [ 77.950501] fb_pan_display+0xd6/0x170 [ 77.950502] bit_update_start+0x24/0x60 [ 77.950504] fbcon_switch+0x3e2/0x670 [ 77.950507] redraw_screen+0x15d/0x220 [ 77.950510] ? tty_do_resize+0x4d/0xa0 [ 77.950512] vc_do_resize+0x4c3/0x4f0 [ 77.950513] vc_resize+0x1a/0x20 [ 77.950515] fbcon_init+0x40b/0x660 [ 77.950516] visual_init+0xce/0x130 [ 77.950517] do_bind_con_driver+0x1c1/0x3a0 [ 77.950519] do_take_over_console+0x113/0x180 [ 77.950520] do_fbcon_takeover+0x51/0xb0 [ 77.950522] fbcon_event_notify+0x75a/0x880 [ 77.950525] notifier_call_chain+0x44/0x70 [ 77.950526] __blocking_notifier_call_chain+0x4e/0x80 [ 77.950528] blocking_notifier_call_chain+0x11/0x20 [ 77.950529] fb_notifier_call_chain+0x16/0x20 [ 77.950531] register_framebuffer+0x200/0x340 [ 77.950533] drm_fb_helper_initial_config+0x201/0x390 piece of code that prints the "kcalloc(2) called": drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state) { kref_init(&(state->ref)); /* TODO legacy paths should maybe do a better job about * setting this appropriately? */ state->allow_modeset = true; state->crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(struct __drm_crtcs_state), GFP_KERNEL); printk("kcalloc called \n"); if (!(state->crtcs)) goto fail; state->planes = kcalloc(dev->mode_config.num_total_plane, sizeof(struct __drm_planes_state), GFP_KERNEL); printk("kcalloc2 called \n"); if (!(state->planes)) goto fail; state->dev = dev; DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state); return 0; fail: printk("fail called \n"); drm_atomic_state_default_release(state); return -ENOMEM; } EXPORT_SYMBOL(drm_atomic_state_init); -- You are receiving this mail because: You are watching the assignee of the bug.

1 9

[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version onwards 3.13
by bugzilla-daemon＠freedesktop.org 09 Dec '19

09 Dec '19

https://bugs.freedesktop.org/show_bug.cgi?id=108514 Bug ID: 108514 Summary: heavy screen flickering with Mobility Radeon X1600 and kernel version onwards 3.13 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: werner.lueckel(a)googlemail.com my laptop: HP Compaq nx9420 my grafic card: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] (prog-if 00 [VGA controller]) screen resolution: 1680x1050(a)60.1 when booting UBUNTU "14.04.5 LTS, Trusty Tahr" kernel 3.13.0-160-generic -> the screen is fine in text-mode and in grafic-mode; NO flickering. boot-messages say: [drm] Initialized radeon 2.36.0 ... BUT, when booting UBUNTU "18.04.1 LTS (Bionic Beaver)" kernel 4.15.0-36-generic -> the screen starts heavy flickering as soon as the kernel-module "radeon.ko" is loaded. The flickering continues in grafic-mode. here the boot-messages say: [drm] Initialized radeon 2.50.0 ... so: this seems to be a new version of radeon.ko. My question: - is there a method or a 'hidden flag' to switch radeon.ko-2.50 back to the good behaviour of radeon.ko-2.16? -- You are receiving this mail because: You are the assignee for the bug.

1 46

[Bug 64721] New: Radeon HD6450 fails on all distro's out of box.
by bugzilla-daemon＠bugzilla.kernel.org 02 Dec '19

02 Dec '19

https://bugzilla.kernel.org/show_bug.cgi?id=64721 Bug ID: 64721 Summary: Radeon HD6450 fails on all distro's out of box. Product: Drivers Version: 2.5 Kernel Version: Linux 3.2.04-amd64 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: ichapman(a)videotron.ca Regression: No I think I'm at the right place to report video card frustrations. Radeon HD450 fails to work out of the box with any Linux. With Debian Wheezy I need to edit the grub line starting with linux and add vga=791 to do anything. vga=771 fails With Knoppix 7.0 I need vga=771 and that's okay, but vga=791 the left half of screen is on right and right on left. The cursor moves to right falls off the screen and re-appears on left side. Very strange. With DebianMint I need vga=771 or 791 to get it to work. On my Acer Aspire laptop with a Radeon HD6310 I do not need any of this vga= stuff. I am sure that this is not a driver problem. All the vga=xxx does is kick it somewhere so that I loads the driver. My Motherboard is M2V-Mx from Asus and once the /etc/default/grub is fixed with GRUB_CMDLINE_LINUX="vga=791" or 771 it's okay. (sudo update-grub of course) I recently junked my Nvidia 8500GT video because the driver for that became sick, the worst feature was not being able to display the layout of the pcb tool unless I disabled the driver and used cpu sw rendering on the video but that's an other story. Ian. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
by bugzilla-daemon＠freedesktop.org 25 Nov '19

25 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97055 Bug ID: 97055 Summary: Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: darktjm(a)gmail.com Created attachment 125267 --> https://bugs.freedesktop.org/attachment.cgi?id=125267&action=edit dmesg from my latest boot (with some wifi messages at end deleted for privacy) I have an HP Pavilion 17-g133cl with A10 Carrizo+Topaz. I struggled for hours/days to get this to actually display anything at all using the amdgpu driver. In the mean time, efifb works perfectly every time (except of course no 3d, no X resolution switching, no brightness control, and slow enough that video playing is also impossible). Since it seemed like there were just issues powering up the display controller correctly, I decided at first to add my notes to https://bugzilla.kernel.org/show_bug.cgi?id=117591 but my symptoms (and cures) are, indeed, different. After much blind playing with my system (I have no way to ssh in, and the keyboard is flaky as well, so that was a lot of fun), I made the following observations: - kernel power management options appeared to have no effect - sometimes (very rarely), it just starts working, regardless - once it starts working for more than 1 minute, it stays working - often, it starts partially working, by giving me a flickering display - often, it starts working with a stable display, only to start flickering again after a few seconds (very rarely even going completely black gain) - my first way of fixing it is fairly reliable, but almost always requires at least one blind reboot before it starts giving my a display: xrandr --output eDP --crtc 1 (added to my .xinitrc) - if, when it finally comes up, it is flickering, it can be cured by toggling the crtc between 0 and 1 often enough until it remains stable for at least a minute. - if crtc 1 is enabled when X is killed, the machine goes blank and hangs hard; switching consoles while X is up works, though (although the consoles remain black). - changing the crtc to 1 in X does nothing for the console; only X displays anything. I have not tried to write a libdrm program to make the console switch to crtc 1, nor have I managed to trace where the crtc list comes from, or how to force it in the amdgpu driver itself. - if, instead of playing with the crtc, I play with power management again, I seem to be able to get it working by booting once with power management enabled, then rebooting with it disabled, and then it works (video in console as well as X, and no crtc switching necessary). However, that may just have been how it decides to work today, and tomorrow it will no longer work. I get identical behavior with kernels 4.6.2, 4.6.3, 4.6.4, 4.7-rc4 (which I decided to try given the supposed major amdgpu overhaul), 4.4.15 (which I decided to try given that the poster of the kernel.org bug was using Ubuntu's 4.4 kernel) (all on Gentoo; with the exception of 4.7-rc4, this is with Gentoo's fbdecor patches, but I obviously have that disabled while working through this problem). Overall, this is very weird and frustrating. I've had power management issues with previous Radeon laptops (all of them), but the gpu pm issue usually manifested as hard locks while playing games with power management enabled, not this crap. I have a feeling that anything that gets it to work only gets it to work due to random chance, and it's just that I'm beating at it often enough that I finally hit the jackpot at some point, and it keeps working correctly until I power cycle for an extended period again. I also get the feeling that I must be a major masochist to keep using ATI/AMD hardware, given that in 15+ years of using it I've never had an experience better than "meh, mostly works". If I weren't dead broke, I'd have chucked this machine over a freeway overpass and bought something else. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[PATCH 0/2] drm/mipi-dsi: support low power transmission
by Inki Dae 20 Nov '19

20 Nov '19

This patch considers low power transmisson to two clock behaviors, non-continuous and continuous clock mode. These two clock behaviors can transmit data in high speed or low power. So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each host driver can setup its host controller properly. Patch 1: Add MIPI_DSI_MODE_LPM flag. If panel driver sets this flag, then msg->flags will have MIPI_DSI_MSG_USE_LPM so that host driver can transmit data in low power. Patch 2: Just exynos part for supporting non-continuous and continuous clock mode. Inki Dae (2): drm/mipi-dsi: consider low power transmission drm/exynos: mipi-dsi: consider non-continuous clock mode drivers/gpu/drm/drm_mipi_dsi.c | 6 ++++++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 +++++++++++++++++++ include/drm/drm_mipi_dsi.h | 2 ++ 3 files changed, 27 insertions(+) -- 1.7.9.5

3 6

← Newer
1
2
3
4
5
6
7
...
198
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2019