[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

https://bugs.freedesktop.org/show_bug.cgi?id=84232

--- Comment #5 from Tom Stellard  ---
It looks like the following sequence may trigger this bug:

for () {
  if (){
break;
  }
  if () {
if () {
break;
}
  }
  if () {
 break;
  }
}

I will investigate further.

-- 
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/20141008/adfb20ed/attachment.html>

FirePro W600 problem

[Andrey Germakovski]

FirePro W600 does not work with more than 4 monitors,

After 5th  monitor attached X acting very slow.

Or if I call drmModeSetCrtc function 5 times one time for each of the monitors, 
it failing out

Andrey
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141008/a3efaf77/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

https://bugs.freedesktop.org/show_bug.cgi?id=82201

Kai  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #32 from Kai  ---
Since upgrading to the stack detailed first in bug 84570, comment #5, I have a
constantly reclocking GPU. Not sure if I missed some patch in my builds of
Alex' drm-next-3.17 branch or if 3.17 brought something else along, which
helpt, but AFAICT this is resolved.

Now, however, the GPU doesn't seem to go to the maximum clock anylonger (mclk
goes to max, but I haven't seen the sclk go to max). But I think that's a
different bug/problem.

-- 
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/20141008/ad3f27f6/attachment.html>

[PATCH] video/hdmi: Relicense header under MIT license

[Thierry Reding]

From: Thierry Reding 

OpenBSD wants to reuse this file but needs the license to be more
permissive.

Acked-by: Alban Bedel 
Acked-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 include/linux/hdmi.h | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 11c0182a153b..cbb5790a35cd 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -1,9 +1,24 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
  */

 #ifndef __LINUX_HDMI_H_
-- 
2.1.0

AMD GPU new API for new module

[Christian König]

Hi Jerome,

yeah that's what we have already planned for the IOCTLs anyway.

The main question currently is rather how we do the fence representation 
and synchronization between different engines.

For fences I think we can agree to use 64bit values (maybe plus engine 
index) for internal representation and android style fence fds for 
sharing them between applications/drivers (assuming the android fences 
ever leave staging).

But what should we do for inter engine synchronization? One requirement 
from our closed source teams is that we have semaphore/mutex style 
synchronization, e.g. fences are only used for GPU to CPU sync, but for 
GPU to GPU sync you have a different sync object type.

Semaphores work like having a mutex that protects resources from 
concurrent access, e.g. we can do two command submissions that need 
access to buffer A and we don't care which command submission runs first 
as long as they don't run at the same time.

The obvious down side is that you inherit problems like lock inversions 
and so you can build deadlocks with them, e.g. command submission A 
needs to wait for B and B needs to wait for A. Which are hard to detect 
and resolve in the kernel except for using timeouts.

Ideas or thoughts on that?

Regards,
Christian.

Am 08.10.2014 um 18:00 schrieb Jerome Glisse:
> Hi,
>
> So if i do not start the discussion now it might be already too late. Given
> plan to converge open source driver and closed source driver to use a single
> common kernel driver and that this would be a new kernel driver. This is an
> opportunity to fix some of the radeon design issues (at least things that i
> would have done differently if only i could get some gas for my DeLorean).
>
> Among the thing that i will not do is the chunk stuff associated with cs
> ioctl. I find it ugly, if my memory serve me well i was trying to be future
> proof and allow the cs ioctl to be extended. While this original aim have
> been somewhat successfully, i think it was the wrong day to do it.
>
> My lastest (and what i still believe to be a good idea until proven wrong),
> is to change the way we do ioctl and use a little trick. This idea was also
> spark by the continuous additions we do to info ioctl which is getting ugly.
>
> So idea is simple, each ioctl would use some struct like :
>
> struct radeon_ioctl {
>   u32 version;
>   u32 size;
> };
>
> The version field is the key here, think of it as an index into an array of
> ioctl dispatch functions. So something like :
>
> struct radeon_ioctls {
>   int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
> };
>
> struct radeon_ioctls rdispatch_ioctls[N];
>
> And now all ioctl go through this single entry point :
>
> int radeon_ioctl_stub(int ioctl, void *data, ...)
> {
>   struct radeon_ioctl *rio = data;
>
>   return rdispatch_ioctls[rio->version][ioctl](data, ...);
> }
>
> So this is rough idea but the point is that we can do proper ioctl versioning
> and have separate functions for each new versions and avoid ioctl cruft, or
> at least this is the theory.
>
> The two things this gave us, is feedback from userspace as we the version the
> kernel will know which version of userspace it is dealing with. The others one
> is that it does allow you to introduce a completely new API either for new
> generation of hardware or just as an evolution. And small bonus is that it
> does allow to slowly phase out API that we consider broken (ioctl per ioctl).
>
> So this is the main design change that i would do. I should probably rought
> up something that goes deeper for the cs ioctl.
>
> Cheers,
> J?r?me
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v11 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

Changes in v10: None

Changes in v11: 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 v11 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

Changes in v10: None

Changes in v11: 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 v11 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.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend.

 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   |  449 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  293 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1427 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 2959 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
+++ 

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

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Changes in v11:
- fix mistake that use wrong variable at rockchip sys_resume/sys_suspend

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|  449 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  293 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1427 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3036 insertions(+)

-- 
1.7.9.5

[PATCH 1/2] drm/tegra: Set the dsi lp clk parent and rate

[Peter De Schrijver]

On Mon, Sep 22, 2014 at 12:11:54PM +0200, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Sep 22, 2014 at 11:00:56AM +0200, Lucas Stach wrote:
> > Am Freitag, den 19.09.2014, 15:53 -0400 schrieb Sean Paul:
> > > Per NVidia, this clock rate should be around 70MHz in
> > > order to properly sample reads on data lane 0. In order
> > > to achieve this rate, we need to reparent the clock from
> > > clk_m which can only achieve 12MHz. Add parent_lp to the
> > > dts bindings and set the parent & rate on init.
> > > 
> > > Signed-off-by: Sean Paul 
> > 
> > NACK
> > 
> > You are pushing SoC integration details into the binding of the device.
> > 
> > You have two reasonable routes to go here: either the clock driver needs
> > to be made smarter to reparent the clock in case the required clock rate
> > could not be achieved with the current parent or you go the easy route
> > and reparent the clock as part of the initial configuration.
> 
> Agreed. There doesn't seem to be a case where it would make sense to
> have this configurable per-board. Can you achieve the same effect by
> adding this to the clock initialization table?
> 
> Oh, I just see that we have this in the Tegra124 clock initialization
> table:
> 
>   {TEGRA114_CLK_DSIALP, TEGRA114_CLK_PLL_P, 6800, 0},
>   {TEGRA114_CLK_DSIBLP, TEGRA114_CLK_PLL_P, 6800, 0},
> 
> Doesn't that work for you already? If not that'd be a bug that should be
> fixed in the clock driver.

This seems the better approach indeed. Unless the rate would differ based
on board or other external factors.

Cheers,

Peter.

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

[Mark yao]

On 2014?10?08? 12:23, 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.
>
> Changes in v10:
> Adviced by Andrzej Hajda
> - check drm_dev if it's NULL at PM suspend/resume
> Adviced by Sean Paul
> - use drm_fb_helper_prepare to init fb_helper funcs
> - Optimized code structure and remove some unnecessary Variables.
>
>   drivers/gpu/drm/Kconfig   |2 +
>   drivers/gpu/drm/Makefile  |1 +
>   drivers/gpu/drm/rockchip/Kconfig  |   17 +
>   drivers/gpu/drm/rockchip/Makefile |8 +
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  465 
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
>   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
>   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
>   drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
>   drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1415 
> +
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
>   14 files changed, 2965 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 

[PATCH v3 4/4] imx-drm: ipuv3-plane: fix plane updates for active planes

[Philipp Zabel]

While the DMA channel is running, it is not allowed to change anything
but the inactive (double) buffer base address, so resizing a plane or
changing to a frame buffer with different pixel format is not possible.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipuv3-plane.c | 15 +++
 drivers/staging/imx-drm/ipuv3-plane.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index ada0d11..3df8fe2 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -143,6 +143,18 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
if (crtc_h < 2)
return -EINVAL;

+   /*
+* since we cannot touch active IDMAC channels, we do not support
+* resizing the enabled plane or changing its format
+*/
+   if (ipu_plane->enabled) {
+   if (src_w != ipu_plane->w || src_h != ipu_plane->h ||
+   fb->pixel_format != ipu_plane->base.fb->pixel_format)
+   return -EINVAL;
+
+   return ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
+   }
+
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ret = ipu_dp_setup_channel(ipu_plane->dp,
@@ -202,6 +214,9 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
if (ret < 0)
return ret;

+   ipu_plane->w = src_w;
+   ipu_plane->h = src_h;
+
return 0;
 }

diff --git a/drivers/staging/imx-drm/ipuv3-plane.h 
b/drivers/staging/imx-drm/ipuv3-plane.h
index c0aae5b..af125fb 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.h
+++ b/drivers/staging/imx-drm/ipuv3-plane.h
@@ -26,6 +26,8 @@ struct ipu_plane {

int x;
int y;
+   int w;
+   int h;

boolenabled;
 };
-- 
2.1.0

[PATCH v3 3/4] imx-drm: ipuv3-plane: enable double buffering

[Philipp Zabel]

This allows to update the buffer base address while the DMA
channel is running. It is needed to flip the frame buffer of
an active plane.

Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Rebased onto 7d2691da901d (gpu: ipu-v3: Add ipu-cpmem unit)
---
 drivers/staging/imx-drm/ipuv3-plane.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index 43dd88e..ada0d11 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -64,6 +64,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct 
drm_framebuffer *fb,
 {
struct drm_gem_cma_object *cma_obj;
unsigned long eba;
+   int active;

cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
if (!cma_obj) {
@@ -76,8 +77,15 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct 
drm_framebuffer *fb,

eba = cma_obj->paddr + fb->offsets[0] +
  fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
-   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
-   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
+
+   if (ipu_plane->enabled) {
+   active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
+   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
+   ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
+   } else {
+   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
+   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
+   }

/* cache offsets for subsequent pageflips */
ipu_plane->x = x;
@@ -187,6 +195,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
return ret;
}
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
+   ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]);

ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
-- 
2.1.0

[PATCH v3 2/4] imx-drm: ipuv3-plane: move stride setting out of base setup

[Philipp Zabel]

Setting the stride can only be done on inactive channels, while
the buffer base address can also be updated for running channels
using the hardware double buffering feature.

Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Rebased onto 7d2691da901d (gpu: ipu-v3: Add ipu-cpmem unit)
---
 drivers/staging/imx-drm/ipuv3-plane.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index c293917..43dd88e 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -74,8 +74,6 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct 
drm_framebuffer *fb,
dev_dbg(ipu_plane->base.dev->dev, "phys = %pad, x = %d, y = %d",
_obj->paddr, x, y);

-   ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]);
-
eba = cma_obj->paddr + fb->offsets[0] +
  fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
@@ -189,6 +187,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
return ret;
}
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
+   ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]);

ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
if (ret < 0)
-- 
2.1.0

[PATCH v3 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()

[Philipp Zabel]

For the overlay plane scanning out a framebuffer with an alpha component,
enable the DP local alpha feature on the partial plane.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index 697aad2..c293917 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -148,14 +148,22 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, 
struct drm_crtc *crtc,
ret);
return ret;
}
-   ipu_dp_set_global_alpha(ipu_plane->dp, 1, 0, 1);
+   ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
break;
case IPU_DP_FLOW_SYNC_FG:
ipu_dp_setup_channel(ipu_plane->dp,
ipu_drm_fourcc_to_colorspace(fb->pixel_format),
IPUV3_COLORSPACE_UNKNOWN);
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
-   break;
+   /* Enable local alpha on partial plane */
+   switch (fb->pixel_format) {
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
+   break;
+   default:
+   break;
+   }
}

ret = ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
-- 
2.1.0

[PATCH] gpu: ipu-v3: Fix IC control register offset

[Philipp Zabel]

The IC register offset is at +0x2 relative to the control module
registers on all IPUv3 versions. This patch fixes wrong values for
i.MX51 and i.MX53.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index f707d25..67bab5c 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -742,7 +742,7 @@ static struct ipu_devtype ipu_type_imx51 = {
.tpm_ofs = 0x1f06,
.csi0_ofs = 0x1f03,
.csi1_ofs = 0x1f038000,
-   .ic_ofs = 0x1f02,
+   .ic_ofs = 0x1e02,
.disp0_ofs = 0x1e04,
.disp1_ofs = 0x1e048000,
.dc_tmpl_ofs = 0x1f08,
@@ -758,7 +758,7 @@ static struct ipu_devtype ipu_type_imx53 = {
.tpm_ofs = 0x0706,
.csi0_ofs = 0x0703,
.csi1_ofs = 0x07038000,
-   .ic_ofs = 0x0702,
+   .ic_ofs = 0x0602,
.disp0_ofs = 0x0604,
.disp1_ofs = 0x06048000,
.dc_tmpl_ofs = 0x0708,
-- 
2.1.0

[Bug 79980] Random radeonsi crashes

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

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #145 from Daniel Kozak  ---
Same issue with my HD 7770 on 3.16 and 3.17 (much often). Even trying to write
this comment here cause crash. So I am unable to write more details on this pc,
because of time to crash is reali tiny :(

-- 
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/20141008/b0c7d370/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #32 from Andreas Hartmetz  ---
OK, looks like the patch will apply to current Linux drm-next. Should have read
comment 19. Sorry.

-- 
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/20141008/fe1cfc22/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #31 from Andreas Hartmetz  ---
The second kernel patch "radeon-NO_CPU_ACCESS-placement.diff" does not apply to
3.17.
Michel, looks like the patch is against some version only you have?
Andy, I think you didn't apply at least the second kernel patch because it's
simply not possible, most likely you ignored that all hunks failed.

-- 
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/20141008/bea39979/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #30 from Andy Furniss  ---
Created attachment 107560
  --> https://bugs.freedesktop.org/attachment.cgi?id=107560=edit
Hud with 2 kernel and 2 mesa patches better but still bad.

-- 
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/20141008/664d3ba7/attachment.html>

[PULL] topic/vblank-rework, take 2

[Thierry Reding]

On Fri, Sep 12, 2014 at 09:48:59AM +0200, Daniel Vetter wrote:
[...]
> Ville Syrj?l? (16):
>   drm: Always reject drm_vblank_get() after drm_vblank_off()

This particular commit seems to be wreaking havoc. Inki already reported
this at some point and Andrzej and Joonyoung tried to fix this on Exynos
already, but it seems like a couple more drivers would suffer from this.
At least those using drm_vblank_off() but not drm_vblank_on() would see
the same issue.

A quick grep indicate that Armada, Exynos, GMA500 and STI would all
suffer from the same problem. Adding the respective maintainers. I've
used the attached patch to fix the issue on Tegra.

Ville, does that conversion look right? Perhaps it would be safer to
call drm_crtc_vblank_on() before activating the CRTC to avoid a
potential race? It seems like drm_vblank_on() and drm_vblank_off()
would replace drm_vblank_{pre,post}_modeset() completely, so I've
removed them as part of the patch as well.

I suppose the attached patch and equivalent ones for the other drivers
would need to be carried in this series to avoid regressions.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-tegra-dc-Add-missing-call-to-drm_vblank_on.patch
Type: text/x-diff
Size: 1991 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141008/5528c6a5/attachment.patch>
-- 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/20141008/5528c6a5/attachment.sig>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #29 from Andy Furniss  ---
(In reply to Michel D?nzer from comment #27)
> Created attachment 107544 [details] [review]
> drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
> 
> Please try current Mesa with no patches except for the two I just attached,
> plus this kernel patch together with the previous kernel patch.

With these it's better but still a bad. There are still pauses but they are a
bit shorter, the start time without intervention is still around 2min. Start
time on a good is around 1 min (assuming first run or mem caches flushed).

Hud wise - pic to follow the vram req/used match well, but the gtt is still
different from a good.

On the upside - Unigine Valley is the best I've ever seen it - way better than
what I've called as good in the past.

-- 
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/20141008/54b4f576/attachment.html>

[PATCH] drm: Implement O_NONBLOCK support on /dev/dri/cardN

[Daniel Vetter]

On Wed, Oct 08, 2014 at 10:45:48AM +0100, Chris Wilson wrote:
> On Wed, Oct 08, 2014 at 11:16:38AM +0200, Daniel Vetter wrote:
> > On Tue, Oct 7, 2014 at 3:13 PM, Chris Wilson  
> > wrote:
> > > The implmentation is simple in the extreme: we only want to wait for
> > > events if the device was opened in blocking mode, otherwise we grab what
> > > is available and report an error if there was none.
> > >
> > > Signed-off-by: Chris Wilson 
> > > Cc: dri-devel at lists.freedesktop.org
> >
> > Testcase for nonblocking behaviour in kms_flip?
>
> To the further dismay of anyone running kms_flip today,
> Testcase: igt/kms_flip/nonblocing_read

Not if they upgrade to -nightly ;-) Thanks for the patch, merged to
topic/core-stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Steven Newbury]

On Wed, 2014-10-08 at 09:17 +0800, Mark yao wrote:
> Hi Steven
>  I'm glad to see you to discuss about rk29xx.
> 
> On 2014?10?08? 06:26, Steven Newbury wrote:
> > I've just been discussing how this relates to rk29xx on #etnaviv.  
> > I
> > looked through the patch and it's good to see it's not limited to
> > supporting Mali GPUs.  I see no reason this wouldn't be compatible
> > with etna_viv for rk29xx (or future Rockchip designs with 
> > alternative
> > GPUs) as long as the rest of the infrastructure to support rk29 is 
> > in
> > place iommu (ARM SMMU?) driver, for example.
> Now the drm driver only test on rk3288, and future when we add
> compatible for rk29xx, we
> would consider to add a non-iommu path for it.
That's great! I'm working on trying to update the rk29 driver support. 
 Getting it supported where possible with the new drivers would make 
it much easier, hopefully such that simply creating a new dts file 
would produce a working kernel for any useful hardware out there.

> > IMHO it's vital to keep a logical separation between the video 
> > display
> > hardware and the graphics processor on SoCs.
> Sure, the graphics processor maybe change in different solutions,
> logical separation is that we
> try to keep.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141008/1304570f/attachment.sig>

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

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

https://bugs.freedesktop.org/show_bug.cgi?id=79659

--- Comment #14 from Alexander Tsoy  ---
Interesting.. My Bonaire XTX (R7 260X) is not affected by this bug. How is this
possible? Cape Verde PRO (HD 7750) is affected and workaround from comment 6
fixes the problem. On both systems I have mesa-10.3 which contains the commit
mentioned in comment 0.

-- 
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/20141008/fa57e771/attachment.html>

[PATCH v7 05/11] drm: add Atmel HLCDC Display Controller support

[Nicolas Ferre]

On 01/10/2014 16:53, Boris Brezillon :
> From: Boris BREZILLON 
> 
> The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> controller device.
> 
> This display controller supports at least one primary plane and might
> provide several overlays and an hardware cursor depending on the IP
> version.
> 
> At the moment, this driver only implements an RGB connector to interface
> with LCD panels, but support for other kind of external devices might be
> added later.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Rob Clark 
> Tested-by: Anthony Harivel 
> Tested-by: Ludovic Desroches 
> ---
>  drivers/gpu/drm/Kconfig  |   2 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/atmel-hlcdc/Kconfig  |  13 +
>  drivers/gpu/drm/atmel-hlcdc/Makefile |   7 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 390 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 531 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 216 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 638 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 394 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 443 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 831 
> +++
>  11 files changed, 3466 insertions(+)
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
>  create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b066bb3..2d97f7e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -185,6 +185,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
>  
>  source "drivers/gpu/drm/armada/Kconfig"
>  
> +source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
> +
>  source "drivers/gpu/drm/rcar-du/Kconfig"
>  
>  source "drivers/gpu/drm/shmobile/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4a55d59..abb4f29 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
>  obj-$(CONFIG_DRM_UDL) += udl/
>  obj-$(CONFIG_DRM_AST) += ast/
>  obj-$(CONFIG_DRM_ARMADA) += armada/
> +obj-$(CONFIG_DRM_ATMEL_HLCDC)+= atmel-hlcdc/
>  obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
>  obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>  obj-$(CONFIG_DRM_OMAP)   += omapdrm/
> diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig 
> b/drivers/gpu/drm/atmel-hlcdc/Kconfig
> new file mode 100644
> index 000..942407f
> --- /dev/null
> +++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig
> @@ -0,0 +1,13 @@
> +config DRM_ATMEL_HLCDC
> + tristate "DRM Support for ATMEL HLCDC Display Controller"
> + depends on DRM && OF && COMMON_CLK
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_PANEL
> + select MFD_ATMEL_HLCDC
> + depends on OF
> + help
> +   Choose this option if you have an ATMEL SoC with an HLCDC display
> +   controller (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family).
> diff --git a/drivers/gpu/drm/atmel-hlcdc/Makefile 
> b/drivers/gpu/drm/atmel-hlcdc/Makefile
> new file mode 100644
> index 000..10ae426
> --- /dev/null
> +++ b/drivers/gpu/drm/atmel-hlcdc/Makefile
> @@ -0,0 +1,7 @@
> +atmel-hlcdc-dc-y := atmel_hlcdc_crtc.o \
> + atmel_hlcdc_dc.o \
> + atmel_hlcdc_layer.o \
> + atmel_hlcdc_output.o \
> + atmel_hlcdc_plane.o
> +
> +obj-$(CONFIG_DRM_ATMEL_HLCDC)+= atmel-hlcdc-dc.o
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> new file mode 100644
> index 000..02f7a98
> --- /dev/null
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -0,0 +1,390 @@
> +/*
> + * Copyright (C) 2014 Traphandler
> + * Copyright (C) 2014 Free Electrons
> + *
> + * Author: Jean-Jacques Hiblot 
> + * Author: Boris BREZILLON 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.

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

https://bugzilla.kernel.org/show_bug.cgi?id=85421

--- Comment #2 from Hin-Tak Leung  ---
The patches listed above don't fix the problem. Had another GPU lock-up while
just switching window from an upload file dialog in firefox (another bugzilla
else) to a terminal to change permission of the file being uploaded...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 84981] Random crashes related to radeon.

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

https://bugzilla.kernel.org/show_bug.cgi?id=84981

--- Comment #4 from Apostolos B.  ---
This and the previous happened while watching YT videos but it might be
unrelated. 

Oct 08 15:23:27 mainland kernel: general protection fault:  [#1] PREEMPT
SMP 
Oct 08 15:23:27 mainland kernel: Modules linked in: mousedev cfg80211 rfkill
hid_logitech_dj hid_generic usbhid hid snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt w83627ehf hwmon_vid
iTCO_vendor_support nls_i
Oct 08 15:23:27 mainland kernel:  mbcache jbd2 ehci_hcd xhci_hcd usbcore sr_mod
cdrom usb_common sd_mod crc_t10dif crct10dif_common ahci libahci libata
scsi_mod radeon hwmon i2c_algo_bit drm_kms_helper ttm drm i2c_core
Oct 08 15:23:27 mainland kernel: CPU: 1 PID: 411 Comm: Xorg.bin Not tainted
3.16.4-1-ARCH #1
Oct 08 15:23:27 mainland kernel: Hardware name:  /DZ77BH-55K,
BIOS BHZ7710H.86A.0094.2012.1101.1115 11/01/2012
Oct 08 15:23:27 mainland kernel: task: 88031be1dbb0 ti: 8803167c4000
task.ti: 8803167c4000
Oct 08 15:23:27 mainland kernel: RIP: 0010:[] 
[] kmem_cache_alloc_trace+0x6f/0x170
Oct 08 15:23:27 mainland kernel: RSP: 0018:8803167c7940  EFLAGS: 00010286
Oct 08 15:23:27 mainland kernel: RAX:  RBX: 
RCX: 6fb5df01
Oct 08 15:23:27 mainland kernel: RDX: 6fb5de81 RSI: 00d0
RDI: a007deb1
Oct 08 15:23:27 mainland kernel: RBP: 8803167c7970 R08: 000173a0
R09: ea00027ba680
Oct 08 15:23:27 mainland kernel: R10: a007e011 R11: 
R12: ff030100ff030100
Oct 08 15:23:27 mainland kernel: R13: 00d0 R14: 
R15: 880322803b00
Oct 08 15:23:27 mainland kernel: FS:  7f57717488c0()
GS:88032f24() knlGS:
Oct 08 15:23:27 mainland kernel: CS:  0010 DS:  ES:  CR0:
80050033
Oct 08 15:23:27 mainland kernel: CR2: 7f5765516000 CR3: cac91000
CR4: 001407e0
Oct 08 15:23:27 mainland kernel: Stack:
Oct 08 15:23:27 mainland kernel:  0028 
 88009ee9ac20
Oct 08 15:23:27 mainland kernel:   88031be88d80
8803167c7a60 a007deb1
Oct 08 15:23:27 mainland kernel:  88031be1dbb0 88031be88de4
88031be88da8 88031d1fc098
Oct 08 15:23:27 mainland kernel: Call Trace:
Oct 08 15:23:27 mainland kernel:  []
ttm_dma_populate+0x581/0xa10 [ttm]
Oct 08 15:23:27 mainland kernel:  [] ? __kmalloc+0x18a/0x1c0
Oct 08 15:23:27 mainland kernel:  []
radeon_ttm_tt_populate+0x21f/0x240 [radeon]
Oct 08 15:23:27 mainland kernel:  [] ttm_tt_bind+0x40/0x80
[ttm]
Oct 08 15:23:27 mainland kernel:  []
ttm_bo_handle_move_mem+0x5bf/0x650 [ttm]
Oct 08 15:23:27 mainland kernel:  [] ?
ttm_bo_mem_space+0x16b/0x350 [ttm]
Oct 08 15:23:27 mainland kernel:  []
ttm_bo_validate+0x265/0x280 [ttm]
Oct 08 15:23:27 mainland kernel:  [] ttm_bo_init+0x24e/0x3a0
[ttm]
Oct 08 15:23:27 mainland kernel:  []
radeon_bo_create+0x164/0x210 [radeon]
Oct 08 15:23:27 mainland kernel:  [] ?
radeon_update_memory_usage.isra.3+0x60/0x60 [radeon]
Oct 08 15:23:27 mainland kernel:  []
radeon_gem_object_create+0xb6/0x1a0 [radeon]
Oct 08 15:23:27 mainland kernel:  []
radeon_gem_create_ioctl+0x6e/0x180 [radeon]
Oct 08 15:23:27 mainland kernel:  [] drm_ioctl+0x1df/0x680
[drm]
Oct 08 15:23:27 mainland kernel:  [] ?
timerqueue_add+0x60/0xb0
Oct 08 15:23:27 mainland kernel:  []
radeon_drm_ioctl+0x4c/0x80 [radeon]
Oct 08 15:23:27 mainland kernel:  [] do_vfs_ioctl+0x2d0/0x4b0
Oct 08 15:23:27 mainland kernel:  [] ? __fget+0x6e/0xb0
Oct 08 15:23:27 mainland kernel:  [] SyS_ioctl+0x81/0xa0
Oct 08 15:23:27 mainland kernel:  []
system_call_fastpath+0x16/0x1b
Oct 08 15:23:27 mainland kernel: Code: 0f 84 c6 00 00 00 4c 8b 20 4d 85 e4 0f
84 da 00 00 00 48 83 78 10 00 0f 84 cf 00 00 00 49 63 47 20 48 8d 8a 80 00 00
00 4d 8b 07 <49> 8b 1c 04 4c 89 e0 65 49 0f c7 08 0f 94 c0 84 c0 74 a2 49 63 
Oct 08 15:23:27 mainland kernel: RIP  []
kmem_cache_alloc_trace+0x6f/0x170
Oct 08 15:23:27 mainland kernel:  RSP 
Oct 08 15:23:27 mainland kernel: general protection fault:  [#2] PREEMPT
SMP 
Oct 08 15:23:27 mainland kernel: Modules linked in: mousedev cfg80211 rfkill
hid_logitech_dj hid_generic usbhid hid snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt w83627ehf hwmon_vid
iTCO_vendor_support nls_i
Oct 08 15:23:27 mainland kernel:  mbcache jbd2 ehci_hcd xhci_hcd usbcore sr_mod
cdrom usb_common sd_mod crc_t10dif crct10dif_common ahci libahci libata
scsi_mod radeon hwmon i2c_algo_bit drm_kms_helper ttm drm i2c_core
Oct 08 15:23:27 mainland kernel: CPU: 1 PID: 411 Comm: Xorg.bin Not tainted
3.16.4-1-ARCH #1
Oct 08 15:23:27 mainland kernel: Hardware name:  /DZ77BH-55K,
BIOS BHZ7710H.86A.0094.2012.1101.1115 11/01/2012
Oct 08 15:23:27 mainland kernel: task: 88031be1dbb0 ti: 8803167c4000
task.ti: 8803167c4000
Oct 08 15:23:27 mainland kernel: RIP: 0010:[] 
[] 

[PATCH v10 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

Changes in v10: 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 v10 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

Changes in v10: 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 v10 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.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  465 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1415 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 2965 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/
 

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

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Mark yao (3):
  drm: rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  465 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  294 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1415 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3042 insertions(+)

-- 
1.7.9.5

[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

[Inki Dae]

On 2014? 10? 08? 11:57, Vivek Gautam wrote:
> Hi,
> 
> 
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
> 
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
> 

Can anyone give me tested-by after test? I cannot test this module
because I have no any board equipped with dp panel.

Jingoo or other?

Thanks,
Inki Dae

>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_on(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg |= dp->enable_mask;
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_off(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg &= ~(dp->enable_mask);
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> -   u32 phy_base;
>> int ret = 0;
>>
>> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> -   if (!dp_phy_node) {
>> -   dp->phy = devm_phy_get(dp->dev, "dp");
>> -   return PTR_ERR_OR_ZERO(dp->phy);
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "reg", _base)) {
>> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> -   >enable_mask)) {
>> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   dp->phy_addr = ioremap(phy_base, SZ_4);
>> -   if (!dp->phy_addr) {
>> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> -   ret = -ENOMEM;
>> -   goto err;
>> +   dp->phy = devm_phy_get(dp->dev, "dp");
>> +   if (IS_ERR(dp->phy)) {
>> +   ret = PTR_ERR(dp->phy);
>> +   if (ret == -ENOSYS || ret == -ENODEV) {
>> +   dp->phy = NULL;
>> +   } else if (ret == -EPROBE_DEFER) {
>> +   return ret;
>> +   } else {
>> +   dev_err(dp->dev, "no DP phy configured\n");
>> +   return ret;
>> +   }
>> }
>>
>> -err:
>> -   of_node_put(dp_phy_node);
>> -
>> return ret;
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk  *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> -   void __iomem*phy_addr;
>> -   unsigned intenable_mask;
>>
>> struct video_info   *video_info;
>> struct link_train   link_train;
>> --
>> 1.7.10.4
>>
> 
> 
> 

AMD GPU new API for new module

[Jerome Glisse]

Hi,

So if i do not start the discussion now it might be already too late. Given
plan to converge open source driver and closed source driver to use a single
common kernel driver and that this would be a new kernel driver. This is an
opportunity to fix some of the radeon design issues (at least things that i
would have done differently if only i could get some gas for my DeLorean).

Among the thing that i will not do is the chunk stuff associated with cs
ioctl. I find it ugly, if my memory serve me well i was trying to be future
proof and allow the cs ioctl to be extended. While this original aim have
been somewhat successfully, i think it was the wrong day to do it.

My lastest (and what i still believe to be a good idea until proven wrong),
is to change the way we do ioctl and use a little trick. This idea was also
spark by the continuous additions we do to info ioctl which is getting ugly.

So idea is simple, each ioctl would use some struct like :

struct radeon_ioctl {
u32 version;
u32 size;
};

The version field is the key here, think of it as an index into an array of
ioctl dispatch functions. So something like :

struct radeon_ioctls {
int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
};

struct radeon_ioctls rdispatch_ioctls[N];

And now all ioctl go through this single entry point :

int radeon_ioctl_stub(int ioctl, void *data, ...)
{
struct radeon_ioctl *rio = data;

return rdispatch_ioctls[rio->version][ioctl](data, ...);
}

So this is rough idea but the point is that we can do proper ioctl versioning
and have separate functions for each new versions and avoid ioctl cruft, or
at least this is the theory.

The two things this gave us, is feedback from userspace as we the version the
kernel will know which version of userspace it is dealing with. The others one
is that it does allow you to introduce a completely new API either for new
generation of hardware or just as an evolution. And small bonus is that it
does allow to slowly phase out API that we consider broken (ioctl per ioctl).

So this is the main design change that i would do. I should probably rought
up something that goes deeper for the cs ioctl.

Cheers,
J?r?me

[PATCH v2] drm/crtc: Remove duplicated ioctl code

[Chuck Ebbert]

Make drm_mode_add_fb() call drm_mode_add_fb2() after converting its
args to the new internal format, instead of duplicating code.

Also picks up a lot more error checking, which the legacy modes
should pass after being converted to the new format.

Signed-off-by: Chuck Ebbert 
---
 drm_crtc.c |   31 +++
 1 file changed, 7 insertions(+), 24 deletions(-)

Against 3.17.0, compile tested only.
This time with the correct signed-off-by.

diff a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2925,11 +2925,9 @@ int drm_mode_addfb(struct drm_device *dev,
 {
struct drm_mode_fb_cmd *or = data;
struct drm_mode_fb_cmd2 r = {};
-   struct drm_mode_config *config = >mode_config;
-   struct drm_framebuffer *fb;
-   int ret = 0;
+   int ret;

-   /* Use new struct with format internally */
+   /* convert to new format and call new ioctl */
r.fb_id = or->fb_id;
r.width = or->width;
r.height = or->height;
@@ -2937,27 +2934,12 @@ int drm_mode_addfb(struct drm_device *dev,
r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
r.handles[0] = or->handle;

-   if (!drm_core_check_feature(dev, DRIVER_MODESET))
-   return -EINVAL;
-
-   if ((config->min_width > r.width) || (r.width > config->max_width))
-   return -EINVAL;
-
-   if ((config->min_height > r.height) || (r.height > config->max_height))
-   return -EINVAL;
-
-   fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
-   if (IS_ERR(fb)) {
-   DRM_DEBUG_KMS("could not create framebuffer\n");
-   return PTR_ERR(fb);
-   }
+   ret = drm_mode_addfb2(dev, , file_priv);
+   if (ret)
+   return ret;
+
+   or->fb_id = r.fb_id;

-   mutex_lock(_priv->fbs_lock);
-   or->fb_id = fb->base.id;
-   list_add(>filp_head, _priv->fbs);
-   DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
-   mutex_unlock(_priv->fbs_lock);
-
return ret;
 }

[PATCH] drm/crtc: Fix two typos

[Chuck Ebbert]

Fix:

  ioclt -> ioctl in comment
  wrong variable name in debug message

Signed-off-by: Chuck Ebbert 
---

--- drivers/gpu/drm/drm_crtc.c.orig 2014-10-08 11:29:50.948406186 -0500
+++ drivers/gpu/drm/drm_crtc.c  2014-10-08 11:30:55.781479300 -0500
@@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format)
  * @file_priv: drm file for the ioctl call
  *
  * Add a new FB to the specified CRTC, given a user request. This is the
- * original addfb ioclt which only supported RGB formats.
+ * original addfb ioctl which only supported RGB formats.
  *
  * Called by the user via ioctl.
  *
@@ -3033,7 +3033,7 @@ static int framebuffer_check(const struc
num_planes = drm_format_num_planes(r->pixel_format);

if (r->width == 0 || r->width % hsub) {
-   DRM_DEBUG_KMS("bad framebuffer width %u\n", r->height);
+   DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
}

drm/crtc: Remove duplicated ioctl code

[Chuck Ebbert]

Make drm_mode_add_fb() call drm_mode_add_fb2() after converting its
args to the new internal format, instead of duplicating code.

Also picks up a lot more error checking, which the legacy modes
should pass after being converted to the new format.

Signed-off-by: Chuck Ebbert 
---
 drm_crtc.c |   31 +++
 1 file changed, 7 insertions(+), 24 deletions(-)

Against 3.17.0, compile tested only.

diff a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2925,11 +2925,9 @@ int drm_mode_addfb(struct drm_device *dev,
 {
struct drm_mode_fb_cmd *or = data;
struct drm_mode_fb_cmd2 r = {};
-   struct drm_mode_config *config = >mode_config;
-   struct drm_framebuffer *fb;
-   int ret = 0;
+   int ret;

-   /* Use new struct with format internally */
+   /* convert to new format and call new ioctl */
r.fb_id = or->fb_id;
r.width = or->width;
r.height = or->height;
@@ -2937,27 +2934,12 @@ int drm_mode_addfb(struct drm_device *dev,
r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
r.handles[0] = or->handle;

-   if (!drm_core_check_feature(dev, DRIVER_MODESET))
-   return -EINVAL;
-
-   if ((config->min_width > r.width) || (r.width > config->max_width))
-   return -EINVAL;
-
-   if ((config->min_height > r.height) || (r.height > config->max_height))
-   return -EINVAL;
-
-   fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
-   if (IS_ERR(fb)) {
-   DRM_DEBUG_KMS("could not create framebuffer\n");
-   return PTR_ERR(fb);
-   }
+   ret = drm_mode_addfb2(dev, , file_priv);
+   if (ret)
+   return ret;
+
+   or->fb_id = r.fb_id;

-   mutex_lock(_priv->fbs_lock);
-   or->fb_id = fb->base.id;
-   list_add(>filp_head, _priv->fbs);
-   DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
-   mutex_unlock(_priv->fbs_lock);
-
return ret;
 }

[PATCH] drm: Implement O_NONBLOCK support on /dev/dri/cardN

[Daniel Vetter]

On Tue, Oct 7, 2014 at 3:13 PM, Chris Wilson  
wrote:
> The implmentation is simple in the extreme: we only want to wait for
> events if the device was opened in blocking mode, otherwise we grab what
> is available and report an error if there was none.
>
> Signed-off-by: Chris Wilson 
> Cc: dri-devel at lists.freedesktop.org

Testcase for nonblocking behaviour in kms_flip?
-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, Oct 6, 2014 at 2:25 PM, Lauri Peltonen  wrote:
>> Also, the problem is that to actually push android stuff out of staging
>> you need a use-case in upstream, which means an open-source gpu driver.
>> There's not a lot of companies who have both that and ship android, and
>> definitely not the nexus/android lead platforms.
>>
>> Display side would be easier since there's a bunch of kms drivers now
>> upstream. But given that google decided to go ahead with their own adf
>> instead of drm-kms that's also a non-starter.
>
> Hmm..  Maybe we could use TegraDRM on the display side..  That and Nouveau
> would already be two upstream drivers that support explicit sync on Tegra K1.
>
> Also, if we bring sync fd's out of staging, one idea would be to add support
> for EGL_ANDROID_native_fence_sync in mesa, along with some tests.  That would
> demonstrate converting between sync fd's and EGLSync objects.

Just read through the extension spec for this and this sounds
excellent. So enabling that in mesa and having some basic piglits for
the conversion should be more than good enough to fullfill the
open-source userspace driver requirement.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH v3 04/11] drm/i915: move check of intel_crtc_cursor_set_obj() out

[Daniel Vetter]

On Tue, Oct 07, 2014 at 06:01:10PM +0300, Ville Syrj?l? wrote:
> On Tue, Oct 07, 2014 at 05:47:52PM +0300, Ville Syrj?l? wrote:
> > On Wed, Sep 24, 2014 at 02:20:25PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan 
> > >
> > > Move check inside intel_crtc_cursor_set_obj() to
> > > intel_check_cursor_plane(), we only use it there so move them out to
> > > make the merge of intel_crtc_cursor_set_obj() into
> > > intel_check_cursor_plane() easier.
> > >
> > > This is another step toward the atomic modesetting support and unification
> > > of plane operations such pin/unpin of fb objects on i915.
> > >
> > > v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the
> > > code
> > > v3: take Ville's comment: kept only the restructuring changes, the rest of
> > > the code was moved to a separated patch since it is a bug fix (we weren't
> > > checking sizes when the fb was the same)
> > >
> > > Signed-off-by: Gustavo Padovan 
> >
> > Looks like the commit messages for patches 2 and 3 got somehow swapped
> > around. With that fixed patches 2 and 3 get:
>
> And make that patches 3 and 4 and we're actaully talking about the
> correct two patches.

Ok, I think I've fixed it up.
>
> > Reviewed-by: Ville Syrj?l? 

Merged up to this patch to dinq.
-Daniel

> >
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 20be2ed..f91a5b0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -11928,9 +11928,6 @@ intel_check_cursor_plane(struct drm_plane *plane,
> > >   if (!obj)
> > >   return 0;
> > >
> > > - if (fb == crtc->cursor->fb)
> > > - return 0;
> > > -
> > >   /* Check for which cursor types we support */
> > >   crtc_w = drm_rect_width(>orig_dst);
> > >   crtc_h = drm_rect_height(>orig_dst);
> > > @@ -11945,6 +11942,9 @@ intel_check_cursor_plane(struct drm_plane *plane,
> > >   return -ENOMEM;
> > >   }
> > >
> > > + if (fb == crtc->cursor->fb)
> > > + return 0;
> > > +
> > >   /* we only need to pin inside GTT if cursor is non-phy */
> > >   mutex_lock(>struct_mutex);
> > >   if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
> > > --
> > > 1.9.3
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrj?l?
> > Intel OTC
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Implement O_NONBLOCK support on /dev/dri/cardN

[Chris Wilson]

On Wed, Oct 08, 2014 at 11:16:38AM +0200, Daniel Vetter wrote:
> On Tue, Oct 7, 2014 at 3:13 PM, Chris Wilson  
> wrote:
> > The implmentation is simple in the extreme: we only want to wait for
> > events if the device was opened in blocking mode, otherwise we grab what
> > is available and report an error if there was none.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: dri-devel at lists.freedesktop.org
> 
> Testcase for nonblocking behaviour in kms_flip?

To the further dismay of anyone running kms_flip today,
Testcase: igt/kms_flip/nonblocing_read
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/exynos: init vblank with real number of crtcs

[Inki Dae]

On 2014? 10? 08? 00:28, Inki Dae wrote:
> 
> Sorry for late.
> 
> On 2014? 10? 07? 21:27, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>>
>> Andrzej
>>
>>
>> On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
>>> Initialization of vblank with MAX_CRTC caused attempts
>>> to disabling vblanks for non-existing crtcs in case
>>> drm used fewer crtcs. The patch fixes it.
> 
> Nice catch~ This patch also resolves unbind issue. When exynos driver is
> unbound, disable_vblank callback is called as dev->num_crtcs so if the
> number of probed crtc drivers is different from the one of enabled crtc

Oops, s/the one of enabled crtc drivers/MAX_CRTC

> drivers then it could attempt to disabling vblank for non-existing crtc,
> which in turn, null pointer access occurs.
> 
> Thanks,
> Inki Dae
> 
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
>>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index 9b00e4e..dc4affd 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
>>> unsigned long flags)
>>> /* init kms poll for handling hpd */
>>> drm_kms_helper_poll_init(dev);
>>>  
>>> -   ret = drm_vblank_init(dev, MAX_CRTC);
>>> -   if (ret)
>>> -   goto err_mode_config_cleanup;
>>> -
>>> /* setup possible_clones. */
>>> exynos_drm_encoder_setup(dev);
>>>  
>>> @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
>>> unsigned long flags)
>>> /* Try to bind all sub drivers. */
>>> ret = component_bind_all(dev->dev, dev);
>>> if (ret)
>>> -   goto err_cleanup_vblank;
>>> +   goto err_mode_config_cleanup;
>>> +
>>> +   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>>> +   if (ret)
>>> +   goto err_unbind_all;
>>>  
>>> /* Probe non kms sub drivers and virtual display driver. */
>>> ret = exynos_drm_device_subdrv_probe(dev);
>>> if (ret)
>>> -   goto err_unbind_all;
>>> +   goto err_cleanup_vblank;
>>>  
>>> /* force connectors detection */
>>> drm_helper_hpd_irq_event(dev);
>>>  
>>> return 0;
>>>  
>>> -err_unbind_all:
>>> -   component_unbind_all(dev->dev, dev);
>>>  err_cleanup_vblank:
>>> drm_vblank_cleanup(dev);
>>> +err_unbind_all:
>>> +   component_unbind_all(dev->dev, dev);
>>>  err_mode_config_cleanup:
>>> drm_mode_config_cleanup(dev);
>>> drm_release_iommu_mapping(dev);
>>> @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
>>> exynos_drm_fbdev_fini(dev);
>>> drm_kms_helper_poll_fini(dev);
>>>  
>>> -   component_unbind_all(dev->dev, dev);
>>> drm_vblank_cleanup(dev);
>>> +   component_unbind_all(dev->dev, dev);
>>> drm_mode_config_cleanup(dev);
>>> drm_release_iommu_mapping(dev);
>>>  
>>>
>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 79980] Random radeonsi crashes

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

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #144 from darkbasic  ---
Unfortunately it doesn't help, on the contrary I just got a new instability
world record: it crashed in *KDM*! Yes of course, I didn't even had time to
type my username!
I never checked GTX 970's price so often: one day or another I will find a good
offer and I will say goodbye to radeoncrash forever.

-- 
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/20141008/68637e0b/attachment.html>

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

[Mark yao]

Hi Steven
 I'm glad to see you to discuss about rk29xx.

On 2014?10?08? 06:26, Steven Newbury wrote:
> I've just been discussing how this relates to rk29xx on #etnaviv.  I
> looked through the patch and it's good to see it's not limited to
> supporting Mali GPUs.  I see no reason this wouldn't be compatible
> with etna_viv for rk29xx (or future Rockchip designs with alternative
> GPUs) as long as the rest of the infrastructure to support rk29 is in
> place iommu (ARM SMMU?) driver, for example.
Now the drm driver only test on rk3288, and future when we add 
compatible for rk29xx, we
would consider to add a non-iommu path for it.
> IMHO it's vital to keep a logical separation between the video display
> hardware and the graphics processor on SoCs.
Sure, the graphics processor maybe change in different solutions, 
logical separation is that we
try to keep.
Regards
-?ark
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141008/7f3fe445/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #28 from Andy Furniss  ---
(In reply to Michel D?nzer from comment #24)
> (In reply to Andy Furniss from comment #22)
> > It seems like current mesa doesn't build/install properly when patched
> > without being totally clean.
> > 
> > The mesa patch in this bug on an already built tree does provoke -
> > 
> > make[3]: Entering directory
> > '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon'
> >   CC   r600_buffer_common.lo
> >   CCLD libradeon.la
> > 
> > but radeonsi_dri.so is not changed after make install.
> 
> How about lib/gallium/radeonsi_dri.so in the build tree? That gets updated
> correctly for me. I don't use make install though, and I'm using an
> out-of-tree build, so maybe it's related to one of those. Anyway, please
> file another report about that.

No, so it seems like it's make that fails to update that for me unless I have
distcleaned.

-- 
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/20141008/5aa92630/attachment.html>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Thierry Reding]

On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote:
> Hi Ajay,
> 
> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
> > > On 20/09/14 14:22, Ajay kumar wrote:
> > >> Well, I am okay with using video ports to describe the relationship
> > >> between the encoder, bridge and the panel.
> > >> But, its just that I need to make use of 2 functions when phandle
> > >> does it using just one function ;)
> > >> -panel_node = of_parse_phandle(dev->of_node, "panel", 0)
> > >> +   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> > >> +   if (!endpoint)
> > >> +   return -EPROBE_DEFER;
> > >> +
> > >> +   panel_node = of_graph_get_remote_port_parent(endpoint);
> > >> +   if (!panel_node)
> > >> +   return -EPROBE_DEFER;
> > >> 
> > >> 
> > >> If nobody else has objections over using of_graph functions instead
> > >> of phandles, I can respin this patchset by making use of video ports.
> > > 
> > > The discussion did digress somewhat.
> > > 
> > > As a clarification, I'm in no way nack'ing this series because it
> > > doesn't use the graphs for video connections. I don't see the simple
> > > phandle bindings used here as broken as such.
> > 
> > Well, I am okay with any approach you guys decide on. I desperately want
> > this to get this in since it has been floating around for quite sometime.
> > The more we drag this, the more rework for me since the number of platforms
> > using bridge support is increasing daily!
> 
> I won't nack this patch either. I'm however concerned that we'll run straight 
> into the wall if we don't come up with an agreement on a standard way to 
> describe connections in DT for display devices, which is why I would prefer 
> the ps8622 bindings to use OF graph to describe connections.

I think there's not really an easy way out here. It's pretty bold trying
to come up with a common way to describe bridges when we have only a
single one (and a single use-case at that). The worst that can happen is
that we need to change the binding at some point, in which case we may
have to special-case early drivers, but I really don't think that's as
much of an issue as everybody seems to think.

This series has been floating around for months because we're being
overly prudent to accept a binding that /may/ turn out to not be generic
enough.

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/20141008/023a049d/attachment.sig>

[PATCH 1/2] drm/tegra: Set the dsi lp clk parent and rate

[Sean Paul]

On Wed, Oct 8, 2014 at 8:11 AM, Peter De Schrijver
 wrote:
> On Mon, Sep 22, 2014 at 12:11:54PM +0200, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Sep 22, 2014 at 11:00:56AM +0200, Lucas Stach wrote:
>> > Am Freitag, den 19.09.2014, 15:53 -0400 schrieb Sean Paul:
>> > > Per NVidia, this clock rate should be around 70MHz in
>> > > order to properly sample reads on data lane 0. In order
>> > > to achieve this rate, we need to reparent the clock from
>> > > clk_m which can only achieve 12MHz. Add parent_lp to the
>> > > dts bindings and set the parent & rate on init.
>> > >
>> > > Signed-off-by: Sean Paul 
>> >
>> > NACK
>> >
>> > You are pushing SoC integration details into the binding of the device.
>> >
>> > You have two reasonable routes to go here: either the clock driver needs
>> > to be made smarter to reparent the clock in case the required clock rate
>> > could not be achieved with the current parent or you go the easy route
>> > and reparent the clock as part of the initial configuration.
>>
>> Agreed. There doesn't seem to be a case where it would make sense to
>> have this configurable per-board. Can you achieve the same effect by
>> adding this to the clock initialization table?
>>
>> Oh, I just see that we have this in the Tegra124 clock initialization
>> table:
>>
>>   {TEGRA114_CLK_DSIALP, TEGRA114_CLK_PLL_P, 6800, 0},
>>   {TEGRA114_CLK_DSIBLP, TEGRA114_CLK_PLL_P, 6800, 0},
>>
>> Doesn't that work for you already? If not that'd be a bug that should be
>> fixed in the clock driver.
>
> This seems the better approach indeed. Unless the rate would differ based
> on board or other external factors.
>

Thanks, Peter.

Just to close the loop, the patch: "clk: tegra124: Add init data for
dsi lp clocks" I sent up last week replaces this one.

Sean


> Cheers,
>
> Peter.

[Bug 79980] Random radeonsi crashes

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

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #143 from Edward  ---
(In reply to darkbasic from comment #140)
> Do you disable the onboard video in the bios or somewhere else?

In the bios. In my case (asrock z77 extreme6) I have to disable the entry "IGPU
Multi-Monitor"

-- 
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/20141008/cea32110/attachment.html>

[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Hi,


CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Wed, Oct 8, 2014 at 8:27 AM, Vivek Gautam  
wrote:
> Hi,
>
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
>
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_on(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg |= dp->enable_mask;
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_off(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg &= ~(dp->enable_mask);
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> -   u32 phy_base;
>> int ret = 0;
>>
>> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> -   if (!dp_phy_node) {
>> -   dp->phy = devm_phy_get(dp->dev, "dp");
>> -   return PTR_ERR_OR_ZERO(dp->phy);
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "reg", _base)) {
>> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> -   >enable_mask)) {
>> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   dp->phy_addr = ioremap(phy_base, SZ_4);
>> -   if (!dp->phy_addr) {
>> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> -   ret = -ENOMEM;
>> -   goto err;
>> +   dp->phy = devm_phy_get(dp->dev, "dp");
>> +   if (IS_ERR(dp->phy)) {
>> +   ret = PTR_ERR(dp->phy);
>> +   if (ret == -ENOSYS || ret == -ENODEV) {
>> +   dp->phy = NULL;
>> +   } else if (ret == -EPROBE_DEFER) {
>> +   return ret;
>> +   } else {
>> +   dev_err(dp->dev, "no DP phy configured\n");
>> +   return ret;
>> +   }
>> }
>>
>> -err:
>> -   of_node_put(dp_phy_node);
>> -
>> return ret;
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk  *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> -   void __iomem*phy_addr;
>> -   unsigned intenable_mask;
>>
>> struct video_info   *video_info;
>> struct link_train   link_train;
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R Institute, Bangalore
> India



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[PATCH 3/3] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Vivek Gautam]

Hi,

CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
wrote:
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index f21b9aa..9b85a2b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
>
> dp_phy: video-phy at 10040720 {
> compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040720 4>;
> +   samsung,pmu-syscon = <_system_controller>;
> #phy-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index bfe056d..a677812 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
> };
>
> dp_phy: video-phy at 10040728 {
> -   compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040728 4>;
> +   compatible = "samsung,exynos5420-dp-video-phy";
> +   samsung,pmu-syscon = <_system_controller>;
> #phy-cells = <0>;
> };
>
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Hi,


On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
> +++
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>  2 files changed, 13 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4f3c7eb..5ffc1b2 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
>
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_on(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg |= dp->enable_mask;
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_off(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg &= ~(dp->enable_mask);
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1210,39 +1196,21 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
>
>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>  {
> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> -   u32 phy_base;
> int ret = 0;
>
> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> -   if (!dp_phy_node) {
> -   dp->phy = devm_phy_get(dp->dev, "dp");
> -   return PTR_ERR_OR_ZERO(dp->phy);
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "reg", _base)) {
> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> -   >enable_mask)) {
> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   dp->phy_addr = ioremap(phy_base, SZ_4);
> -   if (!dp->phy_addr) {
> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
> -   ret = -ENOMEM;
> -   goto err;
> +   dp->phy = devm_phy_get(dp->dev, "dp");
> +   if (IS_ERR(dp->phy)) {
> +   ret = PTR_ERR(dp->phy);
> +   if (ret == -ENOSYS || ret == -ENODEV) {
> +   dp->phy = NULL;
> +   } else if (ret == -EPROBE_DEFER) {
> +   return ret;
> +   } else {
> +   dev_err(dp->dev, "no DP phy configured\n");
> +   return ret;
> +   }
> }
>
> -err:
> -   of_node_put(dp_phy_node);
> -
> return ret;
>  }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
> struct clk  *clock;
> unsigned intirq;
> void __iomem*reg_base;
> -   void __iomem*phy_addr;
> -   unsigned intenable_mask;
>
> struct video_info   *video_info;
> struct link_train   link_train;
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #27 from Michel D?nzer  ---
Created attachment 107544
  --> https://bugs.freedesktop.org/attachment.cgi?id=107544=edit
drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

Please try current Mesa with no patches except for the two I just attached,
plus this kernel patch together with the previous kernel patch.

-- 
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/20141008/1d732ca8/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

Michel D?nzer  changed:

   What|Removed |Added

 Attachment #107391|0   |1
is obsolete||

--- Comment #26 from Michel D?nzer  ---
Created attachment 107543
  --> https://bugs.freedesktop.org/attachment.cgi?id=107543=edit
winsys/radeon: Use separate caching buffer manager for each set of flags

-- 
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/20141008/dcf7/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #25 from Michel D?nzer  ---
Created attachment 107542
  --> https://bugs.freedesktop.org/attachment.cgi?id=107542=edit
r600g,radeonsi: Use staging texture for transfers if any miplevel is tiled

-- 
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/20141008/69269cce/attachment.html>

[Bug 79980] Random radeonsi crashes

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

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #142 from Jacob  ---
(In reply to Michel D?nzer from comment #141)
> (In reply to Jacob from comment #137)
> > It seems to happen on any kernel newer than 3.13, least in my case.
> 
> Can you bisect which change between 3.13 and 3.14 caused the instability for
> you?

I've only downloaded kernel images as .deb files from
http://kernel.ubuntu.com/~kernel-ppa/mainline/
How would I go about bisecting which change caused the instability?

-- 
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/20141008/5927a7a0/attachment-0001.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #24 from Michel D?nzer  ---
(In reply to Andy Furniss from comment #22)
> It seems like current mesa doesn't build/install properly when patched
> without being totally clean.
> 
> The mesa patch in this bug on an already built tree does provoke -
> 
> make[3]: Entering directory
> '/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon'
>   CC   r600_buffer_common.lo
>   CCLD libradeon.la
> 
> but radeonsi_dri.so is not changed after make install.

How about lib/gallium/radeonsi_dri.so in the build tree? That gets updated
correctly for me. I don't use make install though, and I'm using an out-of-tree
build, so maybe it's related to one of those. Anyway, please file another
report about that.

-- 
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/20141008/aed768a7/attachment.html>

[Bug 84663] high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME

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

https://bugs.freedesktop.org/show_bug.cgi?id=84663

--- Comment #5 from Michel D?nzer  ---
(In reply to Christoph Haag from comment #4)
> I hope this is better.

Yes, looks better, thanks.

> By the way, Is there a better way to profile something likethis or is
> sysprof already the most appropriate tool?

I find sysprof's UI the most intuitive, but perf is nice as well.


I don't notice anything using obviously too much CPU in your profile. Can you
get a screenshot with GALLIUM_HUD like in bug 84570?

-- 
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/20141008/b45af258/attachment.html>

[Bug 79980] Random radeonsi crashes

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

https://bugs.freedesktop.org/show_bug.cgi?id=79980

Michel D?nzer  changed:

   What|Removed |Added

 CC||jacobsvenningsen15 at hotmail.
   ||com

--- Comment #141 from Michel D?nzer  ---
(In reply to Jacob from comment #137)
> It seems to happen on any kernel newer than 3.13, least in my case.

Can you bisect which change between 3.13 and 3.14 caused the instability for
you?

-- 
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/20141008/15ba5471/attachment.html>

[PATCH] drm/ast: Fix HW cursor image

[YC Chen]

Reviewed-by: Y.C. Chen 

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
Sent: Tuesday, October 07, 2014 4:05 PM
To: Dave Airlie
Cc: dri-devel at lists.freedesktop.org; YC Chen
Subject: [PATCH] drm/ast: Fix HW cursor image

The translation from the X driver to the KMS one typo'ed a couple of array 
indices, causing the HW cursor to look weird (blocky with leaking edge colors). 
This fixes it.

Signed-off-by: Benjamin Herrenschmidt 
---

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c 
index 19ada0b..9dc0fd5 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1104,8 +1104,8 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, 
int height)
srcdata32[1].ul = *((u32 *)(srcxor + 4)) & 0xf0f0f0f0;
data32.b[0] = srcdata32[0].b[1] | (srcdata32[0].b[0] >> 
4);
data32.b[1] = srcdata32[0].b[3] | (srcdata32[0].b[2] >> 
4);
-   data32.b[2] = srcdata32[0].b[1] | (srcdata32[1].b[0] >> 
4);
-   data32.b[3] = srcdata32[0].b[3] | (srcdata32[1].b[2] >> 
4);
+   data32.b[2] = srcdata32[1].b[1] | (srcdata32[1].b[0] >> 
4);
+   data32.b[3] = srcdata32[1].b[3] | (srcdata32[1].b[2] >> 
4);

writel(data32.ul, dstxor);
csum += data32.ul;

[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2

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

https://bugs.freedesktop.org/show_bug.cgi?id=84614

--- Comment #10 from Paulo Dias  ---
i think i should mention that these crashes only happen if i enable

DynamicLights=True in .local/share/aspyr-media/borderlands\
2/willowgame/config/willowengine.ini

turning it to false, the game runs, but i get stalls for more then 4 seconds
randomly, otherwise is very fast,even with everything maxed out, and of course,
without dynamic lights, the game looks like >.<

the intel driver works fine with dynlights on, without a glitch, only slowerofc

-- 
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/20141008/ca2ed4dc/attachment.html>

[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2

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

:35:27 kerberos kernel: [  775.811032] [drm] PCIE GART of 1024M
enabled (table at 0x00276000).
Oct  7 21:35:27 kerberos kernel: [  775.811147] radeon :03:00.0: WB enabled
Oct  7 21:35:27 kerberos kernel: [  775.811151] radeon :03:00.0: fence
driver on ring 0 use gpu addr 0x8c00 and cpu addr
0x8800354e2c00
Oct  7 21:35:27 kerberos kernel: [  775.811153] radeon :03:00.0: fence
driver on ring 1 use gpu addr 0x8c04 and cpu addr
0x8800354e2c04
Oct  7 21:35:27 kerberos kernel: [  775.811156] radeon :03:00.0: fence
driver on ring 2 use gpu addr 0x8c08 and cpu addr
0x8800354e2c08
Oct  7 21:35:27 kerberos kernel: [  775.811158] radeon :03:00.0: fence
driver on ring 3 use gpu addr 0x8c0c and cpu addr
0x8800354e2c0c
Oct  7 21:35:27 kerberos kernel: [  775.811160] radeon :03:00.0: fence
driver on ring 4 use gpu addr 0x8c10 and cpu addr
0x8800354e2c10
Oct  7 21:35:27 kerberos kernel: [  775.812713] radeon :03:00.0: fence
driver on ring 5 use gpu addr 0x00075a18 and cpu addr
0xc90005935a18
Oct  7 21:35:27 kerberos kernel: [  776.416088] [drm] ring test on 0 succeeded
in 1 usecs
Oct  7 21:35:27 kerberos kernel: [  776.416097] [drm] ring test on 1 succeeded
in 1 usecs
Oct  7 21:35:27 kerberos kernel: [  776.416103] [drm] ring test on 2 succeeded
in 1 usecs
Oct  7 21:35:27 kerberos kernel: [  776.416119] [drm] ring test on 3 succeeded
in 3 usecs
Oct  7 21:35:27 kerberos kernel: [  776.416128] [drm] ring test on 4 succeeded
in 1 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601682] [drm] ring test on 5 succeeded
in 2 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601691] [drm] UVD initialized
successfully.
Oct  7 21:35:27 kerberos kernel: [  776.601727] [drm] ib test on ring 0
succeeded in 0 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601760] [drm] ib test on ring 1
succeeded in 0 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601791] [drm] ib test on ring 2
succeeded in 0 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601823] [drm] ib test on ring 3
succeeded in 0 usecs
Oct  7 21:35:27 kerberos kernel: [  776.601854] [drm] ib test on ring 4
succeeded in 0 usecs
Oct  7 21:35:28 kerberos kernel: [  776.752454] [drm] ib test on ring 5
succeeded
Oct  7 21:36:13 kerberos kernel: [  821.976487] radeon :03:00.0: GPU fault
detected: 147 0x0aa20801
Oct  7 21:36:13 kerberos kernel: [  821.976493] radeon :03:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x01600855
Oct  7 21:36:13 kerberos kernel: [  821.976494] radeon :03:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02008001
Oct  7 21:36:13 kerberos kernel: [  821.976497] VM fault (0x01, vmid 1) at page
23070805, read from TC (8)

-- 
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/20141008/393e07ff/attachment-0001.html>

[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2

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

https://bugs.freedesktop.org/show_bug.cgi?id=84614

--- Comment #8 from Paulo Dias  ---
Created attachment 107529
  --> https://bugs.freedesktop.org/attachment.cgi?id=107529=edit
xorg after crash

-- 
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/20141008/780b6bff/attachment.html>

[PATCH] drm/exynos: init vblank with real number of crtcs

[Inki Dae]

Sorry for late.

On 2014? 10? 07? 21:27, Andrzej Hajda wrote:
> Hi Inki,
> 
> Gently ping.
> 
> Andrzej
> 
> 
> On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
>> Initialization of vblank with MAX_CRTC caused attempts
>> to disabling vblanks for non-existing crtcs in case
>> drm used fewer crtcs. The patch fixes it.

Nice catch~ This patch also resolves unbind issue. When exynos driver is
unbound, disable_vblank callback is called as dev->num_crtcs so if the
number of probed crtc drivers is different from the one of enabled crtc
drivers then it could attempt to disabling vblank for non-existing crtc,
which in turn, null pointer access occurs.

Thanks,
Inki Dae

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

[PATCH] drm/exynos: vidi: fix build warning

[Inki Dae]

encoder object isn't used anymore so remove it.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 9395e85..50faf91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -630,7 +630,6 @@ static int vidi_remove(struct platform_device *pdev)
 {
struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
struct vidi_context *ctx = mgr->ctx;
-   struct drm_encoder *encoder = ctx->encoder;

if (ctx->raw_edid != (struct edid *)fake_edid_info) {
kfree(ctx->raw_edid);
-- 
1.7.9.5

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #23 from Andy Furniss  ---
(In reply to Andy Furniss from comment #13)
> (In reply to Michel D?nzer from comment #12)
> > Created attachment 107391 [details] [review] [review]
> > Make Mesa behave as if the kernel was older

> > The attached patch makes Mesa behave the same with current kernels as it
> > does with older ones which don't have the bisected commit. Does that avoid
> > the problem?
> 
> No, the patch makes no difference.

It seems I wasn't testing it - so the answer now is yes it does - in fact the
goods I get with it on current kernels are better = less stutters than the
goods I saw during the kernel bisect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #22 from Andy Furniss  ---
(In reply to Alexandre Demers from comment #21)

> > So currently a bit confused - as reported by Christoph in the other bug, it
> > is possible to have good with vanilla mesa/kernel, but apparently for me the
> > "same" mesa can also be bad.
> > 
> > I did try more clean/rebuild cycles including single thread but am currently
> > still bad.
> 
> I'm also seeing this behavior while bisecting a different bug on a 7950...
> Probably related...

It seems like current mesa doesn't build/install properly when patched without
being totally clean.

The mesa patch in this bug on an already built tree does provoke -

make[3]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/drivers/radeon'
  CC   r600_buffer_common.lo
  CCLD libradeon.la

but radeonsi_dri.so is not changed after make install.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[Steven Newbury]

I've just been discussing how this relates to rk29xx on #etnaviv.  I 
looked through the patch and it's good to see it's not limited to 
supporting Mali GPUs.  I see no reason this wouldn't be compatible 
with etna_viv for rk29xx (or future Rockchip designs with alternative 
GPUs) as long as the rest of the infrastructure to support rk29 is in 
place iommu (ARM SMMU?) driver, for example.

IMHO it's vital to keep a logical separation between the video display 
hardware and the graphics processor on SoCs.

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: