dri-devel October 2014

dri-devel@lists.freedesktop.org

139 participants
947 discussions

[PATCH] gpu: ipu-v3: Fix IC control register offset
by Philipp Zabel 08 Oct '14

08 Oct '14

The IC register offset is at +0x20000 relative to the control module registers on all IPUv3 versions. This patch fixes wrong values for i.MX51 and i.MX53. Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- drivers/gpu/ipu-v3/ipu-common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c index f707d25..67bab5c 100644 --- a/drivers/gpu/ipu-v3/ipu-common.c +++ b/drivers/gpu/ipu-v3/ipu-common.c @@ -742,7 +742,7 @@ static struct ipu_devtype ipu_type_imx51 = { .tpm_ofs = 0x1f060000, .csi0_ofs = 0x1f030000, .csi1_ofs = 0x1f038000, - .ic_ofs = 0x1f020000, + .ic_ofs = 0x1e020000, .disp0_ofs = 0x1e040000, .disp1_ofs = 0x1e048000, .dc_tmpl_ofs = 0x1f080000, @@ -758,7 +758,7 @@ static struct ipu_devtype ipu_type_imx53 = { .tpm_ofs = 0x07060000, .csi0_ofs = 0x07030000, .csi1_ofs = 0x07038000, - .ic_ofs = 0x07020000, + .ic_ofs = 0x06020000, .disp0_ofs = 0x06040000, .disp1_ofs = 0x06048000, .dc_tmpl_ofs = 0x07080000, -- 2.1.0

1 0

[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

[PATCH] drm: Implement O_NONBLOCK support on /dev/dri/cardN
by Chris Wilson 08 Oct '14

08 Oct '14

The implmentation is simple in the extreme: we only want to wait for events if the device was opened in blocking mode, otherwise we grab what is available and report an error if there was none. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/drm_fops.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index ed7bc68f7e87..91e1105f2800 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -515,10 +515,12 @@ ssize_t drm_read(struct file *filp, char __user *buffer, size_t total; ssize_t ret; - ret = wait_event_interruptible(file_priv->event_wait, - !list_empty(&file_priv->event_list)); - if (ret < 0) - return ret; + if ((filp->f_flags & O_NONBLOCK) == 0) { + ret = wait_event_interruptible(file_priv->event_wait, + !list_empty(&file_priv->event_list)); + if (ret < 0) + return ret; + } total = 0; while (drm_dequeue_event(file_priv, total, count, &e)) { @@ -532,7 +534,7 @@ ssize_t drm_read(struct file *filp, char __user *buffer, e->destroy(e); } - return total; + return total ?: -EAGAIN; } EXPORT_SYMBOL(drm_read); -- 2.1.1

3 4

[PATCH v7 00/11] drm: add support for Atmel HLCDC Display Controller
by Boris Brezillon 08 Oct '14

08 Oct '14

Hello, This series is being sent for several weeks now and I wonder if I shouldn't split it in several pieces: 1) the MFD driver + its DT doc 2) the PWM driver + its DT doc 3) the DRM/KMS driver + its DT doc 4) support for sama5d3 SoCs/boards The first reason for doing this is that Lee already accepted the MFD part, and I'm pretty sure he'd like me to stop sending him each new version of this series. The second reason being that smaller series are more likely to be reviewed by subsystem maintainers :-). Lee, if you still agree with this version, could you take the MTD part (other drivers in this series depend on it). Here is the usal description of the patch series :-) : This patch series adds support for the Atmel HLCDC block (HLCD Controller) available on some Atmel SoCs (i.e. the sama5d3 family). The HLCDC actually provides a Display Controller and a PWM device, hence I decided to declare an MFD device exposing 2 subdevices: a display controller and a PWM chip. This also solves a circular dependency issue preventing HLCDC driver from unloading. The HLCDC request a drm_panel device, which request a backlight device (a PWM backlight), which depends on a PWM which is provided by the HLCDC driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)). The current implementation only supports sama5d3 SoCs but other SoCs should be easily ported by defining new compatible strings and adding HLCDC description structures for these SoCs (Ludovic tested this driver on an at91sam9x5 board). The drivers supports basic CRTC functionalities, several overlays and an hardware cursor. At the moment, it only supports connection to LCD panels through an RGB connector (defined as an LVDS connector in my implementation), though connection to other kind of devices (like DRM bridges) could be added later. It also supports several RGB formats on all planes and some YUV formats on the HEO overlay plane. This series depends on those ones: [1], [2] and [3]. Best Regards, Boris [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html [2]https://lkml.org/lkml/2014/9/29/330 [3]https://lkml.org/lkml/2014/9/22/575 Changes since v7: - move interrupts property from hlcdc display controller node to its parent node (the MFD device) - add mode_set_base implementation - rework page flip handling to rely on vblank events instead of DMA transfer events (the end of a DMA transfer does not mean the frame is actually flipped: data are first copied to an output FIFO before being sent on the RGB/DPI connector) - few minor coding style fixes Changes since v5: - fix Kconfig dependency bug - use adjusted mode in crtc config - move signal config (clk, hsync, vsync) from connector to crtc mode_set function - use standard rotation property - check display_mode validity in connecto mode_valid function - remove dma_set_coherent mask call (now done in MFD core) - do not use drm_platform_init Changes since v4: - fix a few more bugs in rotation handling (rotation was buggy on some formats) - return connector_status_unknown until a panel is exposed by the drm_panel infrastructure (prevent fbdev creation until everyting is in place) - rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration (automatically select this option when selecting the HLCDC PMW or DRM driver, instead of depending on this option) Changes since v3: - rework the layer code to simplify several parts (locking and layer disabling) - make use of the drm_flip_work infrastructure - rely on default HW cursor implementation using on the cursor plane - rework the display controller DT bindings (based on OF graph representation) - add rotation support - retrive RGB bus format from drm_display_info - drop the dynamic pinctrl state selection - rework HLCDC output handling (previously specialized to interface with LCD panels) - drop ".module = THIS_MODULE" lines - change display controller compatible string Changes since v2: - fix coding style issues (macro indentation) - make use of GENMASK in several places - declare regmap config as a static structure - rework hlcdc plane update API - rework cursor handling to make use of the new plane update API - fix backporch config - do not use devm_regmap_init_mmio_clk to avoid extra clk_enable clk disable calls when accessing registers - explicitely include regmap and clk headers instead of relying on atmel-hlcdc.h inclusions - make the atmel-hlcdc driver depends on CONFIG_OF - separate DT bindings documentation from driver implementation - support several pin muxing for HLCDC pins on sama5d3 SoCs Changes since v1: - replace the backlight driver by a PWM driver - make use of drm_panel infrastructure - split driver code in several subsystem: MFD, PWM and DRM - add support for overlays - add support for hardware cursor Boris BREZILLON (10): mfd: add documentation for atmel-hlcdc DT bindings pwm: add support for atmel-hlcdc-pwm device pwm: add DT bindings documentation for atmel-hlcdc-pwm driver drm: add Atmel HLCDC Display Controller support drm: add DT bindings documentation for atmel-hlcdc-dc driver ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi ARM: at91/dt: enable the LCD panel on sama5d3xek boards Boris BREZILLON (10): mfd: add documentation for atmel-hlcdc DT bindings pwm: add support for atmel-hlcdc-pwm device pwm: add DT bindings documentation for atmel-hlcdc-pwm driver drm: add Atmel HLCDC Display Controller support drm: add DT bindings documentation for atmel-hlcdc-dc driver ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi ARM: at91/dt: enable the LCD panel on sama5d3xek boards Boris Brezillon (1): mfd: add atmel-hlcdc driver .../devicetree/bindings/drm/atmel-hlcdc-dc.txt | 53 ++ .../devicetree/bindings/mfd/atmel-hlcdc.txt | 51 ++ .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt | 55 ++ arch/arm/boot/dts/sama5d31ek.dts | 20 + arch/arm/boot/dts/sama5d33ek.dts | 20 + arch/arm/boot/dts/sama5d34ek.dts | 20 + arch/arm/boot/dts/sama5d36ek.dts | 20 + arch/arm/boot/dts/sama5d3_lcd.dtsi | 205 ++++- arch/arm/boot/dts/sama5d3xdm.dtsi | 58 ++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/atmel-hlcdc/Kconfig | 13 + drivers/gpu/drm/atmel-hlcdc/Makefile | 7 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 390 ++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 531 +++++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 216 ++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 638 ++++++++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 394 ++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 443 +++++++++++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 831 +++++++++++++++++++++ drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 1 + drivers/mfd/atmel-hlcdc.c | 122 +++ drivers/pwm/Kconfig | 10 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-atmel-hlcdc.c | 229 ++++++ include/linux/mfd/atmel-hlcdc.h | 85 +++ 27 files changed, 4391 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c create mode 100644 drivers/mfd/atmel-hlcdc.c create mode 100644 drivers/pwm/pwm-atmel-hlcdc.c create mode 100644 include/linux/mfd/atmel-hlcdc.h -- 1.9.1

4 36

[PATCH v10 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. Changes in v10: Adviced by Andrzej Hajda - check drm_dev if it's NULL at PM suspend/resume Adviced by Sean Paul - use drm_fb_helper_prepare to init fb_helper funcs - Optimized code structure and remove some unnecessary Variables. 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 | 465 +++++++ drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 55 + 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 | 210 +++ 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 | 1415 ++++++++++++++++++++ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++ 16 files changed, 3042 insertions(+) -- 1.7.9.5

2 4

[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/ast: Fix HW cursor image
by Benjamin Herrenschmidt 08 Oct '14

08 Oct '14

The translation from the X driver to the KMS one typo'ed a couple of array indices, causing the HW cursor to look weird (blocky with leaking edge colors). This fixes it. Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> --- diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 19ada0b..9dc0fd5 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -1104,8 +1104,8 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height) srcdata32[1].ul = *((u32 *)(srcxor + 4)) & 0xf0f0f0f0; data32.b[0] = srcdata32[0].b[1] | (srcdata32[0].b[0] >> 4); data32.b[1] = srcdata32[0].b[3] | (srcdata32[0].b[2] >> 4); - data32.b[2] = srcdata32[0].b[1] | (srcdata32[1].b[0] >> 4); - data32.b[3] = srcdata32[0].b[3] | (srcdata32[1].b[2] >> 4); + data32.b[2] = srcdata32[1].b[1] | (srcdata32[1].b[0] >> 4); + data32.b[3] = srcdata32[1].b[3] | (srcdata32[1].b[2] >> 4); writel(data32.ul, dstxor); csum += data32.ul;

2 1

[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

[Bug 71051] Cannot suspend with radeon drivers.
by bugzilla-daemon＠bugzilla.kernel.org 07 Oct '14

07 Oct '14

https://bugzilla.kernel.org/show_bug.cgi?id=71051 --- Comment #14 from Hin-Tak Leung <htl10(a)users.sourceforge.net> --- (In reply to Hin-Tak Leung from comment #13) ... attachment 150801 [details] going > upstream ... cik_ring_test/radeon_dp_link_train_cr > error issue looked at. To answer my own question, attachment 150801 is in 3.17-rcX, so will be in 3.17 proper ; my suspend problem is no-more. I've a problem with GPU lock-up under stress, filed as Bug 85421 . -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

← Newer
1
...
88
89
90
91
92
93
94
95
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2014