dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[Bug 81391] New: nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000020f000 [PTE] from BAR1/HOST_CPU on channel 0x00ffbdf000 [unknown]
by bugzilla-daemon＠bugzilla.kernel.org 12 Oct '14

12 Oct '14

https://bugzilla.kernel.org/show_bug.cgi?id=81391 Bug ID: 81391 Summary: nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000020f000 [PTE] from BAR1/HOST_CPU on channel 0x00ffbdf000 [unknown] Product: Drivers Version: 2.5 Kernel Version: 3.16.0-rc7 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: linux.bug.reporting(a)gmail.com Regression: No Created attachment 144731 --> https://bugzilla.kernel.org/attachment.cgi?id=144731&action=edit kernel boot up messages extracted from syslog (/var/log/messages) The error message displayed on the subject line floods the kernel log buffer: nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000020f000 [PTE] from BAR1/HOST_CPU on channel 0x00ffbdf000 [unknown] ... [ 33.807019] systemd-journald[550]: /dev/kmsg buffer overrun, some messages lost. All of the useful messages I could extract out of syslog (/var/log/messages) based on the kernel boot up time stamp is attached to this report. I've also provided lspci -vvv & my .config as well. I was however pleasantly surprised that the X.org & KDE did come up & appear to be functioning fine, even including glxgears running smoothly as well. Thank you for progressing Nouveau so far, so quickly & so nicely. And am happy to test any patch you may want me to. -- You are receiving this mail because: You are watching the assignee of the bug.

1 3

[Bug 82050] New: R9270X pyrit benchmark perf regressions with latest kernel/llvm
by bugzilla-daemon＠freedesktop.org 10 Oct '14

10 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=82050 Priority: medium Bug ID: 82050 Assignee: dri-devel(a)lists.freedesktop.org Summary: R9270X pyrit benchmark perf regressions with latest kernel/llvm Severity: normal Classification: Unclassified OS: All Reporter: adf.lists(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Don't really have time to bisect this but posting FYI. Maybe pyrit benchmark is the glxgears of benchmarks - if so please say so and I'll ignore it :-) Status Que for my R9 270X pyrit 0.3.0 since I got it in May has been around - Computed 75761.96 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 73256.9 PMKs/s (RTT 0.8) #2: 'CPU-Core (SSE2)': 743.3 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 741.3 PMKs/s (RTT 2.8) #4: 'CPU-Core (SSE2)': 740.2 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) This was kernel agd5f drm-fixes-3.16-wip I noticed yesterday after trying agd5f drm-next-3.17-rebased-on-fixes that I lost around 10,000 PMKs/s with the newer kernel. Both were with yesterdays mesa but llvm was older say a couple of weeks. Updated llvm and mesa today and it's regressed more on both kernels - drm-fixes-3.16-wip Computed 58233.89 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 56076.6 PMKs/s (RTT 1.1) #2: 'CPU-Core (SSE2)': 753.6 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 754.5 PMKs/s (RTT 2.9) #4: 'CPU-Core (SSE2)': 753.0 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) drm-next-3.17-rebased-on-fixes Computed 52379.38 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 48822.1 PMKs/s (RTT 1.2) #2: 'CPU-Core (SSE2)': 753.8 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 754.9 PMKs/s (RTT 3.0) #4: 'CPU-Core (SSE2)': 754.8 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) -- You are receiving this mail because: You are the assignee for the bug.

1 80

[Bug 81546] New: Radeon 7990: Output of most applications garbled, Gnome shell mosly fine
by bugzilla-daemon＠freedesktop.org 10 Oct '14

10 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=81546 Priority: medium Bug ID: 81546 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon 7990: Output of most applications garbled, Gnome shell mosly fine Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mail(a)marcelschaal.de Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 103116 --> https://bugs.freedesktop.org/attachment.cgi?id=103116&action=edit Screenshot of Gnome shell Please have a look at the screenshots. Rendering of most windows is totally garbled including window decoration. This is not about Crossfire/SLI/Multi GPU rendering, just plain single GPU. Gnome-shell's own rendering is mostly fine. Panel, lock screen animations, menus and dashboard don't show distortions. KDE's/Kwin is worse, even the panel's are broken, but it's able to draw window decorations. glxgears's rendering is fine. Linux console (no X11) is also fine. Hardware: PowerColor AX7990 6GBD5-2DHJ, which is one of those fake 7990s that actually use 2x7970 Tahiti XT on a single PCB and not 2x Malta. Other GPUs (6950/7950) were working fine with that system. Software: Fedora 19/20 (From stock LiveCD image to current updates incl. Kernel 3.15.4) There were no (drawing!) issues when I was using catalyst. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 53971] New: radeon:Soft reset GPU in StarCraft2 under Wine
by bugzilla-daemon＠bugzilla.kernel.org 09 Oct '14

09 Oct '14

https://bugzilla.kernel.org/show_bug.cgi?id=53971 Summary: radeon:Soft reset GPU in StarCraft2 under Wine Product: Drivers Version: 2.5 Kernel Version: 3.8.0-rc7 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: stalkerg(a)gmail.com Regression: No Random GPU resets and freeze on Radeon 6770 with SC2 game under wine 1.5.23 (GLSL disable, pbuffer enable). Linux sagita 3.8.0-rc7 #1 SMP PREEMPT Sat Feb 16 18:13:51 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux Mesa 9.2-devel (git-f1ab67c) radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec radeon 0000:01:00.0: GPU lockup (waiting for 0x000000000002236b last fence id 0x000000000002235e) radeon 0000:01:00.0: Saved 407 dwords of commands on ring 0. radeon 0000:01:00.0: GPU softreset: 0x00000003 radeon 0000:01:00.0: GRBM_STATUS = 0xE4002CA4 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0xC0000005 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x04000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00040000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00048402 radeon 0000:01:00.0: R_008680_CP_STAT = 0x80860243 radeon 0000:01:00.0: GRBM_SOFT_RESET=0x00007F6B radeon 0000:01:00.0: GRBM_STATUS = 0x00003828 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 radeon 0000:01:00.0: GPU reset succeeded, trying to resume [drm] probing gen 2 caps for device 1002:5a16 = 2/0 [drm] PCIE gen 2 link speeds already enabled [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802321edc00 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8802321edc0c [drm] ring test on 0 succeeded in 3 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 1 usecs -- 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 1

[PATCH 1/2] drm/tegra: Set the dsi lp clk parent and rate
by Sean Paul 08 Oct '14

08 Oct '14

Per NVidia, this clock rate should be around 70MHz in order to properly sample reads on data lane 0. In order to achieve this rate, we need to reparent the clock from clk_m which can only achieve 12MHz. Add parent_lp to the dts bindings and set the parent & rate on init. Signed-off-by: Sean Paul <seanpaul(a)chromium.org> --- .../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 10 ++++++++-- drivers/gpu/drm/tegra/dsi.c | 18 ++++++++++++++++++ drivers/gpu/drm/tegra/dsi.h | 3 +++ 3 files changed, 29 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index b48f4ef..fef2918 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -191,6 +191,10 @@ of the following host1x client modules: - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel + - clock-names: Can include the following entries: + - lp_parent: The parent clock for lp + - clocks: Must contain an entry for each optional entry in clock-names. + See ../clocks/clock-bindings.txt for details. - sor: serial output resource @@ -360,8 +364,10 @@ Example: compatible = "nvidia,tegra20-dsi"; reg = <0x54300000 0x00040000>; clocks = <&tegra_car TEGRA20_CLK_DSI>, - <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; - clock-names = "dsi", "parent"; + <&tegra_car TEGRA124_CLK_DSIALP>, + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>, + <&tegra_car TEGRA124_CLK_PLL_P>; + clock-names = "dsi", "lp", "parent", "lp_parent"; resets = <&tegra_car 48>; reset-names = "dsi"; status = "disabled"; diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index f787445..c0258ae 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -837,6 +837,7 @@ static int tegra_dsi_probe(struct platform_device *pdev) struct tegra_dsi *dsi; struct resource *regs; int err; + struct clk *lp_parent; dsi = devm_kzalloc(&pdev->dev, sizeof(*dsi), GFP_KERNEL); if (!dsi) @@ -879,6 +880,23 @@ static int tegra_dsi_probe(struct platform_device *pdev) return PTR_ERR(dsi->clk_lp); } + lp_parent = devm_clk_get(&pdev->dev, "lp_parent"); + if (!IS_ERR(lp_parent)) { + err = clk_set_parent(dsi->clk_lp, lp_parent); + if (err < 0) { + dev_err(&pdev->dev, "cannot set lp clock parent\n"); + return err; + } + } else { + dev_info(&pdev->dev, "no lp clock parent, using hw default\n"); + } + + err = clk_set_rate(dsi->clk_lp, DSI_LP_CLK_RATE); + if (err < 0) { + dev_err(&pdev->dev, "cannot set low-power clock rate\n"); + return err; + } + err = clk_prepare_enable(dsi->clk_lp); if (err < 0) { dev_err(&pdev->dev, "cannot enable low-power clock\n"); diff --git a/drivers/gpu/drm/tegra/dsi.h b/drivers/gpu/drm/tegra/dsi.h index 5ce610d..a332caf 100644 --- a/drivers/gpu/drm/tegra/dsi.h +++ b/drivers/gpu/drm/tegra/dsi.h @@ -127,4 +127,7 @@ enum tegra_dsi_format { TEGRA_DSI_FORMAT_24P, }; +/* default lp clock rate */ +#define DSI_LP_CLK_RATE (70 * 1000 * 1000) + #endif -- 2.0.0

7 11

[PATCH v9 0/3] Add drm driver for Rockchip Socs
by Mark Yao 08 Oct '14

08 Oct '14

This a series of patches is a DRM Driver for Rockchip Socs, add support for vop devices. Future patches will add additional encoders/connectors, such as eDP, HDMI. The basic "crtc" for rockchip is a "VOP" - Video Output Processor. the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar Vop devices. Vop devices support iommu mapping, we use dma-mapping API with ARM_DMA_USE_IOMMU. Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master device and each vop device can shared the drm dma mapping. - use drm_crtc_init_with_planes and drm_universal_plane_init. - remove unnecessary middle layers. - add cursor set, move funcs to rockchip drm crtc. - add vop reset. Changes in v3: - change "crtc->fb" to "crtc->primary-fb" Adviced by Daniel Vetter - init cursor plane with universal api, remove unnecessary cursor set,move Changes in v4: Adviced by David Herrmann - remove drm_platform_*() usage, use register drm device directly. Adviced by Rob Clark - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset Changes in v5: Adviced by Arnd Bergmann - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark - fix some incorrect dependencies. Adviced by Boris BREZILLON - fix some mistake and bugs. Adviced by Daniel Vetter - drop all special ioctl and use generic kms ioctl instead. Adviced by Rob Clark - use unlocked api for drm_fb_helper_restore_fbdev_mode. - remove unused rockchip_gem_prime_import_sg_table. Changes in v6: - set gem buffer pitch 64 bytes align, needed by mali gpu. Adviced by Daniel Kurtz - fix some mistake, bugs, remove unused define, more better code style etc. - use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable() at runtime instead of clk_prepare_enable(). - provide a help function from vop for encoder to do mode config, instead of using drm_diaplay_mode private method. - change vop mode_set timing to make it more safely. Changes in v7: - fix memory leakage problem. Changes in v8: - fix iommu crash when use dual crtc. - use frame start interrupt for vsync instead of line flag interrupt, because the win config take affect at frame start time, if we use ling flag interrupt, the address check often failed. Adviced by Daniel Kurtz - fix some bugs, mistake, remove unused function - keep clock and vop disabled when probe end - use drm_plane_helper_check_update to check update_plane if vaild Changes in v9: - fix suspend and resume bug, make iommu attach and detach safely. - fix mail info style. Mark yao (3): drm: rockchip: Add basic drm driver dt-bindings: video: Add for rockchip display subsytem dt-bindings: video: Add documentation for rockchip vop .../devicetree/bindings/video/rockchip-drm.txt | 19 + .../devicetree/bindings/video/rockchip-vop.txt | 58 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/rockchip/Kconfig | 17 + drivers/gpu/drm/rockchip/Makefile | 8 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 509 +++++++ drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 65 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++ drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 + drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 209 +++ drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 294 ++++ drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1423 ++++++++++++++++++++ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++ 16 files changed, 3103 insertions(+) -- 1.7.9.5

4 9

[PULL] topic/vblank-rework, take 2
by Daniel Vetter 08 Oct '14

08 Oct '14

Hi Dave, So updated vblank-rework pull request, now with the polish that Mario requested applied (and reviewed by him). Also with backmerge like you've requested for easier merging. The neat thing this finally allows is to immediately disable the vblank interrupt on the last drm_vblank_put if the hardware has perfectly accurate vblank counter and timestamp readout support. On i915 that required piles of small adjustements from Ville since depending upon the platform and port the vblank happens at different scanout lines. Of course this is fully opt-in and per-device (we need that since gen2 doesn't have a hw vblank counter). Cheers, Daniel The following changes since commit fdcaa1dbb7c6ed419b10fb8cdb5001ab0a00538f: Merge tag 'ipu-3.18' of git://git.pengutronix.de/git/pza/linux into drm-next (2014-09-10 19:43:29 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/vblank-rework-2014-09-12 for you to fetch changes up to 336879b1da97fffc097f77c6d6f818660f2826f0: Merge remote-tracking branch 'airlied/drm-next' into topic/vblank-rework (2014-09-11 14:46:53 +0200) ---------------------------------------------------------------- Daniel Vetter (5): drm: Really never disable vblank irqs for offdelay==0 drm: Only update final vblank count when precise ts is available drm: Simplify return value of drm_get_last_vbltimestamp drm: Clarify vblank ts/scanoutpos sampling #defines Merge remote-tracking branch 'airlied/drm-next' into topic/vblank-rework Mario Kleiner (2): drm: Remove drm_vblank_cleanup from drm_vblank_init error path. drm: Use vblank_disable_and_save in drm_vblank_cleanup() Ville Syrjälä (16): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm: Don't clear vblank timestamps when vblank interrupt is disabled drm: Move drm_update_vblank_count() drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off() drm: Avoid random vblank counter jumps if the hardware counter has been reset drm: Reduce the amount of dev->vblank[crtc] in the code drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock drm: Fix race between drm_vblank_off() and drm_queue_vblank_event() drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0 drm: Add dev->vblank_disable_immediate flag drm/i915: Opt out of vblank disable timer on >gen2 drm: Kick start vblank interrupts at drm_vblank_on() drm/i915: Update scanline_offset only for active crtcs drm: Fix confusing debug message in drm_update_vblank_count() drm: Store the vblank timestamp when adjusting the counter during disable Documentation/DocBook/drm.tmpl | 7 + drivers/gpu/drm/drm_drv.c | 4 +- drivers/gpu/drm/drm_irq.c | 379 +++++++++++++++++++----------- drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/intel_display.c | 17 +- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/gpu/drm/radeon/radeon_pm.c | 2 +- include/drm/drmP.h | 18 +- 9 files changed, 286 insertions(+), 155 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

[RFC] Explicit synchronization for Nouveau
by Lauri Peltonen 08 Oct '14

08 Oct '14

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes and emits fences to/from user space when submitting work Implicit synchronization is already implemented in open source drivers, and works well for most use cases. I don't seek to change any of that. My proposal aims at allowing some drm drivers to operate in explicit sync mode to get maximal performance, while still remaining fully compatible with the implicit paradigm. I will try to explain why I think we should support the explicit model as well. 1. Bindless graphics Bindless graphics is a central concept when trying to reduce the OpenGL driver overhead. The idea is that the application can bind a large set of buffers to the working set up front using extensions such as GL_ARB_bindless_texture, and they remain resident until the application releases them (note that compute APIs have typically similar semantics). These working sets can be huge, hundreds or even thousands of buffers, so we would like to opt out from the per-submit overhead of acquiring locks, waiting for fences, and storing fences. Automatically synchronizing these working sets in kernel will also prevent parallelism between channels that are sharing the working set (in fact sharing just one buffer from the working set will cause the jobs of the two channels to be serialized). 2. Evolution of graphics APIs The graphics API evolution seems to be going to a direction where game engine and middleware vendors demand more control over work submission and synchronization. We expect that this trend will continue, and more and more synchronization decisions will be pushed to the API level. OpenGL and EGL already provide good explicit command stream level synchronization primitives: glFenceSync and EGL_KHR_wait_sync. Their use is also encouraged - for example EGL_KHR_image_base spec clearly states that the application is responsible for synchronizing accesses to EGLImages. If the API that is exposed to developers gives the control over synchronization to the developer, then implicit waits that are inserted by the kernel are unnecessary and unexpected, and can severely hurt performance. It also makes it easy for the developer to write code that happens to work on Linux because of implicit sync, but will fail on other platforms. 3. Suballocation Using user space suballocation can help reduce the overhead when a large number of small textures are used. Synchronizing suballocated surfaces implicitly in kernel doesn't make sense - many channels should be able to access the same kernel-level buffer object simultaneously. 4. Buffer sharing complications This is not really an argument for explicit sync as such, but I'd like to point out that sharing buffers across SoC engines is often much more complex than just exporting and importing a dma-buf and waiting for the dma-buf fences. Sometimes we need to do color format or tiling layout conversion. Sometimes, at least on Tegra, we need to decompress buffers when we pass them from the GPU to an engine that doesn't support framebuffer compression. These things are not uncommon, particularly when we have SoC's that combine licensed IP blocks from different vendors. My point is that user space is already heavily involved when sharing buffers between drivers, and giving it some more control over synchronization is not adding that much complexity. Because of the above arguments, I think it makes sense to let some user space drm drivers opt out from implicit synchronization, while allowing them to still remain fully compatible with the rest of the drm world that uses implicit synchronization. In practice, this would require three things: (1) Support passing fences (that are not tied to buffer objects) between kernel and user space. (2) Stop automatically storing fences to the buffers that user space wants to synchronize explicitly. (3) Allow user space to attach an explicit fence to dma-buf when exporting to another driver that uses implicit sync. There are still some open issues beyond these. For example, can we skip acquiring the ww mutex for explicitly synchronized buffers? I think we could eventually, at least on unified memory systems where we don't need to migrate between heaps (our downstream Tegra GPU driver does not lock any buffers at submit, it just grabs refcounts for hw). Another quirk is that now Nouveau waits on the buffer fences when closing the gem object to ensure that it doesn't unmap too early. We need to rework that for explicit sync, but that shouldn't be difficult. I have written a prototype that demonstrates (1) by adding explicit sync fd support to Nouveau. It's not a lot of code, because I only use a relatively small subset of the android sync driver functionality. Thanks to Maarten's rewrite, all I need to do is to allow creating a sync_fence from a drm fence in order to pass it to user space. I don't need to use sync_pt or sync_timeline, or fill in sync_timeline_ops. I can see why the upstream has been reluctant to de-stage the android sync driver in its current form, since (even though it now builds on struct fence) it still duplicates some of the drm fence concepts. I'd like to think that my patches only use the parts of the android sync driver that genuinely are missing from the drm fence model: allowing user space to operate on fence objects that are independent of buffer objects. The last two patches are mocks that show how (2) and (3) might work out. I haven't done any testing with them yet. Before going any further, I'd like to get your feedback. Can you see the benefits of explicit sync as an alternative synchronization model? Do you think we could use the android sync_fence for passing fences between user space? Or did you have something else in mind for explicit sync in the drm world? Thanks, Lauri Lauri Peltonen (7): android: Support creating sync fence from drm fences drm/nouveau: Split nouveau_fence_sync drm/nouveau: Add fence fd helpers drm/nouveau: Support fence fd's at kickoff libdrm: nouveau: Support fence fds drm/nouveau: Support marking buffers for explicit sync drm/prime: Support explicit fence on export -- 1.8.1.5

6 25

[PATCH] drm/exynos: init vblank with real number of crtcs
by Andrzej Hajda 08 Oct '14

08 Oct '14

Initialization of vblank with MAX_CRTC caused attempts to disabling vblanks for non-existing crtcs in case drm used fewer crtcs. The patch fixes it. Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 9b00e4e..dc4affd 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) /* init kms poll for handling hpd */ drm_kms_helper_poll_init(dev); - ret = drm_vblank_init(dev, MAX_CRTC); - if (ret) - goto err_mode_config_cleanup; - /* setup possible_clones. */ exynos_drm_encoder_setup(dev); @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) /* Try to bind all sub drivers. */ ret = component_bind_all(dev->dev, dev); if (ret) - goto err_cleanup_vblank; + goto err_mode_config_cleanup; + + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); + if (ret) + goto err_unbind_all; /* Probe non kms sub drivers and virtual display driver. */ ret = exynos_drm_device_subdrv_probe(dev); if (ret) - goto err_unbind_all; + goto err_cleanup_vblank; /* force connectors detection */ drm_helper_hpd_irq_event(dev); return 0; -err_unbind_all: - component_unbind_all(dev->dev, dev); err_cleanup_vblank: drm_vblank_cleanup(dev); +err_unbind_all: + component_unbind_all(dev->dev, dev); err_mode_config_cleanup: drm_mode_config_cleanup(dev); drm_release_iommu_mapping(dev); @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev) exynos_drm_fbdev_fini(dev); drm_kms_helper_poll_fini(dev); - component_unbind_all(dev->dev, dev); drm_vblank_cleanup(dev); + component_unbind_all(dev->dev, dev); drm_mode_config_cleanup(dev); drm_release_iommu_mapping(dev); -- 1.9.1

3 4

[PATCH] drm/exynos: remove explicit encoder/connector de-initialization
by Andrzej Hajda 07 Oct '14

07 Oct '14

All KMS objects are destroyed by drm_mode_config_cleanup in proper order so component drivers should not care about it. Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> --- Hi Inki, This is another spin-off of exynos_drm tests regarding your component support update. The patch is based as usual on the latest exynos-drm-next branch. Regards Andrzej --- drivers/gpu/drm/exynos/exynos_dp_core.c | 5 ----- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 ---- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ---- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 --- drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ------ 5 files changed, 22 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index cd50ece..6adb1e5 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1355,13 +1355,8 @@ static void exynos_dp_unbind(struct device *dev, struct device *master, void *data) { struct exynos_drm_display *display = dev_get_drvdata(dev); - struct exynos_dp_device *dp = display->ctx; - struct drm_encoder *encoder = dp->encoder; exynos_dp_dpms(display, DRM_MODE_DPMS_OFF); - - exynos_dp_connector_destroy(&dp->connector); - encoder->funcs->destroy(encoder); } static const struct component_ops exynos_dp_ops = { diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index 96c87db..3dc678e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -338,14 +338,10 @@ err_del_component: int exynos_dpi_remove(struct device *dev) { - struct drm_encoder *encoder = exynos_dpi_display.encoder; struct exynos_dpi *ctx = exynos_dpi_display.ctx; exynos_dpi_dpms(&exynos_dpi_display, DRM_MODE_DPMS_OFF); - exynos_dpi_connector_destroy(&ctx->connector); - encoder->funcs->destroy(encoder); - if (ctx->panel) drm_panel_detach(ctx->panel); diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 24741d8..acf7e9e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -1660,13 +1660,9 @@ static void exynos_dsi_unbind(struct device *dev, struct device *master, void *data) { struct exynos_dsi *dsi = exynos_dsi_display.ctx; - struct drm_encoder *encoder = dsi->encoder; exynos_dsi_dpms(&exynos_dsi_display, DRM_MODE_DPMS_OFF); - exynos_dsi_connector_destroy(&dsi->connector); - encoder->funcs->destroy(encoder); - mipi_dsi_host_unregister(&dsi->dsi_host); } diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index d565207..9395e85 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -639,9 +639,6 @@ static int vidi_remove(struct platform_device *pdev) return -EINVAL; } - encoder->funcs->destroy(encoder); - drm_connector_cleanup(&ctx->connector); - return 0; } diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 7910fb3..563a19e 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2312,12 +2312,6 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data) static void hdmi_unbind(struct device *dev, struct device *master, void *data) { - struct exynos_drm_display *display = get_hdmi_display(dev); - struct drm_encoder *encoder = display->encoder; - struct hdmi_context *hdata = display->ctx; - - hdmi_connector_destroy(&hdata->connector); - encoder->funcs->destroy(encoder); } static const struct component_ops hdmi_component_ops = { -- 1.9.1

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014