dri-devel April 2020

dri-devel@lists.freedesktop.org

353 participants
944 discussions

[PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100
by Kai-Heng Feng 07 Oct '20

07 Oct '20

There's another OLED panel needs to use DPCD aux interface to control backlight. BugLink: https://bugs.launchpad.net/bugs/1860303 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/drm/drm_dp_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 8ba4531e808d..a0d4314663de 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1301,6 +1301,8 @@ static … [View More]

2 4

[Bug 199979] New: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control
by bugzilla-daemon＠bugzilla.kernel.org 06 Oct '20

06 Oct '20

https://bugzilla.kernel.org/show_bug.cgi?id=199979 Bug ID: 199979 Summary: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control Product: Drivers Version: 2.5 Kernel Version: 4.17.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: … [View More]

1 1

KASAN: global-out-of-bounds Read in fbcon_get_font
by syzbot 30 Sep '20

30 Sep '20

Hello, syzbot found the following crash on: HEAD commit: 6cf8298d Add linux-next specific files for 20191209 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=168bbb7ae00000 kernel config: https://syzkaller.appspot.com/x/.config?x=682fc0ce6c86e3c7 dashboard link: https://syzkaller.appspot.com/bug?extid=29d4ed7f3bdedf2aa2fd compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12fff061e00000 … [View More]IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+29d4ed7f3bdedf2aa2fd(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: global-out-of-bounds in memcpy include/linux/string.h:425 [inline] BUG: KASAN: global-out-of-bounds in fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 Read of size 32 at addr ffffffff88729d80 by task syz-executor.3/9100 CPU: 1 PID: 9100 Comm: syz-executor.3 Not tainted 5.5.0-rc1-next-20191209-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memcpy+0x24/0x50 mm/kasan/common.c:125 memcpy include/linux/string.h:425 [inline] fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 con_font_get drivers/tty/vt/vt.c:4446 [inline] con_font_op+0x20b/0x1270 drivers/tty/vt/vt.c:4605 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45a6f9 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f30314dcc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a6f9 RDX: 0000000000713000 RSI: 0000000000004b60 RDI: 0000000000000004 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f30314dd6d4 R13: 00000000004c6d87 R14: 00000000004dd3e0 R15: 00000000ffffffff The buggy address belongs to the variable: fontdata_8x16+0x1000/0x1120 Memory state around the buggy address: ffffffff88729c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff88729d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffff88729d80: fa fa fa fa 06 fa fa fa fa fa fa fa 05 fa fa fa ^ ffffffff88729e00: fa fa fa fa 06 fa fa fa fa fa fa fa 00 00 03 fa ffffffff88729e80: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches [View Less]

7 28

[Bug 198551] New: amdgpu error on shutdown or gpu intense game
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '20

24 Sep '20

https://bugzilla.kernel.org/show_bug.cgi?id=198551 Bug ID: 198551 Summary: amdgpu error on shutdown or gpu intense game Product: Drivers Version: 2.5 Kernel Version: 4.14.14-1 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 … [View More]

1 5

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
by Daniel Vetter 23 Sep '20

23 Sep '20

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the … [View More]kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d5cefb1cb2a2..058512f14772 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -2018,15 +2018,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.18.0 [View Less]

3 11

[PATCH 0/7] drm/omap: misc improvements
by Tomi Valkeinen 22 Sep '20

22 Sep '20

Hi, Misc improvements to omapdrm which have been lying around for a long time, and I've missed upstreaming them. And one new one, which makes the DSS5 HDMI pick up the color range automatically. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (3): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes drm/omap: dss: platform_register_drivers() to dss.c and remove … [View More]

7 33

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
by Christian König 16 Sep '20

16 Sep '20

Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > Hi Woody, > > sorry for the late reply, I've been off to a vacation over the holidays. > > On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: >> Regression in 5.4 kernel on 32-bit Radeon IBM T40 >> triggered by >> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 >> Author: Christoph Hellwig <hch(a)lst.de> >> Date: Thu Aug 15 09:27:00 2019 +0200 >> … [View More]

5 5

Re: backend-drm and scanning really large resolutions
by Pekka Paalanen 12 Sep '20

12 Sep '20

Adding Rob back in CC, I don't know if he is subscribed to wayland-devel@. You forgot to CC dri-devel@ too. On Tue, 11 Feb 2020 17:18:52 -0500 Xiaowen Wu <wxiaowen(a)codeaurora.org> wrote: > Hi Rob, > > If the vendor driver doesn't have the hwpipe sub-object and kms plane is > one-to-one mapped to hwpipe (sspp), > do you think if below approach is acceptable if we still want to > virtualize the kms plane to support 4K/8K scanout? > > 1. At kms atomic check … [View More]before calling drm_atomic_helper_check, depending > on scanout width of plane A in state, add idle planes B (C,D,...) > into the same atomic state, backup and then modify > src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...) > to meet scanout > width limits, and set crtc/fb of the affected planes B (C,D,...) same as > plane A. > > 2. At plane's state duplicate function, check if plane's > src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the > change to > plane A's backup value to allow plane A's scanout to update again. These > value will again be updated in step 1) so nothing really changes > if plane A continues updating. > > 3. If plane A's scanout is updated or detached from crtc, detach > affected planes B (C,D,...) in the same atomic state in step 1) and then > run step 1) again. > > 4. If user want to commit plane B (C,D,...), the commit/test will fail > if planes are already used as sister plane of plane A. This failure is > same > as insufficient hwpipe from plane B (C,D,...). > > With above change, any downstream driver can support virtualized plane. > Also as the above approach is generic and not h/w specific, we can make > it a helper function and it's up to vendor to choose if they want to use > or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in > their downstream driver. > > Conceptional above changes didn't borrow hwpipe resources from other > plane but borrow planes themselves directly, however from user point of > view > they should not feel any difference. > > What do you think? > > BR, > Xiaowen Wu > > > On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote: > > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at > > gmail.com> wrote: > >> > >> Hi all, > >> > >> I'm confronting a situation where the hardware with which I work is > >> capable of driving connectors at 4K or 8K, but doing so requires > >> bonding the scanning of multiple planes together. > >> > >> The scenario is that you'd have a big primary framebuffer whose size > >> is too large for an individual hardware scanning pipeline on the > >> display controller to traverse within its maximum allowed clock rate. > >> > >> The hardware supplier's approach is to assign multiple planes, which > >> in the KMS driver map to hardware scanning pipelines, to each be > >> responsible for scanning a smaller section of the framebuffer. The > >> planes are all assigned to the same CRTC, and in concert with each > >> other they cover the whole area of the framebuffer and CRTC. > >> > >> This sounds a little bit wild to me. I hadn't been aware it's even > >> legal to have more than one plane treated a the source of scanout for > >> a single framebuffer. Maybe that distinction isn't really relevant > >> nowadays with universal plane support. > >> > > > > fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate > > one or two hwpipe's from the devices global atomic state, depending on > > scanout width.. the hwpipe (sspp) is the physical resource behind a > > plane, so essentially the kms planes are virtualized. At some point > > if you have too many wide layers, the atomic test step will fail due > > to insufficient hwpipe's. But this sort of scenario is the reason for > > the test step. > > > > BR, > > -R > > > >> I'm wondering if anybody here knows whether this a legit approach for > >> a compositor's DRM backend to take? > >> > _______________________________________________ > wayland-devel mailing list > wayland-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel [View Less]

3 2

[PATCH v2] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs
by Angelo Ribeiro 07 Sep '20

07 Sep '20

Add support for the video pattern generator (VPG) BER pattern mode and configuration in runtime. This enables using the debugfs interface to manipulate the VPG after the pipeline is set. Also, enables the usage of the VPG BER pattern. Changes in v2: - Added VID_MODE_VPG_MODE - Solved incompatible return type on __get and __set Reported-by: kbuild test robot <lkp(a)intel.com> Reported-by: Adrian Pop <pop.adrian61(a)gmail.com> Cc: Gustavo Pimentel <gustavo.pimentel(a)… [View More]synopsys.com> Cc: Joao Pinto <jpinto(a)synopsys.com> Cc: Jose Abreu <jose.abreu(a)synopsys.com> Signed-off-by: Angelo Ribeiro <angelo.ribeiro(a)synopsys.com> --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 98 ++++++++++++++++++++++++--- 1 file changed, 90 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index b18351b..9de3645 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -91,6 +91,7 @@ #define VID_MODE_TYPE_BURST 0x2 #define VID_MODE_TYPE_MASK 0x3 #define VID_MODE_VPG_ENABLE BIT(16) +#define VID_MODE_VPG_MODE BIT(20) #define VID_MODE_VPG_HORIZONTAL BIT(24) #define DSI_VID_PKT_SIZE 0x3c @@ -221,6 +222,21 @@ #define PHY_STATUS_TIMEOUT_US 10000 #define CMD_PKT_STATUS_TIMEOUT_US 20000 +#ifdef CONFIG_DEBUG_FS +#define VPG_DEFS(name, dsi) \ + ((void __force *)&((*dsi).vpg_defs.name)) + +#define REGISTER(name, mask, dsi) \ + { #name, VPG_DEFS(name, dsi), mask, dsi } + +struct debugfs_entries { + const char *name; + bool *reg; + u32 mask; + struct dw_mipi_dsi *dsi; +}; +#endif /* CONFIG_DEBUG_FS */ + struct dw_mipi_dsi { struct drm_bridge bridge; struct mipi_dsi_host dsi_host; @@ -238,9 +254,12 @@ struct dw_mipi_dsi { #ifdef CONFIG_DEBUG_FS struct dentry *debugfs; - - bool vpg; - bool vpg_horizontal; + struct debugfs_entries *debugfs_vpg; + struct { + bool vpg; + bool vpg_horizontal; + bool vpg_ber_pattern; + } vpg_defs; #endif /* CONFIG_DEBUG_FS */ struct dw_mipi_dsi *master; /* dual-dsi master ptr */ @@ -530,9 +549,11 @@ static void dw_mipi_dsi_video_mode_config(struct dw_mipi_dsi *dsi) val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS; #ifdef CONFIG_DEBUG_FS - if (dsi->vpg) { + if (dsi->vpg_defs.vpg) { val |= VID_MODE_VPG_ENABLE; - val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0; + val |= dsi->vpg_defs.vpg_horizontal ? + VID_MODE_VPG_HORIZONTAL : 0; + val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0; } #endif /* CONFIG_DEBUG_FS */ @@ -961,6 +982,68 @@ static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = { #ifdef CONFIG_DEBUG_FS +int dw_mipi_dsi_debugfs_write(void *data, u64 val) +{ + struct debugfs_entries *vpg = data; + struct dw_mipi_dsi *dsi; + u32 mode_cfg; + + if (!vpg) + return -ENODEV; + + dsi = vpg->dsi; + + *vpg->reg = (bool)val; + + mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG); + + if (*vpg->reg) + mode_cfg |= vpg->mask; + else + mode_cfg &= ~vpg->mask; + + dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg); + + return 0; +} + +int dw_mipi_dsi_debugfs_show(void *data, u64 *val) +{ + struct debugfs_entries *vpg = data; + + if (!vpg) + return -ENODEV; + + *val = *vpg->reg; + + return 0; +} + +DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show, + dw_mipi_dsi_debugfs_write, "%llu\n"); + +static void debugfs_create_files(void *data) +{ + struct dw_mipi_dsi *dsi = data; + struct debugfs_entries debugfs[] = { + REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi), + REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi), + REGISTER(vpg_ber_pattern, VID_MODE_VPG_MODE, dsi), + }; + int i; + + dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL); + if (!dsi->debugfs_vpg) + return; + + memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs)); + + for (i = 0; i < ARRAY_SIZE(debugfs); i++) + debugfs_create_file(dsi->debugfs_vpg[i].name, 0644, + dsi->debugfs, &dsi->debugfs_vpg[i], + &fops_x32); +} + static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi) { dsi->debugfs = debugfs_create_dir(dev_name(dsi->dev), NULL); @@ -969,14 +1052,13 @@ static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi) return; } - debugfs_create_bool("vpg", 0660, dsi->debugfs, &dsi->vpg); - debugfs_create_bool("vpg_horizontal", 0660, dsi->debugfs, - &dsi->vpg_horizontal); + debugfs_create_files(dsi); } static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi) { debugfs_remove_recursive(dsi->debugfs); + kfree(dsi->debugfs_vpg); } #else -- 2.7.4 [View Less]

5 9

[PATCH 00/59] devm_drm_dev_alloc, v2
by Daniel Vetter 04 Sep '20

04 Sep '20

Hi all, Here's the next round of devm_drm_dev_alloc. Big changes: - lots of acks, reviews and some testing tags. Very much appreciated! - I dropped the core driver patch, and hence also the patches for vgem, vkms and i915-selftests. That needs more discussions first. - I started to convert some of the other drivers that still used drm_dev_alloc to the shiny new world, with a pile of cleanups on top. So lots more patches to test and review. Looking at git grep output for drm_dev_alloc(… [View More]) I think there's enough room for another few similarly sized patch series. I'm kinda using that also to survey the state of drivers, so I have a good idea what drmm_ versions for various modeset objects should look like. Atm still not sure how to best approach this, with the mix of drivers we do have: Some use devm_kzalloc, some explicit kzalloc + kfree in cleanup code, some embedded it somewhere else. As usual, review, testing and comments very much appreciated. Cheers, Daniel Daniel Vetter (59): drm: Add devm_drm_dev_alloc macro drm/vboxvideo: drop DRM_MTRR_WC #define drm/vboxvideo: Use devm_drm_dev_alloc drm/vboxvideo: Stop using drm_device->dev_private drm/vboxvidoe: use managed pci functions drm/vboxvideo: Use devm_gen_pool_create drm/v3d: Don't set drm_device->dev_private drm/v3d: Use devm_drm_dev_alloc drm/v3d: Delete v3d_dev->dev drm/v3d: Delete v3d_dev->pdev drm/udl: Use devm_drm_dev_alloc drm/udl: don't set drm_device->dev_private drm/st7735r: Use devm_drm_dev_alloc drm/st7586: Use devm_drm_dev_alloc drm/repaper: Use devm_drm_dev_alloc drm/mi0283qt: Use devm_drm_dev_alloc drm/ili9486: Use devm_drm_dev_alloc drm/ili9341: Use devm_drm_dev_alloc drm/ili9225: Use devm_drm_dev_alloc drm/hx8357d: Use devm_drm_dev_alloc drm/gm12u320: Use devm_drm_dev_alloc drm/gm12u320: Don't use drm_device->dev_private drm/tidss: Use devm_drm_dev_alloc drm/tidss: Don't use drm_device->dev_private drm/tidss: Delete tidss->saved_state drm/qxl: Use devm_drm_dev_alloc drm/qxl: Don't use drm_device->dev_private drm/mcde: Use devm_drm_dev_alloc drm/mcde: Don't use drm_device->dev_private drm/ingenic: Use devm_drm_dev_alloc drm/ingenic: Don't set drm_device->dev_private drm/komeda: use devm_drm_dev_alloc drm/armada: Use devm_drm_dev_alloc drm/armada: Don't use drm_device->dev_private drm/cirrus: Use devm_drm_dev_alloc drm/cirrus: Don't use drm_device->dev_private drm/cirrus: Move to drm/tiny drm/i915: Use devm_drm_dev_alloc drm/arcpgu: Switch to devm_drm_dev_alloc drm/arcpgu: Stop using drm_device->dev_private drm/arcpgu: Delete arcpgu_priv->fb drm/arc: Embedded a drm_simple_display_pipe drm/arc: Embedd a drm_connector for sim case drm/arc: Drop surplus connector registration drm/arc: Use drmm_mode_config_cleanup drm/arc: Align with simple pipe helpers drm/arc: Convert to drm_simple_kms_pipe_helper drm/arc: Drop fb/crtc check in arc_pgu_update drm/arc: Inline arcpgu_crtc.c drm/arc: Inline arcpgu_drm_hdmi_init drm/arc: Inline remaining files drm/arc: Initialize sim connector before display pipe drm/arc: Move to drm/tiny drm/aspeed: Drop aspeed_gfx->fbdev drm/aspeed: Use devm_drm_dev_alloc drm/aspeed: Use managed drmm_mode_config_cleanup drm/ast: Use managed pci functions drm/ast: Drop explicit connector register/unregister drm/bochs: Remove explicit drm_connector_register MAINTAINERS | 4 +- drivers/gpu/drm/Kconfig | 4 - drivers/gpu/drm/Makefile | 2 - drivers/gpu/drm/arc/Kconfig | 10 - drivers/gpu/drm/arc/Makefile | 3 - drivers/gpu/drm/arc/arcpgu.h | 37 -- drivers/gpu/drm/arc/arcpgu_crtc.c | 222 --------- drivers/gpu/drm/arc/arcpgu_drv.c | 234 --------- drivers/gpu/drm/arc/arcpgu_hdmi.c | 48 -- drivers/gpu/drm/arc/arcpgu_regs.h | 31 -- drivers/gpu/drm/arc/arcpgu_sim.c | 108 ----- .../gpu/drm/arm/display/komeda/komeda_kms.c | 16 +- drivers/gpu/drm/armada/armada_crtc.c | 4 +- drivers/gpu/drm/armada/armada_debugfs.c | 2 +- drivers/gpu/drm/armada/armada_drm.h | 2 + drivers/gpu/drm/armada/armada_drv.c | 30 +- drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/armada/armada_gem.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 8 +- drivers/gpu/drm/aspeed/aspeed_gfx.h | 3 +- drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 42 +- drivers/gpu/drm/aspeed/aspeed_gfx_out.c | 2 +- drivers/gpu/drm/ast/ast_drv.c | 10 +- drivers/gpu/drm/ast/ast_main.c | 3 - drivers/gpu/drm/ast/ast_mode.c | 3 - drivers/gpu/drm/bochs/bochs_kms.c | 1 - drivers/gpu/drm/cirrus/Kconfig | 19 - drivers/gpu/drm/cirrus/Makefile | 2 - drivers/gpu/drm/drm_drv.c | 23 + drivers/gpu/drm/i915/i915_drv.c | 17 +- drivers/gpu/drm/i915/i915_pci.c | 2 - drivers/gpu/drm/ingenic/ingenic-drm.c | 15 +- drivers/gpu/drm/mcde/mcde_display.c | 10 +- drivers/gpu/drm/mcde/mcde_drm.h | 2 + drivers/gpu/drm/mcde/mcde_drv.c | 21 +- drivers/gpu/drm/mcde/mcde_dsi.c | 2 +- drivers/gpu/drm/qxl/qxl_debugfs.c | 7 +- drivers/gpu/drm/qxl/qxl_display.c | 32 +- drivers/gpu/drm/qxl/qxl_drv.c | 23 +- drivers/gpu/drm/qxl/qxl_drv.h | 7 +- drivers/gpu/drm/qxl/qxl_dumb.c | 2 +- drivers/gpu/drm/qxl/qxl_gem.c | 2 +- drivers/gpu/drm/qxl/qxl_ioctl.c | 14 +- drivers/gpu/drm/qxl/qxl_irq.c | 2 +- drivers/gpu/drm/qxl/qxl_kms.c | 13 +- drivers/gpu/drm/qxl/qxl_object.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 2 +- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- drivers/gpu/drm/tidss/tidss_crtc.c | 16 +- drivers/gpu/drm/tidss/tidss_drv.c | 17 +- drivers/gpu/drm/tidss/tidss_drv.h | 4 +- drivers/gpu/drm/tidss/tidss_irq.c | 12 +- drivers/gpu/drm/tidss/tidss_kms.c | 2 +- drivers/gpu/drm/tidss/tidss_plane.c | 6 +- drivers/gpu/drm/tiny/Kconfig | 29 ++ drivers/gpu/drm/tiny/Makefile | 2 + drivers/gpu/drm/tiny/arcpgu.c | 450 ++++++++++++++++++ drivers/gpu/drm/{cirrus => tiny}/cirrus.c | 22 +- drivers/gpu/drm/tiny/gm12u320.c | 24 +- drivers/gpu/drm/tiny/hx8357d.c | 13 +- drivers/gpu/drm/tiny/ili9225.c | 13 +- drivers/gpu/drm/tiny/ili9341.c | 13 +- drivers/gpu/drm/tiny/ili9486.c | 13 +- drivers/gpu/drm/tiny/mi0283qt.c | 13 +- drivers/gpu/drm/tiny/repaper.c | 14 +- drivers/gpu/drm/tiny/st7586.c | 13 +- drivers/gpu/drm/tiny/st7735r.c | 13 +- drivers/gpu/drm/udl/udl_connector.c | 4 +- drivers/gpu/drm/udl/udl_drv.c | 27 +- drivers/gpu/drm/udl/udl_modeset.c | 6 +- drivers/gpu/drm/v3d/v3d_debugfs.c | 12 +- drivers/gpu/drm/v3d/v3d_drv.c | 47 +- drivers/gpu/drm/v3d/v3d_drv.h | 7 +- drivers/gpu/drm/v3d/v3d_gem.c | 17 +- drivers/gpu/drm/v3d/v3d_irq.c | 16 +- drivers/gpu/drm/v3d/v3d_mmu.c | 10 +- drivers/gpu/drm/v3d/v3d_sched.c | 10 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 26 +- drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 + drivers/gpu/drm/vboxvideo/vbox_irq.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_main.c | 29 +- drivers/gpu/drm/vboxvideo/vbox_mode.c | 10 +- drivers/gpu/drm/vboxvideo/vbox_ttm.c | 12 - include/drm/drm_drv.h | 33 ++ 85 files changed, 822 insertions(+), 1196 deletions(-) delete mode 100644 drivers/gpu/drm/arc/Kconfig delete mode 100644 drivers/gpu/drm/arc/Makefile delete mode 100644 drivers/gpu/drm/arc/arcpgu.h delete mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c delete mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c delete mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c delete mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h delete mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c delete mode 100644 drivers/gpu/drm/cirrus/Kconfig delete mode 100644 drivers/gpu/drm/cirrus/Makefile create mode 100644 drivers/gpu/drm/tiny/arcpgu.c rename drivers/gpu/drm/{cirrus => tiny}/cirrus.c (97%) -- 2.25.1 [View Less]

10 141

← Newer
1
...
4
5
6
7
8
9
10
...
95
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2020