[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #118 from Alexandre Demers  ---
(In reply to comment #117)
> Well, I'm still on Chromium, and I've forced my GPU from the backlist,
> because if you don't then it doesn't use all accel so it should be okay.
> Anyways, I turned off DPM and have no crashing at all, Chromium seems
> stable, LibreOffice seems stable, and also when you turn off DPM, the
> "Screen Jumping/corruption" goes away. It seems to be proportional to number
> of crashes, too. Which I have seen it go away, and no crashes now, so maybe
> it's related. But without DPM I'd say my GPU is now stable. My R9 270X is
> ASUS brand from about January, if that would help figure what hardware it
> has.

Well, it points out a problem with dpm. Maybe the uvd class is problematic?

-- 
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/20140926/66c9a249/attachment.html>

[Bug 73047] radeon_pm_info should be in sysfs instead of debugfs

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

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

--- Comment #7 from Alexandre Demers  ---
I'm about to close this bug since, as Christian said, there should be a way to
expose some PM functions to the user, but not through radeon_pm_info.

But before, I'd like to know if there is something coming this way to expose
these functionality?

-- 
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/20140926/a668d366/attachment.html>

[Bug 69721] Can't reach maximum memory speed (or core speed) when using dpm=1 on r600g on cards not sticking to reference board

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

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Alexandre Demers  ---
Closing since it should be fixed in kernel 3.18 (pull request from
drm-next-3.18).

-- 
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/20140926/fb2cbb72/attachment-0001.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #117 from Aaron B  ---
Well, I'm still on Chromium, and I've forced my GPU from the backlist, because
if you don't then it doesn't use all accel so it should be okay. Anyways, I
turned off DPM and have no crashing at all, Chromium seems stable, LibreOffice
seems stable, and also when you turn off DPM, the "Screen Jumping/corruption"
goes away. It seems to be proportional to number of crashes, too. Which I have
seen it go away, and no crashes now, so maybe it's related. But without DPM I'd
say my GPU is now stable. My R9 270X is ASUS brand from about January, if that
would help figure what hardware it has.

-- 
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/20140926/1cc3c4d6/attachment.html>

[PATCH] drm/edid: Add missing interlaced flag to 576i@100 modes.

[Ville Syrjälä]

On Fri, Sep 26, 2014 at 09:55:24AM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor 
> 
> CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.
> 
> Signed-off-by: Clint Taylor 

Reviewed-by: Ville Syrj?l? 

> ---
>  drivers/gpu/drm/drm_edid.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1bdbfd0..3bf9991 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -841,13 +841,13 @@ static const struct drm_display_mode edid_cea_modes[] = 
> {
>   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 732,
>  795, 864, 0, 576, 580, 586, 625, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> - DRM_MODE_FLAG_DBLCLK),
> + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
>   /* 45 - 720(1440)x576i at 100Hz */
>   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 732,
>  795, 864, 0, 576, 580, 586, 625, 0,
>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> - DRM_MODE_FLAG_DBLCLK),
> + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
>   /* 46 - 1920x1080i at 120Hz */
>   { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[RESENT PATCH v7 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark Yao]

From: Mark yao 

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

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

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

[Mark Yao]

From: Mark yao 

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

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

[RESENT PATCH v7 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

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  516 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   61 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  345 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1422 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 3102 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..87255f7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,17 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   

[RESENT PATCH v7 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.

Resent v7 email to fix mail style.

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.

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|  516 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   61 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  201 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  345 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1422 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3179 insertions(+)

-- 
1.7.9.5

[Bug 75276] Implement VGPR Register Spilling

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

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

--- Comment #50 from equeim at gmail.com ---
(In reply to comment #49)
> Hello,
> 
> I don't know if that helps, but the bug is still present on the brand new
> openSUSE 13.2 beta1, for example. (With libLLVM 3.4.2 and mesa 10.3.0)

This is LLVM bug and it is partially fixed in LLVM 3.5

-- 
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/20140926/3f2406d3/attachment.html>

Stupid NVIDIA 3D vgaarb.c patch

[Ilia Mirkin]

On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner  wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>>> appropriate, but hopefully somebody does. The fact that it makes
>>> things work certainly argues fairly convincingly for it, but I want
>>> some backup here.
>>>
>>> Dave, BenH?
>>>
>>> Christopher(?), can you please also specify which laptop etc. And the
>>> patch itself seems to have come from somebody else, unless you're
>>> Lekensteyn. So we'd want to get the provenance of that too.
>>
>>
>> Hrm, that sucks. "3D" could mean anything really, we might need an
>> explicit vendor ID check as well and maybe even device ID ...
>
>
> If my understanding is correct, the board designers explicitly mark them as
> "3D controller" when they don't have any outputs connected, specifically so
> the SBIOS won't choose them as the boot VGA device. Depending on the design,
> some GPUs on these 3D controller boards don't have a display engine at all,
> while others still have it in the silicon but leave it disabled at runtime.
> In either case, VGA should not be routed to them and I don't think they
> should need to participate in VGA arbitration.

Without commenting on the vga aspects of this discussion (about which
I know next to nothing), I'm moderately sure the nouveau team has seen
optimus setups where the secondary GPU reports itself as a 3d
controller, but has a working display engine, and outputs connected to
it. And I believe the inverse has also happened (a device that reports
itself as VGA but has no outputs advertised and a potentially-absent
display engine).

  -ilia

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

[Rob Clark]

On Mon, Sep 8, 2014 at 4:43 AM, Boris BREZILLON
 wrote:
> 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 
> Tested-by: Ludovic Desroches 

A few small comments below, but with those addressed it has my

Reviewed-by: Rob Clark 


> ---
>  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   | 286 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 488 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 224 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 656 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 403 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 476 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 836 
> +++
>  11 files changed, 3392 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
>

[snip]

> +
> +/**
> + * Atmel HLCDC plane rotation enum
> + *
> + * TODO: export DRM_ROTATE_XX macros defined by omap driver and use them
> + * instead of defining this enum.
> + */
> +enum atmel_hlcdc_plane_rotation {
> +   ATMEL_HLCDC_PLANE_NO_ROTATION,
> +   ATMEL_HLCDC_PLANE_90DEG_ROTATION,
> +   ATMEL_HLCDC_PLANE_180DEG_ROTATION,
> +   ATMEL_HLCDC_PLANE_270DEG_ROTATION,
> +};

DRM_ROTATE_* are already in drm_crtc.h

[snip]

> +static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> +   return MODE_OK;
> +}

your _mode_valid() should perhaps somehow check the constraints in
atmel_hlcdc_crtc_mode_set()?  This way invalid modes get filtered out
earlier..

[snip]

> +static struct atmel_hlcdc_plane_properties *
> +atmel_hlcdc_plane_create_properties(struct drm_device *dev)
> +{
> +   struct atmel_hlcdc_plane_properties *props;
> +   const struct drm_prop_enum_list rotations[] = {
> +   { ATMEL_HLCDC_PLANE_NO_ROTATION,   "rotate-0" },
> +   { ATMEL_HLCDC_PLANE_90DEG_ROTATION,  "rotate-90" },
> +   { ATMEL_HLCDC_PLANE_180DEG_ROTATION, "rotate-180" },
> +   { ATMEL_HLCDC_PLANE_270DEG_ROTATION, "rotate-270" },
> +   };
> +

you could just use drm_mode_create_rotation_property() now


> +   props = devm_kzalloc(dev->dev, sizeof(*props), GFP_KERNEL);
> +   if (!props)
> +   return ERR_PTR(-ENOMEM);
> +
> +   props->alpha = drm_property_create_range(dev, 0, "alpha", 0, 255);
> +   if (!props->alpha)
> +   return ERR_PTR(-ENOMEM);
> +
> +   props->rotation = drm_property_create_enum(dev, 0, "rotation",
> +   rotations,
> +   ARRAY_SIZE(rotations));
> +   return props;
> +}
> +

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

[Mike Turquette]

Quoting Tomi Valkeinen (2014-09-19 06:25:48)
> On 19/09/14 16:12, Nishanth Menon wrote:
> > On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
> >> On 16/09/14 23:40, Jyri Sarha wrote:
> >>> The added ti,gpio-gate-clock is a basic clock that can be enabled and
> >>> disabled trough a gpio output. The DT binding document for the clock
> >>> is also added. For EPROBE_DEFER handling the registering of the clock
> >>> has to be delayed until of_clk_get() call time.
> >>>
> >>> Signed-off-by: Jyri Sarha 
> >>> ---
> >>>  .../bindings/clock/ti/gpio-gate-clock.txt  |   21 ++
> >>>  drivers/clk/ti/Makefile|2 +-
> >>>  drivers/clk/ti/gpio.c  |  202 
> >>> 
> >>>  3 files changed, 224 insertions(+), 1 deletion(-)
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
> >>>  create mode 100644 drivers/clk/ti/gpio.c
> >>
> >> Why is this a TI clock? Sounds like a generic one to me.
> > 
> > Like thread: https://lkml.org/lkml/2014/9/5/284 ?
> 
> Right, I should've read the earlier versions before making any smart
> comments =).

No supporters cropped up for the generic gpio clock, but the design is
common enough to merit a common clock type. And all of that stuff I said
about the machine-specific ops isn't that relevant since it is hidden
behing the gpio api.

Regards,
Mike

> 
>  Tomi
> 
> 

[PATCH] drm/tegra: Setup PHY_TIMING & BTA_TIMING registers in setup_clock()

[Sean Paul]

Make sure we initialize the dsi PHY_TIMING and BTA_TIMING registers
when we setup the clocks, as opposed to in dsi_configure. The phy
timings must be initialized before drm_panel prepare() so that any
DCS commands sent at this time are using the appropriate timings.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/tegra/dsi.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index c0258ae..6923c9b 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -369,6 +369,9 @@ static int tegra_dsi_set_phy_timing(struct tegra_dsi *dsi)
DSI_TIMING_FIELD(timing.tago, period, 1);
tegra_dsi_writel(dsi, value, DSI_BTA_TIMING);

+   if (dsi->slave)
+   return tegra_dsi_set_phy_timing(dsi->slave);
+
return 0;
 }

@@ -482,10 +485,6 @@ static int tegra_output_dsi_enable(struct tegra_output 
*output)
value &= ~DSI_CONTROL_HOST_ENABLE;
tegra_dsi_writel(dsi, value, DSI_CONTROL);

-   err = tegra_dsi_set_phy_timing(dsi);
-   if (err < 0)
-   return err;
-
for (i = 0; i < NUM_PKT_SEQ; i++)
tegra_dsi_writel(dsi, pkt_seq[i], DSI_PKT_SEQ_0_LO + i);

@@ -660,6 +659,12 @@ static int tegra_output_dsi_setup_clock(struct 
tegra_output *output,
value = DSI_TALLY_TA(0) | DSI_TALLY_LRX(0) | DSI_TALLY_HTX(0);
tegra_dsi_writel(dsi, value, DSI_TO_TALLY);

+   err = tegra_dsi_set_phy_timing(dsi);
+   if (err) {
+   dev_err(dsi->dev, "failed to setup phy timing: %d\n", err);
+   return err;
+   }
+
return 0;
 }

-- 
2.1.1

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #15 from Alexandre Demers  ---
(In reply to comment #14)
> (In reply to comment #11)
> > Is ULV standing for Ultra-low voltage? If so, isn't this option something
> > meant to be applied on APU only?
> 
> Mmm don't know. 
> Haven't digged more, but my GPU (R7-265) is running hotter than before,
> always around 39?-40? (even without any running application).
> With the kernel in debian sid, 3.16.X, I can see low temperatures in idle.
> 
> I'm unable to trigger this warning booting up with radeon.dpm=0, so I think
> is something related to power management.

Well, according to my journalctl log, it seems to always be triggered after a
power state switching. It doesn't do it from boot (power state 0) to
performance (power state 1), but it is later. Strangely, I see a 
Sep 25 20:28:28 Xander kernel: switching from power state:
Sep 25 20:28:28 Xander kernel: ui class: performance
...
Sep 25 20:28:28 Xander kernel: switching to power state:
Sep 25 20:28:28 Xander kernel: ui class: performance

Why would it try to switch from power state 1 to power state 1 (the same power
state)? And why is it at that moment the problem arises? I'll have to do more
tests to see if this behaviour happens each time.

-- 
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/20140926/ff68ce17/attachment.html>

[PATCH v7 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark yao]

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

 .../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 v7 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark yao]

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

 .../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 1/3] drm/rockchip: Add basic drm driver

[Mark yao]

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  516 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   61 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  345 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1422 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 3102 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..87255f7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,17 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select VT_HW_CONSOLE_BINDING if 

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

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|  516 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   61 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  201 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  345 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1422 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3179 insertions(+)

-- 
1.7.9.5

[PATCH 10/12] video: Add ADV751[13] DT bindings documentation

[Laurent Pinchart]

Hi Geert,

On Thursday 25 September 2014 12:10:59 Geert Uytterhoeven wrote:
> On Thu, Sep 25, 2014 at 11:57 AM, Laurent Pinchart wrote:
> > On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
> >> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
> >> 
> >>  wrote:
> >> > +- adi,input-style: The input components arrangement variant (1, 2 or
> >> > 3).
> >> 
> >> What's the meaning of the numerical values 1, 2, and 3?
> >> 
> >> I found this code in "[PATCH 11/12] drm: Add adv7511 encoder driver":
> >> 
> >> +   input_style = config->input_style == 1 ? 2
> >> +   : (config->input_style == 2 ? 1 : 3);
> >> 
> >> which didn't really help much ;-)
> >> 
> > :-)
> > 
> > The ADV751[13]W? datasheets document all the supported input formats.
> > They're split in categories, each of them having multiple variants called
> > styles. The styles are just numbered 1, 2 and 3 in the tables that
> > describe the formats, and there's a register field used to select a
> > style. For some reason style 1 maps to register value 2, style 2 to
> > register value 1, and style 3 to register value 3. Go figure...
> 
> Thanks, that explains it.
> 
> Then I suggest to reflect this in the binding:
> 
> - adi,input-style: The input components arrangement variant (1, 2 or 3),
> as listed in the datasheet.
> 
> and in the code, e.g. by translating the values using a mapping array?

I'll document the property as

- adi,input-style: The input components arrangement variant (1, 2 or 3), as
  listed in the input format tables in the datasheet.

and modify the code to use an array as in

/*
 * The input style values documented in the datasheet don't match the
 * hardware register field values :-(
 */
static const unsigned int input_styles[4] = { 0, 2, 1, 3 };

...
regmap_update_bits(adv7511->regmap, ADV7511_REG_VIDEO_INPUT_CFG1, 0x7e,
   (color_depth << 4) |
   (input_styles[config->input_style] << 2));

(config->input_style is validated when parsing DT).

-- 
Regards,

Laurent Pinchart

[PATCH 00/12] Renesas R-Car DU HDMI support

[Laurent Pinchart]

Hi Philipp,

On Thursday 25 September 2014 15:09:13 Philipp Zabel wrote:
> Am Mittwoch, den 24.09.2014, 23:04 +0300 schrieb Laurent Pinchart:
> > Hello,
> > 
> > This patch set adds support for the HDMI output port present on the
> > Renesas Koelsch board. Doing so requires two components, a driver for the
> > external ADV7511W HDMI encoder, and support for HDMI encoders in the DU
> > driver.
> > 
> > The HDMI encoder drivers uses the DRM slave encoder framework and the
> > component framework to communicate with the DU driver. The DT bindings are
> > based on the OF graph bindings to link the display controller and encoder.
> > 
> > The first two patches have been taken from Philipp Zabel's "[PATCH v3 0/8]
> > Add of-graph helpers to loop over endpoints and find ports by id" series.
> > Philipp, I don't see that series in linux-next, what's the merge status ?
> 
> There is a remaining comment by Guennadi on the soc_camera patch.

I've seen that, it shouldn't be too hard to sort out.

I'll probably drop the dependency for now and implement a manual loop in the 
rcar-du-drm driver for now, and switch to your helpers when this series hit 
mainling. Which tree do you plan to send it through ?

-- 
Regards,

Laurent Pinchart

page allocator bug in 3.16?

[Thomas Hellstrom]

On 09/26/2014 02:28 PM, Rob Clark wrote:
> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom  
> wrote:
>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>>> On Fri, 26 Sep 2014 09:15:57 +0200
>>> Thomas Hellstrom  wrote:
>>>
 On 09/26/2014 01:52 AM, Peter Hurley wrote:
> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>> There are six ttm patches queued for 3.16.4:
>>
>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
>> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
>> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
> Thanks for info, Chuck.
>
> Unfortunately, none of these fix TTM dma allocation doing CMA dma 
> allocation,
> which is the root problem.
>
> Regards,
> Peter Hurley
 The problem is not really in TTM but in CMA, There was a guy offering to
 fix this in the CMA code but I guess he didn't probably because he
 didn't receive any feedback.

>>> Yeah, the "solution" to this problem seems to be "don't enable CMA on
>>> x86". Maybe it should even be disabled in the config system.
>> Or, as previously suggested, don't use CMA for order 0 (single page)
>> allocations
> On devices that actually need CMA pools to arrange for memory to be in
> certain ranges, I think you probably do want to have order 0 pages
> come from the CMA pool.

But can the DMA subsystem or more specifically dma_alloc_coherent()
really guarantee such things? Isn't it better for such devices to use
CMA directly?

/Thomas


>
> Seems like disabling CMA on x86 (where it should be unneeded) is the
> better way, IMO
>
> BR,
> -R
>
>
>> /Thomas
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/dri-devel=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=Uz7JXDXYXp4RlLs7G6qxMQlhOOT0trW3l78xpKg6Ass%3D%0A=50d6b7b3bfd093c93a228437a3d4414e49b4de817657c49c35154a115a5c2188

[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx

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

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

--- Comment #3 from Armandos  ---
I also received this suggestion from the Kalypso support team:
Dear Armandos,

please disable post processing and enable v-sync in the options in game.

Best regards.


Following their instructions DID NOT fix the issue, unfortunately.

-- 
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/20140926/8aa76a0e/attachment.html>

[PATCH libdrm 3/3] intel/skl: add gen9 to the CS decoding init

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
Reviewed-by: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
---
 intel/intel_decode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index a5d6e04..7d5cbe5 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3829,7 +3829,9 @@ drm_intel_decode_context_alloc(uint32_t devid)
ctx->devid = devid;
ctx->out = stdout;

-   if (IS_GEN8(devid))
+   if (IS_GEN9(devid))
+   ctx->gen = 9;
+   else if (IS_GEN8(devid))
ctx->gen = 8;
else if (IS_GEN7(devid))
ctx->gen = 7;
-- 
1.8.3.1

[PATCH libdrm 2/3] intel/skl: Add gen9 to the buffer manager init

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
Reviewed-by: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
---
 intel/intel_bufmgr_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index ba65527..a6fa224 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3479,6 +3479,8 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 7;
else if (IS_GEN8(bufmgr_gem->pci_device))
bufmgr_gem->gen = 8;
+   else if (IS_GEN9(bufmgr_gem->pci_device))
+   bufmgr_gem->gen = 9;
else {
free(bufmgr_gem);
bufmgr_gem = NULL;
-- 
1.8.3.1

[PATCH libdrm 1/3] intel/skl: Add SKL PCI ids

[Damien Lespiau]

v2: Add more PCI IDs (Michael H. Nguyen)
v3: Synchronize one more with the kernel PCI IDs (Damien)

Signed-off-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
Signed-off-by: Michael H. Nguyen 
---
 intel/intel_chipset.h | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 6f9bfad..e22a867 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -165,6 +165,22 @@
 #define PCI_CHIP_CHERRYVIEW_2  0x22b2
 #define PCI_CHIP_CHERRYVIEW_3  0x22b3

+#define PCI_CHIP_SKYLAKE_ULT_GT2   0x1916
+#define PCI_CHIP_SKYLAKE_ULT_GT1   0x1906
+#define PCI_CHIP_SKYLAKE_ULT_GT3   0x1926
+#define PCI_CHIP_SKYLAKE_ULT_GT2F  0x1921
+#define PCI_CHIP_SKYLAKE_ULX_GT1   0x190E
+#define PCI_CHIP_SKYLAKE_ULX_GT2   0x191E
+#define PCI_CHIP_SKYLAKE_DT_GT20x1912
+#define PCI_CHIP_SKYLAKE_DT_GT10x1902
+#define PCI_CHIP_SKYLAKE_HALO_GT2  0x191B
+#define PCI_CHIP_SKYLAKE_HALO_GT3  0x192B
+#define PCI_CHIP_SKYLAKE_HALO_GT1  0x190B
+#define PCI_CHIP_SKYLAKE_SRV_GT2   0x191A
+#define PCI_CHIP_SKYLAKE_SRV_GT3   0x192A
+#define PCI_CHIP_SKYLAKE_SRV_GT1   0x190A
+#define PCI_CHIP_SKYLAKE_WKS_GT2   0x191D
+
 #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
 (devid) == PCI_CHIP_I915_GM || \
 (devid) == PCI_CHIP_I945_GM || \
@@ -324,12 +340,37 @@
 #define IS_GEN8(devid) (IS_BROADWELL(devid) || \
 IS_CHERRYVIEW(devid))

+#define IS_SKL_GT1(devid)  ((devid) == PCI_CHIP_SKYLAKE_ULT_GT1|| \
+(devid) == PCI_CHIP_SKYLAKE_ULX_GT1|| \
+(devid) == PCI_CHIP_SKYLAKE_DT_GT1 || \
+(devid) == PCI_CHIP_SKYLAKE_HALO_GT1   || \
+(devid) == PCI_CHIP_SKYLAKE_SRV_GT1)
+
+#define IS_SKL_GT2(devid)  ((devid) == PCI_CHIP_SKYLAKE_ULT_GT2|| \
+(devid) == PCI_CHIP_SKYLAKE_ULT_GT2F   || \
+(devid) == PCI_CHIP_SKYLAKE_ULX_GT2|| \
+(devid) == PCI_CHIP_SKYLAKE_DT_GT2 || \
+(devid) == PCI_CHIP_SKYLAKE_HALO_GT2   || \
+(devid) == PCI_CHIP_SKYLAKE_SRV_GT2|| \
+(devid) == PCI_CHIP_SKYLAKE_WKS_GT2)
+
+#define IS_SKL_GT3(devid)  ((devid) == PCI_CHIP_SKYLAKE_ULT_GT3|| \
+(devid) == PCI_CHIP_SKYLAKE_HALO_GT3   || \
+(devid) == PCI_CHIP_SKYLAKE_SRV_GT3)
+
+#define IS_SKYLAKE(devid)  (IS_SKL_GT1(devid) || \
+IS_SKL_GT2(devid) || \
+IS_SKL_GT3(devid))
+
+#define IS_GEN9(devid) IS_SKYLAKE(devid)
+
 #define IS_9XX(dev)(IS_GEN3(dev) || \
 IS_GEN4(dev) || \
 IS_GEN5(dev) || \
 IS_GEN6(dev) || \
 IS_GEN7(dev) || \
-IS_GEN8(dev))
+IS_GEN8(dev) || \
+IS_GEN9(dev))


 #endif /* _INTEL_CHIPSET_H */
-- 
1.8.3.1

Stupid NVIDIA 3D vgaarb.c patch

[Aaron Plattner]

On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> Adding proper people and mailing lists..
>>
>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> appropriate, but hopefully somebody does. The fact that it makes
>> things work certainly argues fairly convincingly for it, but I want
>> some backup here.
>>
>> Dave, BenH?
>>
>> Christopher(?), can you please also specify which laptop etc. And the
>> patch itself seems to have come from somebody else, unless you're
>> Lekensteyn. So we'd want to get the provenance of that too.
>
> Hrm, that sucks. "3D" could mean anything really, we might need an
> explicit vendor ID check as well and maybe even device ID ...

If my understanding is correct, the board designers explicitly mark them 
as "3D controller" when they don't have any outputs connected, 
specifically so the SBIOS won't choose them as the boot VGA device. 
Depending on the design, some GPUs on these 3D controller boards don't 
have a display engine at all, while others still have it in the silicon 
but leave it disabled at runtime.  In either case, VGA should not be 
routed to them and I don't think they should need to participate in VGA 
arbitration.

-- Aaron

> Ben.
>
>>  Linus
>>
>> On Mon, Sep 22, 2014 at 1:28 PM, C Bergstr?m  
>> wrote:
>>> Hi Linus,
>>>
>>> I don't know who the original author is and I can have one of the distro
>>> graphics friends review it, but I need this patch below to get NVIDIA
>>> drivers to work (without using any Intel graphics) on my laptop
>>> http://pastebin.com/wpmFi38k
>>>
>>> Sorry - I know this is not the proper way to submit a patch, but it's
>>> trivial and I'm not a kernel dev.
>>>
>>> Thanks
>>>
>>> ./C

[PATCH v3 00/23] AMDKFD Kernel Driver

[Oded Gabbay]

On 05/08/14 21:35, Gabbay, Oded wrote:
> 
> 
> On 05/08/14 20:11, David Herrmann wrote:
>> Hi
>>
>> On Tue, Aug 5, 2014 at 5:30 PM, Oded Gabbay  wrote:
>>> Hi,
>>> Here is the v3 patch set of amdkfd.
>>>
>>> This version contains changes and fixes to code, as agreed on during the 
>>> review
>>> of the v2 patch set.
>>>
>>> The major changes are:
>>>
>>> - There are two new module parameters: # of processes and # of queues per
>>>   process. The defaults, as agreed on in the v2 review, are 32 and 128
>>>   respectively. This sets the default amount of GART address space that 
>>> amdkfd
>>>   requires to 3.5MB (3MB for userspace queues mqds and 0.5MB for other 
>>> stuff,
>>>   such as mqd for kernel queue, hpd for pipelines, etc.)
>>>
>>> - All the GART address space usage of amdkfd is done inside a single 
>>> contiguous
>>>   buffer that is allocated from system memory, and pinned to the start of 
>>> the
>>>   GART during the startup of amdkfd (which is just after the startup of
>>>   radeon). The management of this buffer is done by the radeon sa manager.
>>>   This buffer is not evict-able.
>>>
>>> - Mapping of doorbells is initiated by the userspace lib (by mmap syscall),
>>>   instead of initiating it from inside an ioctl (using vm_mmap).
>>>
>>> - Removed ioctls for exclusive access to performance counters
>>>
>>> - Added documentation about the QCM (Queue Control Management), apertures 
>>> and
>>>   interfaces between amdkfd and radeon.
>>>
>>> Two important notes:
>>>
>>> - The topology patch has not been changed. Look at
>>>   http://lists.freedesktop.org/archives/dri-devel/2014-July/065042.html
>>>   for my response. I also put my answer as an explanation in the commit msg
>>>   of the patch.
>>
>> This patchset adds 10.000 lines and contains nearly 0 comments *why*
>> stuff is added. Seriously, it is almost impossible to understand what
>> you're doing. Can you please include a high-level introduction in the
>> [0/X] cover-letter and include it in every series you send? A
>> blog-post or something would also be fine. And yes, it's totally ok if
>> this is 10k lines of plain-text.
> 
> My bad. I forgot to attach the cover letter of v2 and especially v1,
> which includes a lengthy explanation of the driver.
> 
> So here it is and I will respond to your other comments later.
> 
> Oded
> 
> v2 cover letter:
> ---
> 
> As a continuation to the existing discussion, here is a v2 patch series
> restructured with a cleaner history and no totally-different-early-versions
> of the code.
> 
> Instead of 83 patches, there are now a total of 25 patches, where 5 of them
> are modifications to radeon driver and 18 of them include only amdkfd code.
> There is no code going away or even modified between patches, only added.
> 
> The driver was renamed from radeon_kfd to amdkfd and moved to reside under
> drm/radeon/amdkfd. This move was done to emphasize the fact that this
> driver
> is an AMD-only driver at this point. Having said that, we do foresee
> a generic hsa framework being implemented in the future and in that case,
> we will adjust amdkfd to work within that framework.
> 
> As the amdkfd driver should support multiple AMD gfx drivers, we want to
> keep it as a seperate driver from radeon. Therefore, the amdkfd code is
> contained in its own folder. The amdkfd folder was put under the radeon
> folder because the only AMD gfx driver in the Linux kernel at this point
> is the radeon driver. Having said that, we will probably need to move
> it (maybe to be directly under drm) after we integrate with additional AMD
> gfx drivers.
> 
> For people who like to review using git, the v2 patch set is located at:
> http://cgit.freedesktop.org/~gabbayo/linux/log/?h=kfd-next-3.17-v2
> 
> Written by Oded Gabbayh 
> 
> -
> Original Cover Letter:
> -
> 
> This patch set implements a Heterogeneous System Architecture (HSA) driver
> for radeon-family GPUs.
> 
> HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share
> system resources more effectively via HW features including shared pageable
> memory, userspace-accessible work queues, and platform-level atomics. In
> addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea
> Islands family of GPUs also performs HW-level validation of commands passed
> in through the queues (aka rings).
> 
> The code in this patch set is intended to serve both as a sample driver for
> other HSA-compatible hardware devices and as a production driver for
> radeon-family processors. The code is architected to support multiple CPUs
> each with connected GPUs, although the current implementation focuses on a
> single Kaveri/Berlin APU, and works alongside the existing radeon kernel
> graphics driver (kgd).
> 
> AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware
> functionality between HSA compute and regular gfx/compute (memory,
> interrupts, registers), 

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Alexandre Courbot]

On 09/26/2014 12:48 AM, Stephen Warren wrote:
> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>> still required for enabling the GPU. Is there anything blocking it
>> (firmware
>> not available yet in liux-firmware?)
>
> I think initially I was waiting for the DRM patch "drm/nouvea: support
> for probing platform devices" to be applied, but it looks like that's
> been applied already, so only patches 4 and 5 in this series are still
> outstanding.

Actually I am waiting for the firmware and firmware loading support 
patch to land in linux-firmware and Nouveau respectively. I have yet to 
send these patches publicly due to some ongoing discussion about the 
firmware's license.

For now if you want to run Nouveau on TK1, the easiest solution is to 
use my kernel and Nouveau branches. The branches that should be used are 
visible in the manifest of 
https://github.com/Gnurou/tegra-nouveau-rootfs - which BTW also provides 
an easy way to enable the FOSS graphics stack on a L4T image (minus the 
firmware at the moment).

More generally speaking, I still have a lot of patches to upstream - I 
apologize for not having been able to catch up with them. Things have 
been busy on other fronts, but since these other fronts are soon not 
going to be a concern anymore I will be able to focus on Nouveau again 
after mid-next week. :)

>
> Alex, wasn't there also some issue where the VPR register had to be
> programmed, and if it wasn't there'd be a hang when the GPU registers
> were touched? If we've added code to Nouveau/tegradrm to detect that and
> avoid the problem, then I guess we can commit these last two patches for
> 3.19. A resend after the 3.18 merge window might help.

The VPR patch has landed in U-boot mainline, so this should be less of a 
problem now. AFAIK there is no safe way to check whether VPR has been 
disabled, but the solution might be in your suggestion to make the 
bootloader enable the GPU DT node if it finds it safe to do so.

[RFC PATCH 7/7] drm/prime: Support explicit fence on export

[Lauri Peltonen]

Allow user space to provide an explicit sync fence fd when exporting
a dma-buf from gem handle.  The fence will be stored as the explicit
fence to the reservation object.

Signed-off-by: Lauri Peltonen 
---
 drivers/gpu/drm/drm_prime.c | 41 +
 include/uapi/drm/drm.h  |  9 -
 2 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2807a77..c69df2e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -28,8 +28,10 @@

 #include 
 #include 
+#include 
 #include 
 #include "drm_internal.h"
+#include "../../staging/android/sync.h"

 /*
  * DMA-BUF/GEM Object references and lifetime overview:
@@ -329,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * drm_gem_prime_export - helper library implemention of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC or DRM_SYNC_FD
  *
  * This is the implementation of the gem_prime_export functions for GEM drivers
  * using the PRIME helpers.
@@ -385,7 +387,7 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
  * @dev: dev to export the buffer from
  * @file_priv: drm file-private structure
  * @handle: buffer handle to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC or DRM_SYNC_FD
  * @prime_fd: pointer to storage for the fd id of the create dma-buf
  *
  * This is the PRIME export function which must be used mandatorily by GEM
@@ -401,6 +403,24 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_gem_object *obj;
int ret = 0;
struct dma_buf *dmabuf;
+   struct fence *fence = NULL;
+
+   if (flags & DRM_SYNC_FD) {
+#ifdef CONFIG_SYNC
+   struct sync_fence *sf = sync_fence_fdget(*prime_fd);
+   if (!sf)
+   return -ENOENT;
+   if (sf->num_fences != 1) {
+   sync_fence_put(sf);
+   return -EINVAL;
+   }
+   fence = fence_get(sf->cbs[0].sync_pt);
+   sync_fence_put(sf);
+   flags &= ~DRM_SYNC_FD;
+#else
+   return -ENODEV;
+#endif
+   }

mutex_lock(_priv->prime.lock);
obj = drm_gem_object_lookup(dev, file_priv, handle);
@@ -453,6 +473,14 @@ out_have_obj:
goto fail_put_dmabuf;

 out_have_handle:
+   if (fence) {
+   if (!dmabuf->resv) {
+   ret = -ENODEV;
+   goto fail_put_dmabuf;
+   }
+   reservation_object_add_excl_fence(dmabuf->resv, fence);
+   }
+
ret = dma_buf_fd(dmabuf, flags);
/*
 * We must _not_ remove the buffer from the handle cache since the newly
@@ -475,6 +503,7 @@ out:
drm_gem_object_unreference_unlocked(obj);
 out_unlock:
mutex_unlock(_priv->prime.lock);
+   fence_put(fence);

return ret;
 }
@@ -624,7 +653,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
 struct drm_file *file_priv)
 {
struct drm_prime_handle *args = data;
-   uint32_t flags;

if (!drm_core_check_feature(dev, DRIVER_PRIME))
return -EINVAL;
@@ -633,14 +661,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
return -ENOSYS;

/* check flags are valid */
-   if (args->flags & ~DRM_CLOEXEC)
+   if (args->flags & ~(DRM_CLOEXEC | DRM_SYNC_FD))
return -EINVAL;

-   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
-   flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
-   args->handle, flags, >fd);
+   args->handle, args->flags, >fd);
 }

 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b0b8556..a11b893 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -661,13 +661,20 @@ struct drm_set_client_cap {
 };

 #define DRM_CLOEXEC O_CLOEXEC
+#define DRM_SYNC_FD O_DSYNC
 struct drm_prime_handle {
__u32 handle;

/** Flags.. only applicable for handle->fd */
__u32 flags;

-   /** Returned dmabuf file descriptor */
+   /**
+* DRM_IOCTL_PRIME_FD_TO_HANDLE:
+*   in: dma-buf fd
+* DRM_IOCTL_PRIME_HANDLE_TO_FD:
+*   in: sync fence fd if DRM_SYNC_FD flag is passed
+*   out: dma-buf fd
+*/
__s32 fd;
 };

-- 
1.8.1.5

[RFC PATCH 6/7] drm/nouveau: Support marking buffers for explicit sync

[Lauri Peltonen]

Do not attach fences automatically to buffers that are marked for
explicit synchronization.

Signed-off-by: Lauri Peltonen 
---
 drm/nouveau_bo.c   |  8 
 drm/nouveau_bo.h   |  4 ++--
 drm/nouveau_drm.c  |  1 +
 drm/nouveau_gem.c  | 47 +++---
 drm/nouveau_gem.h  |  6 --
 drm/nouveau_ttm.c  |  8 
 drm/nv50_display.c |  2 +-
 drm/uapi/drm/nouveau_drm.h |  5 -
 8 files changed, 60 insertions(+), 21 deletions(-)

diff --git a/drm/nouveau_bo.c b/drm/nouveau_bo.c
index 534734a..68b7bdd 100644
--- a/drm/nouveau_bo.c
+++ b/drm/nouveau_bo.c
@@ -180,7 +180,7 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,

 int
 nouveau_bo_new(struct drm_device *dev, int size, int align,
-  uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
+  uint32_t flags, uint32_t tile_mode, uint32_t bo_flags,
   struct sg_table *sg,
   struct nouveau_bo **pnvbo)
 {
@@ -211,7 +211,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
INIT_LIST_HEAD(>entry);
INIT_LIST_HEAD(>vma_list);
nvbo->tile_mode = tile_mode;
-   nvbo->tile_flags = tile_flags;
+   nvbo->bo_flags = bo_flags;
nvbo->bo.bdev = >ttm.bdev;

if (!nv_device_is_cpu_coherent(nvkm_device(>device)))
@@ -272,7 +272,7 @@ set_placement_range(struct nouveau_bo *nvbo, uint32_t type)
 * speed up when alpha-blending and depth-test are enabled
 * at the same time.
 */
-   if (nvbo->tile_flags & NOUVEAU_GEM_TILE_ZETA) {
+   if (nvbo->bo_flags & NOUVEAU_GEM_TILE_ZETA) {
fpfn = vram_pages / 2;
lpfn = ~0;
} else {
@@ -1291,7 +1291,7 @@ nouveau_bo_vm_bind(struct ttm_buffer_object *bo, struct 
ttm_mem_reg *new_mem,
if (drm->device.info.family >= NV_DEVICE_INFO_V0_CELSIUS) {
*new_tile = nv10_bo_set_tiling(dev, offset, new_mem->size,
nvbo->tile_mode,
-   nvbo->tile_flags);
+   nvbo->bo_flags);
}

return 0;
diff --git a/drm/nouveau_bo.h b/drm/nouveau_bo.h
index f97bc26..ff1edba 100644
--- a/drm/nouveau_bo.h
+++ b/drm/nouveau_bo.h
@@ -25,7 +25,7 @@ struct nouveau_bo {
unsigned page_shift;

u32 tile_mode;
-   u32 tile_flags;
+   u32 bo_flags;
struct nouveau_drm_tile *tile;

/* Only valid if allocated via nouveau_gem_new() and iff you hold a
@@ -68,7 +68,7 @@ extern struct ttm_bo_driver nouveau_bo_driver;

 void nouveau_bo_move_init(struct nouveau_drm *);
 int  nouveau_bo_new(struct drm_device *, int size, int align, u32 flags,
-   u32 tile_mode, u32 tile_flags, struct sg_table *sg,
+   u32 tile_mode, u32 bo_flags, struct sg_table *sg,
struct nouveau_bo **);
 int  nouveau_bo_pin(struct nouveau_bo *, u32 flags);
 int  nouveau_bo_unpin(struct nouveau_bo *);
diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c
index 74d5ac6..3d84f3a 100644
--- a/drm/nouveau_drm.c
+++ b/drm/nouveau_drm.c
@@ -816,6 +816,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_SET_INFO, nouveau_gem_ioctl_set_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 };

 long
diff --git a/drm/nouveau_gem.c b/drm/nouveau_gem.c
index ee5782c..bb19507 100644
--- a/drm/nouveau_gem.c
+++ b/drm/nouveau_gem.c
@@ -149,7 +149,7 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct 
drm_file *file_priv)

 int
 nouveau_gem_new(struct drm_device *dev, int size, int align, uint32_t domain,
-   uint32_t tile_mode, uint32_t tile_flags,
+   uint32_t tile_mode, uint32_t bo_flags,
struct nouveau_bo **pnvbo)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -165,7 +165,7 @@ nouveau_gem_new(struct drm_device *dev, int size, int 
align, uint32_t domain,
flags |= TTM_PL_FLAG_SYSTEM;

ret = nouveau_bo_new(dev, size, align, flags, tile_mode,
-tile_flags, NULL, pnvbo);
+bo_flags, NULL, pnvbo);
if (ret)
return ret;
nvbo = *pnvbo;
@@ -216,7 +216,21 @@ nouveau_gem_info(struct drm_file *file_priv, struct 
drm_gem_object *gem,
rep->size = nvbo->bo.mem.num_pages << PAGE_SHIFT;
rep->map_handle = drm_vma_node_offset_addr(>bo.vma_node);
rep->tile_mode = nvbo->tile_mode;
-   rep->tile_flags = 

[RFC PATCH 5/7] libdrm: nouveau: Support fence fds

[Lauri Peltonen]

Add a new nouveau_pushbuf_kick_fence function that takes and emits
a sync fence fd.  The fence fd can be waited on, or merged with
other fence fd's, or passed back to kernel as a prerquisite for a
subsequent hw operation.

Signed-off-by: Lauri Peltonen 
---
 include/drm/nouveau_drm.h | 10 +
 nouveau/nouveau.h |  2 +
 nouveau/pushbuf.c | 93 ---
 3 files changed, 76 insertions(+), 29 deletions(-)

diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index b18cad0..3e40210 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -171,6 +171,15 @@ struct drm_nouveau_gem_pushbuf {
uint64_t gart_available;
 };

+#define NOUVEAU_GEM_PUSHBUF_2_FENCE_WAIT 0x0001
+#define NOUVEAU_GEM_PUSHBUF_2_FENCE_EMIT 0x0002
+struct drm_nouveau_gem_pushbuf_2 {
+   struct drm_nouveau_gem_pushbuf base;
+   uint32_t flags;
+   int32_t  fence;
+   uint64_t reserved;
+};
+
 #define NOUVEAU_GEM_CPU_PREP_NOWAIT  0x0001
 #define NOUVEAU_GEM_CPU_PREP_NOBLOCK 0x0002
 #define NOUVEAU_GEM_CPU_PREP_WRITE   0x0004
@@ -204,5 +213,6 @@ struct drm_nouveau_sarea {
 #define DRM_NOUVEAU_GEM_CPU_PREP   0x42
 #define DRM_NOUVEAU_GEM_CPU_FINI   0x43
 #define DRM_NOUVEAU_GEM_INFO   0x44
+#define DRM_NOUVEAU_GEM_PUSHBUF_2  0x45

 #endif /* __NOUVEAU_DRM_H__ */
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index a55e2b0..281420f 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -225,6 +225,8 @@ void nouveau_pushbuf_reloc(struct nouveau_pushbuf *, struct 
nouveau_bo *,
 int  nouveau_pushbuf_validate(struct nouveau_pushbuf *);
 uint32_t nouveau_pushbuf_refd(struct nouveau_pushbuf *, struct nouveau_bo *);
 int  nouveau_pushbuf_kick(struct nouveau_pushbuf *, struct nouveau_object 
*channel);
+int  nouveau_pushbuf_kick_fence(struct nouveau_pushbuf *,
+   struct nouveau_object *channel, int *fence);
 struct nouveau_bufctx *
 nouveau_pushbuf_bufctx(struct nouveau_pushbuf *, struct nouveau_bufctx *);

diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index 6e703a4..8667d05 100644
--- a/nouveau/pushbuf.c
+++ b/nouveau/pushbuf.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -77,7 +78,7 @@ nouveau_pushbuf(struct nouveau_pushbuf *push)
 }

 static int pushbuf_validate(struct nouveau_pushbuf *, bool);
-static int pushbuf_flush(struct nouveau_pushbuf *);
+static int pushbuf_flush(struct nouveau_pushbuf *, int *);

 static bool
 pushbuf_kref_fits(struct nouveau_pushbuf *push, struct nouveau_bo *bo,
@@ -172,7 +173,7 @@ pushbuf_kref(struct nouveau_pushbuf *push, struct 
nouveau_bo *bo,
 */
fpush = cli_push_get(push->client, bo);
if (fpush && fpush != push)
-   pushbuf_flush(fpush);
+   pushbuf_flush(fpush, NULL);

kref = cli_kref_get(push->client, bo);
if (kref) {
@@ -305,18 +306,21 @@ pushbuf_dump(struct nouveau_pushbuf_krec *krec, int 
krec_id, int chid)
 }

 static int
-pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan)
+pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan,
+  int *fence)
 {
struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(push);
struct nouveau_pushbuf_krec *krec = nvpb->list;
struct nouveau_device *dev = push->client->device;
struct drm_nouveau_gem_pushbuf_bo_presumed *info;
struct drm_nouveau_gem_pushbuf_bo *kref;
-   struct drm_nouveau_gem_pushbuf req;
+   struct drm_nouveau_gem_pushbuf_2 req_2;
+   struct drm_nouveau_gem_pushbuf *req = _2.base;
struct nouveau_fifo *fifo = chan->data;
struct nouveau_bo *bo;
int krec_id = 0;
int ret = 0, i;
+   int fence_out = -1;

if (chan->oclass != NOUVEAU_FIFO_CHANNEL_CLASS)
return -EINVAL;
@@ -326,30 +330,42 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct 
nouveau_object *chan)

nouveau_pushbuf_data(push, NULL, 0, 0);

+   /* TODO: If fence is requested, force kickoff. */
while (krec && krec->nr_push) {
-   req.channel = fifo->channel;
-   req.nr_buffers = krec->nr_buffer;
-   req.buffers = (uint64_t)(unsigned long)krec->buffer;
-   req.nr_relocs = krec->nr_reloc;
-   req.nr_push = krec->nr_push;
-   req.relocs = (uint64_t)(unsigned long)krec->reloc;
-   req.push = (uint64_t)(unsigned long)krec->push;
-   req.suffix0 = nvpb->suffix0;
-   req.suffix1 = nvpb->suffix1;
-   req.vram_available = 0; /* for valgrind */
-   req.gart_available = 0;
+   req->channel = fifo->channel;
+   req->nr_buffers = krec->nr_buffer;
+   

[RFC PATCH 4/7] drm/nouveau: Support fence fd's at kickoff

[Lauri Peltonen]

Add a new NOUVEAU_GEM_PUSHBUF_2 ioctl that accepts and emits a sync
fence fd from/to user space if the user space requests it by passing
corresponding flags.

Signed-off-by: Lauri Peltonen 
---
 drm/nouveau_drm.c  |  1 +
 drm/nouveau_gem.c  | 46 ++
 drm/nouveau_gem.h  |  2 ++
 drm/uapi/drm/nouveau_drm.h | 11 +++
 4 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c
index 244d78f..74d5ac6 100644
--- a/drm/nouveau_drm.c
+++ b/drm/nouveau_drm.c
@@ -812,6 +812,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GPUOBJ_FREE, nouveau_abi16_ioctl_gpuobj_free, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_NEW, nouveau_gem_ioctl_new, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF, nouveau_gem_ioctl_pushbuf, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF_2, nouveau_gem_ioctl_pushbuf_2, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
diff --git a/drm/nouveau_gem.c b/drm/nouveau_gem.c
index 78398d4..ee5782c 100644
--- a/drm/nouveau_gem.c
+++ b/drm/nouveau_gem.c
@@ -636,15 +636,16 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
return ret;
 }

-int
-nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+static int
+__nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
+   struct drm_nouveau_gem_pushbuf *req,
+   struct drm_nouveau_gem_pushbuf_2 *req_2,
+   struct drm_file *file_priv)
 {
struct nouveau_abi16 *abi16 = nouveau_abi16_get(file_priv, dev);
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_abi16_chan *temp;
struct nouveau_drm *drm = nouveau_drm(dev);
-   struct drm_nouveau_gem_pushbuf *req = data;
struct drm_nouveau_gem_pushbuf_push *push;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
@@ -725,6 +726,14 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
}
}

+   if (req_2 && (req_2->flags & NOUVEAU_GEM_PUSHBUF_2_FENCE_WAIT)) {
+   ret = nouveau_fence_sync_fd(req_2->fence, chan);
+   if (ret) {
+   NV_PRINTK(error, cli, "fence wait: %d\n", ret);
+   goto out;
+   }
+   }
+
if (chan->dma.ib_max) {
ret = nouveau_dma_wait(chan, req->nr_push + 1, 16);
if (ret) {
@@ -800,6 +809,16 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
goto out;
}

+   if (req_2 && (req_2->flags & NOUVEAU_GEM_PUSHBUF_2_FENCE_EMIT)) {
+   ret = nouveau_fence_install(>base, "nv-pushbuf",
+   _2->fence);
+   if (ret) {
+   NV_PRINTK(error, cli, "fence install: %d\n", ret);
+   WIND_RING(chan);
+   goto out;
+   }
+   }
+
 out:
validate_fini(, fence, bo);
nouveau_fence_unref();
@@ -825,6 +844,25 @@ out_next:
return nouveau_abi16_put(abi16, ret);
 }

+int
+nouveau_gem_ioctl_pushbuf_2(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_nouveau_gem_pushbuf_2 *req_2 = data;
+   struct drm_nouveau_gem_pushbuf *req = _2->base;
+
+   return __nouveau_gem_ioctl_pushbuf(dev, req, req_2, file_priv);
+}
+
+int
+nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_nouveau_gem_pushbuf *req = data;
+
+   return __nouveau_gem_ioctl_pushbuf(dev, req, NULL, file_priv);
+}
+
 static inline uint32_t
 domain_to_ttm(struct nouveau_bo *nvbo, uint32_t domain)
 {
diff --git a/drm/nouveau_gem.h b/drm/nouveau_gem.h
index ddab762..7454dea 100644
--- a/drm/nouveau_gem.h
+++ b/drm/nouveau_gem.h
@@ -27,6 +27,8 @@ extern int nouveau_gem_ioctl_new(struct drm_device *, void *,
 struct drm_file *);
 extern int nouveau_gem_ioctl_pushbuf(struct drm_device *, void *,
 struct drm_file *);
+extern int nouveau_gem_ioctl_pushbuf_2(struct drm_device *, void *,
+  struct drm_file *);
 extern int nouveau_gem_ioctl_cpu_prep(struct drm_device *, void *,
  struct drm_file *);
 extern int 

[RFC PATCH 3/7] drm/nouveau: Add fence fd helpers

[Lauri Peltonen]

Add nouveau_fence_install, which installs a drm fence as a file
descriptor that can be returned to user space.

Add nouveau_fence_sync_fd, which pushes semaphore wait commands for
each Nouveau fence contained within the sync fd.  If the sync fd
contains non-Nouveau fences, those are waited on the CPU.

Add missing fence_value_str and timeline_value_str callbacks to
nouveau fence_ops.

Signed-off-by: Lauri Peltonen 
---
 drm/nouveau_fence.c | 71 -
 drm/nouveau_fence.h |  2 ++
 2 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drm/nouveau_fence.c b/drm/nouveau_fence.c
index 39b5436..e67d467 100644
--- a/drm/nouveau_fence.c
+++ b/drm/nouveau_fence.c
@@ -37,6 +37,8 @@
 #include "nouveau_dma.h"
 #include "nouveau_fence.h"

+#include "../drivers/staging/android/sync.h"
+
 static const struct fence_ops nouveau_fence_ops_uevent;
 static const struct fence_ops nouveau_fence_ops_legacy;

@@ -471,11 +473,78 @@ static bool nouveau_fence_enable_signaling(struct fence 
*f)
return ret;
 }

+static void nouveau_fence_timeline_value_str(struct fence *fence,
+char *str, int size)
+{
+   struct nouveau_fence *f = from_fence(fence);
+   struct nouveau_fence_chan *fctx = nouveau_fctx(f);
+   u32 cur;
+
+   cur = f->channel ? fctx->read(f->channel) : 0;
+   snprintf(str, size, "%d", cur);
+}
+
+static void
+nouveau_fence_value_str(struct fence *fence, char *str, int size)
+{
+   snprintf(str, size, "%d", fence->seqno);
+}
+
 static const struct fence_ops nouveau_fence_ops_uevent = {
.get_driver_name = nouveau_fence_get_get_driver_name,
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_enable_signaling,
.signaled = nouveau_fence_is_signaled,
.wait = fence_default_wait,
-   .release = NULL
+   .release = NULL,
+   .fence_value_str = nouveau_fence_value_str,
+   .timeline_value_str = nouveau_fence_timeline_value_str,
 };
+
+int
+nouveau_fence_install(struct fence *fence, const char *name, int *fd_out)
+{
+#ifdef CONFIG_SYNC
+   struct sync_fence *f;
+   int fd;
+
+   f = sync_fence_create(name, , 1);
+   if (!f)
+   return -ENOMEM;
+
+   fd = get_unused_fd();
+   if (fd < 0) {
+   sync_fence_put(f);
+   return fd;
+   }
+   sync_fence_install(f, fd);
+   *fd_out = fd;
+   return 0;
+#else
+   return -ENODEV;
+#endif
+}
+
+int
+nouveau_fence_sync_fd(int fence_fd, struct nouveau_channel *chan)
+{
+#ifdef CONFIG_SYNC
+   int i, ret = 0;
+   struct sync_fence *fence;
+
+   fence = sync_fence_fdget(fence_fd);
+   if (!fence)
+   return -EINVAL;
+
+   for (i = 0; i < fence->num_fences; ++i) {
+   struct fence *pt = fence->cbs[i].sync_pt;
+
+   ret = nouveau_fence_sync(pt, chan);
+   if (ret)
+   break;
+   }
+   sync_fence_put(fence);
+   return ret;
+#else
+   return -ENODEV;
+#endif
+}
diff --git a/drm/nouveau_fence.h b/drm/nouveau_fence.h
index 8b70166..76342ea 100644
--- a/drm/nouveau_fence.h
+++ b/drm/nouveau_fence.h
@@ -27,6 +27,8 @@ bool nouveau_fence_done(struct nouveau_fence *);
 void nouveau_fence_work(struct fence *, void (*)(void *), void *);
 int  nouveau_fence_wait(struct nouveau_fence *, bool lazy, bool intr);
 int  nouveau_fence_sync(struct fence *, struct nouveau_channel *);
+int  nouveau_fence_sync_fd(int, struct nouveau_channel *);
+int  nouveau_fence_install(struct fence *, const char *name, int *);

 struct nouveau_fence_chan {
spinlock_t lock;
-- 
1.8.1.5

[RFC PATCH 2/7] drm/nouveau: Split nouveau_fence_sync

[Lauri Peltonen]

Split nouveau_fence_sync to two functions:

 * nouveau_fence_sync, which only adds a fence wait to the channel
   command stream, and
 * nouveau_bo_sync, which gets the fences from the reservation object
   and passes them to nouveau_fence_sync.

Signed-off-by: Lauri Peltonen 
---
 drm/nouveau_bo.c  | 38 +++-
 drm/nouveau_bo.h  |  2 ++
 drm/nouveau_display.c |  4 ++--
 drm/nouveau_fence.c   | 54 ---
 drm/nouveau_fence.h   |  2 +-
 drm/nouveau_gem.c |  2 +-
 6 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/drm/nouveau_bo.c b/drm/nouveau_bo.c
index 70c3cb5..534734a 100644
--- a/drm/nouveau_bo.c
+++ b/drm/nouveau_bo.c
@@ -463,6 +463,42 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
 }

 int
+nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool 
exclusive)
+{
+   struct fence *fence;
+   struct reservation_object *resv = nvbo->bo.resv;
+   struct reservation_object_list *fobj;
+   int ret = 0, i;
+
+   if (!exclusive) {
+   ret = reservation_object_reserve_shared(resv);
+
+   if (ret)
+   return ret;
+   }
+
+   fobj = reservation_object_get_list(resv);
+   fence = reservation_object_get_excl(resv);
+
+   if (fence && (!exclusive || !fobj || !fobj->shared_count))
+   return nouveau_fence_sync(fence, chan);
+
+   if (!exclusive || !fobj)
+   return ret;
+
+   for (i = 0; i < fobj->shared_count && !ret; ++i) {
+   fence = rcu_dereference_protected(fobj->shared[i],
+   reservation_object_held(resv));
+   ret = nouveau_fence_sync(fence, chan);
+
+   if (ret)
+   break;
+   }
+
+   return ret;
+}
+
+int
 nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
 {
@@ -1070,7 +1106,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
}

mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
-   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true);
+   ret = nouveau_bo_sync(nouveau_bo(bo), chan, true);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, >mem, new_mem);
if (ret == 0) {
diff --git a/drm/nouveau_bo.h b/drm/nouveau_bo.h
index 8ab877b..f97bc26 100644
--- a/drm/nouveau_bo.h
+++ b/drm/nouveau_bo.h
@@ -84,6 +84,8 @@ int  nouveau_bo_validate(struct nouveau_bo *, bool 
interruptible,
 bool no_wait_gpu);
 void nouveau_bo_sync_for_device(struct nouveau_bo *nvbo);
 void nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo);
+int  nouveau_bo_sync(struct nouveau_bo *, struct nouveau_channel *,
+bool exclusive);

 struct nouveau_vma *
 nouveau_bo_vma_find(struct nouveau_bo *, struct nouveau_vm *);
diff --git a/drm/nouveau_display.c b/drm/nouveau_display.c
index 6d0a3cd..41b130c 100644
--- a/drm/nouveau_display.c
+++ b/drm/nouveau_display.c
@@ -658,7 +658,7 @@ nouveau_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(>event_lock, flags);

/* Synchronize with the old framebuffer */
-   ret = nouveau_fence_sync(old_bo, chan, false);
+   ret = nouveau_bo_sync(old_bo, chan, false);
if (ret)
goto fail;

@@ -722,7 +722,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
goto fail_unpin;

/* synchronise rendering channel with the kernel's channel */
-   ret = nouveau_fence_sync(new_bo, chan, false);
+   ret = nouveau_bo_sync(new_bo, chan, false);
if (ret) {
ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
diff --git a/drm/nouveau_fence.c b/drm/nouveau_fence.c
index decfe6c..39b5436 100644
--- a/drm/nouveau_fence.c
+++ b/drm/nouveau_fence.c
@@ -342,57 +342,19 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
lazy, bool intr)
 }

 int
-nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool 
exclusive)
+nouveau_fence_sync(struct fence *fence, struct nouveau_channel *chan)
 {
struct nouveau_fence_chan *fctx = chan->fence;
-   struct fence *fence;
-   struct reservation_object *resv = nvbo->bo.resv;
-   struct reservation_object_list *fobj;
+   struct nouveau_channel *prev = NULL;
struct nouveau_fence *f;
-   int ret = 0, i;
-
-   if (!exclusive) {
-   ret = reservation_object_reserve_shared(resv);
-
-   if (ret)
-   return ret;
-   }
-
-   fobj = reservation_object_get_list(resv);
-   fence = reservation_object_get_excl(resv);
-
-   if (fence && (!exclusive || !fobj || !fobj->shared_count)) {
-   struct nouveau_channel *prev = NULL;
-
-   f = nouveau_local_fence(fence, chan->drm);
-   if (f)
- 

[RFC PATCH 1/7] android: Support creating sync fence from drm fences

[Lauri Peltonen]

Modify sync_fence_create to accept an array of 'struct fence' objects.
This will allow drm drivers to create sync_fence objects and pass sync
fd's between user space with minimal modifications, without ever creating
sync_timeline or sync_pt objects, and without implementing the
sync_timeline_ops interface.

Modify the sync driver debug code to not assume that every 'struct fence'
(that is associated with a 'struct sync_fence') is embedded within a
'struct sync_pt'.

Signed-off-by: Lauri Peltonen 
---
 drivers/staging/android/sw_sync.c|  3 ++-
 drivers/staging/android/sync.c   | 34 ++---
 drivers/staging/android/sync.h   | 11 ++-
 drivers/staging/android/sync_debug.c | 37 +---
 4 files changed, 44 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/android/sw_sync.c 
b/drivers/staging/android/sw_sync.c
index a76db3f..6949812 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -184,7 +184,8 @@ static long sw_sync_ioctl_create_fence(struct 
sw_sync_timeline *obj,
}

data.name[sizeof(data.name) - 1] = '\0';
-   fence = sync_fence_create(data.name, pt);
+   fence = sync_fence_create(data.name,
+ (struct fence *[]){ >base }, 1);
if (fence == NULL) {
sync_pt_free(pt);
err = -ENOMEM;
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index e7b2e02..1d0d968 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -187,28 +187,32 @@ static void fence_check_cb_func(struct fence *f, struct 
fence_cb *cb)
wake_up_all(>wq);
 }

-/* TODO: implement a create which takes more that one sync_pt */
-struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+struct sync_fence *sync_fence_create(const char *name,
+struct fence **fences, int num_fences)
 {
-   struct sync_fence *fence;
+   struct sync_fence *sync_fence;
+   int size = offsetof(struct sync_fence, cbs[num_fences]);
+   int i;

-   fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[1]), name);
-   if (fence == NULL)
+   sync_fence = sync_fence_alloc(size, name);
+   if (sync_fence == NULL)
return NULL;

-   fence->num_fences = 1;
-   atomic_set(>status, 1);
+   sync_fence->num_fences = num_fences;
+   atomic_set(_fence->status, 0);

-   fence_get(>base);
-   fence->cbs[0].sync_pt = >base;
-   fence->cbs[0].fence = fence;
-   if (fence_add_callback(>base, >cbs[0].cb,
-  fence_check_cb_func))
-   atomic_dec(>status);
+   for (i = 0; i < num_fences; i++) {
+   struct fence *f = fences[i];
+   struct sync_fence_cb *cb = _fence->cbs[i];

-   sync_fence_debug_add(fence);
+   cb->sync_pt = fence_get(f);
+   cb->fence = sync_fence;
+   if (!fence_add_callback(f, >cb, fence_check_cb_func))
+   atomic_inc(_fence->status);
+   }
+   sync_fence_debug_add(sync_fence);

-   return fence;
+   return sync_fence;
 }
 EXPORT_SYMBOL(sync_fence_create);

diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 66b0f43..b8ad72c 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -246,13 +246,14 @@ void sync_pt_free(struct sync_pt *pt);

 /**
  * sync_fence_create() - creates a sync fence
- * @name:  name of fence to create
- * @pt:sync_pt to add to the fence
+ * @name:  name of the sync fence to create
+ * @fences:fences to add to the sync fence
+ * @num_fences:the number of fences in the @fences array
  *
- * Creates a fence containg @pt.  Once this is called, the fence takes
- * ownership of @pt.
+ * Creates a sync fence from an array of drm fences. Takes refs to @fences.
  */
-struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
+struct sync_fence *sync_fence_create(const char *name,
+struct fence **fences, int num_fences);

 /*
  * API for sync_fence consumers
diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 257fc91..2d8873e 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -81,33 +81,33 @@ static const char *sync_status_str(int status)
return "error";
 }

-static void sync_print_pt(struct seq_file *s, struct sync_pt *pt, bool fence)
+static void sync_print_pt(struct seq_file *s, struct fence *pt, bool fence)
 {
int status = 1;
-   struct sync_timeline *parent = sync_pt_parent(pt);

-   if (fence_is_signaled_locked(>base))
-   status = pt->base.status;
+   if (fence_is_signaled_locked(pt))
+   status = pt->status;

-   

[RFC] Explicit synchronization for Nouveau

[Lauri Peltonen]

Hi guys,


I'd like to start a new thread about explicit fence synchronization.  This time
with a Nouveau twist. :-)

First, let me define what I understand by implicit/explicit sync:

Implicit synchronization
* Fences are attached to buffers
* Kernel manages fences automatically based on buffer read/write access

Explicit synchronization
* Fences are passed around independently
* Kernel takes and emits fences to/from user space when submitting work

Implicit synchronization is already implemented in open source drivers, and
works well for most use cases.  I don't seek to change any of that.  My
proposal aims at allowing some drm drivers to operate in explicit sync mode to
get maximal performance, while still remaining fully compatible with the
implicit paradigm.

I will try to explain why I think we should support the explicit model as well.


1. Bindless graphics

Bindless graphics is a central concept when trying to reduce the OpenGL driver
overhead.  The idea is that the application can bind a large set of buffers to
the working set up front using extensions such as GL_ARB_bindless_texture, and
they remain resident until the application releases them (note that compute
APIs have typically similar semantics).  These working sets can be huge,
hundreds or even thousands of buffers, so we would like to opt out from the
per-submit overhead of acquiring locks, waiting for fences, and storing fences.
Automatically synchronizing these working sets in kernel will also prevent
parallelism between channels that are sharing the working set (in fact sharing
just one buffer from the working set will cause the jobs of the two channels to
be serialized).

2. Evolution of graphics APIs

The graphics API evolution seems to be going to a direction where game engine
and middleware vendors demand more control over work submission and
synchronization.  We expect that this trend will continue, and more and more
synchronization decisions will be pushed to the API level.  OpenGL and EGL
already provide good explicit command stream level synchronization primitives:
glFenceSync and EGL_KHR_wait_sync.  Their use is also encouraged - for example
EGL_KHR_image_base spec clearly states that the application is responsible for
synchronizing accesses to EGLImages.  If the API that is exposed to developers
gives the control over synchronization to the developer, then implicit waits
that are inserted by the kernel are unnecessary and unexpected, and can
severely hurt performance.  It also makes it easy for the developer to write
code that happens to work on Linux because of implicit sync, but will fail on
other platforms.

3. Suballocation

Using user space suballocation can help reduce the overhead when a large number
of small textures are used.  Synchronizing suballocated surfaces implicitly in
kernel doesn't make sense - many channels should be able to access the same
kernel-level buffer object simultaneously.

4. Buffer sharing complications

This is not really an argument for explicit sync as such, but I'd like to point
out that sharing buffers across SoC engines is often much more complex than
just exporting and importing a dma-buf and waiting for the dma-buf fences.
Sometimes we need to do color format or tiling layout conversion.  Sometimes,
at least on Tegra, we need to decompress buffers when we pass them from the GPU
to an engine that doesn't support framebuffer compression.  These things are
not uncommon, particularly when we have SoC's that combine licensed IP blocks
from different vendors.  My point is that user space is already heavily
involved when sharing buffers between drivers, and giving it some more control
over synchronization is not adding that much complexity.


Because of the above arguments, I think it makes sense to let some user space
drm drivers opt out from implicit synchronization, while allowing them to still
remain fully compatible with the rest of the drm world that uses implicit
synchronization.  In practice, this would require three things:

(1) Support passing fences (that are not tied to buffer objects) between kernel
and user space.

(2) Stop automatically storing fences to the buffers that user space wants to
synchronize explicitly.

(3) Allow user space to attach an explicit fence to dma-buf when exporting to
another driver that uses implicit sync.

There are still some open issues beyond these.  For example, can we skip
acquiring the ww mutex for explicitly synchronized buffers?  I think we could
eventually, at least on unified memory systems where we don't need to migrate
between heaps (our downstream Tegra GPU driver does not lock any buffers at
submit, it just grabs refcounts for hw).  Another quirk is that now Nouveau
waits on the buffer fences when closing the gem object to ensure that it
doesn't unmap too early.  We need to rework that for explicit sync, but that
shouldn't be difficult.

I have written a prototype that demonstrates (1) by adding explicit sync fd
support to 

page allocator bug in 3.16?

[Thomas Hellstrom]

On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
> On Fri, 26 Sep 2014 09:15:57 +0200
> Thomas Hellstrom  wrote:
>
>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
 There are six ttm patches queued for 3.16.4:

 drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
 drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
 drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
 drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
 drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
 drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
>>> Thanks for info, Chuck.
>>>
>>> Unfortunately, none of these fix TTM dma allocation doing CMA dma 
>>> allocation,
>>> which is the root problem.
>>>
>>> Regards,
>>> Peter Hurley
>> The problem is not really in TTM but in CMA, There was a guy offering to
>> fix this in the CMA code but I guess he didn't probably because he
>> didn't receive any feedback.
>>
> Yeah, the "solution" to this problem seems to be "don't enable CMA on
> x86". Maybe it should even be disabled in the config system.
Or, as previously suggested, don't use CMA for order 0 (single page)
allocations

/Thomas

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #14 from Lorenzo Bona  ---
(In reply to comment #11)
> Is ULV standing for Ultra-low voltage? If so, isn't this option something
> meant to be applied on APU only?

Mmm don't know. 
Haven't digged more, but my GPU (R7-265) is running hotter than before, always
around 39?-40? (even without any running application).
With the kernel in debian sid, 3.16.X, I can see low temperatures in idle.

I'm unable to trigger this warning booting up with radeon.dpm=0, so I think is
something related to power management.

-- 
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/20140926/54efee6b/attachment.html>

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Thierry Reding]

On Thu, Sep 25, 2014 at 08:10:31PM +0200, Sjoerd Simons wrote:
> On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > > >still required for enabling the GPU. Is there anything blocking it 
> > > >(firmware
> > > >not available yet in liux-firmware?)
> > > 
> > > I think initially I was waiting for the DRM patch "drm/nouvea: support for
> > > probing platform devices" to be applied, but it looks like that's been
> > > applied already, so only patches 4 and 5 in this series are still
> > > outstanding.
> > > 
> > > Alex, wasn't there also some issue where the VPR register had to be
> > > programmed, and if it wasn't there'd be a hang when the GPU registers were
> > > touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> > > the problem, then I guess we can commit these last two patches for 3.19. A
> > > resend after the 3.18 merge window might help.
> > 
> > A patch that programs VPR was merged into U-Boot (though I don't think
> > it's made it into master yet).
> 
> Assuming you're talking about "ARM: tegra: Disable VPR",that has landed
> in u-boot master and released as part of v2014.10-rc2 [0]

Oh, good.

> >  I'm not sure we can reasonably check for
> > that in Nouveau, given that the register is somewhere completely
> > unrelated. In fact I think the U-Boot patch was triggered by some
> > discussion about how to solve this and it was decided that it shouldn't
> > be done in the kernel, but U-Boot should set it up.
> > 
> > That said, perhaps one solution would be to make U-Boot enable the gk20a
> > device if it's set up the VPR and disable it otherwise?
> 
> I guess in that case the vdd-supply should still be added to the dts
> with u-boot toggling the status field of the node?

Yes, if that's what we decide on then this patch should be modified to
remove the status = "okay" line.

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/20140926/d408be81/attachment.sig>

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Thierry Reding]

On Thu, Sep 25, 2014 at 12:07:01PM -0600, Stephen Warren wrote:
> On 09/25/2014 10:41 AM, Thierry Reding wrote:
> >On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> >>On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> >>>Playing a bit with todays linux-next on my jetson, it seems this patch is
> >>>still required for enabling the GPU. Is there anything blocking it 
> >>>(firmware
> >>>not available yet in liux-firmware?)
> >>
> >>I think initially I was waiting for the DRM patch "drm/nouvea: support for
> >>probing platform devices" to be applied, but it looks like that's been
> >>applied already, so only patches 4 and 5 in this series are still
> >>outstanding.
> >>
> >>Alex, wasn't there also some issue where the VPR register had to be
> >>programmed, and if it wasn't there'd be a hang when the GPU registers were
> >>touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> >>the problem, then I guess we can commit these last two patches for 3.19. A
> >>resend after the 3.18 merge window might help.
> >
> >A patch that programs VPR was merged into U-Boot (though I don't think
> >it's made it into master yet). I'm not sure we can reasonably check for
> >that in Nouveau, given that the register is somewhere completely
> >unrelated. In fact I think the U-Boot patch was triggered by some
> >discussion about how to solve this and it was decided that it shouldn't
> >be done in the kernel, but U-Boot should set it up.
> >
> >That said, perhaps one solution would be to make U-Boot enable the gk20a
> >device if it's set up the VPR and disable it otherwise?
> 
> For that to work, we'd need the DT to say status="disabled" by default for
> the GPU, and for the fixed U-Boot (and indeed every other bootloader...) to
> enable the GPU node. This would allow people with old versions of U-Boot (or
> other bootloaders) to continue to boot. This means bootloaders would only
> have to set status="okay", but never have to set status="disabled", which at
> least simplifies them a tiny bit.

Sounds like a reasonable requirement on bootloaders to me. If it's clear
that the device will not work without an initialized VPR region, part of
the "boot protocol" should be for the bootloader to tell the kernel when
it's safe to enable the GPU.

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/20140926/3813d982/attachment.sig>

[PATCH] drm/gma500: add support for atom e6xx lpc lvds i2c

[Jan Safrata]

add gpio bitbanging i2c adapter on LPC device of atom e6xx
gpu chipset to access lvds EDID
tested on SECO QuadMo747-E6xx-EXTREME Qseven platform

Cc: Patrik Jakobsson 
Signed-off-by: Jan Safrata 
---
 drivers/gpu/drm/gma500/Makefile|   1 +
 drivers/gpu/drm/gma500/oaktrail_lvds.c |  31 --
 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 170 +
 drivers/gpu/drm/gma500/psb_drv.c   |  20 
 drivers/gpu/drm/gma500/psb_drv.h   |   3 +
 drivers/gpu/drm/gma500/psb_intel_drv.h |   1 +
 6 files changed, 214 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c

diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index b153155..190e55f 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -39,6 +39,7 @@ gma500_gfx-$(CONFIG_DRM_GMA3600) +=  cdv_device.o \
 gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \
  oaktrail_crtc.o \
  oaktrail_lvds.o \
+ oaktrail_lvds_i2c.o \
  oaktrail_hdmi.o \
  oaktrail_hdmi_i2c.o

diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 0d39da6..83bbc27 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -359,22 +359,26 @@ void oaktrail_lvds_init(struct drm_device *dev,
 *if closed, act like it's not there for now
 */

+   edid = NULL;
mutex_lock(>mode_config.mutex);
i2c_adap = i2c_get_adapter(dev_priv->ops->i2c_bus);
-   if (i2c_adap == NULL)
-   dev_err(dev->dev, "No ddc adapter available!\n");
+   if (i2c_adap)
+   edid = drm_get_edid(connector, i2c_adap);
+   if (edid == NULL && dev_priv->lpc_gpio_base) {
+   oaktrail_lvds_i2c_init(encoder);
+   if (gma_encoder->ddc_bus != NULL) {
+   i2c_adap = _encoder->ddc_bus->adapter;
+   edid = drm_get_edid(connector, i2c_adap);
+   }
+   }
/*
 * Attempt to get the fixed panel mode from DDC.  Assume that the
 * preferred mode is the right one.
 */
-   if (i2c_adap) {
-   edid = drm_get_edid(connector, i2c_adap);
-   if (edid) {
-   drm_mode_connector_update_edid_property(connector,
-   edid);
-   drm_add_edid_modes(connector, edid);
-   kfree(edid);
-   }
+   if (edid) {
+   drm_mode_connector_update_edid_property(connector, edid);
+   drm_add_edid_modes(connector, edid);
+   kfree(edid);

list_for_each_entry(scan, >probed_modes, head) {
if (scan->type & DRM_MODE_TYPE_PREFERRED) {
@@ -383,7 +387,8 @@ void oaktrail_lvds_init(struct drm_device *dev,
goto out;   /* FIXME: check for quirks */
}
}
-   }
+   } else
+   dev_err(dev->dev, "No ddc adapter available!\n");
/*
 * If we didn't get EDID, try geting panel timing
 * from configuration data
@@ -411,8 +416,10 @@ failed_find:
mutex_unlock(>mode_config.mutex);

dev_dbg(dev->dev, "No LVDS modes found, disabling.\n");
-   if (gma_encoder->ddc_bus)
+   if (gma_encoder->ddc_bus) {
psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+   gma_encoder->ddc_bus = NULL;
+   }

 /* failed_ddc: */

diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
new file mode 100644
index 000..f913a62
--- /dev/null
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (c) 2002-2010, Intel Corporation.
+ * Copyright (c) 2014 ATRON electronic GmbH
+ *   Author: Jan Safrata 
+ *
+ * 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, sublicense, 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 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 NONINFRINGEMENT. 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 

[PATCH] ACPI / i915: Update the condition to ignore firmware backlight change request

[Aaron Lu]

Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests
for backlight change). Then there is a Dell laptop whose vendor backlight
interface also makes use of operation region to change backlight level
and with the above commit, that interface no long works. The condition
used to ignore the backlight change request from firmware is thus
changed to: if the vendor backlight interface is not in use and the ACPI
backlight interface is broken, we ignore the requests; oterwise, we keep
processing them.

Reference: https://lkml.org/lkml/2014/9/23/854
Reported-and-tested-by: Pali Roh?r 
Cc:  # v3.16 and later
Signed-off-by: Aaron Lu 
---
 drivers/gpu/drm/i915/intel_opregion.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index ca52ad2ae7d1..d8de1d5140a7 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -396,6 +396,16 @@ int intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
return -EINVAL;
 }

+/*
+ * If the vendor backlight interface is not in use and ACPI backlight interface
+ * is broken, do not bother processing backlight change requests from firmware.
+ */
+static bool should_ignore_backlight_request(void)
+{
+   return acpi_video_backlight_support() &&
+  !acpi_video_verify_backlight_support();
+}
+
 static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -404,11 +414,7 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)

DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);

-   /*
-* If the acpi_video interface is not supposed to be used, don't
-* bother processing backlight level change requests from firmware.
-*/
-   if (!acpi_video_verify_backlight_support()) {
+   if (should_ignore_backlight_request()) {
DRM_DEBUG_KMS("opregion backlight request ignored\n");
return 0;
}
-- 
1.9.3

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Aaron Lu]

On 09/26/2014 03:58 AM, Rafael J. Wysocki wrote:
> On Thursday, September 25, 2014 11:15:35 AM Aaron Lu wrote:
>> Hi Hans,
>>
>> Thanks for following up and explaining the situation to Pali.
>>
>> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
>>> On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
 Ok, so the dell-laptop interface is just an obsolete wrapper
 around the i915 opregion code, which shows that the right
 interface to use is the i915 one, which we do if you don't
 specify any kernel commandline parameters, case closed.

 Regards,

 Hans
>>>
>>> Nope, its not closed.
>>>
>>> Still i915 interface has problem with setting backlight. It 
>>> exports lot of levels which turning display off. Which breaking 
>>> exiting applications for configuring display brightness. This is 
>>> still big regression as black screen is not want people want to 
>>> see.
>>>
>>> Driver dell-laptop has exported only few - not thousands level 
>>> (which is insane) and only usefull levels (not lot of levels 
>>> which turn display off).
>>>
>>> So for this reason using i915 backlight interface is not possible 
>>> and also Dell (for E6440) set kernel param acpi_backlight=vendor 
>>> to use dell_laptop module for controlling brightness.
>>>
>>> On my laptop E6440 is better for using dell-laptop and not acpi 
>>> or i915.
>>
>> Hi Pali,
>>
>> Please test this patch:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
>> b/drivers/gpu/drm/i915/intel_opregion.c
>> index ca52ad2ae7d1..15534345bd57 100644
>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> @@ -396,6 +396,24 @@ int intel_opregion_notify_adapter(struct drm_device 
>> *dev, pci_power_t state)
>>  return -EINVAL;
>>  }
>>  
>> +/*
>> + * Some of the Thinkpads' firmware will issue a backlight change operation
>> + * region request unconditionally on AC plug/unplug, this is undesirable and
>> + * should be ignored. Then there is a Dell laptop whose vendor backlight
>> + * interface also makes use of operation region request to change backlight
>> + * level and we have to keep it work. The rule used here is: if the vendor
>> + * backlight interface is not in use and the ACPI backlight interface is
>> + * broken, we ignore the requests; oterwise, we keep processing them.
>> + */
>> +static bool should_ignore_backlight_request(void)
>> +{
>> +if (acpi_video_backlight_support() &&
>> +!acpi_video_verify_backlight_support())
>> +return true;
>> +
>> +return false;
>> +}
> 
> Well, what about
> 
>   return acpi_video_backlight_support() && 
> !acpi_video_verify_backlight_support();
> 
> ?

Yes that's better.
Will send out a patch with this change, thanks for the suggestion.

-Aaron

> 
>> +
>>  static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
>>  {
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>> @@ -404,11 +422,7 @@ static u32 asle_set_backlight(struct drm_device *dev, 
>> u32 bclp)
>>  
>>  DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);
>>  
>> -/*
>> - * If the acpi_video interface is not supposed to be used, don't
>> - * bother processing backlight level change requests from firmware.
>> - */
>> -if (!acpi_video_verify_backlight_support()) {
>> +if (should_ignore_backlight_request()) {
>>  DRM_DEBUG_KMS("opregion backlight request ignored\n");
>>  return 0;
>>  }
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 

page allocator bug in 3.16?

[Peter Hurley]

[ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ]

On 09/26/2014 08:40 AM, Rik van Riel wrote:
> On 09/26/2014 08:28 AM, Rob Clark wrote:
>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>>  wrote:
>>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
 On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom
  wrote:

> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>>> There are six ttm patches queued for 3.16.4:
>>>
>>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>>>
>>>
> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>>> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>>>
>>>
> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
>>> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch 
>>> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
>>
>>>
> Thanks for info, Chuck.
>>
>> Unfortunately, none of these fix TTM dma allocation doing
>> CMA dma allocation, which is the root problem.
>>
>> Regards, Peter Hurley
> The problem is not really in TTM but in CMA, There was a guy
> offering to fix this in the CMA code but I guess he didn't
> probably because he didn't receive any feedback.
>
 Yeah, the "solution" to this problem seems to be "don't enable
 CMA on x86". Maybe it should even be disabled in the config
 system.
>>> Or, as previously suggested, don't use CMA for order 0 (single
>>> page) allocations
>>
>> On devices that actually need CMA pools to arrange for memory to be
>> in certain ranges, I think you probably do want to have order 0
>> pages come from the CMA pool.
>>
>> Seems like disabling CMA on x86 (where it should be unneeded) is
>> the better way, IMO
> 
> CMA has its uses on x86. For example, CMA is used to allocate 1GB huge
> pages.
> 
> There may also be people with devices that do not scatter-gather, and
> need a large physically contiguous buffer, though there should be
> relatively few of those on x86.
> 
> I suspect it makes most sense to do DMA allocations up to PAGE_ORDER
> through the normal allocator on x86, and only invoking CMA for larger
> allocations.

The code that uses CMA to satisfy DMA allocations on x86 is
specific to the x86 arch and was added in 2011 as a means of _testing_
CMA in KVM:

commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6
Author: Marek Szyprowski 
Date:   Thu Dec 29 13:09:51 2011 +0100

X86: integrate CMA with DMA-mapping subsystem

This patch adds support for CMA to dma-mapping subsystem for x86
architecture that uses common pci-dma/pci-nommu implementation. This
allows to test CMA on KVM/QEMU and a lot of common x86 boxes.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 

(no x86 maintainer acks?).

Unfortunately, this code is enabled whenever CMA is enabled, rather
than as a separate test configuration.

So, while enabling CMA may have other purposes on x86, using it for
x86 swiotlb and nommu dma allocations is not one of the them.

And Ubuntu should not be enabling CONFIG_DMA_CMA for their i386
and amd64 configurations, as this is trying to drive _all_ dma mapping
allocations through a _very_ small window (which is killing GPU
performance).

Regards,
Peter Hurley

[PATCH] drm/edid: Add missing interlaced flag to 576i@100 modes.

[clinton.a.tay...@intel.com]

From: Clint Taylor 

CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_edid.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bdbfd0..3bf9991 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -841,13 +841,13 @@ static const struct drm_display_mode edid_cea_modes[] = {
{ DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 732,
   795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_DBLCLK),
+   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
/* 45 - 720(1440)x576i at 100Hz */
{ DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 27000, 720, 732,
   795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-   DRM_MODE_FLAG_DBLCLK),
+   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 46 - 1920x1080i at 120Hz */
{ DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
-- 
1.7.9.5

page allocator bug in 3.16?

[Rob Clark]

On Fri, Sep 26, 2014 at 8:34 AM, Thomas Hellstrom  
wrote:
> On 09/26/2014 02:28 PM, Rob Clark wrote:
>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom  
>> wrote:
>>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
 On Fri, 26 Sep 2014 09:15:57 +0200
 Thomas Hellstrom  wrote:

> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>>> There are six ttm patches queued for 3.16.4:
>>>
>>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>>> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>>> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
>>> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
>>> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
>> Thanks for info, Chuck.
>>
>> Unfortunately, none of these fix TTM dma allocation doing CMA dma 
>> allocation,
>> which is the root problem.
>>
>> Regards,
>> Peter Hurley
> The problem is not really in TTM but in CMA, There was a guy offering to
> fix this in the CMA code but I guess he didn't probably because he
> didn't receive any feedback.
>
 Yeah, the "solution" to this problem seems to be "don't enable CMA on
 x86". Maybe it should even be disabled in the config system.
>>> Or, as previously suggested, don't use CMA for order 0 (single page)
>>> allocations
>> On devices that actually need CMA pools to arrange for memory to be in
>> certain ranges, I think you probably do want to have order 0 pages
>> come from the CMA pool.
>
> But can the DMA subsystem or more specifically dma_alloc_coherent()
> really guarantee such things? Isn't it better for such devices to use
> CMA directly?

Well, I was thinking more specifically about a use-case that was
mentioned several times during the early CMA discussions, about video
decoders/encoders which needed Y and UV split across memory banks to
achieve sufficient bandwidth.  I assume they must use CMA directly for
this (since they'd need multiple pools per device), but not really
100% sure about that.

So perhaps, yeah, if you shunt order 0 allocations away from CMA at
the DMA layer, maybe it is ok.  If there actually is a valid use-case
for CMA on sane hardware, then maybe this is the better way, and let
the insane hw folks hack around it.

(plus, well, the use-case I was mentioning isn't really about order 0
allocations anyway)

BR,
-R


> /Thomas
>
>
>>
>> Seems like disabling CMA on x86 (where it should be unneeded) is the
>> better way, IMO
>>
>> BR,
>> -R
>>
>>
>>> /Thomas
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/dri-devel=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=Uz7JXDXYXp4RlLs7G6qxMQlhOOT0trW3l78xpKg6Ass%3D%0A=50d6b7b3bfd093c93a228437a3d4414e49b4de817657c49c35154a115a5c2188
>

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

[Mark yao]

On 2014?09?25? 20:11, Mark yao wrote:
> On 2014?09?25? 16:58, Mark yao wrote:
>> On 2014?09?25? 00:20, Daniel Kurtz wrote:
>>> Hi Mark,
>>>
>>> Please review comments inline...
>>>
>>> On Wed, Sep 24, 2014 at 10:12 AM, Mark yao  
>>> wrote:
>>> To match the enum name, use ROCKCHIP_OUTPUT_TYPE_*.
>>> Also, no need to explicitly set the first one to 0.
>>> However, see below.  I don't think we to modify the drm_display_mode
>>> to include an output type.
>> but vop devices need know the connector type, connector enable 
>> register is in vop.
>> can I do that like under to  get connector type for crtc?
>>
>> static int rockchip_get_connector_type(struct drm_crtc *crtc)
>> {
>>   struct drm_device *dev = crtc->dev;
>>   struct drm_connector * connector;
>>
>>   list_for_each_entry(connector, 
>> >mode_config.connector_list, head) {
>>   if (!connector->encoder)
>>   continue;
>>   /*
>>* one crtc only has one connector in my case, so just find 
>> the first connector at list.
>>*/
>>   if (connector->encoder->crtc == crtc)
>>   break;
>> }
>>
>> if (!connector)
>> return -EINVAL;
>>
>> return connector->connector_type;
>> } 
> Oh, sorry, forgot to drop this comment,
> for connector type problem, I try to new a help function for encoder 
> to call as Daniel advices.
>>>> +#define to_rockchip_plane(x) container_of(x, struct rockchip_plane, base)
>>>> +
>>>> +struct rockchip_plane {
>>>> +   int id;
>>>> +   struct drm_plane base;
>>>> +   const struct vop_win *win;
>>>> +   struct vop_context *ctx;
>>> Isn't ctx just: to_vop_ctx(base->crtc)
>>>
>> OK. we can use to_vop_ctx(base->crtc) to get ctx. 
> I have do a test to use "to_vop_ctx(base->crtc)", but found that 
> "base->crtc" maybe not init.
> for cursor plane, base->crtc always is NULL. and disable_plane will fail.
> maybe we can add "base->crtc = crtc" at update_plane, but it seems not 
> good.
> so I think still use "rockchip_plane->ctx" would be better.
>
> -Mark
I found that: plane->crtc will be set if update_plane success, and will 
be set NULL if disable_plane success.
so disable_plane must after update_plane.
disable_plane get crtc==NULL problem is that disable_plane was called 
before update_plane or been called  twice.
for this reason we can just check if crtc is NULL at disable_plane.

-Mark




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/2b73fb2e/attachment.html>

page allocator bug in 3.16?

[Thomas Hellstrom]

On 09/26/2014 01:52 AM, Peter Hurley wrote:
> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>> There are six ttm patches queued for 3.16.4:
>>
>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
>> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
>> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
> Thanks for info, Chuck.
>
> Unfortunately, none of these fix TTM dma allocation doing CMA dma allocation,
> which is the root problem.
>
> Regards,
> Peter Hurley

The problem is not really in TTM but in CMA, There was a guy offering to
fix this in the CMA code but I guess he didn't probably because he
didn't receive any feedback.


/Thomas

page allocator bug in 3.16?

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/26/2014 08:28 AM, Rob Clark wrote:
> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>  wrote:
>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>>> On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom
>>>  wrote:
>>> 
 On 09/26/2014 01:52 AM, Peter Hurley wrote:
> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>> There are six ttm patches queued for 3.16.4:
>> 
>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>>
>> 
drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
>>
>> 
drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
>> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch 
>> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
>
>> 
Thanks for info, Chuck.
> 
> Unfortunately, none of these fix TTM dma allocation doing
> CMA dma allocation, which is the root problem.
> 
> Regards, Peter Hurley
 The problem is not really in TTM but in CMA, There was a guy
 offering to fix this in the CMA code but I guess he didn't
 probably because he didn't receive any feedback.
 
>>> Yeah, the "solution" to this problem seems to be "don't enable
>>> CMA on x86". Maybe it should even be disabled in the config
>>> system.
>> Or, as previously suggested, don't use CMA for order 0 (single
>> page) allocations
> 
> On devices that actually need CMA pools to arrange for memory to be
> in certain ranges, I think you probably do want to have order 0
> pages come from the CMA pool.
> 
> Seems like disabling CMA on x86 (where it should be unneeded) is
> the better way, IMO

CMA has its uses on x86. For example, CMA is used to allocate 1GB huge
pages.

There may also be people with devices that do not scatter-gather, and
need a large physically contiguous buffer, though there should be
relatively few of those on x86.

I suspect it makes most sense to do DMA allocations up to PAGE_ORDER
through the normal allocator on x86, and only invoking CMA for larger
allocations.

- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUJV6lAAoJEM553pKExN6DjrQH/1N19Hp5FrJr+a3GpQDh6ouc
YSBChxe+wG1h3OmcFGAG69tOK9XPw0oaV77ohwLxnvSv6BQZyi2CUIJvUdgSaOOx
8XYnn8VIIlMn4IKYmraAhSWT/gm3FkyDW7tckEdLV0NsrKeUcavCRHcLXxh41OBw
XJboZyS3XvwF+scAwjHpWPxby1Byi0lZJizTAzI3xdlyVaM5Lio1xLvOW2MHY7dR
h/ai8mfAAdQvnaHsFLoypBM/xYJqaUVU8IyCzhOeO86dUMy2xhD4vm/f9vSLuOju
4VYf7POuziNo1q2vJ8YcrThsAjB0Oiu9B5nDar471G3l1xN1zHQVw/RAnpNF9Kk=
=iZlM
-END PGP SIGNATURE-

page allocator bug in 3.16?

[Rob Clark]

On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom  
wrote:
> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>> On Fri, 26 Sep 2014 09:15:57 +0200
>> Thomas Hellstrom  wrote:
>>
>>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
 On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> There are six ttm patches queued for 3.16.4:
>
> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
 Thanks for info, Chuck.

 Unfortunately, none of these fix TTM dma allocation doing CMA dma 
 allocation,
 which is the root problem.

 Regards,
 Peter Hurley
>>> The problem is not really in TTM but in CMA, There was a guy offering to
>>> fix this in the CMA code but I guess he didn't probably because he
>>> didn't receive any feedback.
>>>
>> Yeah, the "solution" to this problem seems to be "don't enable CMA on
>> x86". Maybe it should even be disabled in the config system.
> Or, as previously suggested, don't use CMA for order 0 (single page)
> allocations

On devices that actually need CMA pools to arrange for memory to be in
certain ranges, I think you probably do want to have order 0 pages
come from the CMA pool.

Seems like disabling CMA on x86 (where it should be unneeded) is the
better way, IMO

BR,
-R


> /Thomas
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

page allocator bug in 3.16?

[Leann Ogasawara]

On Fri, Sep 26, 2014 at 7:10 AM, Peter Hurley  
wrote:
> [ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ]
>
> On 09/26/2014 08:40 AM, Rik van Riel wrote:
>> On 09/26/2014 08:28 AM, Rob Clark wrote:
>>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>>>  wrote:
 On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
> On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom
>  wrote:
>
>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
 There are six ttm patches queued for 3.16.4:

 drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch


>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
 drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch


>> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
 drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
 drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
>>>

>> Thanks for info, Chuck.
>>>
>>> Unfortunately, none of these fix TTM dma allocation doing
>>> CMA dma allocation, which is the root problem.
>>>
>>> Regards, Peter Hurley
>> The problem is not really in TTM but in CMA, There was a guy
>> offering to fix this in the CMA code but I guess he didn't
>> probably because he didn't receive any feedback.
>>
> Yeah, the "solution" to this problem seems to be "don't enable
> CMA on x86". Maybe it should even be disabled in the config
> system.
 Or, as previously suggested, don't use CMA for order 0 (single
 page) allocations
>>>
>>> On devices that actually need CMA pools to arrange for memory to be
>>> in certain ranges, I think you probably do want to have order 0
>>> pages come from the CMA pool.
>>>
>>> Seems like disabling CMA on x86 (where it should be unneeded) is
>>> the better way, IMO
>>
>> CMA has its uses on x86. For example, CMA is used to allocate 1GB huge
>> pages.
>>
>> There may also be people with devices that do not scatter-gather, and
>> need a large physically contiguous buffer, though there should be
>> relatively few of those on x86.
>>
>> I suspect it makes most sense to do DMA allocations up to PAGE_ORDER
>> through the normal allocator on x86, and only invoking CMA for larger
>> allocations.
>
> The code that uses CMA to satisfy DMA allocations on x86 is
> specific to the x86 arch and was added in 2011 as a means of _testing_
> CMA in KVM:
>
> commit 0a2b9a6ea93650b8a00f9fd5ee8fdd25671e2df6
> Author: Marek Szyprowski 
> Date:   Thu Dec 29 13:09:51 2011 +0100
>
> X86: integrate CMA with DMA-mapping subsystem
>
> This patch adds support for CMA to dma-mapping subsystem for x86
> architecture that uses common pci-dma/pci-nommu implementation. This
> allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
>
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Kyungmin Park 
> CC: Michal Nazarewicz 
> Acked-by: Arnd Bergmann 
>
> (no x86 maintainer acks?).
>
> Unfortunately, this code is enabled whenever CMA is enabled, rather
> than as a separate test configuration.
>
> So, while enabling CMA may have other purposes on x86, using it for
> x86 swiotlb and nommu dma allocations is not one of the them.
>
> And Ubuntu should not be enabling CONFIG_DMA_CMA for their i386
> and amd64 configurations, as this is trying to drive _all_ dma mapping
> allocations through a _very_ small window (which is killing GPU
> performance).

Thanks for the note Peter.  We do have this disabled for our upcoming
Ubuntu 14.10 release.  It is however still enabled in the previous 14.04
release.  We have been tracking this in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362261 but users
able to reproduce performance impacts in 14.10 were unable to reproduce
in 14.04 which is why we hadn't yet disabled it there.

Thanks,
Leann

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #116 from Alexandre Demers  ---
I've been reading the comments in fast forward, and I'm sure I'm hitting the
same bug.

For info, I'm using a 7950 on Arch 64. I'm running Xorg server 1.16.1. Mesa,
drm and ddx are all from the latest git repositories. I was not experiencing
this bug yesterday while I was still using a 6950 on Glamor.

Now, I have a log that I can push from just after a hang and reset or from a
hang and a badly running Xorg server. There is something about ring 5 not
responding. I'll send the file later when I'll get to my desktop.

To trigger the bug in no time, as you, I just have to watch a movie (either
flash or html5) on chrome or firefox and wait. Otherwise, going through
websites, apps, etc will get you to the same point, but it will take more time.

I must warn you though: chrome/chromium has been hanging with both r600 and
readeonsi drivers. It should not be mixed with the current issue, because they
are probably two different bugs. Thus, I prefer to use firefox for now to
eleminate mixing these two.

-- 
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/20140926/052864bb/attachment-0001.html>

page allocator bug in 3.16?

[Chuck Ebbert]

On Fri, 26 Sep 2014 09:15:57 +0200
Thomas Hellstrom  wrote:

> On 09/26/2014 01:52 AM, Peter Hurley wrote:
> > On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> >> There are six ttm patches queued for 3.16.4:
> >>
> >> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
> >> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
> >> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
> >> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
> >> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
> >> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
> > Thanks for info, Chuck.
> >
> > Unfortunately, none of these fix TTM dma allocation doing CMA dma 
> > allocation,
> > which is the root problem.
> >
> > Regards,
> > Peter Hurley
> 
> The problem is not really in TTM but in CMA, There was a guy offering to
> fix this in the CMA code but I guess he didn't probably because he
> didn't receive any feedback.
> 

Yeah, the "solution" to this problem seems to be "don't enable CMA on
x86". Maybe it should even be disabled in the config system.

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #13 from Alexandre Demers  ---
I commented out every "return ret;" of si_dpm_set_power_state() in si_dpm.c.
After booting this modified kernel, I can confirm this is the only error
reported in si_dpm_set_power_state(): every other verification passes OK and it
goes down to the very end.

-- 
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/20140926/5d04ff65/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #115 from Aaron B  ---
Haha, was it the SI power state ULV one? I was worried I accidentally posted in
that and this was a reply. No crashes so far, I'll report tomorrow if I have
any, but it seems stable with DPM off. But we'll continue more tomorrow. :)

-- 
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/20140926/ed3fe02b/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #114 from Alexandre Demers  ---
(In reply to comment #113)
> I commented out every "return ret;" of si_dpm_set_power_state() in si_dpm.c.
> After booting this modified kernel, I can confirm this is the only error
> reported in si_dpm_set_power_state(): every other verification passes OK and
> it goes down to the very end.

Oops, I had too many bugs opened, I wrote this comment in the wrong one.

-- 
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/20140926/097405f8/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #113 from Alexandre Demers  ---
I commented out every "return ret;" of si_dpm_set_power_state() in si_dpm.c.
After booting this modified kernel, I can confirm this is the only error
reported in si_dpm_set_power_state(): every other verification passes OK and it
goes down to the very end.

-- 
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/20140926/04dcf71c/attachment.html>

[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)

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

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Alexandre Demers  ---
I don't remember seeing this error in the log file for a long time, so it must
have been fixed at some point. Also, I will not be using a Cayman GPU anymore.
I'm closing this bug. If someone hits it, they can reopen it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/0e728f5c/attachment.html>

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #12 from Alexandre Demers  ---
Created attachment 106884
  --> https://bugs.freedesktop.org/attachment.cgi?id=106884=edit
journalctl log

-- 
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/20140926/d64ee215/attachment.html>

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #11 from Alexandre Demers  ---
Is ULV standing for Ultra-low voltage? If so, isn't this option something meant
to be applied on APU only?

-- 
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/20140926/26c70650/attachment-0001.html>

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #10 from Alexandre Demers  ---
Just moved from a 6950 (r600g) to a 7950 (radeonsi) and hit the same error on
kernel 3.17-rc6.

-- 
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/20140926/35da2c28/attachment.html>