[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails

[Keith Packard]

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

[Mark Yao]

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 = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v9 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark Yao]

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 = <_out>, <_out>;
+};
-- 
1.7.9.5

[PATCH v9 1/3] drm: rockchip: Add basic drm driver

[Mark Yao]

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 

[PATCH v9 0/3] Add drm driver for Rockchip Socs

[Mark Yao]

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

[Matt Turner]

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

[Mark Brown]

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(>hdmi->dev,
> +  "hdmi-audio-codec",
> +   PLATFORM_DEVID_NONE,
> +   NULL, 0,
> +   _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

[Mark Brown]

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

[Keith Packard]

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, 
))
+   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_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, 
_fd))
+   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_FD, 
_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

[Andrzej Hajda]

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(>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(>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(>object_name_lock);
-- 
1.9.1

[Bug 84519] New: GPU hang xbmc tvheadend uvd

[bugzilla-dae...@freedesktop.org]

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=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

[Mark yao]

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 = <_out>, <_out>;
>> +};
>> -- 
>> 1.7.9.5
>>
>>

[PATCH v9 1/3] drm: rockchip: Add basic drm driver

[Andrzej Hajda]

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

[Tomi Valkeinen]

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

[Daniel Vetter]

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(>crtcs[i]->base,
> - priv->rotation_prop, 0);
> - }
> -
> - for (i = 0; i < priv->num_planes; i++) {
> - drm_object_property_set_value(>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_property 

[PATCH] drm/i915: don't crash if unable to setup stolen

[Rob Clark]

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

[Tomi Valkeinen]

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

[Tomi Valkeinen]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[Mark Yao]

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 = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v8 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark Yao]

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 = <_out>, <_out>;
+};
-- 
1.7.9.5

[PATCH v8 1/3] drm: rockchip: Add basic drm driver

[Mark Yao]

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

[PATCH v8 0/3] Add drm driver for Rockchip Socs

[Mark Yao]

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

[Daniel Vetter]

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

[Daniel Vetter]

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

[Daniel Vetter]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@freedesktop.org]

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

[Andrzej Hajda]

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(_driver);
> - if (ret < 0)
> - return ret;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_DP
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_fimd_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_DSI
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_dp_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_HDMI
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_dsi_drv;
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_mixer_drv;
> + _driver,
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_G2D
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_hdmi_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_FIMC
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_g2d_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_ROTATOR
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_fimc_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_GSC
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_rotator_drv;
> + _driver,
>  #endif
> -
>  #ifdef CONFIG_DRM_EXYNOS_IPP
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_gsc_drv;
> + _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(>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(_driver);
> -err_unregister_gsc_drv:
> -#endif
>  
> -#ifdef CONFIG_DRM_EXYNOS_GSC
> - platform_driver_unregister(_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(_driver);
> -err_unregister_fimc_drv:
> -#endif
> -
> -#ifdef CONFIG_DRM_EXYNOS_FIMC
> - platform_driver_unregister(_driver);
> -err_unregister_g2d_drv:
> -#endif
> -
> -#ifdef CONFIG_DRM_EXYNOS_G2D
> - platform_driver_unregister(_driver);
> -err_unregister_hdmi_drv:
> 

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

[bugzilla-dae...@freedesktop.org]

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=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!

[bugzilla-dae...@freedesktop.org]

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.

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[Damien Lespiau]

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

[Boris Brezillon]

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

[Thomas Wood]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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=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

[Thierry Reding]

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

[bugzilla-dae...@bugzilla.kernel.org]

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=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

[Daniel Vetter]

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

[Daniel Vetter]

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

[Christian König]

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

[Heiko Stübner]

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

[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.

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 = <_out>, <_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

[Alex Deucher]

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

[Boris Brezillon]

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

[bugzilla-dae...@freedesktop.org]

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

[Mark yao]

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/
>> 

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

[bugzilla-dae...@freedesktop.org]

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!

[bugzilla-dae...@freedesktop.org]

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.

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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!

[bugzilla-dae...@freedesktop.org]

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!

[bugzilla-dae...@freedesktop.org]

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.

[bugzilla-dae...@freedesktop.org]

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.

[bugzilla-dae...@freedesktop.org]

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=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.

[bugzilla-dae...@freedesktop.org]

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.

[bugzilla-dae...@freedesktop.org]

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?)

[bugzilla-dae...@bugzilla.kernel.org]

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

[PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Laurent Pinchart]

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.

Incidentally, patch 2/5 in this series is missing a documentation update ;-)

-- 
Regards,

Laurent Pinchart