[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails
Matt Turner writes: > Reviewed-by: Matt Turner > > Should we add a Cc: for the stable branch? Also seems like a good plan. I've added that and pushed. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 810 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/3203225b/attachment.sig>
[PATCH v9 3/3] dt-bindings: video: Add documentation for rockchip vop
From: Mark yao This adds binding documentation for Rockchip SoC VOP driver. Signed-off-by: Mark Yao --- Changes in v2: - rename "lcdc" to "vop" - add vop reset - add iommu node - add port for display-subsystem Changes in v3: None Changes in v4: None Changes in v5: None Changes in v6: None Changes in v7: None Changes in v8: None Changes in v9: None .../devicetree/bindings/video/rockchip-vop.txt | 58 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt b/Documentation/devicetree/bindings/video/rockchip-vop.txt new file mode 100644 index 000..d15351f --- /dev/null +++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt @@ -0,0 +1,58 @@ +device-tree bindings for rockchip soc display controller (vop) + +VOP (Visual Output Processor) is the Display Controller for the Rockchip +series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be one of the following + "rockchip,rk3288-vop"; + +- interrupts: should contain a list of all VOP IP block interrupts in the +order: VSYNC, LCD_SYSTEM. The interrupt specifier +format depends on the interrupt controller used. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: Must contain + aclk_vop: for ddr buffer transfer. + hclk_vop: for ahb bus to R/W the phy regs. + dclk_vop: pixel clock. + +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - axi + - ahb + - dclk + +- iommus: required a iommu node + +- port: A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: +SoC specific DT entry: + vopb: vopb at ff93 { + compatible = "rockchip,rk3288-vop"; + reg = <0xff93 0x19c>; + interrupts = ; + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_edp: endpoint at 0 { + reg = <0>; + remote-endpoint=<&edp_in_vopb>; + }; + vopb_out_hdmi: endpoint at 1 { + reg = <1>; + remote-endpoint=<&hdmi_in_vopb>; + }; + }; + }; -- 1.7.9.5
[PATCH v9 2/3] dt-bindings: video: Add for rockchip display subsytem
From: Mark yao This add a display subsystem comprise the all display interface nodes. Signed-off-by: Mark Yao --- Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. Changes in v3: None Changes in v4: None Changes in v5: None Changes in v6: None Changes in v7: None Changes in v8: None Changes in v9: None .../devicetree/bindings/video/rockchip-drm.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt b/Documentation/devicetree/bindings/video/rockchip-drm.txt new file mode 100644 index 000..7fff582 --- /dev/null +++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt @@ -0,0 +1,19 @@ +Rockchip DRM master device + + +The Rockchip DRM master device is a virtual device needed to list all +vop devices or other display interface nodes that comprise the +graphics subsystem. + +Required properties: +- compatible: Should be "rockchip,display-subsystem" +- ports: Should contain a list of phandles pointing to display interface port + of vop devices. vop definitions as defined in + Documentation/devicetree/bindings/video/rockchip-vop.txt + +example: + +display-subsystem { + compatible = "rockchip,display-subsystem"; + ports = <&vopl_out>, <&vopb_out>; +}; -- 1.7.9.5
[PATCH v9 1/3] drm: rockchip: Add basic drm driver
From: Mark yao This patch adds the basic structure of a DRM Driver for Rockchip Socs. Signed-off-by: Mark Yao Signed-off-by: Daniel Kurtz Acked-by: Daniel Vetter Reviewed-by: Rob Clark --- Changes in v2: - 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. - use vop reset at first init - reference framebuffer when used and unreference when swap out vop 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. 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 14 files changed, 3026 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/Kconfig create mode 100644 drivers/gpu/drm/rockchip/Makefile create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b066bb3..7c4c3c6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -171,6 +171,8 @@ config DRM_SAVAGE source "drivers/gpu/drm/exynos/Kconfig" +source "drivers/gpu/drm/rockchip/Kconfig" + source "drivers/gpu/drm/vmwgfx/Kconfig" source "drivers/gpu/drm/gma500/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4a55d59..d03387a 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ obj-$(CONFIG_DRM_VIA) +=via/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ diff --git a/drivers/gpu/drm/rockchip/Kconfig
[PATCH v9 0/3] Add drm driver for Rockchip Socs
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
[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails
On Tue, Sep 30, 2014 at 8:09 PM, Keith Packard wrote: > Instead of just segfaulting in the driver when a buffer allocation fails, > report error messages indicating what went wrong so that we can debug things. > > As a simple example, chromium wraps Mesa in a sandbox which doesn't allow > access to most syscalls, including the ability to create shared memory > segments for fences. Before, you'd get a simple segfault in mesa and your 3D > acceleration would fail. Now you get: > > $ chromium --disable-gpu-blacklist > [10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, > loaded==false: NSS error code: -8018 > libGL: pci id for fd 12: 8086:0a16, driver i965 > libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so > libGL: Can't open configuration file /home/keithp/.drirc: Operation not > permitted. > libGL: Can't open configuration file /home/keithp/.drirc: Operation not > permitted. > libGL error: DRI3 Fence object allocation failure Operation not permitted > [10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not > send GpuCommandBufferMsg_Initialize. > [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)] > CommandBufferProxy::Initialize failed. > [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)] > Failed to initialize command buffer. > > This made it pretty easy to diagnose the problem in the referenced bug report. > > Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681 > Signed-off-by: Keith Packard > --- Seems like a good plan. Reviewed-by: Matt Turner Should we add a Cc: for the stable branch?
[PATCH v6 2/2] drm/i2c:tda998x: Use the HDMI audio CODEC
On Wed, Sep 24, 2014 at 10:11:21AM +0200, Jean-Francois Moine wrote: > This patch interfaces the HDMI transmitter with the audio system. Please use subject lines corresponding to the style for the subsystem. > + request_module("snd-soc-hdmi-codec"); > + pdev = platform_device_register_resndata(&priv->hdmi->dev, > + "hdmi-audio-codec", > + PLATFORM_DEVID_NONE, > + NULL, 0, > + &tda998x_hdmi_data, > + sizeof tda998x_hdmi_data); Why is this request_module() needed? If there is a good reason for it we should have some documentation. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/25764887/attachment.sig>
[PATCH v6 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
On Wed, Sep 24, 2014 at 10:23:34AM +0200, Jean-Francois Moine wrote: > The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link > from 2 different sources, I2S and S/PDIF. > > This patch set adds an interface between the HDMI transmitter and > the HDMI CODEC. I'd really like to see some of the other people who are working with HDMI reviewing this - this is a generic part which seems to be very widely used so we need to make sure that what's being done works for other systems. Jyri, I see you're on CC? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/403af0a9/attachment-0001.sig>
[PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails
Instead of just segfaulting in the driver when a buffer allocation fails, report error messages indicating what went wrong so that we can debug things. As a simple example, chromium wraps Mesa in a sandbox which doesn't allow access to most syscalls, including the ability to create shared memory segments for fences. Before, you'd get a simple segfault in mesa and your 3D acceleration would fail. Now you get: $ chromium --disable-gpu-blacklist [10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, loaded==false: NSS error code: -8018 libGL: pci id for fd 12: 8086:0a16, driver i965 libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted. libGL error: DRI3 Fence object allocation failure Operation not permitted [10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not send GpuCommandBufferMsg_Initialize. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)] CommandBufferProxy::Initialize failed. [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)] Failed to initialize command buffer. This made it pretty easy to diagnose the problem in the referenced bug report. Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681 Signed-off-by: Keith Packard --- src/glx/dri3_glx.c | 33 + 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c index 753b8d8..5cae50e 100644 --- a/src/glx/dri3_glx.c +++ b/src/glx/dri3_glx.c @@ -816,11 +816,15 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, Drawable draw, */ fence_fd = xshmfence_alloc_shm(); - if (fence_fd < 0) + if (fence_fd < 0) { + ErrorMessageF("DRI3 Fence object allocation failure %s\n", strerror(errno)); return NULL; + } shm_fence = xshmfence_map_shm(fence_fd); - if (shm_fence == NULL) + if (shm_fence == NULL) { + ErrorMessageF("DRI3 Fence object map failure %s\n", strerror(errno)); goto no_shm_fence; + } /* Allocate the image from the driver */ @@ -829,8 +833,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, Drawable draw, goto no_buffer; buffer->cpp = dri3_cpp_for_format(format); - if (!buffer->cpp) + if (!buffer->cpp) { + ErrorMessageF("DRI3 buffer format %d invalid\n", format); goto no_image; + } if (!psc->is_different_gpu) { buffer->image = (*psc->image->createImage) (psc->driScreen, @@ -841,8 +847,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, Drawable draw, buffer); pixmap_buffer = buffer->image; - if (!buffer->image) + if (!buffer->image) { + ErrorMessageF("DRI3 other gpu image creation failure\n"); goto no_image; + } } else { buffer->image = (*psc->image->createImage) (psc->driScreen, width, height, @@ -850,8 +858,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, Drawable draw, 0, buffer); - if (!buffer->image) + if (!buffer->image) { + ErrorMessageF("DRI3 gpu image creation failure\n"); goto no_image; + } buffer->linear_buffer = (*psc->image->createImage) (psc->driScreen, width, height, @@ -861,19 +871,25 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, Drawable draw, buffer); pixmap_buffer = buffer->linear_buffer; - if (!buffer->linear_buffer) + if (!buffer->linear_buffer) { + ErrorMessageF("DRI3 gpu linear image creation failure\n"); goto no_linear_buffer; + } } /* X wants the stride, so ask the image for it */ - if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_STRIDE, &stride)) + if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_STRIDE, &stride)) { + ErrorMessageF("DRI3 get image stride failed\n"); goto no_buffer_attrib; + } buffer->pitch = stride; - if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_FD, &buffer_fd)) + if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_FD, &buffer_fd)) { + ErrorMessageF("DRI3 get image FD failed\n"); goto no_buffer_attrib; + } xcb_dri3_pixmap_from_buffer(c, (pixmap = xcb_generate_id(c)), @@ -913,6 +929,7 @@ no_buffer: xshmfence_unmap_shm(shm_fence); no_shm_fence: close(fence_fd); + ErrorMessageF("DRI3 alloc_render_buffer failed\n"); return NULL; } -- 2.1.1
[PATCH] drm/core: use helper to check driver features
The patch replaces direct access to driver_features field by calls to helper function. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/drm_drv.c | 4 ++-- drivers/gpu/drm/drm_fops.c | 8 drivers/gpu/drm/drm_gem.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 6a11902..2b30430 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -598,7 +598,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver, goto err_ht; } - if (driver->driver_features & DRIVER_GEM) { + if (drm_core_check_feature(dev, DRIVER_GEM)) { ret = drm_gem_init(dev); if (ret) { DRM_ERROR("Cannot initialize graphics execution manager (GEM)\n"); @@ -628,7 +628,7 @@ static void drm_dev_release(struct kref *ref) { struct drm_device *dev = container_of(ref, struct drm_device, ref); - if (dev->driver->driver_features & DRIVER_GEM) + if (drm_core_check_feature(dev, DRIVER_GEM)) drm_gem_destroy(dev); drm_legacy_ctxbitmap_cleanup(dev); diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 3e66946..ed7bc68 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -171,7 +171,7 @@ static int drm_open_helper(struct file *filp, struct drm_minor *minor) init_waitqueue_head(&priv->event_wait); priv->event_space = 4096; /* set aside 4k for event buffer */ - if (dev->driver->driver_features & DRIVER_GEM) + if (drm_core_check_feature(dev, DRIVER_GEM)) drm_gem_open(dev, priv); if (drm_core_check_feature(dev, DRIVER_PRIME)) @@ -256,7 +256,7 @@ out_close: out_prime_destroy: if (drm_core_check_feature(dev, DRIVER_PRIME)) drm_prime_destroy_file_private(&priv->prime); - if (dev->driver->driver_features & DRIVER_GEM) + if (drm_core_check_feature(dev, DRIVER_GEM)) drm_gem_release(dev, priv); put_pid(priv->pid); kfree(priv); @@ -408,10 +408,10 @@ int drm_release(struct inode *inode, struct file *filp) drm_events_release(file_priv); - if (dev->driver->driver_features & DRIVER_MODESET) + if (drm_core_check_feature(dev, DRIVER_MODESET)) drm_fb_release(file_priv); - if (dev->driver->driver_features & DRIVER_GEM) + if (drm_core_check_feature(dev, DRIVER_GEM)) drm_gem_release(dev, file_priv); drm_legacy_ctxbitmap_flush(dev, file_priv); diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index eb5dd67..b2c7bab 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -580,7 +580,7 @@ drm_gem_close_ioctl(struct drm_device *dev, void *data, struct drm_gem_close *args = data; int ret; - if (!(dev->driver->driver_features & DRIVER_GEM)) + if (!drm_core_check_feature(dev, DRIVER_GEM)) return -ENODEV; ret = drm_gem_handle_delete(file_priv, args->handle); @@ -607,7 +607,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, struct drm_gem_object *obj; int ret; - if (!(dev->driver->driver_features & DRIVER_GEM)) + if (!drm_core_check_feature(dev, DRIVER_GEM)) return -ENODEV; obj = drm_gem_object_lookup(dev, file_priv, args->handle); @@ -660,7 +660,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, int ret; u32 handle; - if (!(dev->driver->driver_features & DRIVER_GEM)) + if (!drm_core_check_feature(dev, DRIVER_GEM)) return -ENODEV; mutex_lock(&dev->object_name_lock); -- 1.9.1
[Bug 84519] New: GPU hang xbmc tvheadend uvd
https://bugs.freedesktop.org/show_bug.cgi?id=84519 Priority: medium Bug ID: 84519 Assignee: dri-devel at lists.freedesktop.org Summary: GPU hang xbmc tvheadend uvd Severity: normal Classification: Unclassified OS: All Reporter: serafean at gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa Created attachment 107140 --> https://bugs.freedesktop.org/attachment.cgi?id=107140&action=edit dmesg from around the hang When playing back a live TV stream using xbmc and tvheadend I immediately get a GPU hang. relevant dmesg attached. 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] Anything more I could do, please tell me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/02f1f067/attachment.html>
[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem
On 2014?09?30? 16:10, Daniel Vetter wrote: > On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote: >> From: Mark yao >> >> This add a display subsystem comprise the all display interface nodes. >> >> Signed-off-by: Mark Yao >> Signed-off-by: Daniel Kurtz >> Acked-by: Daniel Vetter >> Reviewed-by: Rob Clark > Just a quick clarification: My ack was only about the drm driver itself, I > try really hard to stay away from DT insanity ;-) So please drop my ack > from these two patches. > > Aside: DT patches need to go through a special process and you must cc dt > maintainers and mailing lists. Your patch seems to lack this, which afaiui > is a blocker for merging the driver. > > Thanks, Daniel Oh, I'm sorry, I will drop it soon. >> --- >> Changes in v2: >> - add DRM master device node to list all display nodes that comprise >>the graphics subsystem. >> >> Changes in v3: None >> >> Changes in v4: None >> >> Changes in v5: None >> >> Changes in v6: None >> >> Changes in v7: None >> >> Changes in v8: None >> >> .../devicetree/bindings/video/rockchip-drm.txt | 19 >> +++ >> 1 file changed, 19 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt >> >> diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt >> b/Documentation/devicetree/bindings/video/rockchip-drm.txt >> new file mode 100644 >> index 000..7fff582 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt >> @@ -0,0 +1,19 @@ >> +Rockchip DRM master device >> + >> + >> +The Rockchip DRM master device is a virtual device needed to list all >> +vop devices or other display interface nodes that comprise the >> +graphics subsystem. >> + >> +Required properties: >> +- compatible: Should be "rockchip,display-subsystem" >> +- ports: Should contain a list of phandles pointing to display interface >> port >> + of vop devices. vop definitions as defined in >> + Documentation/devicetree/bindings/video/rockchip-vop.txt >> + >> +example: >> + >> +display-subsystem { >> +compatible = "rockchip,display-subsystem"; >> +ports = <&vopl_out>, <&vopb_out>; >> +}; >> -- >> 1.7.9.5 >> >>
[PATCH v9 1/3] drm: rockchip: Add basic drm driver
Hi Mark, On 09/30/2014 03:03 PM, Mark Yao wrote: > From: Mark yao > > This patch adds the basic structure of a DRM Driver for Rockchip Socs. > > Signed-off-by: Mark Yao > Signed-off-by: Daniel Kurtz > Acked-by: Daniel Vetter > Reviewed-by: Rob Clark > --- > Changes in v2: > - 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. > - use vop reset at first init > - reference framebuffer when used and unreference when swap out vop > > 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. > > 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 > 14 files changed, 3026 insertions(+) > create mode 100644 drivers/gpu/drm/rockchip/Kconfig > create mode 100644 drivers/gpu/drm/rockchip/Makefile > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index b066bb3..7c4c3c6 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -171,6 +171,8 @@ config DRM_SAVAGE > > source "drivers/gpu/drm/exynos/Kconfig" > > +source "drivers/gpu/drm/rockchip/Kconfig" > + > source "drivers/gpu/drm/vmwgfx/Kconfig" > > source "drivers/gpu/drm/gma500/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 4a55d59..d03387a 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ >
[PATCH] drm/omap: move rotation property to drm core mode_config
On 30/09/14 14:52, Daniel Vetter wrote: > On Tue, Sep 30, 2014 at 01:49:20PM +0200, Daniel Vetter wrote: >> On Tue, Sep 30, 2014 at 02:42:01PM +0300, Tomi Valkeinen wrote: >>> On 06/08/14 11:40, Daniel Vetter wrote: This allows us to ditch the driver-private lastclose logic. Cc: Tomi Valkeinen Cc: Rob Clark Signed-off-by: Daniel Vetter -- Untested and atm only applies on top of drm-intel-nightly. >>> >>> I could give this a try if you point me to a git tree with the patch. >> >> I should apply on top of drm-next nowadays, prerequisites that went in >> through drm-intel are all merged now. I guess you'll take care of this one >> now? It didn't compile, but it was trivial to fix. And yes, I can pick it to my omapdrm patches, which I guess will be delayed until 3.19. > btw if this works you can drop the entire if (rotation_property) hunk from > lastclose, since the fbdev helper now takes care of this itself: > > commit 3a5f87c286515c54ff5c52c3e64d0c522b7570c0 > Author: Thomas Wood > Date: Wed Aug 20 14:45:00 2014 +0100 > > drm: fix plane rotation when restoring fbdev configuration I updated the patch, with the compile fix and removal of the lastclose stuff. Seems to work fine with a quick test: I exit X (after fiddling with xrandr rotation in there), and I see the rotation property restored to the default value. Tomi
[PATCH] drm/omap: move rotation property to drm core mode_config
On Tue, Sep 30, 2014 at 03:15:07PM +0300, Tomi Valkeinen wrote: > On 30/09/14 14:52, Daniel Vetter wrote: > > On Tue, Sep 30, 2014 at 01:49:20PM +0200, Daniel Vetter wrote: > >> On Tue, Sep 30, 2014 at 02:42:01PM +0300, Tomi Valkeinen wrote: > >>> On 06/08/14 11:40, Daniel Vetter wrote: > This allows us to ditch the driver-private lastclose logic. > > Cc: Tomi Valkeinen > Cc: Rob Clark > Signed-off-by: Daniel Vetter > > -- > > Untested and atm only applies on top of drm-intel-nightly. > >>> > >>> I could give this a try if you point me to a git tree with the patch. > >> > >> I should apply on top of drm-next nowadays, prerequisites that went in > >> through drm-intel are all merged now. I guess you'll take care of this one > >> now? > > It didn't compile, but it was trivial to fix. And yes, I can pick it to my > omapdrm patches, which I guess will be delayed until 3.19. > > > btw if this works you can drop the entire if (rotation_property) hunk from > > lastclose, since the fbdev helper now takes care of this itself: > > > > commit 3a5f87c286515c54ff5c52c3e64d0c522b7570c0 > > Author: Thomas Wood > > Date: Wed Aug 20 14:45:00 2014 +0100 > > > > drm: fix plane rotation when restoring fbdev configuration > > I updated the patch, with the compile fix and removal of the lastclose stuff. > Seems to work fine with a quick test: I exit X (after fiddling with xrandr > rotation in there), and I see the rotation property restored to the default > value. Yeah, lgtm. Thanks for taking care of this. -Daniel > > Tomi > > From afb37e165010fc5f3db82efdec9b883fb578deac Mon Sep 17 00:00:00 2001 > From: Daniel Vetter > Date: Wed, 6 Aug 2014 10:40:24 +0200 > Subject: [PATCH] drm/omap: move rotation property to drm core mode_config > > Move rotation property to drm core mode_config. This allows us to ditch > the driver-private lastclose logic. > > Cc: Rob Clark > Signed-off-by: Daniel Vetter > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++-- > drivers/gpu/drm/omapdrm/omap_drv.c | 20 > drivers/gpu/drm/omapdrm/omap_drv.h | 1 - > drivers/gpu/drm/omapdrm/omap_plane.c | 7 --- > 4 files changed, 6 insertions(+), 26 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c > b/drivers/gpu/drm/omapdrm/omap_crtc.c > index 2d28dc337cfb..1240fa61b397 100644 > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > @@ -385,9 +385,9 @@ static int omap_crtc_set_property(struct drm_crtc *crtc, > struct drm_property *property, uint64_t val) > { > struct omap_crtc *omap_crtc = to_omap_crtc(crtc); > - struct omap_drm_private *priv = crtc->dev->dev_private; > + struct drm_device *dev = crtc->dev; > > - if (property == priv->rotation_prop) { > + if (property == dev->mode_config.rotation_property) { > crtc->invert_dimensions = > !!(val & ((1LL << DRM_ROTATE_90) | (1LL << > DRM_ROTATE_270))); > } > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c > b/drivers/gpu/drm/omapdrm/omap_drv.c > index 862ba03c236c..282f5ec4f1a2 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -560,8 +560,6 @@ static int dev_open(struct drm_device *dev, struct > drm_file *file) > */ > static void dev_lastclose(struct drm_device *dev) > { > - int i; > - > /* we don't support vga-switcheroo.. so just make sure the fbdev >* mode is active >*/ > @@ -570,24 +568,6 @@ static void dev_lastclose(struct drm_device *dev) > > DBG("lastclose: dev=%p", dev); > > - if (priv->rotation_prop) { > - /* need to restore default rotation state.. not sure > - * if there is a cleaner way to restore properties to > - * default state? Maybe a flag that properties should > - * automatically be restored to default state on > - * lastclose? > - */ > - for (i = 0; i < priv->num_crtcs; i++) { > - drm_object_property_set_value(&priv->crtcs[i]->base, > - priv->rotation_prop, 0); > - } > - > - for (i = 0; i < priv->num_planes; i++) { > - drm_object_property_set_value(&priv->planes[i]->base, > - priv->rotation_prop, 0); > - } > - } > - > ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev); > if (ret) > DBG("failed to restore crtc mode"); > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h > b/drivers/gpu/drm/omapdrm/omap_drv.h > index 60e47b33c801..aa596504e662 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.h > +++ b/drivers/gpu/drm/omapdrm/omap_drv.h > @@ -111,7 +111,6 @@ struct omap_drm_private { > bool has_dmm; > > /* properties: */ > - struct drm_propert
[PATCH] drm/i915: don't crash if unable to setup stolen
On this baytrail NUC I would see: *ERROR* conflict detected with stolen region: [0xbb00 - 0xbf00] Since stolen region is not setup, dev_priv->mm.stolen would not be initialized, which results that vlv_pctx is not allocated in valleyview_setup_pctx() which results in things going BOOM in valleyview_check_pctx(). Things seem to work out much better if we check for NULL ptr first. Signed-off-by: Rob Clark --- drivers/gpu/drm/i915/intel_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 45f71e6..bba8901 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4185,6 +4185,9 @@ static void valleyview_check_pctx(struct drm_i915_private *dev_priv) { unsigned long pctx_addr = I915_READ(VLV_PCBR) & ~4095; + if (!dev_priv->vlv_pctx) + return; + WARN_ON(pctx_addr != dev_priv->mm.stolen_base + dev_priv->vlv_pctx->stolen->start); } -- 1.9.3
[PATCH] drm/omap: move rotation property to drm core mode_config
On 06/08/14 11:40, Daniel Vetter wrote: > This allows us to ditch the driver-private lastclose logic. > > Cc: Tomi Valkeinen > Cc: Rob Clark > Signed-off-by: Daniel Vetter > > -- > > Untested and atm only applies on top of drm-intel-nightly. I could give this a try if you point me to a git tree with the patch. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/9e22d8fb/attachment.sig>
[PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing
Hi, On 06/08/14 15:52, Daniel Vetter wrote: > In drm/i915 we want to get at the video= cmdline modes even when we > don't have fbdev support enabled, so that users can always override > the kernel's initial mode selection. > > But that gives us a direct depency upon the parsing code in the fbdev > subsystem. Since it's so little code just extract these 2 functions > and always build them in. > > Whiel at it fix the checkpatch fail in this code. > > v2: Also move fb_mode_option. Spotted by the kbuild. > > v3: Review from Geert: > - Keep the old copyright notice from fb_mem.c, although I have no > idea what exactly applies. > - Only compile this when needed. > > Cc: Geert Uytterhoeven > Cc: Plagniol-Villard > Cc: Tomi Valkeinen > Cc: linux-fbdev at vger.kernel.org > Signed-off-by: Daniel Vetter > > -- > > I prefer if we can merge this through drm-next since we'll use it > there in follow-up patches. > -Daniel > --- > drivers/video/fbdev/Kconfig | 4 ++ > drivers/video/fbdev/core/Makefile | 1 + > drivers/video/fbdev/core/fb_cmdline.c | 110 > ++ > drivers/video/fbdev/core/fbmem.c | 92 > drivers/video/fbdev/core/modedb.c | 3 - > 5 files changed, 115 insertions(+), 95 deletions(-) > create mode 100644 drivers/video/fbdev/core/fb_cmdline.c Sorry for late response. Looks fine for me, and I'm fine merging it via drm-next. Acked-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/8c79ea67/attachment.sig>
[Bug 85311] radeon 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug
https://bugzilla.kernel.org/show_bug.cgi?id=85311 Bjorn Helgaas changed: What|Removed |Added CC||bhelgaas at google.com Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v8 3/3] dt-bindings: video: Add documentation for rockchip vop
From: Mark yao This adds binding documentation for Rockchip SoC VOP driver. Signed-off-by: Mark Yao Acked-by: Daniel Vetter Reviewed-by: Rob Clark --- Changes in v2: - rename "lcdc" to "vop" - add vop reset - add iommu node - add port for display-subsystem Changes in v3: None Changes in v4: None Changes in v5: None Changes in v6: None Changes in v7: None Changes in v8: None .../devicetree/bindings/video/rockchip-vop.txt | 58 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt b/Documentation/devicetree/bindings/video/rockchip-vop.txt new file mode 100644 index 000..d15351f --- /dev/null +++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt @@ -0,0 +1,58 @@ +device-tree bindings for rockchip soc display controller (vop) + +VOP (Visual Output Processor) is the Display Controller for the Rockchip +series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be one of the following + "rockchip,rk3288-vop"; + +- interrupts: should contain a list of all VOP IP block interrupts in the +order: VSYNC, LCD_SYSTEM. The interrupt specifier +format depends on the interrupt controller used. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: Must contain + aclk_vop: for ddr buffer transfer. + hclk_vop: for ahb bus to R/W the phy regs. + dclk_vop: pixel clock. + +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - axi + - ahb + - dclk + +- iommus: required a iommu node + +- port: A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: +SoC specific DT entry: + vopb: vopb at ff93 { + compatible = "rockchip,rk3288-vop"; + reg = <0xff93 0x19c>; + interrupts = ; + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_edp: endpoint at 0 { + reg = <0>; + remote-endpoint=<&edp_in_vopb>; + }; + vopb_out_hdmi: endpoint at 1 { + reg = <1>; + remote-endpoint=<&hdmi_in_vopb>; + }; + }; + }; -- 1.7.9.5
[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem
From: Mark yao This add a display subsystem comprise the all display interface nodes. Signed-off-by: Mark Yao Signed-off-by: Daniel Kurtz Acked-by: Daniel Vetter Reviewed-by: Rob Clark --- Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. Changes in v3: None Changes in v4: None Changes in v5: None Changes in v6: None Changes in v7: None Changes in v8: None .../devicetree/bindings/video/rockchip-drm.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt b/Documentation/devicetree/bindings/video/rockchip-drm.txt new file mode 100644 index 000..7fff582 --- /dev/null +++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt @@ -0,0 +1,19 @@ +Rockchip DRM master device + + +The Rockchip DRM master device is a virtual device needed to list all +vop devices or other display interface nodes that comprise the +graphics subsystem. + +Required properties: +- compatible: Should be "rockchip,display-subsystem" +- ports: Should contain a list of phandles pointing to display interface port + of vop devices. vop definitions as defined in + Documentation/devicetree/bindings/video/rockchip-vop.txt + +example: + +display-subsystem { + compatible = "rockchip,display-subsystem"; + ports = <&vopl_out>, <&vopb_out>; +}; -- 1.7.9.5
[PATCH v8 1/3] drm: rockchip: Add basic drm driver
From: Mark yao This patch adds the basic structure of a DRM Driver for Rockchip Socs. Signed-off-by: Mark Yao Signed-off-by: Daniel Kurtz Acked-by: Daniel Vetter Reviewed-by: Rob Clark --- Changes in v2: - 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. - use vop reset at first init - reference framebuffer when used and unreference when swap out vop 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 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 | 1438 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 14 files changed, 3041 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/Kconfig create mode 100644 drivers/gpu/drm/rockchip/Makefile create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b066bb3..7c4c3c6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -171,6 +171,8 @@ config DRM_SAVAGE source "drivers/gpu/drm/exynos/Kconfig" +source "drivers/gpu/drm/rockchip/Kconfig" + source "drivers/gpu/drm/vmwgfx/Kconfig" source "drivers/gpu/drm/gma500/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4a55d59..d03387a 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ obj-$(CONFIG_DRM_VIA) +=via/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig new file mode 100644 index 000..87255f7 ---
[PATCH v8 0/3] Add drm driver for Rockchip Socs
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 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| 1438 drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 196 +++ 16 files changed, 3118 insertions(+) -- 1.7.9.5
[PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing
On Tue, Sep 30, 2014 at 1:40 PM, Tomi Valkeinen wrote: > On 06/08/14 15:52, Daniel Vetter wrote: >> In drm/i915 we want to get at the video= cmdline modes even when we >> don't have fbdev support enabled, so that users can always override >> the kernel's initial mode selection. >> >> But that gives us a direct depency upon the parsing code in the fbdev >> subsystem. Since it's so little code just extract these 2 functions >> and always build them in. >> >> Whiel at it fix the checkpatch fail in this code. >> >> v2: Also move fb_mode_option. Spotted by the kbuild. >> >> v3: Review from Geert: >> - Keep the old copyright notice from fb_mem.c, although I have no >> idea what exactly applies. >> - Only compile this when needed. >> >> Cc: Geert Uytterhoeven >> Cc: Plagniol-Villard >> Cc: Tomi Valkeinen >> Cc: linux-fbdev at vger.kernel.org >> Signed-off-by: Daniel Vetter >> >> -- >> >> I prefer if we can merge this through drm-next since we'll use it >> there in follow-up patches. >> -Daniel >> --- >> drivers/video/fbdev/Kconfig | 4 ++ >> drivers/video/fbdev/core/Makefile | 1 + >> drivers/video/fbdev/core/fb_cmdline.c | 110 >> ++ >> drivers/video/fbdev/core/fbmem.c | 92 >> drivers/video/fbdev/core/modedb.c | 3 - >> 5 files changed, 115 insertions(+), 95 deletions(-) >> create mode 100644 drivers/video/fbdev/core/fb_cmdline.c > > Sorry for late response. > > Looks fine for me, and I'm fine merging it via drm-next. > > Acked-by: Tomi Valkeinen Well totally forgotten about this one here - I even forgot to drop the "pls ack this" text from the commit message before sending the pull request to Dave :( Anyway, thanks for having a look. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/omap: move rotation property to drm core mode_config
On Tue, Sep 30, 2014 at 01:49:20PM +0200, Daniel Vetter wrote: > On Tue, Sep 30, 2014 at 02:42:01PM +0300, Tomi Valkeinen wrote: > > On 06/08/14 11:40, Daniel Vetter wrote: > > > This allows us to ditch the driver-private lastclose logic. > > > > > > Cc: Tomi Valkeinen > > > Cc: Rob Clark > > > Signed-off-by: Daniel Vetter > > > > > > -- > > > > > > Untested and atm only applies on top of drm-intel-nightly. > > > > I could give this a try if you point me to a git tree with the patch. > > I should apply on top of drm-next nowadays, prerequisites that went in > through drm-intel are all merged now. I guess you'll take care of this one > now? btw if this works you can drop the entire if (rotation_property) hunk from lastclose, since the fbdev helper now takes care of this itself: commit 3a5f87c286515c54ff5c52c3e64d0c522b7570c0 Author: Thomas Wood Date: Wed Aug 20 14:45:00 2014 +0100 drm: fix plane rotation when restoring fbdev configuration Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/omap: move rotation property to drm core mode_config
On Tue, Sep 30, 2014 at 02:42:01PM +0300, Tomi Valkeinen wrote: > On 06/08/14 11:40, Daniel Vetter wrote: > > This allows us to ditch the driver-private lastclose logic. > > > > Cc: Tomi Valkeinen > > Cc: Rob Clark > > Signed-off-by: Daniel Vetter > > > > -- > > > > Untested and atm only applies on top of drm-intel-nightly. > > I could give this a try if you point me to a git tree with the patch. I should apply on top of drm-next nowadays, prerequisites that went in through drm-intel are all merged now. I guess you'll take care of this one now? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 85311] radeon 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug
https://bugzilla.kernel.org/show_bug.cgi?id=85311 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Does radeon.runpm=0 "fix" this? I think the kernel is trying to access the device while it is powered off. Seems like a possible bug in the kernel runtime pm code. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #60 from Andy Furniss --- (In reply to comment #59) > (In reply to comment #58) > > (In reply to comment #57) > > > I'm trying drm-next-3.18 and mesa git and many unreal engine demos are > > > still > > > broken like this: > > > https://www.youtube.com/watch?v=NvgA9_B0dMo > > > > Are you sure that's directly related to the Unigine Heaven stuttering > > discussed in this report? E.g., does reverting the Mesa commit in question > > help, or do you see similar symptoms in the Gallium HUD? > > It does look like the same symptoms. Only rare and short hangs in unigine > heaven, but frequent hangs of ~1-2 sconds in unigine valley. The HUD shows > that these hangs mostly correlate with jumps in vram/gtt usage. > > Is the mesa commit in question 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938? If > so, it doesn't revert cleanly anymore, but I can have a look if I can > manually see how to do it. Some Unreal are OK for me after a glitchy start. I can reproduce what you see with Scifi hallway and Elemental - the latter is very bad, the former did come good after a while. I hadn't "seen" these two before today, as in the past they just bailed with an llvm error. I'll try, when I have time, to see if they are better with the revert. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/80e95795/attachment.html>
[PATCH] drm/exynos: remove ifdeferry from initialization code
Hi Inki, Gently ping. Andrzej On 09/10/2014 01:53 PM, Andrzej Hajda wrote: > The patch replaces separate calls to driver (de)registration by > loops over the array of drivers. As a result it significantly > decreases number of ifdefs. Additionally it moves device registration > related ifdefs to header file. > > Signed-off-by: Andrzej Hajda > --- > Hi Inki, > > During testing your component match support patch [1] I have prepared patch > removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but > I can rebase it if necessary. > > [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031 > > Regards > Andrzej > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 170 > +++- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++-- > 2 files changed, 48 insertions(+), 147 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index b2c710a..a660e46 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -553,74 +553,54 @@ static const struct component_master_ops exynos_drm_ops > = { > .unbind = exynos_drm_unbind, > }; > > -static int exynos_drm_platform_probe(struct platform_device *pdev) > -{ > - struct component_match *match; > - int ret; > - > - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > - exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); > - > +static struct platform_driver * const exynos_drm_drivers[] = { > #ifdef CONFIG_DRM_EXYNOS_FIMD > - ret = platform_driver_register(&fimd_driver); > - if (ret < 0) > - return ret; > + &fimd_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_DP > - ret = platform_driver_register(&dp_driver); > - if (ret < 0) > - goto err_unregister_fimd_drv; > + &dp_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_DSI > - ret = platform_driver_register(&dsi_driver); > - if (ret < 0) > - goto err_unregister_dp_drv; > + &dsi_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_HDMI > - ret = platform_driver_register(&mixer_driver); > - if (ret < 0) > - goto err_unregister_dsi_drv; > - ret = platform_driver_register(&hdmi_driver); > - if (ret < 0) > - goto err_unregister_mixer_drv; > + &mixer_driver, > + &hdmi_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_G2D > - ret = platform_driver_register(&g2d_driver); > - if (ret < 0) > - goto err_unregister_hdmi_drv; > + &g2d_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_FIMC > - ret = platform_driver_register(&fimc_driver); > - if (ret < 0) > - goto err_unregister_g2d_drv; > + &fimc_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_ROTATOR > - ret = platform_driver_register(&rotator_driver); > - if (ret < 0) > - goto err_unregister_fimc_drv; > + &rotator_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_GSC > - ret = platform_driver_register(&gsc_driver); > - if (ret < 0) > - goto err_unregister_rotator_drv; > + &gsc_driver, > #endif > - > #ifdef CONFIG_DRM_EXYNOS_IPP > - ret = platform_driver_register(&ipp_driver); > - if (ret < 0) > - goto err_unregister_gsc_drv; > + &ipp_driver, > +#endif > +}; > + > +static int exynos_drm_platform_probe(struct platform_device *pdev) > +{ > + struct component_match *match; > + int ret, i; > + > + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); > + > + for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) { > + ret = platform_driver_register(exynos_drm_drivers[i]); > + if (ret < 0) > + goto err_unregister_drivers; > + } > > ret = exynos_platform_device_ipp_register(); > if (ret < 0) > - goto err_unregister_ipp_drv; > -#endif > + goto err_unregister_drivers; > > match = exynos_drm_match_add(&pdev->dev); > if (IS_ERR(match)) { > @@ -632,96 +612,24 @@ static int exynos_drm_platform_probe(struct > platform_device *pdev) > match); > > err_unregister_ipp_dev: > - > -#ifdef CONFIG_DRM_EXYNOS_IPP > exynos_platform_device_ipp_unregister(); > -err_unregister_ipp_drv: > - platform_driver_unregister(&ipp_driver); > -err_unregister_gsc_drv: > -#endif > > -#ifdef CONFIG_DRM_EXYNOS_GSC > - platform_driver_unregister(&gsc_driver); > -err_unregister_rotator_drv: > -#endif > +err_unregister_drivers: > + while (--i >= 0) > + platform_driver_unregister(exynos_drm_drivers[i]); > > -#ifdef CONFIG_DRM_EXYNOS_ROTATOR > - platform_driver_unregister(&rotator_driver); > -err_unregister_fimc_drv: > -#endif > - > -#ifdef CONFIG_DRM_EXYNOS_FIMC > - platform_driver_unregister(&fimc_driver); > -err_unregister_g2d_drv
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #4 from Alex Deucher --- Created attachment 107128 --> https://bugs.freedesktop.org/attachment.cgi?id=107128&action=edit dump full CS when we hit a packet 0 This kernel patch should make it much easier to debug. When you hit the error, please attach the full output of the CS. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/572c340a/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #3 from Alexandre Demers --- (In reply to comment #2) > Can you run the browser with the environment variable RADEON_DUMP_CS=1, and > attach any command stream dumps that generates on stderr? I'll run firefox with this env var later today. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/c9eb27be/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #142 from Alexandre Demers --- (In reply to comment #141) > If someone has a way to reliably reproduce the 'Packet0 not allowed!' error, > please file a separate report for that. Or, if you know at least which > process triggers it, you can run that process with the environment variable > RADEON_DUMP_CS=1, and it should print a dump of the failed command stream(s) > on stderr. > > P.S. I'm afraid this report has turned into a train wreck, it's impossible > to keep track of who encountered what issue(s) under what circumstances. I opened Bug 84500 just for Packet0. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/0d5ce1df/attachment.html>
[Bug 83792] Kernel hangs on boot without nomodeset option
https://bugs.freedesktop.org/show_bug.cgi?id=83792 --- Comment #8 from Alex Deucher --- (In reply to comment #6) > Created attachment 107113 [details] > Kernel messages, round 1 > > Good news; I have some kernel messages to attach. These were gained using > netconsole, which was on another machine. It seems to me that it detects > the radeon FireMV2400 (although it never mentions it by name), and detects > two of the four connectors (I'm assuming two that are connected to the same > chip; this card has 2 chips with 2 displays each; total of 4 displays). If netconsole works, can you get remote access to the box (e.g., ssh) as well or does it hang completely? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/c717b372/attachment-0001.html>
[PATCH libdrm 1/3] intel/skl: Add SKL PCI ids
On Tue, Sep 30, 2014 at 11:19:37AM +0100, Thomas Wood wrote: > On 26 September 2014 14:19, Damien Lespiau > wrote: > > v2: Add more PCI IDs (Michael H. Nguyen) > > v3: Synchronize one more with the kernel PCI IDs (Damien) > > > > Signed-off-by: Damien Lespiau > > Signed-off-by: Ben Widawsky > > Signed-off-by: Michael H. Nguyen > > Reviewed-by: Thomas Wood Thanks for the review, pushed the whole series (the other two patches where already reviewed). -- Damien
[PATCH v2 1/5] video: move mediabus format definition to a more standard place
On Tue, 30 Sep 2014 10:39:53 +0200 Thierry Reding wrote: > On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote: > > On Mon, 29 Sep 2014 23:41:09 +0300 > > Laurent Pinchart wrote: > [...] > > > Incidentally, patch 2/5 in this series is missing a documentation update > > > ;-) > > > > Yep, regarding this patch, I wonder if it's really necessary to add > > new formats to the v4l2_mbus_pixelcode enum. > > If we want to move to this new common definition (across the video > > related subsytems), we should deprecate the old enum > > v4l2_mbus_pixelcode, and this start by not adding new formats, don't > > you think ? > > I agree in general, but I think it could prove problematic in practice. > If somebody wants to use one of the new codes but is using the V4L2 enum > they have a problem. > > That said, given that there is now a unified enum people will hopefully > start converting drivers to it instead. I'm more worried about user-space lib/programs as this header is part of the uapi... But let's be optimistic here and keep porting new formats to v4l2_mbus_pixelcode enum ;-). Anyway, I still don't know where to put the documentation. Dropping a new video format doc without any context (I mean subdev-formats.xml is included in media documentation, but there's no generic video doc yet) is a bit weird... -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH libdrm 1/3] intel/skl: Add SKL PCI ids
On 26 September 2014 14:19, Damien Lespiau wrote: > v2: Add more PCI IDs (Michael H. Nguyen) > v3: Synchronize one more with the kernel PCI IDs (Damien) > > Signed-off-by: Damien Lespiau > Signed-off-by: Ben Widawsky > Signed-off-by: Michael H. Nguyen Reviewed-by: Thomas Wood > --- > intel/intel_chipset.h | 43 ++- > 1 file changed, 42 insertions(+), 1 deletion(-) > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h > index 6f9bfad..e22a867 100644 > --- a/intel/intel_chipset.h > +++ b/intel/intel_chipset.h > @@ -165,6 +165,22 @@ > #define PCI_CHIP_CHERRYVIEW_2 0x22b2 > #define PCI_CHIP_CHERRYVIEW_3 0x22b3 > > +#define PCI_CHIP_SKYLAKE_ULT_GT2 0x1916 > +#define PCI_CHIP_SKYLAKE_ULT_GT1 0x1906 > +#define PCI_CHIP_SKYLAKE_ULT_GT3 0x1926 > +#define PCI_CHIP_SKYLAKE_ULT_GT2F 0x1921 > +#define PCI_CHIP_SKYLAKE_ULX_GT1 0x190E > +#define PCI_CHIP_SKYLAKE_ULX_GT2 0x191E > +#define PCI_CHIP_SKYLAKE_DT_GT20x1912 > +#define PCI_CHIP_SKYLAKE_DT_GT10x1902 > +#define PCI_CHIP_SKYLAKE_HALO_GT2 0x191B > +#define PCI_CHIP_SKYLAKE_HALO_GT3 0x192B > +#define PCI_CHIP_SKYLAKE_HALO_GT1 0x190B > +#define PCI_CHIP_SKYLAKE_SRV_GT2 0x191A > +#define PCI_CHIP_SKYLAKE_SRV_GT3 0x192A > +#define PCI_CHIP_SKYLAKE_SRV_GT1 0x190A > +#define PCI_CHIP_SKYLAKE_WKS_GT2 0x191D > + > #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \ > (devid) == PCI_CHIP_I915_GM || \ > (devid) == PCI_CHIP_I945_GM || \ > @@ -324,12 +340,37 @@ > #define IS_GEN8(devid) (IS_BROADWELL(devid) || \ > IS_CHERRYVIEW(devid)) > > +#define IS_SKL_GT1(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \ > +(devid) == PCI_CHIP_SKYLAKE_ULX_GT1|| \ > +(devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \ > +(devid) == PCI_CHIP_SKYLAKE_HALO_GT1 || \ > +(devid) == PCI_CHIP_SKYLAKE_SRV_GT1) > + > +#define IS_SKL_GT2(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT2|| \ > +(devid) == PCI_CHIP_SKYLAKE_ULT_GT2F || \ > +(devid) == PCI_CHIP_SKYLAKE_ULX_GT2|| \ > +(devid) == PCI_CHIP_SKYLAKE_DT_GT2 || \ > +(devid) == PCI_CHIP_SKYLAKE_HALO_GT2 || \ > +(devid) == PCI_CHIP_SKYLAKE_SRV_GT2|| \ > +(devid) == PCI_CHIP_SKYLAKE_WKS_GT2) > + > +#define IS_SKL_GT3(devid) ((devid) == PCI_CHIP_SKYLAKE_ULT_GT3|| \ > +(devid) == PCI_CHIP_SKYLAKE_HALO_GT3 || \ > +(devid) == PCI_CHIP_SKYLAKE_SRV_GT3) > + > +#define IS_SKYLAKE(devid) (IS_SKL_GT1(devid) || \ > +IS_SKL_GT2(devid) || \ > +IS_SKL_GT3(devid)) > + > +#define IS_GEN9(devid) IS_SKYLAKE(devid) > + > #define IS_9XX(dev)(IS_GEN3(dev) || \ > IS_GEN4(dev) || \ > IS_GEN5(dev) || \ > IS_GEN6(dev) || \ > IS_GEN7(dev) || \ > -IS_GEN8(dev)) > +IS_GEN8(dev) || \ > +IS_GEN9(dev)) > > > #endif /* _INTEL_CHIPSET_H */ > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 83792] Kernel hangs on boot without nomodeset option
https://bugs.freedesktop.org/show_bug.cgi?id=83792 --- Comment #7 from Tim Nelson --- Anyway, it looks like I was wrong about the kernel modesetting; I think this is a side-effect of the more modern radeon driver not supporting nomodeset. So it's just a bug in the radeon driver, pure and simple. So now I suspect I have to do a kernel bisect. If you have any other advice, though, let me know. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/19ca796d/attachment-0001.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #59 from Christoph Haag --- (In reply to comment #58) > (In reply to comment #57) > > I'm trying drm-next-3.18 and mesa git and many unreal engine demos are still > > broken like this: > > https://www.youtube.com/watch?v=NvgA9_B0dMo > > Are you sure that's directly related to the Unigine Heaven stuttering > discussed in this report? E.g., does reverting the Mesa commit in question > help, or do you see similar symptoms in the Gallium HUD? It does look like the same symptoms. Only rare and short hangs in unigine heaven, but frequent hangs of ~1-2 sconds in unigine valley. The HUD shows that these hangs mostly correlate with jumps in vram/gtt usage. Is the mesa commit in question 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938? If so, it doesn't revert cleanly anymore, but I can have a look if I can manually see how to do it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/705a3b1a/attachment.html>
[Bug 83792] Kernel hangs on boot without nomodeset option
https://bugs.freedesktop.org/show_bug.cgi?id=83792 --- Comment #6 from Tim Nelson --- Created attachment 107113 --> https://bugs.freedesktop.org/attachment.cgi?id=107113&action=edit Kernel messages, round 1 Good news; I have some kernel messages to attach. These were gained using netconsole, which was on another machine. It seems to me that it detects the radeon FireMV2400 (although it never mentions it by name), and detects two of the four connectors (I'm assuming two that are connected to the same chip; this card has 2 chips with 2 displays each; total of 4 displays). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/e10d26e6/attachment.html>
[PATCH v2 1/5] video: move mediabus format definition to a more standard place
On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote: > On Mon, 29 Sep 2014 23:41:09 +0300 > Laurent Pinchart wrote: [...] > > Incidentally, patch 2/5 in this series is missing a documentation update ;-) > > Yep, regarding this patch, I wonder if it's really necessary to add > new formats to the v4l2_mbus_pixelcode enum. > If we want to move to this new common definition (across the video > related subsytems), we should deprecate the old enum > v4l2_mbus_pixelcode, and this start by not adding new formats, don't > you think ? I agree in general, but I think it could prove problematic in practice. If somebody wants to use one of the new codes but is using the V4L2 enum they have a problem. That said, given that there is now a unified enum people will hopefully start converting drivers to it instead. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/f9b553a2/attachment.sig>
[Bug 85311] New: radeon 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug
https://bugzilla.kernel.org/show_bug.cgi?id=85311 Bug ID: 85311 Summary: radeon :01:00.0: Max Payload Size 16384, but upstream :00:01.0 set to 128; if necessary, use "pci=pcie_bus_safe" and report a bug Product: Drivers Version: 2.5 Kernel Version: 3.17-rc6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: pali.rohar at gmail.com Regression: No Created attachment 152131 --> https://bugzilla.kernel.org/attachment.cgi?id=152131&action=edit dmesg log Every time when I open LID on my notebook I see tons of new error lines in dmesg with kernel 3.17-rc6. And more lines come from radeon card (dmesg log is attached). I do not see these log lines with 3.13 kernel, so this is regression. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem
On Tue, Sep 30, 2014 at 10:10:20AM +0200, Daniel Vetter wrote: > On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote: > > From: Mark yao > > > > This add a display subsystem comprise the all display interface nodes. > > > > Signed-off-by: Mark Yao > > Signed-off-by: Daniel Kurtz > > Acked-by: Daniel Vetter > > Reviewed-by: Rob Clark > > Just a quick clarification: My ack was only about the drm driver itself, I > try really hard to stay away from DT insanity ;-) So please drop my ack > from these two patches. > > Aside: DT patches need to go through a special process and you must cc dt > maintainers and mailing lists. Your patch seems to lack this, which afaiui > is a blocker for merging the driver. With coffee working I've now noticed that DT people are on cc ;-) I guess you need to poke them for review, since the drm/driver side looks ready. Would be sad if this would miss 3.18 imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC] Explicit synchronization for Nouveau
On Mon, Sep 29, 2014 at 10:20:44AM -0700, James Jones wrote: > Additionally, I think the goal is to move to a model where some higher-level > object such as a working set, rather than individual buffers, are assigned > counters or sync primitives on a per-submission basis. Versioning off tags > for individual buffers then moves to working set modification time. This is > more feasible if the only thing that needs precise fencing of individual > surfaces is lifetime management. Yeah, there's always ways to make the fence assignment and tracking a bit more efficient, we're playing around with working-set tricks for i915 ourselves. But fundamentally you still have fences for each buffer object (just can't directly access them). And for buffers exported with dma_buf you still need the direct link I think, at least when you care about implicit syncing somewhat. > The trend seems to be towards establishing a relatively large working set up > front and then submitting many command buffers against it, perhaps with > incremental modifications to the working set along the way. This may be > what's referred to as the Android model above, but I view it as the > "non-glitchy graphic" model going forward. Nah, that's something different. Afaik Android drivers don't really bother a lot with swap and page migration and having a working shrinker for gpu objects. At least our android guys need to disable the lowmemory killer since that thing just goes bananas if we driver i915 memory usuage against the wall and into swap. I'm not really sure what you mean by "non-glitchy graphics", for me this can mean anything from avoiding stalls to proper syncing with vblanks to anything else really ... So might be good to elaborate here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/radeon: remove unecessary includes
Am 30.09.2014 um 04:46 schrieb Alex Deucher: > The requirement for these was removed in: > 0a168933976eb483da91161316cb74d00486 > > Signed-off-by: Alex Deucher Reviewed-by: Christian K?nig > --- > drivers/gpu/drm/radeon/evergreen.c | 1 - > drivers/gpu/drm/radeon/rv770.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/evergreen.c > b/drivers/gpu/drm/radeon/evergreen.c > index dbca60c..c09e40a 100644 > --- a/drivers/gpu/drm/radeon/evergreen.c > +++ b/drivers/gpu/drm/radeon/evergreen.c > @@ -22,7 +22,6 @@ >* Authors: Alex Deucher >*/ > #include > -#include > #include > #include > #include "radeon.h" > diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c > index d9f5ce7..372016e 100644 > --- a/drivers/gpu/drm/radeon/rv770.c > +++ b/drivers/gpu/drm/radeon/rv770.c > @@ -26,7 +26,6 @@ >* Jerome Glisse >*/ > #include > -#include > #include > #include > #include "radeon.h"
[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem
Am Dienstag, 30. September 2014, 10:10:20 schrieb Daniel Vetter: > On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote: > > From: Mark yao > > > > This add a display subsystem comprise the all display interface nodes. > > > > Signed-off-by: Mark Yao > > Signed-off-by: Daniel Kurtz > > Acked-by: Daniel Vetter > > Reviewed-by: Rob Clark > > Just a quick clarification: My ack was only about the drm driver itself, I > try really hard to stay away from DT insanity ;-) So please drop my ack > from these two patches. > > Aside: DT patches need to go through a special process and you must cc dt > maintainers and mailing lists. Your patch seems to lack this, which afaiui > is a blocker for merging the driver. Looking at the recipients I see the dt list (devicetree at vger.kernel.org) as well as the dt maintainers (Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell and Kumar Gala) listed there. So from this side it should be fine Heiko
[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem
On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote: > From: Mark yao > > This add a display subsystem comprise the all display interface nodes. > > Signed-off-by: Mark Yao > Signed-off-by: Daniel Kurtz > Acked-by: Daniel Vetter > Reviewed-by: Rob Clark Just a quick clarification: My ack was only about the drm driver itself, I try really hard to stay away from DT insanity ;-) So please drop my ack from these two patches. Aside: DT patches need to go through a special process and you must cc dt maintainers and mailing lists. Your patch seems to lack this, which afaiui is a blocker for merging the driver. Thanks, Daniel > --- > Changes in v2: > - add DRM master device node to list all display nodes that comprise > the graphics subsystem. > > Changes in v3: None > > Changes in v4: None > > Changes in v5: None > > Changes in v6: None > > Changes in v7: None > > Changes in v8: None > > .../devicetree/bindings/video/rockchip-drm.txt | 19 +++ > 1 file changed, 19 insertions(+) > create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt > > diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt > b/Documentation/devicetree/bindings/video/rockchip-drm.txt > new file mode 100644 > index 000..7fff582 > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt > @@ -0,0 +1,19 @@ > +Rockchip DRM master device > + > + > +The Rockchip DRM master device is a virtual device needed to list all > +vop devices or other display interface nodes that comprise the > +graphics subsystem. > + > +Required properties: > +- compatible: Should be "rockchip,display-subsystem" > +- ports: Should contain a list of phandles pointing to display interface port > + of vop devices. vop definitions as defined in > + Documentation/devicetree/bindings/video/rockchip-vop.txt > + > +example: > + > +display-subsystem { > + compatible = "rockchip,display-subsystem"; > + ports = <&vopl_out>, <&vopb_out>; > +}; > -- > 1.7.9.5 > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/radeon/cik: write gfx ucode version to ucode addr reg
Helpful for debugging as the version shows up in a register dump. Cc: Jay Cornwall Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/cik.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 0d761f7..05c2f43 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -4235,7 +4235,7 @@ static int cik_cp_gfx_load_microcode(struct radeon_device *rdev) WREG32(CP_PFP_UCODE_ADDR, 0); for (i = 0; i < fw_size; i++) WREG32(CP_PFP_UCODE_DATA, le32_to_cpup(fw_data++)); - WREG32(CP_PFP_UCODE_ADDR, 0); + WREG32(CP_PFP_UCODE_ADDR, le32_to_cpu(pfp_hdr->header.ucode_version)); /* CE */ fw_data = (const __le32 *) @@ -4244,7 +4244,7 @@ static int cik_cp_gfx_load_microcode(struct radeon_device *rdev) WREG32(CP_CE_UCODE_ADDR, 0); for (i = 0; i < fw_size; i++) WREG32(CP_CE_UCODE_DATA, le32_to_cpup(fw_data++)); - WREG32(CP_CE_UCODE_ADDR, 0); + WREG32(CP_CE_UCODE_ADDR, le32_to_cpu(ce_hdr->header.ucode_version)); /* ME */ fw_data = (const __be32 *) @@ -4253,7 +4253,8 @@ static int cik_cp_gfx_load_microcode(struct radeon_device *rdev) WREG32(CP_ME_RAM_WADDR, 0); for (i = 0; i < fw_size; i++) WREG32(CP_ME_RAM_DATA, le32_to_cpup(fw_data++)); - WREG32(CP_ME_RAM_WADDR, 0); + WREG32(CP_ME_RAM_WADDR, le32_to_cpu(me_hdr->header.ucode_version)); + WREG32(CP_ME_RAM_RADDR, le32_to_cpu(me_hdr->header.ucode_version)); } else { const __be32 *fw_data; @@ -4279,10 +4280,6 @@ static int cik_cp_gfx_load_microcode(struct radeon_device *rdev) WREG32(CP_ME_RAM_WADDR, 0); } - WREG32(CP_PFP_UCODE_ADDR, 0); - WREG32(CP_CE_UCODE_ADDR, 0); - WREG32(CP_ME_RAM_WADDR, 0); - WREG32(CP_ME_RAM_RADDR, 0); return 0; } @@ -4564,7 +4561,7 @@ static int cik_cp_compute_load_microcode(struct radeon_device *rdev) WREG32(CP_MEC_ME1_UCODE_ADDR, 0); for (i = 0; i < fw_size; i++) WREG32(CP_MEC_ME1_UCODE_DATA, le32_to_cpup(fw_data++)); - WREG32(CP_MEC_ME1_UCODE_ADDR, 0); + WREG32(CP_MEC_ME1_UCODE_ADDR, le32_to_cpu(mec_hdr->header.ucode_version)); /* MEC2 */ if (rdev->family == CHIP_KAVERI) { @@ -4578,7 +4575,7 @@ static int cik_cp_compute_load_microcode(struct radeon_device *rdev) WREG32(CP_MEC_ME2_UCODE_ADDR, 0); for (i = 0; i < fw_size; i++) WREG32(CP_MEC_ME2_UCODE_DATA, le32_to_cpup(fw_data++)); - WREG32(CP_MEC_ME2_UCODE_ADDR, 0); + WREG32(CP_MEC_ME2_UCODE_ADDR, le32_to_cpu(mec2_hdr->header.ucode_version)); } } else { const __be32 *fw_data; @@ -6227,7 +6224,7 @@ static int cik_rlc_resume(struct radeon_device *rdev) WREG32(RLC_GPM_UCODE_ADDR, 0); for (i = 0; i < size; i++) WREG32(RLC_GPM_UCODE_DATA, le32_to_cpup(fw_data++)); - WREG32(RLC_GPM_UCODE_ADDR, 0); + WREG32(RLC_GPM_UCODE_ADDR, le32_to_cpu(hdr->header.ucode_version)); } else { const __be32 *fw_data; -- 1.8.3.1
[PATCH v2 1/5] video: move mediabus format definition to a more standard place
On Mon, 29 Sep 2014 23:41:09 +0300 Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Monday 29 September 2014 16:02:39 Boris Brezillon wrote: > > Rename mediabus formats and move the enum into a separate header file so > > that it can be used by DRM/KMS subsystem without any reference to the V4L2 > > subsystem. > > > > Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_ > > definitions. > > > > Signed-off-by: Boris BREZILLON > > Acked-by: Guennadi Liakhovetski > > --- > > include/uapi/linux/Kbuild | 1 + > > include/uapi/linux/v4l2-mediabus.h| 183 +-- > > include/uapi/linux/video-bus-format.h | 127 +++ > > 3 files changed, 207 insertions(+), 104 deletions(-) > > create mode 100644 include/uapi/linux/video-bus-format.h > > One of the self-inflicted rules in V4L2 is to properly document every new > media bus format when adding it to the kernel. The documentation is located > in > Documentation/DocBook/media/v4l/subdev-formats.xml. If we move the formats to > a centralized header (which I believe is a good idea), we should also update > the documentation, and possibly its location. I really want to avoid getting > undocumented formats merged, and this will happen if we don't make the rule > clear and/or don't make the documentation easily accessible. Any idea where this new documentation should go (Documentation/DocBook/video/video-bus-formats.xml) ? > > Incidentally, patch 2/5 in this series is missing a documentation update ;-) Yep, regarding this patch, I wonder if it's really necessary to add new formats to the v4l2_mbus_pixelcode enum. If we want to move to this new common definition (across the video related subsytems), we should deprecate the old enum v4l2_mbus_pixelcode, and this start by not adding new formats, don't you think ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #58 from Michel D?nzer --- (In reply to comment #57) > I'm trying drm-next-3.18 and mesa git and many unreal engine demos are still > broken like this: > https://www.youtube.com/watch?v=NvgA9_B0dMo Are you sure that's directly related to the Unigine Heaven stuttering discussed in this report? E.g., does reverting the Mesa commit in question help, or do you see similar symptoms in the Gallium HUD? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/b7bf1bf1/attachment-0001.html>
[RESENT PATCH v7 1/3] drm: rockchip: Add basic drm driver
On 2014?09?29? 12:01, Daniel Kurtz wrote: > Hi Mark, > > More review comments inline... (sorry for the delay) Thanks for your review. > > On Fri, Sep 26, 2014 at 6:55 PM, Mark Yao wrote: >> From: Mark yao >> >> This patch adds the basic structure of a DRM Driver for Rockchip Socs. >> >> Signed-off-by: Mark Yao >> Signed-off-by: Daniel Kurtz >> Acked-by: Daniel Vetter >> Reviewed-by: Rob Clark >> --- >> Changes in v2: >> - 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. >> - use vop reset at first init >> - reference framebuffer when used and unreference when swap out vop >> >> 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 >> >> 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 | 516 + >> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 61 ++ >> drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 201 >> drivers/gpu/drm/rockchip/rockchip_drm_fb.h| 28 + >> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 230 >> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 + >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 345 ++ >> drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 55 + >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1422 >> + >> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 >> 14 files changed, 3102 insertions(+) >> create mode 100644 drivers/gpu/drm/rockchip/Kconfig >> create mode 100644 drivers/gpu/drm/rockchip/Makefile >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c >> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index b066bb3..7c4c3c6 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -171,6 +171,8 @@ config DRM_SAVAGE >> >> source "drivers/gpu/drm/exynos/Kconfig" >> >> +source "drivers/gpu/drm/rockchip/Kconfig" >> + >> source "drivers/gpu/drm/vmwgfx/Kconfig" >> >> source "drivers/gpu/drm/gma500/Kconfig" >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 4a55d59..d03387a 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ >> obj-$(CONFIG_DRM_VIA) +=via/ >> obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ >> obj-$(CONFIG_DRM_EXYNOS) +=exynos/ >> +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ >> obj-$(CONFIG_DRM_GMA500) += gma500/ >> obj-$(CONFIG_DRM_UDL) += udl/ >> obj-$(CONFIG_DRM_AST) += ast/ >> di
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 Christoph Haag changed: What|Removed |Added CC||haagch at frickel.club --- Comment #57 from Christoph Haag --- So almost a month has gone by... I'm trying drm-next-3.18 and mesa git and many unreal engine demos are still broken like this: https://www.youtube.com/watch?v=NvgA9_B0dMo (ignore the excessive jumpy frames that come from dri3 offloading) R600_DEBUG=nodma does not help by the way. Has there been any progress? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/9f64f886/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #2 from Michel D?nzer --- Can you run the browser with the environment variable RADEON_DUMP_CS=1, and attach any command stream dumps that generates on stderr? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/b41990f9/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #141 from Michel D?nzer --- If someone has a way to reliably reproduce the 'Packet0 not allowed!' error, please file a separate report for that. Or, if you know at least which process triggers it, you can run that process with the environment variable RADEON_DUMP_CS=1, and it should print a dump of the failed command stream(s) on stderr. P.S. I'm afraid this report has turned into a train wreck, it's impossible to keep track of who encountered what issue(s) under what circumstances. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/8bb889df/attachment.html>
[Bug 83500] si_dma_copy_tile causes GPU hangs
https://bugs.freedesktop.org/show_bug.cgi?id=83500 --- Comment #9 from Michel D?nzer --- Do the fixes from http://lists.freedesktop.org/archives/mesa-dev/2014-September/068738.html help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/e0cbc02a/attachment-0001.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #1 from Alexandre Demers --- Even when UVD is manually disabled, the error still shows in dmesg. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/a0d0e097/attachment.html>
[Bug 84500] New: [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 Priority: medium Bug ID: 84500 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] radeon :01:00.0: Packet0 not allowed! Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.demers at gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI On a 7950, I keep getting this error from time to time in dmesg: radeon :01:00.0: Packet0 not allowed! I have associated this error with playing either html5 or flash videos. It may happen when playing offline movies, but I can't tell since I haven't tested it. When the error happens, there is a slight "stuttering" (from a fraction of second to a few seconds). And then it continues. There is nothing in Xorg.0.log about it, and no other message than "radeon :01:00.0: Packet0 not allowed!" in dmesg. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/4b753c18/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #140 from Aaron B --- I dunno, I've had all those bugs, and when I'm stable, none happen to my knowldge. I think they're all same things, different ways of triggering. Or, maybe we do have multiple bugs. Chromium/Chrome/VLC/Video/Screen blanks: UVD What bugs should be classified as a different trigger? We should probably ping what is what now, that we have lots more people with the same problems posting. :) Also, started watching a movie, crashed in 5 minutes, UVD died. Turned off PM, and UVD is fine , an hour or so in to the movie, and I'm going to watch 2 more after it, so we'll see. If it's stable after 2 more hours, DPM is definitely causing something, maybe both bugs with UVD and GPU faulting/EQ overflow/MSC Numbers unequal. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/5263ec7a/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #139 from Alexandre Demers --- Created attachment 107099 --> https://bugs.freedesktop.org/attachment.cgi?id=107099&action=edit Xorg log when it froze -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/2816a417/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #138 from Alexandre Demers --- (In reply to comment #135) > (In reply to comment #134) > > I'd like to test disabling UVD. I'll dig in the kernel to report UVD as > > disabled for SI for this test. This should narrow where we have to look for > > this bug. > > Sometimes UVD functions are needed for power management to work correctly, > so not enabling UVD at all might not be an option either. But I'm not sure > if that applies to your hardware or not. > > Easiest way to disable UVD otherwise is to just add an "return -1" to the > beginning of radeon_uvd_init in the kernel module. Well, when disabling UVD as suggested, I had no hang when viewing movies all night long. No ring 5 error either. I did get some Packet0 errors though, which were "stuttering" the display for short times, but it never crashed. However, at one point, Xorg just froze (the sound was still playing and the mouse was moving but nothing else was responding) but I think it is a different bug (there is nothing in dmesg, but there is errors in Xorg.0.log). I'll attach the file in a second. If someone is sure this is a different bug, let me know so I'll open a new bug for it. Overall, I'd be tempted to point at UVD for the current bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/00de3091/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #137 from Aaron B --- I'm gonna try with more DPM to make sure the combo of DPM and DMA isn't what is causing it. I'm getting many more consistent crashes with Chrome. Also, seems by bug report here is a dup of this one just posted to, a month before mine: http://lists.freedesktop.org/archives/dri-devel/2014-September/069303.html Same everything, so yeah. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140930/13835f05/attachment.html>
[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 Jean-Michel Smith changed: What|Removed |Added CC||jean.michel.sm at gmail.com --- Comment #23 from Jean-Michel Smith --- I've seen this bug as well, through quite a few versions of 3.15 and 3.16. Sometimes it just freezes X, other times it hangs the entire system. Here is the output of the last hang (I was able to log in remotely as this time it didn't completely crash the system) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X] (uname -a) Linux prime 3.16.3-gentoo #1 SMP PREEMPT Thu Sep 18 20:59:58 CDT 2014 x86_64 Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz GenuineIntel GNU/Linux (lsmod) cfbfillrect 3634 1 radeon cfbimgblt 2055 1 radeon cfbcopyarea 3110 1 radeon i2c_algo_bit5055 1 radeon drm_kms_helper 33715 1 radeon ttm59052 1 radeon drm 226864 6 ttm,drm_kms_helper,radeon firmware_class 8187 1 radeon radeon 1258462 3 (relevant dmesg info) [120499.589293] radeon :01:00.0: ring 0 stalled for more than 10473msec [120499.589296] radeon :01:00.0: GPU lockup (waiting for 0x000783d0 last fence id 0x000783cf on ring 0) [120499.589299] radeon :01:00.0: failed to get a new IB (-35) [120500.099613] radeon :01:00.0: Saved 3600 dwords of commands on ring 0. [120500.099743] radeon :01:00.0: GPU softreset: 0x006C [120500.099746] radeon :01:00.0: GRBM_STATUS = 0xA0003028 [120500.099748] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 [120500.099750] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 [120500.099751] radeon :01:00.0: SRBM_STATUS = 0x2AC0 [120500.099862] radeon :01:00.0: SRBM_STATUS2 = 0x [120500.099864] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [120500.099866] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 [120500.099868] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 [120500.099870] radeon :01:00.0: R_008680_CP_STAT = 0x80010243 [120500.099872] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83146 [120500.099874] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44E84266 [120500.099876] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [120500.099879] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [120500.592138] radeon :01:00.0: GRBM_SOFT_RESET=0xDDFF [120500.592192] radeon :01:00.0: SRBM_SOFT_RESET=0x00100140 [120500.593350] radeon :01:00.0: GRBM_STATUS = 0x3028 [120500.593352] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 [120500.593354] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 [120500.593356] radeon :01:00.0: SRBM_STATUS = 0x2AC0 [120500.593466] radeon :01:00.0: SRBM_STATUS2 = 0x [120500.593468] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [120500.593470] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [120500.593472] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [120500.593473] radeon :01:00.0: R_008680_CP_STAT = 0x [120500.593475] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [120500.593477] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 [120500.593718] radeon :01:00.0: GPU reset succeeded, trying to resume [120500.621478] [drm] probing gen 2 caps for device 8086:3c04 = 7a7103/e [120500.621482] [drm] PCIE gen 3 link speeds already enabled [120500.623908] [drm] PCIE GART of 1024M enabled (table at 0x00276000). [120500.624051] radeon :01:00.0: WB enabled [120500.624054] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x8807fb4aac00 [120500.624056] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x8807fb4aac04 [120500.624058] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x8807fb4aac08 [120500.624059] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x8807fb4aac0c [120500.624061] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x8807fb4aac10 [120500.624680] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc900142b5a18 [120500.789277] [drm] ring test on 0 succeeded in 3 usecs [120500.789283] [drm] ring test on 1 succeeded in 1 usecs [120500.789287] [drm] ring test on 2 succeeded in 1 usecs [120500.789351] [drm] ring test on 3 succeeded in 2 usecs [120500.789