dri-devel March 2018

dri-devel@lists.freedesktop.org

263 participants
1856 discussions

[PATCH] drm/pl111: Enable device-specific assigned memory
by Linus Walleij 07 Mar '18

07 Mar '18

The Versatile Express has 8 MB of dedicated video RAM (VRAM) on the motherboard, which is what we should be using for the PL111 if available. On this platform, the memory backplane is constructed so that only this memory will work properly with the CLCD on the motherboard, using any other memory region just gives random snow on the display. The CA9 Versatile Express also has a PL111 instance on its core tile. This is OK, it has been tested with the motherboard VRAM and that works just as fine as regular CMA memory. The memory is assigned to the device using the memory-region device tree property and a "shared-dma-pool" reserved memory pool like this: reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; vram: vram@48000000 { compatible = "shared-dma-pool"; reg = <0x48000000 0x00800000>; no-map; }; }; clcd@1f000 { compatible = "arm,pl111", "arm,primecell"; (...) memory-region = <&vram>; }·; Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Mali DP Maintainers <malidp(a)foss.arm.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/gpu/drm/pl111/pl111_drv.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c index b469aa317d9d..e301f2a719a3 100644 --- a/drivers/gpu/drm/pl111/pl111_drv.c +++ b/drivers/gpu/drm/pl111/pl111_drv.c @@ -60,6 +60,7 @@ #include <linux/slab.h> #include <linux/of.h> #include <linux/of_graph.h> +#include <linux/of_reserved_mem.h> #include <drm/drmP.h> #include <drm/drm_atomic_helper.h> @@ -262,6 +263,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev, drm->dev_private = priv; priv->variant = variant; + ret = of_reserved_mem_device_init(dev); + if (!ret) + dev_info(dev, "using device-specific reserved memory\n"); + if (of_property_read_u32(dev->of_node, "max-memory-bandwidth", &priv->memory_bw)) { dev_info(dev, "no max memory bandwidth specified, assume unlimited\n"); -- 2.14.3

2 1

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)
by bugzilla-daemon＠freedesktop.org 07 Mar '18

07 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=104932 Bug ID: 104932 Summary: Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: robink(a)creosotehill.org Created attachment 137158 --> https://bugs.freedesktop.org/attachment.cgi?id=137158&action=edit Kernel serial log while firing up the Awesome WM Hello- I've been having (for a while now, and going back a bit in terms of AMDGPU tree commit history) an issue whereby the framebuffer & graphics stack (*usually* not the kernel writ large) will hang upon firing up XOrg's XServer or a Wayland compositor (in my case, GNOME-Shell). What compounded my frustration was that I'd rarely (if ever) see any output from the Xorg server, the Wayland compositor, or the kernel indicating there was any sort of problem, save for a trapped SIGQUIT (trap3) hitting gnome-shell. Finally, in firing up X11 directly w/ Awesome as the WM I obtained some kernel output which will hopefully prove useful in diagnosing this issue. It's below (and attached): amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00500002 amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A088002 amdgpu 0000:01:00.0: VM fault (0x02, vmid 5, pasid 32768) at page 5242882, read from 'TC6' (0x54433600) (136) [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, last signaled seq=45, last emitted seq=48 [drm] IP block:gfx_v8_0 is hung! [drm] GPU recovery disabled. Doubt it's tremendously useful, but kernel output with gnome-shell (in this case acting as a Wayland compositor) is below and attached as well: traps: gnome-shell[1260] trap int3 ip:7f6e4b956e01 sp:7ffe72a8aa50 error:0 in libglib-2.0.so.0.5200.3[7f6e4b908000+10f000] traps: gnome-shell[1336] trap int3 ip:7f0f89b3ee01 sp:7ffefd8d3df0 error:0 in libglib-2.0.so.0.5200.3[7f0f89af0000+10f000] traps: gnome-shell[1351] trap int3 ip:7f0984cb6e01 sp:7ffd3caa7650 error:0 in libglib-2.0.so.0.5200.3[7f0984c68000+10f000] Lastly, my Xorg.0.log is attached, but you'll find it's quite boring (no complaints, which is good, but seemingly no useful debugging information, either). -- You are receiving this mail because: You are the assignee for the bug.

1 8

[GIT PULL] R-Car DU changes for v4.17
by Laurent Pinchart 07 Mar '18

07 Mar '18

Hi Dave, Please pull the R-Car DU changes for v4.17. This contains - Convert LVDS support to a drm_bridge driver - Add DT bindings for the R8A77995 SoC - Add DT bindings and driver support for the R8A77970 SoC Note that the LVDS conversion depends on a patch series from Frank Rowand that will make it upstream through Rob Herring's tree. Frank has provided a stable branch based on v4.16-rc1 with the patches, and both Rob and I have merged it into our trees. This should thus generate no conflict when reaching -next. The following changes since commit f073d78eeb8efd85718e611c15f9a78647751dea: Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/ drm-intel into drm-next (2018-03-01 14:07:22 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git drm/next/du for you to fetch changes up to 77f59f895da2fe5526073181c74c3fb85a7c80d1: dt-bindings: display: renesas: lvds: Document r8a77995 bindings (2018-03-07 19:30:11 +0200) ---------------------------------------------------------------- Frank Rowand (5): x86: devicetree: fix config option around x86_flattree_get_config() of: change overlay apply input data from unflattened to FDT of: Documentation: of_overlay_apply() replaced by of_overlay_fdt_apply() of: convert unittest overlay devicetree source to sugar syntax of: improve reporting invalid overlay target path Kieran Bingham (2): dt-bindings: display: renesas: du: Document r8a77995 bindings dt-bindings: display: renesas: lvds: Document r8a77995 bindings Laurent Pinchart (5): Merge tag 'overlay_apply_fdt_v7-for-4.17' of git://git.kernel.org/.../ frowand/linux into drm/next/du dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings drm: rcar-du: Fix legacy DT to create LVDS encoder nodes drm: rcar-du: Convert LVDS encoder code to bridge driver Sergei Shtylyov (4): dt-bindings: display: renesas: du: Document R8A77970 bindings dt-bindings: display: renesas: lvds: Document R8A77970 bindings drm: rcar-du: Add R8A77970 support drm: rcar-du: lvds: Add R8A77970 support .../devicetree/bindings/display/bridge/renesas,lvds.txt | 58 +++ .../devicetree/bindings/display/renesas,du.txt | 35 +- Documentation/devicetree/overlay-notes.txt | 4 +- MAINTAINERS | 1 + arch/x86/kernel/devicetree.c | 2 +- drivers/gpu/drm/rcar-du/Kconfig | 6 +- drivers/gpu/drm/rcar-du/Makefile | 10 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 42 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +------- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 ---- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 -- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 ----------- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- drivers/gpu/drm/rcar-du/rcar_du_of.c | 322 +++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_of.h | 20 + drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 76 ++++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c | 540 +++++++++++++++ drivers/of/Kconfig | 1 + drivers/of/overlay.c | 134 +++++- drivers/of/resolver.c | 6 - drivers/of/unittest-data/Makefile | 28 +- drivers/of/unittest-data/overlay.dts | 101 ++--- drivers/of/unittest-data/overlay_0.dts | 14 + drivers/of/unittest-data/overlay_1.dts | 14 + drivers/of/unittest-data/overlay_10.dts | 27 ++ drivers/of/unittest-data/overlay_11.dts | 28 ++ drivers/of/unittest-data/overlay_12.dts | 14 + drivers/of/unittest-data/overlay_13.dts | 14 + drivers/of/unittest-data/overlay_15.dts | 30 ++ drivers/of/unittest-data/overlay_2.dts | 9 + drivers/of/unittest-data/overlay_3.dts | 9 + drivers/of/unittest-data/overlay_4.dts | 18 + drivers/of/unittest-data/overlay_5.dts | 9 + drivers/of/unittest-data/overlay_6.dts | 10 + drivers/of/unittest-data/overlay_7.dts | 10 + drivers/of/unittest-data/overlay_8.dts | 10 + drivers/of/unittest-data/overlay_9.dts | 10 + drivers/of/unittest-data/overlay_bad_phandle.dts | 23 +- drivers/of/unittest-data/overlay_bad_symbol.dts | 25 +- drivers/of/unittest-data/tests-overlay.dtsi | 217 +--------- drivers/of/unittest.c | 300 +++++++------ include/linux/of.h | 6 +- 49 files changed, 1884 insertions(+), 1124 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ renesas,lvds.txt delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c create mode 100644 drivers/of/unittest-data/overlay_0.dts create mode 100644 drivers/of/unittest-data/overlay_1.dts create mode 100644 drivers/of/unittest-data/overlay_10.dts create mode 100644 drivers/of/unittest-data/overlay_11.dts create mode 100644 drivers/of/unittest-data/overlay_12.dts create mode 100644 drivers/of/unittest-data/overlay_13.dts create mode 100644 drivers/of/unittest-data/overlay_15.dts create mode 100644 drivers/of/unittest-data/overlay_2.dts create mode 100644 drivers/of/unittest-data/overlay_3.dts create mode 100644 drivers/of/unittest-data/overlay_4.dts create mode 100644 drivers/of/unittest-data/overlay_5.dts create mode 100644 drivers/of/unittest-data/overlay_6.dts create mode 100644 drivers/of/unittest-data/overlay_7.dts create mode 100644 drivers/of/unittest-data/overlay_8.dts create mode 100644 drivers/of/unittest-data/overlay_9.dts -- Regards, Laurent Pinchart

1 0

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
by Daniel Vetter 07 Mar '18

07 Mar '18

Since this also involves the kernel let's add dri-devel ... On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico <mvicomoya(a)nvidia.com> wrote: > Hi all, > > As many of you already know, I've been working with James Jones on the > Generic Device Allocator project lately. He started a discussion thread > some weeks ago seeking feedback on the current prototype of the library > and advice on how to move all this forward, from a prototype stage to > production. For further reference, see: > > https://lists.freedesktop.org/archives/mesa-dev/2017-November/177632.html > > From the thread above, we came up with very interesting high level > design ideas for one of the currently missing parts in the library: > Usage transitions. That's something I'll personally work on during the > following weeks. > > > In the meantime, I've been working on putting together an open source > implementation of the allocator mechanisms using the Nouveau driver for > all to be able to play with. > > Below I'm seeking feedback on a bunch of changes I had to make to > different components of the graphics stack: > > ** Allocator ** > > An allocator driver implementation on top of Nouveau. The current > implementation only handles pitch linear layouts, but that's enough > to have the kmscube port working using the allocator and Nouveau > drivers. > > You can pull these changes from > > https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/nouveau-driver > > ** Mesa ** > > James's kmscube port to use the allocator relies on the > EXT_external_objects extension to import allocator allocations to > OpenGL as a texture object. However, the Nouveau implementation of > these mechanisms is missing in Mesa, so I went ahead and added them. > > You can pull these changes from > > https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_external_objects-n… > > Also, James's kmscube port uses the NVX_unix_allocator_import > extension to attach allocator metadata to texture objects so the > driver knows how to deal with the imported memory. > > Note that there isn't a formal spec for this extension yet. For now, > it just serves as an experimental mechanism to import allocator > memory in OpenGL, and attach metadata to texture objects. > > You can pull these changes (written on top of the above) from: > > https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_unix_allocator_imp… > > ** kmscube ** > > Mostly minor fixes and improvements on top of James's port to use the > allocator. Main thing is the allocator initialization path will use > EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported > by the underlying EGL implementation. > > You can pull these changes from: > > https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/allocator-nouveau > > > With all the above you should be able to get kmscube working using the > allocator on top of the Nouveau driver. > > > Another of the missing pieces before we can move this to production is > importing allocations to DRM FB objects. This is probably one of the > most sensitive parts of the project as it requires modification/addition > of kernel driver interfaces. > > At XDC2017, James had several hallway conversations with several people > about this, all having different opinions. I'd like to take this > opportunity to also start a discussion about what's the best option to > create a path to get allocator allocations added as DRM FB objects. > > These are the few options we've considered to start with: > > A) Have vendor-private ioctls to set properties on GEM objects that > are inherited by the FB objects. This is how our (NVIDIA) desktop > DRM driver currently works. This would require every vendor to add > their own ioctl to process allocator metadata, but the metadata is > actually a vendor-agnostic object more like DRM modifiers. We'd > like to come up with a vendor-agnostic solutions that can be > integrated to core DRM. > > B) Add a new drmModeAddFBWithMetadata() command that takes allocator > metadata blobs for each plane of the FB. Some people in the > community have mentioned this is their preferred design. This, > however, means we'd have to go through the exercise of adding > another metadata mechanism to the whole graphics stack. > > C) Shove allocator metadata into DRM by defining it to be a separate > plane in the image, and using the existing DRM modifiers mechanism > to indicate there is another plane for each "real" plane added. It > isn't clear how this scales to surfaces that already need several > planes, but there are some people that see this as the only way > forward. Also, we would have to create a separate GEM buffer for > the metadatada itself, which seems excessive. > > We personally like option (B) better, and have already started to > prototype the new path (which is actually very similar to the > drmModeAddFB2() one). You can take a look at the new interfaces here: > > https://github.com/mvicomoya/linux/tree/wip/mvicomoya/drm_addfb_with_metada… > > There may be other options that haven't been explored yet that could be > a better choice than the above, so any suggestion will be greatly > appreciated. What kind of metadata are we talking about here? Addfb has tons of stuff already that's "metadata". The only thing I've spotted is PITCH_ALIGNMENT, which is maybe something we want drm drivers to tell userspace, but definitely not something addfb ever needs. addfb only needs the resulting pitch that we actually allocated (and might decide it doesn't like that, but that's a different issue). And since there's no patches for nouveau itself I can't really say anything beyond that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

10 15

[PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests
by Daniel Stone 07 Mar '18

07 Mar '18

Object and property IDs cannot be zero. Prevent them from being added to the request stream at all, rather than breaking at commit time. Signed-off-by: Daniel Stone <daniels(a)collabora.com> --- xf86drmMode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xf86drmMode.c b/xf86drmMode.c index 15957ffc..bd59ef25 100644 --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -1313,6 +1313,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req, if (!req) return -EINVAL; + if (object_id == 0 || property_id == 0) + return -EINVAL; + if (req->cursor >= req->size_items) { drmModeAtomicReqItemPtr new; -- 2.14.3

3 2

[PATCH v2 2/2] drm: rcar-du: add R8A77970 support
by Sergei Shtylyov 07 Mar '18

07 Mar '18

Add support for the R-Car V3M (R8A77970) SoC to the R-Car DU driver. Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> --- Changes in version 2: - removed the 'model' and 'dpll_ch' field initializers; - fixed up the DU port numbers; - split the DU bindings and the LVDS driver updates into a separate patches; - removed the check before the DPTSR write (to be done in a separate patch). drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c =================================================================== --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -249,6 +249,26 @@ static const struct rcar_du_device_info .dpll_ch = BIT(1), }; +static const struct rcar_du_device_info rcar_du_r8a77970_info = { + .gen = 3, + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK + | RCAR_DU_FEATURE_EXT_CTRL_REGS + | RCAR_DU_FEATURE_VSP1_SOURCE, + .num_crtcs = 1, + .routes = { + /* R8A77970 has one RGB output and one LVDS output. */ + [RCAR_DU_OUTPUT_DPAD0] = { + .possible_crtcs = BIT(0), + .port = 0, + }, + [RCAR_DU_OUTPUT_LVDS0] = { + .possible_crtcs = BIT(0), + .port = 1, + }, + }, + .num_lvds = 1, +}; + static const struct of_device_id rcar_du_of_table[] = { { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info }, { .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info }, @@ -260,6 +280,7 @@ static const struct of_device_id rcar_du { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info }, { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info }, { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info }, + { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info }, { } };

2 1

[PATCH v2 1/2] DT: display: renesas,du: document R8A77970 bindings
by Sergei Shtylyov 07 Mar '18

07 Mar '18

Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings. Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com> --- Changes in version 2: - documented R8A77970 DU ports; - patch split from the main R8A77970 DU support patch. Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ 1 file changed, 2 insertions(+) Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt =================================================================== --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt @@ -13,6 +13,7 @@ Required Properties: - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU + - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU - reg: A list of base address and length of each memory resource, one for each entry in the reg-names property. @@ -63,6 +64,7 @@ corresponding to each DU output. R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0 R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - + R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - Example: R8A7795 (R-Car H3) ES2.0 DU

3 3

Aspirant for GSOC 2018 for Nouveau Vulkan driver
by Anusha Srivastava 07 Mar '18

07 Mar '18

Hi, I would like to participate in GSOC 2018 with Xorg to contribute to project "Initial Nouveau Vulkan driver' I would need some help in how to get started with the same. Regards, Anusha Srivastava

3 4

[RFC][PATCH 00/11] drm: Try to make display info less nuts
by Ville Syrjala 07 Mar '18

07 Mar '18

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Currently the display info is cleared/populated in a very ad-hoc manner. I'd like to make it more robust by making sure it gets cleared by the core forcing drivers to repopulate in .fill_modes(). The bus_formats stuff looks very much ad-hoc all over, so I left that out from consideration for now. The locking around the display info and edid updates looks somewhat busted as well, so I figured I'd sprinkle some lockdep asserts around. That last part probably won't cooperate nicely with amdgpu as they seem to be doing edid updates from the modeset path. So need to think of some way to untangle that mess. Hence this is just an RFC for now. Cc: Alison Wang <alison.wang(a)freescale.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Boris Brezillon <boris.brezillon(a)bootlin.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Eric Anholt <eric(a)anholt.net> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Keith Packard <keithp(a)keithp.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-renesas-soc(a)vger.kernel.org Cc: Manfred Schlaegl <manfred.schlaegl(a)gmx.at> Cc: Marek Vasut <marex(a)denx.de> Cc: Maxime Ripard <maxime.ripard(a)bootlin.com> Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Shashank Sharma <shashank.sharma(a)intel.com> Cc: Stefan Agner <stefan(a)agner.ch> Cc: Thierry Reding <thierry.reding(a)gmail.com> Ville Syrjälä (11): drm/gma500: Fill display_info.{width,height}_mm from .get_modes() drm/i915: Fill display_info.{width,height}_mm from .get_modes() drm/shmobile: Don't fill display_info.{width,height}_mm at init time drm: Split the display info into static and dynamic parts drm/edid: Clear display info fully drm/edid: Don't call drm_add_display_info() with an invalid EDID drm/probe-helper: Avoid iterating the list twice on ww backoff drm: Add drm_connector_fill_modes() drm: Fix getconnector locking drm: Fix debugfs edid_override locking drm: Sprinkle lockdep asserts for edid/display_info drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/drm_connector.c | 70 ++++++++--- drivers/gpu/drm/drm_debugfs.c | 12 +- drivers/gpu/drm/drm_edid.c | 35 +----- drivers/gpu/drm/drm_fb_helper.c | 4 +- drivers/gpu/drm/drm_probe_helper.c | 10 +- drivers/gpu/drm/drm_sysfs.c | 6 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 14 +-- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/intel_dp.c | 15 ++- drivers/gpu/drm/i915/intel_dsi.c | 17 +-- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 11 +- drivers/gpu/drm/i915/intel_sdvo.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c | 4 +- drivers/gpu/drm/imx/parallel-display.c | 2 +- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 6 +- drivers/gpu/drm/panel/panel-arm-versatile.c | 2 +- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 8 +- drivers/gpu/drm/panel/panel-lvds.c | 4 +- .../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 4 +- drivers/gpu/drm/panel/panel-simple.c | 4 +- drivers/gpu/drm/pl111/pl111_display.c | 4 +- drivers/gpu/drm/radeon/radeon_connectors.c | 4 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 - drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +- drivers/gpu/drm/tve200/tve200_display.c | 2 +- drivers/gpu/drm/vc4/vc4_dpi.c | 4 +- include/drm/drm_connector.h | 128 ++++++++++++--------- include/drm/drm_edid.h | 1 - 43 files changed, 227 insertions(+), 185 deletions(-) -- 2.13.6

11 36

[PULL] drm-intel-fixes
by Rodrigo Vivi 07 Mar '18

07 Mar '18

Hi Dave, Fixes for 2 regressions that got captured by CI. Here goes drm-intel-fixes-2018-03-07: - 2 fixes: 1 for perf and 1 execlist submission race. Thanks, Rodrigo. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-07 for you to fetch changes up to 88d3dfb6a69042381161290c7ce19e1f53fc2a66: drm/i915: Suspend submission tasklets around wedging (2018-03-05 16:08:31 -0800) ---------------------------------------------------------------- - 2 fixes: 1 for perf and 1 execlist submission race. ---------------------------------------------------------------- Chris Wilson (1): drm/i915: Suspend submission tasklets around wedging Lionel Landwerlin (1): drm/i915/perf: fix perf stream opening lock drivers/gpu/drm/i915/i915_gem.c | 6 +++++- drivers/gpu/drm/i915/i915_perf.c | 40 +++++++++++++--------------------------- drivers/gpu/drm/i915/intel_lrc.c | 5 +++++ 3 files changed, 23 insertions(+), 28 deletions(-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2018