[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

--- Comment #6 from Mike Lothian  ---
I think this also affects i965 too

6ce9006d76c050663af0be61cc88c3215d6f8cea is the first bad commit
commit 6ce9006d76c050663af0be61cc88c3215d6f8cea 
Author: Neil Roberts  
Date:   Wed Oct 1 20:00:50 2014 +0100   

i965: Enable flush control  

Reviewed-by: Adam Jackson  
Reviewed-by: Nicolai Hähnle    
Reviewed-by: Emil Velikov   
Reviewed-by: Kenneth Graunke 
Signed-off-by: Neil Roberts 

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

--- Comment #11 from Sergey Kvachonok  ---
I can confirm that switching from radeon to amdgpu on

03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Pitcairn XT [Radeon HD 7870 GHz Edition]

Device: AMD Radeon HD 7800 Series (PITCAIRN / DRM 3.19.0 / 4.14.11-1-ARCH, LLVM
5.0.1) (0x6818)

fixes the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100393] Cemu wiiu emulator crashes after selecting game on radeonsi

[bugzilla-daemon]

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

--- Comment #12 from Daniel Monaga  ---
Hi all, i tried with MESA_GLSL_OVERRIDE="400" with a new game on menu, but you
see the black screen that if the audio is perfect, you hear walking and jumping
normal but without image.
instead, when using MESA_GL_VERSION_OVERRIDE=4.5COMPAT, it shows a corrupted
image and when loading the saved game it breaks

in driconf, force_glsl_extensions_warn=enable,
allow_higher_compat_version=enable

use ubuntu 17.10+Mesa 17.3.1 - padoka PPA Stable+Kernel 4.15.0-RC6 AMDGPU
GitHub
M-Bab(https://github.com/M-Bab/linux-kernel-amdgpu-binaries)+Wine-Staging 2.21

this is what I get;
log Cemu 1.11.3 - https://pastebin.com/jRYZXNaV
crashlog Cemu 1.11.3 - https://pastebin.com/NSEmYE01
Console Dump Cemu 1.11.3 - https://pastebin.com/nLy92LbP

more info:
Video Test https://www.youtube.com/watch?v=2bmYvZENVTw

Wine Configuration OS WIN 7
Wine regedit key Direct3D AMD - https://pastebin.com/hBSbBLbj
Wine regedit key OpenGL AMD - https://pastebin.com/iH3skhEJ

Hardware - MSI RX580+Ryzen 5 1600

I hope you can guide me, I know it came out mesa 17.3.2, maybe improve
something.
-https://lists.freedesktop.org/archives/mesa-dev/2018-January/181024.html

I have also seen a version of mesa patched version of mikakev1
mesa_mild_compatibility, which I failed to install in ubuntu 17.10.

greetings from Chile.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

--- Comment #5 from Sebastian Parborg  ---
I spoke too soon. It seems like I needed to go back a bit further. And with
MESA_GLSL_CACHE_DISABLE=true, it seems like I could pinpoint the commit.

This is the commit that breaks dota2 for me:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=0d044351b7043cd0bc94c1cb9b7a2213f8054414

I reverted that one and tried the master branch and now it works. I'm guessing
that there is some implementation bugs or something as that commit only seems
to switch on already implemented stuff.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[gabbayo:amdkfd-next 10/53] drivers/gpu/drm/amd/amdkfd/kfd_process.c:289:37: sparse: constant 0x2000000000000 is so big it is long

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux amdkfd-next
head:   9f0a0b41ffccf9a76b19ea263ae16d2d5888093e
commit: 373d7080896a3cb3b28ae3a2abdafb7bb87552b1 [10/53] drm/amdkfd: Add CWSR 
support
reproduce:
# apt-get install sparse
git checkout 373d7080896a3cb3b28ae3a2abdafb7bb87552b1
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)


vim +289 drivers/gpu/drm/amd/amdkfd/kfd_process.c

   273  
   274  static int kfd_process_init_cwsr(struct kfd_process *p, struct file 
*filep)
   275  {
   276  int err = 0;
   277  unsigned long  offset;
   278  struct kfd_process_device *temp, *pdd = NULL;
   279  struct kfd_dev *dev = NULL;
   280  struct qcm_process_device *qpd = NULL;
   281  
   282  mutex_lock(>mutex);
   283  list_for_each_entry_safe(pdd, temp, >per_device_data,
   284  per_device_list) {
   285  dev = pdd->dev;
   286  qpd = >qpd;
   287  if (!dev->cwsr_enabled || qpd->cwsr_kaddr)
   288  continue;
 > 289  offset = (dev->id | KFD_MMAP_RESERVED_MEM_MASK) << 
 > PAGE_SHIFT;
   290  qpd->tba_addr = (int64_t)vm_mmap(filep, 0,
   291  KFD_CWSR_TBA_TMA_SIZE, PROT_READ | PROT_EXEC,
   292  MAP_SHARED, offset);
   293  
   294  if (IS_ERR_VALUE(qpd->tba_addr)) {
   295  pr_err("Failure to set tba address. error 
-%d.\n",
   296  (int)qpd->tba_addr);
   297  err = qpd->tba_addr;
   298  qpd->tba_addr = 0;
   299  qpd->cwsr_kaddr = NULL;
   300  goto out;
   301  }
   302  
   303  memcpy(qpd->cwsr_kaddr, dev->cwsr_isa, 
dev->cwsr_isa_size);
   304  
   305  qpd->tma_addr = qpd->tba_addr + KFD_CWSR_TMA_OFFSET;
   306  pr_debug("set tba :0x%llx, tma:0x%llx, cwsr_kaddr:%p 
for pqm.\n",
   307  qpd->tba_addr, qpd->tma_addr, qpd->cwsr_kaddr);
   308  }
   309  out:
   310  mutex_unlock(>mutex);
   311  return err;
   312  }
   313  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/10] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

[Hyun Kwon]

This add a dt binding for ZynqMP DP subsystem.

Signed-off-by: Hyun Kwon 
---
 .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 94 ++
 1 file changed, 94 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt

diff --git 
a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt 
b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
new file mode 100644
index 000..4e478ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
@@ -0,0 +1,94 @@
+Xilinx ZynqMP DisplayPort subsystem
+---
+
+Required properties:
+
+- compatible: Must be "xlnx,zynqmp-dpsub-1.7".
+
+- reg: Physical base address and length of the registers set for the device.
+- reg-names: Must be "dp", "blend", "av_buf", and "aud" to map logical register
+  partitions.
+
+- interrupts: Interrupt number.
+- interrupts-parent: phandle for interrupt controller.
+
+- clocks: phandles for axi, audio, non-live video, and live video clocks.
+  axi clock is required. Audio clock is optional. If not present, audio will
+  be disabled. One of non-live or live video clock should be present.
+- clock-names: The identification strings are required. "aclk" for axi clock.
+  "dp_aud_clk" for audio clock. "dp_vtc_pixel_clk_in" for non-live video clock.
+  "dp_live_video_in_clk" for live video clock (clock from programmable logic).
+
+- phys: phandles for phy specifier.
+- phy-names: The identifier strings. "dp-phy" followed by index.
+
+- power-domains: phandle for the corresponding power domain
+
+- ports: crtc and encoder ports are required using DT bindings defined in
+  Documentation/devicetree/bindings/graph.txt.
+
+- vid-layer, gfx-layer: Required to represent available layers
+
+Required layer properties
+
+- dmas: phandles for DMA channels as defined in
+  Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names: The identifier strings are required. "graphics0" for graphics
+  layer. "video" followed by index for video layer
+
+Optional child node
+
+- The driver populates any child device node in this node. This can be used,
+  for example, to populate the sound device from the DisplayPort subsystem
+  driver.
+
+Example:
+   zynqmp_dpsub: zynqmp_dpsub@fd4a {
+   compatible = "xlnx,zynqmp-dpsub-1.7";
+   reg = <0x0 0xfd4a 0x0 0x1000>,
+ <0x0 0xfd4aa000 0x0 0x1000>,
+ <0x0 0xfd4ab000 0x0 0x1000>,
+ <0x0 0xfd4ac000 0x0 0x1000>;
+   reg-names = "dp", "blend", "av_buf", "aud";
+   interrupts = <0 119 4>;
+   interrupt-parent = <>;
+
+   clock-names = "dp_apb_clk", "dp_aud_clk", 
"dp_live_video_in_clk";
+   clocks = <_aclk>, < 17>, <_1>;
+
+   phys = < PHY_TYPE_DP 0 1 2700>,
+  < PHY_TYPE_DP 1 1 2700>;
+   phy-names = "dp-phy0", "dp-phy1";
+
+   power-domains = <_dp>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vid-layer {
+   dma-names = "vid0", "vid1", "vid2";
+   dmas = <_dpdma 0>,
+  <_dpdma 1>,
+  <_dpdma 2>;
+   };
+
+   gfx-layer {
+   dma-names = "gfx0";
+   dmas = <_dpdma 3>;
+   };
+
+   crtc_port: port@0 {
+   reg = <0>;
+   crtc: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   encoder: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+};
+
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/10] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display

[Hyun Kwon]

Xilinx ZynqMP has a hardened display pipeline. The pipeline can
be logically partitioned into 2 parts: display and DisplayPort.
This driver handles the display part of the pipeline that handles
buffer management and blending.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 2935 
 drivers/gpu/drm/xlnx/zynqmp_disp.h |   28 +
 2 files changed, 2963 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
new file mode 100644
index 000..68f829c
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -0,0 +1,2935 @@
+/*
+ * ZynqMP Display Controller Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_crtc.h"
+#include "xlnx_fb.h"
+#include "zynqmp_disp.h"
+#include "zynqmp_dp.h"
+#include "zynqmp_dpsub.h"
+
+/*
+ * Overview
+ * 
+ *
+ * The display part of ZynqMP DP subsystem. Internally, the device
+ * is partitioned into 3 blocks: AV buffer manager, Blender, Audio.
+ * The driver creates the DRM crtc and plane objectes and maps the DRM
+ * interface into those 3 blocks. In high level, the driver is layered
+ * in the following way:
+ *
+ * zynqmp_disp_crtc & zynqmp_disp_plane
+ * |->zynqmp_disp
+ * |->zynqmp_disp_aud
+ * |->zynqmp_disp_blend
+ * |->zynqmp_disp_av_buf
+ *
+ * The driver APIs are used externally by
+ * - zynqmp_dpsub: Top level ZynqMP DP subsystem driver
+ * - zynqmp_dp: ZynqMP DP driver
+ * - xlnx_crtc: Xilinx DRM specific crtc functions
+ */
+
+/* Blender registers */
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_0   0x0
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_1   0x4
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_2   0x8
+#define ZYNQMP_DISP_V_BLEND_BG_MAX 0xfff
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA   0xc
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MASK  0x1fe
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MAX   0xff
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT 0x14
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB 0x0
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4440x1
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4220x2
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YONLY   0x3
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_XVYCC   0x4
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_EN_DOWNSAMPLE   BIT(4)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL  0x18
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_EN_USBIT(0)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_RGB  BIT(1)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_BYPASS   BIT(8)
+#define ZYNQMP_DISP_V_BLEND_NUM_COEFF  9
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF0   0x20
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF1   0x24
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF2   0x28
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF3   0x2c
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF4   0x30
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF5   0x34
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF6   0x38
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF7   0x3c
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF8   0x40
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF0  0x44
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF1  0x48
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF2  0x4c
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF3  0x50
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF4  0x54
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF5  0x58
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF6  0x5c
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF7  0x60
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF8  0x64
+#define ZYNQMP_DISP_V_BLEND_NUM_OFFSET 3
+#define ZYNQMP_DISP_V_BLEND_LUMA_IN1CSC_OFFSET 0x68
+#define ZYNQMP_DISP_V_BLEND_CR_IN1CSC_OFFSET   0x6c
+#define ZYNQMP_DISP_V_BLEND_CB_IN1CSC_OFFSET   0x70
+#define ZYNQMP_DISP_V_BLEND_LUMA_OUTCSC_OFFSET 0x74
+#define ZYNQMP_DISP_V_BLEND_CR_OUTCSC_OFFSET   0x78
+#define ZYNQMP_DISP_V_BLEND_CB_OUTCSC_OFFSET   0x7c
+#define ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF0  0x80
+#define ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF1  0x84
+#define ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF2  0x88
+#define ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF3  0x8c
+#define ZYNQMP_DISP_V_BLEND_IN2CSC_COEFF4  

[PATCH 05/10] drm: xlnx: Xilinx DRM KMS driver

[Hyun Kwon]

Xilinx has various platforms for display, where users can create
using multiple IPs in the programmable FPGA fabric, or where
some hardened piepline is available on the chip. Furthermore,
hardened pipeline can also interact with soft logics in FPGA.

The Xilinx DRM KMS is a softwrae layer to glue subdevice drivers
with DRM core and integrate multiple subdevice drivers together.

Signed-off-by: Hyun Kwon 
---
 MAINTAINERS  |   8 +
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/xlnx/Kconfig |  12 ++
 drivers/gpu/drm/xlnx/Makefile|   2 +
 drivers/gpu/drm/xlnx/xlnx_crtc.c |   1 +
 drivers/gpu/drm/xlnx/xlnx_drv.c  | 436 +++
 drivers/gpu/drm/xlnx/xlnx_drv.h  |  22 ++
 drivers/gpu/drm/xlnx/xlnx_fb.c   |   1 +
 drivers/gpu/drm/xlnx/xlnx_gem.c  |   1 +
 10 files changed, 486 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/Kconfig
 create mode 100644 drivers/gpu/drm/xlnx/Makefile
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d4b1635..101a3e6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4785,6 +4785,14 @@ F:   drivers/gpu/drm/etnaviv/
 F: include/uapi/drm/etnaviv_drm.h
 F: Documentation/devicetree/bindings/display/etnaviv/
 
+DRM DRIVERS FOR XILINX
+M: Hyun Kwon 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/xlnx/
+F: Documentation/devicetree/bindings/display/xlnx/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVERS FOR ZTE ZX
 M: Shawn Guo 
 L: dri-devel@lists.freedesktop.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0bc3744..82b7fc3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -293,6 +293,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
 
 source "drivers/gpu/drm/tve200/Kconfig"
 
+source "drivers/gpu/drm/xlnx/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd5ae67..72ee1a1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_SCHED)+= scheduler/
+obj-$(CONFIG_DRM_XLNX) += xlnx/
diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
new file mode 100644
index 000..19fd7cd
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -0,0 +1,12 @@
+config DRM_XLNX
+   tristate "Xilinx DRM KMS Driver"
+   depends on DRM && OF
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Xilinx DRM KMS driver. Choose this option if you have
+ a Xilinx SoCs with hardened display pipeline or soft
+ display pipeline using Xilinx IPs in FPGA. This module
+ provides the kernel mode setting functionalities
+ for Xilinx display drivers.
diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
new file mode 100644
index 000..c60a281
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/Makefile
@@ -0,0 +1,2 @@
+xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o
+obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o
diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c b/drivers/gpu/drm/xlnx/xlnx_crtc.c
index 57ee939..8387e1e 100644
--- a/drivers/gpu/drm/xlnx/xlnx_crtc.c
+++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
@@ -13,6 +13,7 @@
 #include 
 
 #include "xlnx_crtc.h"
+#include "xlnx_drv.h"
 
 /*
  * Overview
diff --git a/drivers/gpu/drm/xlnx/xlnx_drv.c b/drivers/gpu/drm/xlnx/xlnx_drv.c
new file mode 100644
index 000..273420b
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_drv.c
@@ -0,0 +1,436 @@
+/*
+ * Xilinx DRM KMS Driver
+ *
+ *  Copyright (C) 2013 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_crtc.h"
+#include "xlnx_fb.h"
+#include "xlnx_gem.h"
+
+#define DRIVER_NAME"xlnx"
+#define DRIVER_DESC"Xilinx DRM KMS Driver"
+#define DRIVER_DATE"20130509"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+
+static uint xlnx_fbdev_vres = 2;
+module_param_named(fbdev_vres, xlnx_fbdev_vres, uint, 0444);
+MODULE_PARM_DESC(fbdev_vres,
+"fbdev virtual resolution multiplier for fb (default: 2)");
+
+/**
+ * struct xlnx_drm - Xilinx DRM private data
+ * @drm: DRM core
+ * @crtc: Xilinx DRM CRTC helper
+ * @fb: DRM fb helper
+ * @pdev: platform device
+ * @suspend_state: atomic state for suspend / resume
+ */
+struct xlnx_drm {
+   struct drm_device *drm;
+   struct xlnx_crtc_helper *crtc;
+ 

[PATCH 04/10] drm: xlnx: Add xlnx gem of Xilinx DRM KMS

[Hyun Kwon]

Implement a simple wrapper around drm_gem_cma_dumb_create_internal()
for alignment.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/xlnx_gem.c | 38 ++
 drivers/gpu/drm/xlnx/xlnx_gem.h | 18 ++
 2 files changed, 56 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h

diff --git a/drivers/gpu/drm/xlnx/xlnx_gem.c b/drivers/gpu/drm/xlnx/xlnx_gem.c
new file mode 100644
index 000..af1abdc
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_gem.c
@@ -0,0 +1,38 @@
+/*
+ * Xilinx DRM KMS GEM helper
+ *
+ *  Copyright (C) 2015 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+
+#include "xlnx_gem.h"
+
+/*
+ * xlnx_gem_cma_dumb_create - (struct drm_driver)->dumb_create callback
+ * @file_priv: drm_file object
+ * @drm: DRM object
+ * @args: info for dumb scanout buffer creation
+ *
+ * This function is for dumb_create callback of drm_driver struct. Simply
+ * it wraps around drm_gem_cma_dumb_create() and sets the pitch value
+ * by retrieving the value from the device.
+ *
+ * Return: The return value from drm_gem_cma_dumb_create()
+ */
+int xlnx_gem_cma_dumb_create(struct drm_file *file_priv, struct drm_device 
*drm,
+struct drm_mode_create_dumb *args)
+{
+   int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+   unsigned int align = xlnx_get_align(drm);
+
+   if (!args->pitch || !IS_ALIGNED(args->pitch, align))
+   args->pitch = ALIGN(pitch, align);
+
+   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
+}
diff --git a/drivers/gpu/drm/xlnx/xlnx_gem.h b/drivers/gpu/drm/xlnx/xlnx_gem.h
new file mode 100644
index 000..bed8ff9
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_gem.h
@@ -0,0 +1,18 @@
+/*
+ * Xilinx DRM KMS GEM helper header
+ *
+ *  Copyright (C) 2015 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#ifndef _XLNX_GEM_H_
+#define _XLNX_GEM_H_
+
+int xlnx_gem_cma_dumb_create(struct drm_file *file_priv,
+struct drm_device *drm,
+struct drm_mode_create_dumb *args);
+
+#endif /* _XLNX_GEM_H_ */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/10] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort

[Hyun Kwon]

This driver creates DRM encoder and connector for ZynqMP DisplayPort.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 1864 ++
 drivers/gpu/drm/xlnx/zynqmp_dp.h |   29 +
 2 files changed, 1893 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
new file mode 100644
index 000..ce3c7c5
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -0,0 +1,1864 @@
+/*
+ * ZynqMP DisplayPort Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dpsub.h"
+
+static uint zynqmp_dp_aux_timeout_ms = 50;
+module_param_named(aux_timeout_ms, zynqmp_dp_aux_timeout_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in msec (default: 50)");
+
+/*
+ * Some sink requires a delay after power on request
+ */
+static uint zynqmp_dp_power_on_delay_ms = 4;
+module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
+
+/* Link configuration registers */
+#define ZYNQMP_DP_TX_LINK_BW_SET   0x0
+#define ZYNQMP_DP_TX_LANE_CNT_SET  0x4
+#define ZYNQMP_DP_TX_ENHANCED_FRAME_EN 0x8
+#define ZYNQMP_DP_TX_TRAINING_PATTERN_SET  0xc
+#define ZYNQMP_DP_TX_SCRAMBLING_DISABLE0x14
+#define ZYNQMP_DP_TX_DOWNSPREAD_CTL0x18
+#define ZYNQMP_DP_TX_SW_RESET  0x1c
+#define ZYNQMP_DP_TX_SW_RESET_STREAM1  BIT(0)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM2  BIT(1)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM3  BIT(2)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM4  BIT(3)
+#define ZYNQMP_DP_TX_SW_RESET_AUX  BIT(7)
+#define ZYNQMP_DP_TX_SW_RESET_ALL  
(ZYNQMP_DP_TX_SW_RESET_STREAM1 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM2 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM3 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM4 | \
+
ZYNQMP_DP_TX_SW_RESET_AUX)
+
+/* Core enable registers */
+#define ZYNQMP_DP_TX_ENABLE0x80
+#define ZYNQMP_DP_TX_ENABLE_MAIN_STREAM0x84
+#define ZYNQMP_DP_TX_FORCE_SCRAMBLER_RESET 0xc0
+#define ZYNQMP_DP_TX_VERSION   0xf8
+#define ZYNQMP_DP_TX_VERSION_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_VERSION_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_VERSION_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_VERSION_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_VERSION_REVISION_MASK GENMASK(15, 12)
+#define ZYNQMP_DP_TX_VERSION_REVISION_SHIFT12
+#define ZYNQMP_DP_TX_VERSION_PATCH_MASKGENMASK(11, 8)
+#define ZYNQMP_DP_TX_VERSION_PATCH_SHIFT   8
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_MASK GENMASK(7, 0)
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_SHIFT0
+
+/* Core ID registers */
+#define ZYNQMP_DP_TX_CORE_ID   0xfc
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_MASK GENMASK(15, 8)
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_SHIFT8
+#define ZYNQMP_DP_TX_CORE_ID_DIRECTION GENMASK(1)
+
+/* AUX channel interface registers */
+#define ZYNQMP_DP_TX_AUX_COMMAND   0x100
+#define ZYNQMP_DP_TX_AUX_COMMAND_CMD_SHIFT 8
+#define ZYNQMP_DP_TX_AUX_COMMAND_ADDRESS_ONLY  BIT(12)
+#define ZYNQMP_DP_TX_AUX_COMMAND_BYTES_SHIFT   0
+#define ZYNQMP_DP_TX_AUX_WRITE_FIFO0x104
+#define ZYNQMP_DP_TX_AUX_ADDRESS   0x108
+#define ZYNQMP_DP_TX_CLK_DIVIDER   0x10c
+#define ZYNQMP_DP_TX_CLK_DIVIDER_MHZ   100
+#define ZYNQMP_DP_TX_CLK_DIVIDER_AUX_FILTER_SHIFT  8
+#define ZYNQMP_DP_TX_INTR_SIGNAL_STATE 0x130
+#define ZYNQMP_DP_TX_INTR_SIGNAL_STATE_HPD BIT(0)
+#define ZYNQMP_DP_TX_INTR_SIGNAL_STATE_REQUEST BIT(1)

[PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings

[Hyun Kwon]

The dt binding for Xilinx DRM KMS driver.

Signed-off-by: Hyun Kwon 
---
 .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt

diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt 
b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
new file mode 100644
index 000..8dcd552
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
@@ -0,0 +1,20 @@
+Xilinx KMS Pipeline
+---
+
+Xilinx display pipelines can be designed with hardened video IPs and soft video
+IPs in programmable logic. This KMS module provides the common functionality
+of individual subdevice drivers, and glue logics between them.
+
+Required properties:
+
+- compatible: Must be "xlnx,kms".
+
+- ports: phandles for CRTC ports, using the DT bindings defined in
+  Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   xlnx_drm: xlnx_drm {
+   compatible = "xlnx,kms";
+   ports = <_port>;
+   };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/10] drm: xlnx: Add xlnx crtc of Xilinx DRM KMS

[Hyun Kwon]

xlnx_crtc is a part of Xilinx DRM KMS and a layer that
provides some interface between the Xilinx DRM KMS and
crtc drivers.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/xlnx_crtc.c | 194 +++
 drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
 2 files changed, 264 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h

diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c b/drivers/gpu/drm/xlnx/xlnx_crtc.c
new file mode 100644
index 000..57ee939
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
@@ -0,0 +1,194 @@
+/*
+ * Xilinx DRM crtc driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+
+#include 
+
+#include "xlnx_crtc.h"
+
+/*
+ * Overview
+ * 
+ *
+ * The Xilinx CRTC layer is to enable the custom interface to CRTC drivers.
+ * The interface is used by Xilinx DRM driver where it needs CRTC
+ * functionailty. CRTC drivers should attach the desired callbacks
+ * to struct xlnx_crtc and register the xlnx_crtc with correcsponding
+ * drm_device. It's highly recommended CRTC drivers register all callbacks
+ * even though many of them are optional.
+ * The CRTC helper simply walks through the registered CRTC device,
+ * and call the callbacks.
+ */
+
+/**
+ * struct xlnx_crtc_helper - Xilinx CRTC helper
+ * @xlnx_crtcs: list of Xilinx CRTC devices
+ * @lock: lock to protect @xlnx_crtcs
+ * @drm: back pointer to DRM core
+ */
+struct xlnx_crtc_helper {
+   struct list_head xlnx_crtcs;
+   struct mutex lock; /* lock for @xlnx_crtcs */
+   struct drm_device *drm;
+};
+
+#define XLNX_CRTC_MAX_HEIGHT_WIDTH UINT_MAX
+
+int xlnx_crtc_helper_enable_vblank(struct xlnx_crtc_helper *helper,
+  unsigned int crtc_id)
+{
+   struct xlnx_crtc *crtc;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list)
+   if (drm_crtc_index(>crtc) == crtc_id)
+   if (crtc->enable_vblank)
+   return crtc->enable_vblank(crtc);
+   return -ENODEV;
+}
+
+void xlnx_crtc_helper_disable_vblank(struct xlnx_crtc_helper *helper,
+unsigned int crtc_id)
+{
+   struct xlnx_crtc *crtc;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (drm_crtc_index(>crtc) == crtc_id) {
+   if (crtc->disable_vblank)
+   crtc->disable_vblank(crtc);
+   return;
+   }
+   }
+}
+
+unsigned int xlnx_crtc_helper_get_align(struct xlnx_crtc_helper *helper)
+{
+   struct xlnx_crtc *crtc;
+   unsigned int align = 1, tmp;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (crtc->get_align) {
+   tmp = crtc->get_align(crtc);
+   align = ALIGN(align, tmp);
+   }
+   }
+
+   return align;
+}
+
+u64 xlnx_crtc_helper_get_dma_mask(struct xlnx_crtc_helper *helper)
+{
+   struct xlnx_crtc *crtc;
+   u64 mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8), tmp;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (crtc->get_dma_mask) {
+   tmp = crtc->get_dma_mask(crtc);
+   mask = min(mask, tmp);
+   }
+   }
+
+   return mask;
+}
+
+int xlnx_crtc_helper_get_max_width(struct xlnx_crtc_helper *helper)
+{
+   struct xlnx_crtc *crtc;
+   unsigned int width = XLNX_CRTC_MAX_HEIGHT_WIDTH, tmp;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (crtc->get_max_width) {
+   tmp = crtc->get_max_width(crtc);
+   width = min(width, tmp);
+   }
+   }
+
+   return width;
+}
+
+int xlnx_crtc_helper_get_max_height(struct xlnx_crtc_helper *helper)
+{
+   struct xlnx_crtc *crtc;
+   unsigned int height = XLNX_CRTC_MAX_HEIGHT_WIDTH, tmp;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (crtc->get_max_height) {
+   tmp = crtc->get_max_height(crtc);
+   height = min(height, tmp);
+   }
+   }
+
+   return height;
+}
+
+uint32_t xlnx_crtc_helper_get_format(struct xlnx_crtc_helper *helper)
+{
+   struct xlnx_crtc *crtc;
+   u32 format = 0, tmp;
+
+   list_for_each_entry(crtc, >xlnx_crtcs, list) {
+   if (crtc->get_format) {
+   tmp = crtc->get_format(crtc);
+   if (format && format != tmp)
+   return 0;
+   format = tmp;
+   }
+   }
+
+   return format;
+}
+
+struct xlnx_crtc_helper *xlnx_crtc_helper_init(struct drm_device *drm)
+{
+   struct xlnx_crtc_helper *helper;
+
+   helper = 

[PATCH 03/10] drm: xlnx: Add xlnx fb of Xilinx DRM KMS

[Hyun Kwon]

Helpers for framebuffers backed by cma allocator.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/xlnx_fb.c | 467 +
 drivers/gpu/drm/xlnx/xlnx_fb.h |  30 +++
 2 files changed, 497 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h

diff --git a/drivers/gpu/drm/xlnx/xlnx_fb.c b/drivers/gpu/drm/xlnx/xlnx_fb.c
new file mode 100644
index 000..dbe9fbf
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_fb.c
@@ -0,0 +1,467 @@
+/*
+ * Xilinx DRM KMS Framebuffer helper
+ *
+ *  Copyright (C) 2015 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * Based on drm_fb_cma_helper.c
+ *
+ *  Copyright (C) 2012 Analog Device Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_fb.h"
+
+#define XLNX_MAX_PLANES4
+
+struct xlnx_fb {
+   struct drm_framebuffer  base;
+   struct drm_gem_cma_object   *obj[XLNX_MAX_PLANES];
+};
+
+struct xlnx_fbdev {
+   struct drm_fb_helper fb_helper;
+   struct xlnx_fb  *fb;
+   unsigned int align;
+   unsigned int vres_mult;
+};
+
+static inline struct xlnx_fbdev *to_fbdev(struct drm_fb_helper *fb_helper)
+{
+   return container_of(fb_helper, struct xlnx_fbdev, fb_helper);
+}
+
+static inline struct xlnx_fb *to_fb(struct drm_framebuffer *base_fb)
+{
+   return container_of(base_fb, struct xlnx_fb, base);
+}
+
+static void xlnx_fb_destroy(struct drm_framebuffer *base_fb)
+{
+   struct xlnx_fb *fb = to_fb(base_fb);
+   int i;
+
+   for (i = 0; i < XLNX_MAX_PLANES; i++)
+   if (fb->obj[i])
+   drm_gem_object_unreference_unlocked(>obj[i]->base);
+
+   drm_framebuffer_cleanup(base_fb);
+   kfree(fb);
+}
+
+static int xlnx_fb_create_handle(struct drm_framebuffer *base_fb,
+struct drm_file *file_priv,
+unsigned int *handle)
+{
+   struct xlnx_fb *fb = to_fb(base_fb);
+
+   return drm_gem_handle_create(file_priv, >obj[0]->base, handle);
+}
+
+static struct drm_framebuffer_funcs xlnx_fb_funcs = {
+   .destroy= xlnx_fb_destroy,
+   .create_handle  = xlnx_fb_create_handle,
+};
+
+/**
+ * xlnx_fb_alloc - Allocate a xlnx_fb
+ * @drm: DRM object
+ * @mode_cmd: drm_mode_fb_cmd2 struct
+ * @obj: pointers for returned drm_gem_cma_objects
+ * @num_planes: number of planes to be allocated
+ *
+ * This function is based on drm_fb_cma_alloc().
+ *
+ * Return: a xlnx_fb object, or ERR_PTR.
+ */
+static struct xlnx_fb *
+xlnx_fb_alloc(struct drm_device *drm,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_cma_object **obj, unsigned int num_planes)
+{
+   struct xlnx_fb *fb;
+   int ret;
+   int i;
+
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+   if (!fb)
+   return ERR_PTR(-ENOMEM);
+
+   drm_helper_mode_fill_fb_struct(drm, >base, mode_cmd);
+
+   for (i = 0; i < num_planes; i++)
+   fb->obj[i] = obj[i];
+
+   ret = drm_framebuffer_init(drm, >base, _fb_funcs);
+   if (ret) {
+   dev_err(drm->dev, "Failed to initialize fb: %d\n", ret);
+   kfree(fb);
+   return ERR_PTR(ret);
+   }
+
+   return fb;
+}
+
+/**
+ * xlnx_fb_get_paddr - Get physycal address of framebuffer
+ * @base_fb: the framebuffer
+ * @plane: which plane
+ *
+ * This function is based on drm_fb_cma_get_gem_obj().
+ *
+ * Return: a physical address of the plane, or 0
+ */
+dma_addr_t
+xlnx_fb_get_paddr(struct drm_framebuffer *base_fb, unsigned int plane)
+{
+   struct xlnx_fb *fb = to_fb(base_fb);
+
+   if (plane >= XLNX_MAX_PLANES)
+   return 0;
+
+   return fb->obj[plane]->paddr;
+}
+EXPORT_SYMBOL_GPL(xlnx_fb_get_paddr);
+
+static int
+xlnx_fb_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   unsigned int i;
+   int ret = 0;
+
+   switch (cmd) {
+   case FBIO_WAITFORVSYNC:
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_mode_set *mode_set;
+   struct drm_crtc *crtc;
+
+   mode_set = _helper->crtc_info[i].mode_set;
+   crtc = mode_set->crtc;
+   ret = drm_crtc_vblank_get(crtc);
+   if (!ret) {
+   drm_crtc_wait_one_vblank(crtc);
+   drm_crtc_vblank_put(crtc);
+   }
+   }
+   return ret;
+   default:
+   return -ENOTTY;
+   }
+
+   return 0;
+}
+
+static struct fb_ops xlnx_fbdev_ops = {
+   .owner  = THIS_MODULE,
+   .fb_fillrect= sys_fillrect,
+   .fb_copyarea= sys_copyarea,
+   

[PATCH 09/10] drm: xlnx: ZynqMP DP subsystem DRM KMS driver

[Hyun Kwon]

This is a wrapper around the ZynqMP Display and DisplayPort drivers.

Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/Kconfig|  11 +++
 drivers/gpu/drm/xlnx/Makefile   |   3 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 141 
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h |  19 +
 4 files changed, 174 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h

diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
index 19fd7cd..7c5529c 100644
--- a/drivers/gpu/drm/xlnx/Kconfig
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -10,3 +10,14 @@ config DRM_XLNX
  display pipeline using Xilinx IPs in FPGA. This module
  provides the kernel mode setting functionalities
  for Xilinx display drivers.
+
+config DRM_ZYNQMP_DPSUB
+   tristate "ZynqMP DP Subsystem Driver"
+   depends on ARCH_ZYNQMP && OF && DRM_XLNX && COMMON_CLK
+   select DMA_ENGINE
+   select GENERIC_PHY
+   help
+ DRM KMS driver for ZynqMP DP Subsystem controller. Choose
+ this option if you have a Xilinx ZynqMP SoC with DisplayPort
+ subsystem. The driver provides the kernel mode setting
+ functionlaities for ZynqMP DP subsystem.
diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
index c60a281..064a05a 100644
--- a/drivers/gpu/drm/xlnx/Makefile
+++ b/drivers/gpu/drm/xlnx/Makefile
@@ -1,2 +1,5 @@
 xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o
 obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o
+
+zynqmp-dpsub-objs += zynqmp_disp.o zynqmp_dpsub.o zynqmp_dp.o
+obj-$(CONFIG_DRM_ZYNQMP_DPSUB) += zynqmp-dpsub.o
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
new file mode 100644
index 000..ccca798
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -0,0 +1,141 @@
+/*
+ * ZynqMP DP Subsystem Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dp.h"
+#include "zynqmp_dpsub.h"
+
+static int
+zynqmp_dpsub_bind(struct device *dev, struct device *master, void *data)
+{
+   int ret;
+
+   ret = zynqmp_disp_bind(dev, master, data);
+   if (ret)
+   return ret;
+
+   /* zynqmp_disp should bind first, so zynqmp_dp encoder can find crtc */
+   ret = zynqmp_dp_bind(dev, master, data);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static void
+zynqmp_dpsub_unbind(struct device *dev, struct device *master, void *data)
+{
+   zynqmp_dp_unbind(dev, master, data);
+   zynqmp_disp_unbind(dev, master, data);
+}
+
+static const struct component_ops zynqmp_dpsub_component_ops = {
+   .bind   = zynqmp_dpsub_bind,
+   .unbind = zynqmp_dpsub_unbind,
+};
+
+static int zynqmp_dpsub_probe(struct platform_device *pdev)
+{
+   struct zynqmp_dpsub *dpsub;
+   int ret;
+
+   dpsub = devm_kzalloc(>dev, sizeof(*dpsub), GFP_KERNEL);
+   if (!dpsub)
+   return -ENOMEM;
+
+   /* Sub-driver will access dpsub from drvdata */
+   platform_set_drvdata(pdev, dpsub);
+   pm_runtime_enable(>dev);
+
+   /*
+* DP should be probed first so that the zynqmp_disp can set the output
+* format accordingly.
+*/
+   ret = zynqmp_dp_probe(pdev);
+   if (ret)
+   goto err_pm;
+
+   ret = zynqmp_disp_probe(pdev);
+   if (ret)
+   goto err_dp;
+
+   ret = component_add(>dev, _dpsub_component_ops);
+   if (ret)
+   goto err_disp;
+
+   /* Populate the sound child nodes */
+   ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
+   if (ret) {
+   dev_err(>dev, "failed to populate child nodes\n");
+   goto err_component;
+   }
+
+   dev_info(>dev, "ZynqMP DisplayPort Subsystem driver probed");
+
+   return 0;
+
+err_component:
+   component_del(>dev, _dpsub_component_ops);
+err_disp:
+   zynqmp_disp_remove(pdev);
+err_dp:
+   zynqmp_dp_remove(pdev);
+err_pm:
+   pm_runtime_disable(>dev);
+   return ret;
+}
+
+static int zynqmp_dpsub_remove(struct platform_device *pdev)
+{
+   int err, ret = 0;
+
+   of_platform_depopulate(>dev);
+   component_del(>dev, _dpsub_component_ops);
+
+   err = zynqmp_disp_remove(pdev);
+   if (err)
+   ret = -EIO;
+
+   err = zynqmp_dp_remove(pdev);
+   if (err)
+   ret = -EIO;
+
+   pm_runtime_disable(>dev);
+
+   return err;
+}
+
+static const struct of_device_id zynqmp_dpsub_of_match[] = {
+   { .compatible = "xlnx,zynqmp-dpsub-1.7", },
+   { /* end of table */ },
+};
+MODULE_DEVICE_TABLE(of, zynqmp_dpsub_of_match);
+
+static struct platform_driver 

[PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

[Hyun Kwon]

Debugfs can be used to exploit some specific setting. Main purpose
is for testing and debug diagnostic.

Signed-off-by: Tejas Upadhyay 
Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/Kconfig   |  21 +++
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 326 +
 drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304 ++
 3 files changed, 651 insertions(+)

diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
index 7c5529c..befce0f 100644
--- a/drivers/gpu/drm/xlnx/Kconfig
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
  this option if you have a Xilinx ZynqMP SoC with DisplayPort
  subsystem. The driver provides the kernel mode setting
  functionlaities for ZynqMP DP subsystem.
+
+config DRM_ZYNQMP_DISP_DEBUG_FS
+   bool "ZynqMP Display debugfs"
+   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
+   select DRM_ZYNQMP_DP_DEBUG_FS
+   help
+ Enable the debugfs code for DP Sub driver. The debugfs code
+ enables debugging or testing related features. It exposes some
+ low level controls to the user space to help testing automation,
+ as well as can enable additional diagnostic or statistical
+ information.
+
+config DRM_ZYNQMP_DP_DEBUG_FS
+   bool "ZynqMP DP debugfs"
+   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
+   help
+ Enable the debugfs code for DP driver. The debugfs code
+ enables debugging or testing related features. It exposes some
+ low level controls to the user space to help testing automation,
+ as well as can enable additional diagnostic or statistical
+ information.
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 68f829c..9fe6d49 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem *base, int 
offset, u32 set)
zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) | set);
 }
 
+#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
+
+#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE  32UL
+#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL   0xFFF
+#define IN_RANGE(x, min, max) ({   \
+   typeof(x) _x = (x); \
+   _x >= (min) && _x <= (max); })
+
+/* Match xilinx_dp_testcases vs dp_debugfs_reqs[] entry */
+enum zynqmp_disp_testcases {
+   DP_SUB_TC_BG_COLOR,
+   DP_SUB_TC_OUTPUT_FMT,
+   DP_SUB_TC_NONE
+};
+
+struct zynqmp_disp_debugfs {
+   enum zynqmp_disp_testcases testcase;
+   u16 r_value;
+   u16 g_value;
+   u16 b_value;
+   u32 output_fmt;
+   struct zynqmp_disp *zynqmp_disp;
+};
+
+static struct dentry *zynqmp_disp_debugfs_dir;
+struct zynqmp_disp_debugfs disp_debugfs;
+struct zynqmp_disp_debugfs_request {
+   const char *req;
+   enum zynqmp_disp_testcases tc;
+   ssize_t (*read_handler)(char **kern_buff);
+   ssize_t (*write_handler)(char **cmd);
+};
+
+static void
+zynqmp_disp_set_output_fmt(struct zynqmp_disp *disp, unsigned int id);
+static s64 zynqmp_disp_debugfs_argument_value(char *arg)
+{
+   s64 value;
+
+   if (!arg)
+   return -1;
+
+   if (!kstrtos64(arg, 0, ))
+   return value;
+
+   return -1;
+}
+
+static ssize_t
+zynqmp_disp_debugfs_background_color_write(char **disp_test_arg)
+{
+   char *r_color, *g_color, *b_color;
+   s64 r_val, g_val, b_val;
+
+   r_color = strsep(disp_test_arg, " ");
+   g_color = strsep(disp_test_arg, " ");
+   b_color = strsep(disp_test_arg, " ");
+
+   /* char * to int conversion */
+   r_val = zynqmp_disp_debugfs_argument_value(r_color);
+   g_val = zynqmp_disp_debugfs_argument_value(g_color);
+   b_val = zynqmp_disp_debugfs_argument_value(b_color);
+
+   if (!(IN_RANGE(r_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
+ IN_RANGE(g_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
+ IN_RANGE(b_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL)))
+   return -EINVAL;
+
+   disp_debugfs.r_value = r_val;
+   disp_debugfs.g_value = g_val;
+   disp_debugfs.b_value = b_val;
+
+   disp_debugfs.testcase = DP_SUB_TC_BG_COLOR;
+
+   return 0;
+}
+
+static ssize_t
+zynqmp_disp_debugfs_output_display_format_write(char **disp_test_arg)
+{
+   char *output_format;
+   struct zynqmp_disp *disp = disp_debugfs.zynqmp_disp;
+
+   /* Read the value from a user value */
+   output_format = strsep(disp_test_arg, " ");
+   if (strncmp(output_format, "rgb", 3) == 0) {
+   disp_debugfs.output_fmt =
+   ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB;
+   } else if (strncmp(output_format, "ycbcr444", 8) == 0) {
+  

[PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver

[Hyun Kwon]

Hi,

This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort subsystem. 
The Xilinx ZynqMP SoC has a hardened full display pipeline which supports 
blending of up to 2 planes, and the encoder is DisplayPort v1.2 compatible.

This series mainly includes 2 sets: Xilinx DRM KMS (patch 1/10 - 5/10) and 
ZynqMP DP subsystem drivers (patch 6/10 - 10/10).

The Xilinx DRM KMS is intended as a common layer shared across other (upcoming) 
Xilinx sub-drivers. It helps sub-drivers for both hardened as well as soft IPs 
interoperate together.

ZynqMP DP subsystem driver is a sub-driver that implements corresponding drm 
objects (crtc, plane, encoder, connector,,,) for ZynqMP SoC display pipeline. 
The entire pipeline is mainly partitioned into 2 blocks: generic display logic 
(zynqmp_disp.c) such as blending, csc,,, and the DP transmitter logic 
(zynqmp_dp.c).

Thanks,
-hyun

Hyun Kwon (10):
  dt-bindings: display: xlnx: Add Xilinx kms bindings
  drm: xlnx: Add xlnx crtc of Xilinx DRM KMS
  drm: xlnx: Add xlnx fb of Xilinx DRM KMS
  drm: xlnx: Add xlnx gem of Xilinx DRM KMS
  drm: xlnx: Xilinx DRM KMS driver
  dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
  drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display
  drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort
  drm: xlnx: ZynqMP DP subsystem DRM KMS driver
  drm: xlnx: zynqmp: Add debugfs

 .../devicetree/bindings/display/xlnx/xlnx,kms.txt  |   20 +
 .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt|   94 +
 MAINTAINERS|8 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/xlnx/Kconfig   |   44 +
 drivers/gpu/drm/xlnx/Makefile  |5 +
 drivers/gpu/drm/xlnx/xlnx_crtc.c   |  195 ++
 drivers/gpu/drm/xlnx/xlnx_crtc.h   |   70 +
 drivers/gpu/drm/xlnx/xlnx_drv.c|  436 +++
 drivers/gpu/drm/xlnx/xlnx_drv.h|   22 +
 drivers/gpu/drm/xlnx/xlnx_fb.c |  468 +++
 drivers/gpu/drm/xlnx/xlnx_fb.h |   30 +
 drivers/gpu/drm/xlnx/xlnx_gem.c|   39 +
 drivers/gpu/drm/xlnx/xlnx_gem.h|   18 +
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 3261 
 drivers/gpu/drm/xlnx/zynqmp_disp.h |   28 +
 drivers/gpu/drm/xlnx/zynqmp_dp.c   | 2168 +
 drivers/gpu/drm/xlnx/zynqmp_dp.h   |   29 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c|  141 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h|   19 +
 21 files changed, 7098 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
 create mode 100644 
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
 create mode 100644 drivers/gpu/drm/xlnx/Kconfig
 create mode 100644 drivers/gpu/drm/xlnx/Makefile
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
 create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for 4.15-rc7

[Dave Airlie]

Hey Linus,

Just collecting some fixes to finish my hoildays :-).

A few fixes for i915 (one documentation build fix), one ttm fix, one
AMD display fix, one omapdrm fix, and a set of armada fixes from
Russell.

All seem pretty small, you can now return to your latest security news site.

Dave.

The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d:

  Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.15-rc7

for you to fetch changes up to bc6fe533278e84595406546b0b44aa7db7990806:

  Merge tag 'drm-intel-fixes-2018-01-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-01-05
09:25:01 +1000)


drm fixes for i915, amd, armada, omapdrm


Dave Airlie (4):
  Merge tag 'omapdrm-4.15-fixes' of
git://git.kernel.org/.../tomba/linux into drm-fixes
  Merge branch 'drm-armada-fixes-4.15' of
git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes
  Merge branch 'drm-fixes-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-01-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Dhinakaran Pandiyan (1):
  drm/i915/psr: Fix register name mess up.

Hans Verkuil (1):
  omapdrm/dss/hdmi4_cec: fix interrupt handling

Lucas De Marchi (1):
  drm/i915: Apply Display WA #1183 on skl, kbl, and cfl

Markus Heiser (1):
  docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

Randy Dunlap (1):
  documentation/gpu/i915: fix docs build error after file rename

Russell King (5):
  drm/armada: fix leak of crtc structure
  drm/armada: fix SRAM powerdown
  drm/armada: fix UV swap code
  drm/armada: improve efficiency of armada_drm_plane_calc_addrs()
  drm/armada: fix YUV planar format framebuffer offsets

Ville Syrjälä (2):
  drm/i915: Disable DC states around GMBUS on GLK
  drm/i915: Put all non-blocking modesets onto an ordered wq

Xiongwei Song (1):
  drm/ttm: check the return value of kzalloc

Yue Hin Lau (1):
  drm/amd/display: call set csc_default if enable adjustment is false

 Documentation/gpu/i915.rst |  5 +--
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h   |  2 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c|  6 +--
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  2 +
 drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h|  2 +-
 drivers/gpu/drm/armada/armada_crtc.c   | 47 +-
 drivers/gpu/drm/armada/armada_crtc.h   |  2 +
 drivers/gpu/drm/armada/armada_overlay.c| 38 -
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_reg.h|  2 +
 drivers/gpu/drm/i915/intel_cdclk.c | 35 +++-
 drivers/gpu/drm/i915/intel_display.c   | 14 +--
 drivers/gpu/drm/i915/intel_psr.c   | 16 
 drivers/gpu/drm/i915/intel_runtime_pm.c| 11 +
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c| 46 +
 drivers/gpu/drm/ttm/ttm_page_alloc.c   |  2 +
 16 files changed, 127 insertions(+), 106 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_cdclk.c

between commit:

  30414f3010af ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")

from the drm-intel-fixes tree and commit:

  2aa97491da8a ("drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_cdclk.c
index 60cf4e58389a,9c5ceb98d48f..
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@@ -917,11 -994,9 +988,9 @@@ static void skl_set_cdclk(struct drm_i9
  {
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
-   u32 freq_select, pcu_ack, cdclk_ctl;
 -  u32 freq_select;
++  u32 freq_select, cdclk_ctl;
int ret;
  
-   WARN_ON((cdclk == 24000) != (vco == 0));
- 
mutex_lock(_priv->pcu_lock);
ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
SKL_CDCLK_PREPARE_FOR_CHANGE,
@@@ -934,8 -1009,16 +1003,16 @@@
return;
}
  
 -  /* set CDCLK_CTL */
 +  /* Choose frequency for this cdclk */
switch (cdclk) {
+   default:
+   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
+   WARN_ON(vco != 0);
+   /* fall through */
+   case 308571:
+   case 337500:
+   freq_select = CDCLK_FREQ_337_308;
+   break;
case 45:
case 432000:
freq_select = CDCLK_FREQ_450_432;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2018-01-04 at 23:46 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2018-01-04 at 18:21 -0500, Lyude Paul wrote:
> > Sorry for the late reply, I've been having very similar issues on my own 
> > MST hub
> > and I wanted to make sure that they were the same issue, although it seems 
> > like
> > they aren't.
> > 
> > So; I've been doing a lot of MST debugging this week and last and something 
> > I've
> > discovered needs to be taken into account sometimes with MST hubs is the 
> > actual
> > state that they're in at the point that the DRM driver detects them. I've
> > managed to on multiple occasions, get my hub into a weird state by:
> > 
> > - Plugging in MST displays into the hub
> > - Turning on the machine
> > - Unplugging MST displays from the hub (while still in the BIOS)
> > - Booting into linux
> > - Plugging MST displays into the hub
> > - Everything times out, the world explodes, the economy collapses, etc.
> > 
> > I think maybe, especially since this should be perfectly valid behavior and 
> > not
> > break well or poor behaving hubs, we should do a power cycle with the 
> > display
> > like this when the DP port initially detects an MST hub and before we start
> > doing any serious communication with it. Could you see if this fixes your 
> > issue
> > instead of the patch you've got here?
> > 
> 
> Well, my reasoning to power cycle after a failure was to not affect hubs
> that work. Besides that I also saw an odd cycle of timeouts and late
> replies when I did this.
> 
> 1. Detect hub
> 2. Toggle power state and send LINK_ADDRESS req.
> 3. LINK_ADDRESS req times out.
> 4. Toggle power state and send LINK_ADDRESS req.
> 5. Get late response for the first (and expired) LINK_ADDRESS req.
> 6. Go to step 3
> 
> It seems like toggling the power states flushes out some message buffers
> in the MST hub.
> 
> But, in the retry approach, power cycling resulted in getting the
> response for the current LINK_ADDRESS request along with the previous
> one that timed out.
> 
> I could not come up with an explanation for all the behavior. So, I
> decided to get back to this later.
> 
> 
> > As well, mind attaching your full dmesg with drm.debug=0x6?
> 
> I don't have the old logs anymore, will try to get something for you.
Here you go

Setup: Laptop -> ThinkPad dock -> Dell MST monitor -> Dell monitor
Hotplugged display to dock[passed] - https://pastebin.com/CemRGsCb
Connected boot[failed] - https://pastebin.com/jjXP6HzB

> 
> -DK
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] Armada DRM (drm-armada-devel-4.15 branch)

[Dave Airlie]

On 1 January 2018 at 22:19, Russell King  wrote:
> David,
>
> Please incorporate the latest Armada DRM (drm-armada-devel-4.15 branch),
> which can be found at:
>
>   git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel-4.15

This conflicted with:

a01cb8ba3f6282934cff65e89ab36b18b14cbe27
Author: Ville Syrjälä 
Date:   Wed Nov 1 22:16:19 2017 +0200

drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

I've fixed up the version I pulled into drm-next, but I'd appreciate
if you could give it a test.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Pandiyan, Dhinakaran]

On Thu, 2018-01-04 at 18:21 -0500, Lyude Paul wrote:
> Sorry for the late reply, I've been having very similar issues on my own MST 
> hub
> and I wanted to make sure that they were the same issue, although it seems 
> like
> they aren't.
> 
> So; I've been doing a lot of MST debugging this week and last and something 
> I've
> discovered needs to be taken into account sometimes with MST hubs is the 
> actual
> state that they're in at the point that the DRM driver detects them. I've
> managed to on multiple occasions, get my hub into a weird state by:
> 
> - Plugging in MST displays into the hub
> - Turning on the machine
> - Unplugging MST displays from the hub (while still in the BIOS)
> - Booting into linux
> - Plugging MST displays into the hub
> - Everything times out, the world explodes, the economy collapses, etc.
> 
> I think maybe, especially since this should be perfectly valid behavior and 
> not
> break well or poor behaving hubs, we should do a power cycle with the display
> like this when the DP port initially detects an MST hub and before we start
> doing any serious communication with it. Could you see if this fixes your 
> issue
> instead of the patch you've got here?
> 

Well, my reasoning to power cycle after a failure was to not affect hubs
that work. Besides that I also saw an odd cycle of timeouts and late
replies when I did this.

1. Detect hub
2. Toggle power state and send LINK_ADDRESS req.
3. LINK_ADDRESS req times out.
4. Toggle power state and send LINK_ADDRESS req.
5. Get late response for the first (and expired) LINK_ADDRESS req.
6. Go to step 3

It seems like toggling the power states flushes out some message buffers
in the MST hub.

But, in the retry approach, power cycling resulted in getting the
response for the current LINK_ADDRESS request along with the previous
one that timed out.

I could not come up with an explanation for all the behavior. So, I
decided to get back to this later.


> As well, mind attaching your full dmesg with drm.debug=0x6?

I don't have the old logs anymore, will try to get something for you.

-DK
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

--- Comment #4 from Sebastian Parborg  ---
(In reply to Michel Dänzer from comment #2)
> (In reply to Sebastian Parborg from comment #0)
> > [...] there seems to be some kind of cached behaviour (not the mesa shader
> > cache as I removed the directory [...]
> 
> Which directory exactly did you remove? Have you tried setting the
> environment variable MESA_GLSL_CACHE_DISABLE=true to see if that avoids the
> problem?

I removed "~/.cache/mesa_shader_cache". I tried that environment variable now
and it doesn't seem to solve it either for me (with mesa from 2017-12-01)...

I really do not know how I should try to bisect this...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH v4 1/3] Add meson build system

[Dylan Baker]

Quoting Igor Gnatenko (2018-01-04 13:43:51)
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Thu, 2018-01-04 at 10:28 -0800, Dylan Baker wrote:
> > This patch adds a complete meson build system, including tests and
> > install. It has the necessary hooks to allow it be used as a subproject
> > for other meson based builds such as mesa.
> 
> Builds fine on all architectures supported by Fedora, boots fine on my laptop
> (x86_64).
> 
> All nitpicks are inline.
> 
> > Signed-off-by: Dylan Baker 
> 
> Reviewed-and-tested-by: Igor Gnatenko 
> 
> > diff --git a/meson_options.txt b/meson_options.txt
> > new file mode 100644
> > index 000..08c2ccd
> > --- /dev/null
> > +++ b/meson_options.txt
> > @@ -0,0 +1,143 @@
> > [...]
> > +option(
> > +  'intel',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : '''Enable support for Intel's KMS API.''',
> 
> Any reason to use `'''` here and there?

to avoid escaping the ' in "Intel's". But I can change it if you prefer.

> 
> > [...]
> > +option(
> > +  'man-pages',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : 'Enable manpage generation and install.',
> 
> "installation".
> 
> > [...]
> > +option(
> > +  'valgrind',
> > +  type : 'combo',
> > +  value : 'auto',
> > +  choices : ['true', 'false', 'auto'],
> > +  description : 'build libdrm with valgrind support',
> 
> "Build". And fullstop at the end of sentence.
> - -- 
> - -Igor Gnatenko
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpOoBcACgkQaVcUvRu8
> X0yF9w//cgaMVkU4xTKegRJY4uuzTE3MQvMmaCoA8ivBaCWPuoX3ozlwsAgZZXaZ
> Vo83tZ0u80cjgoSG4I/JcNp3UhsxtGgqcrqqcof/SGn+YS43eFKPL57dowwQ5qk3
> ccAUgHtAdQXuCJFaQFsTISSEj1X07RA04mIMe7QZFh7AHsKmv+ctaTUO7uJsXJzi
> aX7Z9rntTCnXvzZy7Y56XPCleXfi+yDzQPdDopZAEdLYT8hYUvebo6JGQUpg8iNd
> YuvZsbkrpyV1uMY/2feSJ3Ns4ZTAj3I4F41Xbb7CqZt/BX60EnkZJXog4RSbdlri
> cxMX7gPkrOXxNJbllmdN0nPdBP/atViRY7dDkE4Lv4YrmwL8oT4Mjfyb/TeINT2X
> 6NltSgc8+zSvQSkjWyKHzQ3ZQCQHIAheG+V2Cvnc1NIfX06AV9USRsSRzBMza+gW
> cWNT2g/M0jjmLTVEoLR8MSLXAB9gfsBdRDEnvqEsZCqDh1idW1Ttuk3m/h3+BT8i
> GMyCrswVgKLI7gBbdVFdLDarEIVtTJlYvPkGXxRyOzv1r5dM/MMmeay7P3WD+liE
> CLF9nRVrekQA7Mh4Y61RSyFAntzBokNKL+FrSzSuseNtgYAM3Es0JgY1ndsczvVX
> zUqULC0AEAEwmAIQmDlYFG+ut8nIvmk6aWHHlvLwUHgiDD+MEc4=
> =dAKV
> -END PGP SIGNATURE-
> 


signature.asc
Description: signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[sunpeng.li]

From: "Leo (Sunpeng) Li" 

During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).

Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.

Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.

Signed-off-by: Leo (Sunpeng) Li 
---
 drivers/gpu/drm/drm_atomic_helper.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab40321..4253f57 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3421,6 +3421,15 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
 void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
 {
if (state->commit) {
+   /*
+* In the event that a non-blocking commit returns
+* -ERESTARTSYS before the commit_tail work is queued, we will
+* have an extra reference to the commit object. Release it, if
+* the event has not been consumed by the worker.
+*/
+   if (state->event)
+   drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
drm_crtc_commit_put(state->commit);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: Power cycle display if LINK_ADDRESS fails.

[Lyude Paul]

Sorry for the late reply, I've been having very similar issues on my own MST hub
and I wanted to make sure that they were the same issue, although it seems like
they aren't.

So; I've been doing a lot of MST debugging this week and last and something I've
discovered needs to be taken into account sometimes with MST hubs is the actual
state that they're in at the point that the DRM driver detects them. I've
managed to on multiple occasions, get my hub into a weird state by:

- Plugging in MST displays into the hub
- Turning on the machine
- Unplugging MST displays from the hub (while still in the BIOS)
- Booting into linux
- Plugging MST displays into the hub
- Everything times out, the world explodes, the economy collapses, etc.

I think maybe, especially since this should be perfectly valid behavior and not
break well or poor behaving hubs, we should do a power cycle with the display
like this when the DP port initially detects an MST hub and before we start
doing any serious communication with it. Could you see if this fixes your issue
instead of the patch you've got here?

As well, mind attaching your full dmesg with drm.debug=0x6?

On Wed, 2017-12-20 at 22:36 -0800, Dhinakaran Pandiyan wrote:
> Occasionally there are LINK_ADDRESS sideband messages timing out with the
> Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> failures lead to the display not coming up on boot. Power cycling the port
> corresponding to the MST monitor's branch device and resending the message
> fixes the issue. I am not entirely sure if this is specific to my setup.
> However, as the power state is toggled conditionally on LINK_ADDRESS
> timeouts, this should not affect the working cases.
> 
> Cc: Lyude 
> Cc: Dave Airlie 
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..e06defcdcf18 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1596,8 +1596,9 @@ static void drm_dp_send_link_address(struct
> drm_dp_mst_topology_mgr *mgr,
>   int len;
>   struct drm_dp_sideband_msg_tx *txmsg;
>   int ret;
> + int attempts = 5;
>  
> - txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> +retry:   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
>   if (!txmsg)
>   return;
>  
> @@ -1635,9 +1636,17 @@ static void drm_dp_send_link_address(struct
> drm_dp_mst_topology_mgr *mgr,
>   }
>   (*mgr->cbs->hotplug)(mgr);
>   }
> + } else if (attempts--) {
> + kfree(txmsg);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  false);
> + drm_dp_send_power_updown_phy(mstb->mgr, mstb->port_parent,
> +  true);
> + DRM_DEBUG_KMS("link address failed %d, retrying\n", ret);
> + goto retry;
>   } else {
>   mstb->link_address_sent = false;
> - DRM_DEBUG_KMS("link address failed %d\n", ret);
> + DRM_DEBUG_KMS("link address failed %d, giving up\n", ret);
>   }
>  
>   kfree(txmsg);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 892/896] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:653:33: warning: passing argument 2 of 'smu_free_memory' makes pointer from integer without a ca

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   fececd1b5c375bdddf4d510fb52d7d823678c082
commit: 222fbf72c1c90668e43d313dd84c1390d72cbf80 [892/896] drm/amd/powerplay: 
fix typo error for '3be7be08ac'
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 222fbf72c1c90668e43d313dd84c1390d72cbf80
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c: In function 
'smu7_smu_fini':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:653:33: 
>> warning: passing argument 2 of 'smu_free_memory' makes pointer from integer 
>> without a cast [-Wint-conversion]
 smu_free_memory(hwmgr->device, smu_data->header_buffer.handle);
^~~~
   In file included from 
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:26:0:
   drivers/gpu/drm/amd/amdgpu/../powerplay/inc/smumgr.h:114:12: note: expected 
'void *' but argument is of type 'long unsigned int'
extern int smu_free_memory(void *device, void *handle);
   ^~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:655:34: 
warning: passing argument 2 of 'smu_free_memory' makes pointer from integer 
without a cast [-Wint-conversion]
  smu_free_memory(hwmgr->device, smu_data->smu_buffer.handle);
 ^~~~
   In file included from 
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:26:0:
   drivers/gpu/drm/amd/amdgpu/../powerplay/inc/smumgr.h:114:12: note: expected 
'void *' but argument is of type 'long unsigned int'
extern int smu_free_memory(void *device, void *handle);
   ^~~

vim +/smu_free_memory +653 
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c

1ff55f46 Rex Zhu 2016-08-19  647  
1ff55f46 Rex Zhu 2016-08-19  648  
d3f8c0ab Rex Zhu 2017-09-20  649  int smu7_smu_fini(struct pp_hwmgr *hwmgr)
1ff55f46 Rex Zhu 2016-08-19  650  {
222fbf72 Yintian Tao 2018-01-04  651struct smu7_smumgr *smu_data = (struct 
smu7_smumgr *)(hwmgr->smu_backend);
3be7be08 Yintian Tao 2018-01-04  652  
3be7be08 Yintian Tao 2018-01-04 @653smu_free_memory(hwmgr->device, 
smu_data->header_buffer.handle);

:: The code at line 653 was first introduced by commit
:: 3be7be08acd52a9cefb6b8836aaaecd15f56abf0 drm/amd/powerplay: fix memory 
leakage when reload

:: TO: Yintian Tao 
:: CC: Gerrit Cr 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: fix semicolon.cocci warnings

[kbuild test robot]

From: Fengguang Wu 

drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:281:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 620f774f4687 ("drm/amdgpu: separate VMID and PASID handling")
CC: Christian König 
Signed-off-by: Fengguang Wu 
---

 amdgpu_ids.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -278,7 +278,7 @@ int amdgpu_vmid_grab(struct amdgpu_vm *v
else
goto no_flush_needed;
 
-   };
+   }
 
/* Still no ID to use? Then use the idle one found earlier */
id = idle;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.16-wip 1/49] drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:281:2-3: Unneeded semicolon

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.16-wip
head:   08300c1f07a3707b6a1b540f5a99ec4e2a902480
commit: 620f774f4687d86c420152309eefb0ef0fcc7e51 [1/49] drm/amdgpu: separate 
VMID and PASID handling


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:281:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/amdgpu: allow framebuffer in GART memory as well

[Alex Deucher]

On Thu, Jan 4, 2018 at 5:26 PM, Samuel Li  wrote:
>>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
>>
>> Please rename this amdgpu_display_framebuffer_domains() for consistency.
> Currently all the functions in this file are named without _display_. Am I 
> missing something?

That file is still a bit of a mess but I'm trying to make all the
files use consistent naming going forward to make the code more
readable.  The IP files (gfx, uvd, gmc, etc.) already do and I
recently cleaned up amdgpu_device.c.

>
>>> +   if (plane->type != DRM_PLANE_TYPE_CURSOR)
>>
>> Do cursors have to be in vram?  It seems like they shouldn't.
> I checked some design documentation and related implementation just now. 
> Looks like cursor is still supposed to be put in vram now.
>

Sounds good.  thanks for checking.

Alex

> Regards,
> Sam
>
>
>
> On 2018-01-04 04:18 PM, Alex Deucher wrote:
>> On Thu, Jan 4, 2018 at 4:11 PM, Samuel Li  wrote:
>>> From: Christian König 
>>>
>>> On CZ and newer APUs we can pin the fb into GART as well as VRAM.
>>>
>>> v2: Don't enable gpu_vm_support for Raven yet since it leads to
>>> a black screen. Need to debug this further before enabling.
>>>
>>> Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
>>> Signed-off-by: Christian König 
>>> Reviewed-by: Andrey Grodzovsky 
>>> Acked-by: Alex Deucher 
>>> Signed-off-by: Samuel Li 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 14 +-
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  1 +
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 ++
>>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
>>>  4 files changed, 29 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> index d704a45..d9fdc19 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> @@ -29,6 +29,7 @@
>>>  #include "amdgpu_i2c.h"
>>>  #include "atom.h"
>>>  #include "amdgpu_connectors.h"
>>> +#include "amdgpu_display.h"
>>>  #include 
>>>
>>>  #include 
>>> @@ -188,7 +189,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
>>> goto cleanup;
>>> }
>>>
>>> -   r = amdgpu_bo_pin(new_abo, AMDGPU_GEM_DOMAIN_VRAM, );
>>> +   r = amdgpu_bo_pin(new_abo, amdgpu_framebuffer_domains(adev), );
>>> if (unlikely(r != 0)) {
>>> DRM_ERROR("failed to pin new abo buffer before flip\n");
>>> goto unreserve;
>>> @@ -501,6 +502,17 @@ static const struct drm_framebuffer_funcs 
>>> amdgpu_fb_funcs = {
>>> .create_handle = amdgpu_user_framebuffer_create_handle,
>>>  };
>>>
>>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
>>
>> Please rename this amdgpu_display_framebuffer_domains() for consistency.
>>
>>> +{
>>> +   uint32_t domain = AMDGPU_GEM_DOMAIN_VRAM;
>>> +
>>> +   if (adev->asic_type >= CHIP_CARRIZO && adev->asic_type < CHIP_RAVEN 
>>> &&
>>> +   adev->flags & AMD_IS_APU)
>>> +   domain |= AMDGPU_GEM_DOMAIN_GTT;
>>> +
>>> +   return domain;
>>> +}
>>> +
>>>  int
>>>  amdgpu_framebuffer_init(struct drm_device *dev,
>>> struct amdgpu_framebuffer *rfb,
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>>> index 11ae4ab..f241949 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>>> @@ -23,6 +23,7 @@
>>>  #ifndef __AMDGPU_DISPLAY_H__
>>>  #define __AMDGPU_DISPLAY_H__
>>>
>>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev);
>>>  struct drm_framebuffer *
>>>  amdgpu_user_framebuffer_create(struct drm_device *dev,
>>>struct drm_file *file_priv,
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>> index 90fa8e8..9be3228 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>> @@ -38,6 +38,8 @@
>>>
>>>  #include 
>>>
>>> +#include "amdgpu_display.h"
>>> +
>>>  /* object hierarchy -
>>> this contains a helper + a amdgpu fb
>>> the helper contains a pointer to amdgpu framebuffer baseclass.
>>> @@ -124,7 +126,7 @@ static int amdgpufb_create_pinned_object(struct 
>>> amdgpu_fbdev *rfbdev,
>>> struct drm_gem_object *gobj = NULL;
>>> struct amdgpu_bo *abo = NULL;
>>> bool fb_tiled = false; /* useful for testing */
>>> -   u32 tiling_flags = 0;
>>> +   u32 tiling_flags = 0, domain;
>>> int ret;
>>> int aligned_size, size;
>>> int height = mode_cmd->height;
>>> @@ -135,12 +137,12 @@ static int 

Re: [PATCH 1/3] drm/amdgpu: allow framebuffer in GART memory as well

[Samuel Li]

>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
> 
> Please rename this amdgpu_display_framebuffer_domains() for consistency.
Currently all the functions in this file are named without _display_. Am I 
missing something?

>> +   if (plane->type != DRM_PLANE_TYPE_CURSOR)
> 
> Do cursors have to be in vram?  It seems like they shouldn't.
I checked some design documentation and related implementation just now. Looks 
like cursor is still supposed to be put in vram now.

Regards,
Sam



On 2018-01-04 04:18 PM, Alex Deucher wrote:
> On Thu, Jan 4, 2018 at 4:11 PM, Samuel Li  wrote:
>> From: Christian König 
>>
>> On CZ and newer APUs we can pin the fb into GART as well as VRAM.
>>
>> v2: Don't enable gpu_vm_support for Raven yet since it leads to
>> a black screen. Need to debug this further before enabling.
>>
>> Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
>> Signed-off-by: Christian König 
>> Reviewed-by: Andrey Grodzovsky 
>> Acked-by: Alex Deucher 
>> Signed-off-by: Samuel Li 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 14 +-
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  1 +
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 ++
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
>>  4 files changed, 29 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> index d704a45..d9fdc19 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> @@ -29,6 +29,7 @@
>>  #include "amdgpu_i2c.h"
>>  #include "atom.h"
>>  #include "amdgpu_connectors.h"
>> +#include "amdgpu_display.h"
>>  #include 
>>
>>  #include 
>> @@ -188,7 +189,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
>> goto cleanup;
>> }
>>
>> -   r = amdgpu_bo_pin(new_abo, AMDGPU_GEM_DOMAIN_VRAM, );
>> +   r = amdgpu_bo_pin(new_abo, amdgpu_framebuffer_domains(adev), );
>> if (unlikely(r != 0)) {
>> DRM_ERROR("failed to pin new abo buffer before flip\n");
>> goto unreserve;
>> @@ -501,6 +502,17 @@ static const struct drm_framebuffer_funcs 
>> amdgpu_fb_funcs = {
>> .create_handle = amdgpu_user_framebuffer_create_handle,
>>  };
>>
>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
> 
> Please rename this amdgpu_display_framebuffer_domains() for consistency.
> 
>> +{
>> +   uint32_t domain = AMDGPU_GEM_DOMAIN_VRAM;
>> +
>> +   if (adev->asic_type >= CHIP_CARRIZO && adev->asic_type < CHIP_RAVEN 
>> &&
>> +   adev->flags & AMD_IS_APU)
>> +   domain |= AMDGPU_GEM_DOMAIN_GTT;
>> +
>> +   return domain;
>> +}
>> +
>>  int
>>  amdgpu_framebuffer_init(struct drm_device *dev,
>> struct amdgpu_framebuffer *rfb,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>> index 11ae4ab..f241949 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
>> @@ -23,6 +23,7 @@
>>  #ifndef __AMDGPU_DISPLAY_H__
>>  #define __AMDGPU_DISPLAY_H__
>>
>> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev);
>>  struct drm_framebuffer *
>>  amdgpu_user_framebuffer_create(struct drm_device *dev,
>>struct drm_file *file_priv,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>> index 90fa8e8..9be3228 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>> @@ -38,6 +38,8 @@
>>
>>  #include 
>>
>> +#include "amdgpu_display.h"
>> +
>>  /* object hierarchy -
>> this contains a helper + a amdgpu fb
>> the helper contains a pointer to amdgpu framebuffer baseclass.
>> @@ -124,7 +126,7 @@ static int amdgpufb_create_pinned_object(struct 
>> amdgpu_fbdev *rfbdev,
>> struct drm_gem_object *gobj = NULL;
>> struct amdgpu_bo *abo = NULL;
>> bool fb_tiled = false; /* useful for testing */
>> -   u32 tiling_flags = 0;
>> +   u32 tiling_flags = 0, domain;
>> int ret;
>> int aligned_size, size;
>> int height = mode_cmd->height;
>> @@ -135,12 +137,12 @@ static int amdgpufb_create_pinned_object(struct 
>> amdgpu_fbdev *rfbdev,
>> /* need to align pitch with crtc limits */
>> mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
>>   fb_tiled);
>> +   domain = amdgpu_framebuffer_domains(adev);
>>
>> height = ALIGN(mode_cmd->height, 8);
>> size = mode_cmd->pitches[0] * height;
>> aligned_size = ALIGN(size, PAGE_SIZE);
>> -   

[PATCH 1/3] drm/amdgpu: allow framebuffer in GART memory as well

[Samuel Li]

From: Christian König 

On CZ and newer APUs we can pin the fb into GART as well as VRAM.

v2: Don't enable gpu_vm_support for Raven yet since it leads to
a black screen. Need to debug this further before enabling.

Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
Signed-off-by: Christian König 
Reviewed-by: Andrey Grodzovsky 
Acked-by: Alex Deucher 
Signed-off-by: Samuel Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
 4 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d704a45..d9fdc19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -29,6 +29,7 @@
 #include "amdgpu_i2c.h"
 #include "atom.h"
 #include "amdgpu_connectors.h"
+#include "amdgpu_display.h"
 #include 
 
 #include 
@@ -188,7 +189,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
goto cleanup;
}
 
-   r = amdgpu_bo_pin(new_abo, AMDGPU_GEM_DOMAIN_VRAM, );
+   r = amdgpu_bo_pin(new_abo, amdgpu_framebuffer_domains(adev), );
if (unlikely(r != 0)) {
DRM_ERROR("failed to pin new abo buffer before flip\n");
goto unreserve;
@@ -501,6 +502,17 @@ static const struct drm_framebuffer_funcs amdgpu_fb_funcs 
= {
.create_handle = amdgpu_user_framebuffer_create_handle,
 };
 
+uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)
+{
+   uint32_t domain = AMDGPU_GEM_DOMAIN_VRAM;
+
+   if (adev->asic_type >= CHIP_CARRIZO && adev->asic_type < CHIP_RAVEN &&
+   adev->flags & AMD_IS_APU)
+   domain |= AMDGPU_GEM_DOMAIN_GTT;
+
+   return domain;
+}
+
 int
 amdgpu_framebuffer_init(struct drm_device *dev,
struct amdgpu_framebuffer *rfb,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
index 11ae4ab..f241949 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
@@ -23,6 +23,7 @@
 #ifndef __AMDGPU_DISPLAY_H__
 #define __AMDGPU_DISPLAY_H__
 
+uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev);
 struct drm_framebuffer *
 amdgpu_user_framebuffer_create(struct drm_device *dev,
   struct drm_file *file_priv,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 90fa8e8..9be3228 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -38,6 +38,8 @@
 
 #include 
 
+#include "amdgpu_display.h"
+
 /* object hierarchy -
this contains a helper + a amdgpu fb
the helper contains a pointer to amdgpu framebuffer baseclass.
@@ -124,7 +126,7 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
struct drm_gem_object *gobj = NULL;
struct amdgpu_bo *abo = NULL;
bool fb_tiled = false; /* useful for testing */
-   u32 tiling_flags = 0;
+   u32 tiling_flags = 0, domain;
int ret;
int aligned_size, size;
int height = mode_cmd->height;
@@ -135,12 +137,12 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
/* need to align pitch with crtc limits */
mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
  fb_tiled);
+   domain = amdgpu_framebuffer_domains(adev);
 
height = ALIGN(mode_cmd->height, 8);
size = mode_cmd->pitches[0] * height;
aligned_size = ALIGN(size, PAGE_SIZE);
-   ret = amdgpu_gem_object_create(adev, aligned_size, 0,
-  AMDGPU_GEM_DOMAIN_VRAM,
+   ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain,
   AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED |
   AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS |
   AMDGPU_GEM_CREATE_VRAM_CLEARED,
@@ -166,7 +168,7 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
}
 
 
-   ret = amdgpu_bo_pin(abo, AMDGPU_GEM_DOMAIN_VRAM, NULL);
+   ret = amdgpu_bo_pin(abo, domain, NULL);
if (ret) {
amdgpu_bo_unreserve(abo);
goto out_unref;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a3bf021..9b05abd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2982,11 +2982,13 @@ static int 

[PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse

[Samuel Li]

Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
Signed-off-by: Samuel Li 
---
 drivers/gpu/drm/drm_prime.c | 53 ++---
 include/drm/drm_prime.h | 22 +++
 2 files changed, 53 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 8de93a2..68a69e9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct 
drm_prime_file_private *prime_fpri
return -ENOENT;
 }
 
-static int drm_gem_map_attach(struct dma_buf *dma_buf,
- struct device *target_dev,
- struct dma_buf_attachment *attach)
+int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
+  struct dma_buf_attachment *attach)
 {
struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
@@ -200,9 +199,10 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
 
return dev->driver->gem_prime_pin(obj);
 }
+EXPORT_SYMBOL(drm_gem_map_attach);
 
-static void drm_gem_map_detach(struct dma_buf *dma_buf,
-  struct dma_buf_attachment *attach)
+void drm_gem_map_detach(struct dma_buf *dma_buf,
+   struct dma_buf_attachment *attach)
 {
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
@@ -227,6 +227,7 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf,
kfree(prime_attach);
attach->priv = NULL;
 }
+EXPORT_SYMBOL(drm_gem_map_detach);
 
 void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private 
*prime_fpriv,
struct dma_buf *dma_buf)
@@ -253,8 +254,8 @@ void drm_prime_remove_buf_handle_locked(struct 
drm_prime_file_private *prime_fpr
}
 }
 
-static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
-   enum dma_data_direction dir)
+struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir)
 {
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
@@ -289,13 +290,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 
return sgt;
 }
+EXPORT_SYMBOL(drm_gem_map_dma_buf);
 
-static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
- struct sg_table *sgt,
- enum dma_data_direction dir)
+void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+  struct sg_table *sgt,
+  enum dma_data_direction dir)
 {
/* nothing to be done here */
 }
+EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
 
 /**
  * drm_gem_dmabuf_export - dma_buf export implementation for GEM
@@ -346,47 +349,52 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);
 
-static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
+void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
return dev->driver->gem_prime_vmap(obj);
 }
+EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
 
-static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
+void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
 {
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
dev->driver->gem_prime_vunmap(obj, vaddr);
 }
+EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
-static void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
-   unsigned long page_num)
+void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
+unsigned long page_num)
 {
return NULL;
 }
+EXPORT_SYMBOL(drm_gem_dmabuf_kmap_atomic);
 
-static void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
-unsigned long page_num, void *addr)
+void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
+ unsigned long page_num, void *addr)
 {
 
 }
-static void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf,
-unsigned long page_num)
+EXPORT_SYMBOL(drm_gem_dmabuf_kunmap_atomic);
+
+void *drm_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
 {
return NULL;
 }
+EXPORT_SYMBOL(drm_gem_dmabuf_kmap);
 
-static void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
+void drm_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long page_num,
+  void *addr)
 {
 
 }

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

--- Comment #4 from florian.w...@googlemail.com ---
Maybe the bug is in compiler/glsl/lower_buffer_access.cpp?
https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/lower_buffer_access.cpp?id=396c006d907b023f9b187db618ee2a6e4e1b8a85#n51

I'm not sure about the control flow for radeonsi, but if that pass is used in
my setup, and this emit_access() code is used to break down struct derefs into
multiple scalar/array/vec derefs, then it seems like the check for packing ==
GLSL_INTERFACE_STD430 is missing in lines 77/78 and 85, and the std140 layout
is assumed instead. I think that might explain the observed incorrect
behaviour.

In that same file, the check for std430 was added in a few places, like in line
338.

I'd love to give this a try and add checks to use std430_base_alignment() and
std430_size() if appropriate, but I'm not really prepared to compile Mesa
myself right now.

So, if someone who knows this code feels like my suggested change is correct
and required, I'd be more than happy if they could take care of this. Otherwise
I might give it a try myself in some time.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH v4 1/3] Add meson build system

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-04 at 10:28 -0800, Dylan Baker wrote:
> This patch adds a complete meson build system, including tests and
> install. It has the necessary hooks to allow it be used as a subproject
> for other meson based builds such as mesa.

Builds fine on all architectures supported by Fedora, boots fine on my laptop
(x86_64).

All nitpicks are inline.

> Signed-off-by: Dylan Baker 

Reviewed-and-tested-by: Igor Gnatenko 

> diff --git a/meson_options.txt b/meson_options.txt
> new file mode 100644
> index 000..08c2ccd
> --- /dev/null
> +++ b/meson_options.txt
> @@ -0,0 +1,143 @@
> [...]
> +option(
> +  'intel',
> +  type : 'combo',
> +  value : 'auto',
> +  choices : ['true', 'false', 'auto'],
> +  description : '''Enable support for Intel's KMS API.''',

Any reason to use `'''` here and there?

> [...]
> +option(
> +  'man-pages',
> +  type : 'combo',
> +  value : 'auto',
> +  choices : ['true', 'false', 'auto'],
> +  description : 'Enable manpage generation and install.',

"installation".

> [...]
> +option(
> +  'valgrind',
> +  type : 'combo',
> +  value : 'auto',
> +  choices : ['true', 'false', 'auto'],
> +  description : 'build libdrm with valgrind support',

"Build". And fullstop at the end of sentence.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpOoBcACgkQaVcUvRu8
X0yF9w//cgaMVkU4xTKegRJY4uuzTE3MQvMmaCoA8ivBaCWPuoX3ozlwsAgZZXaZ
Vo83tZ0u80cjgoSG4I/JcNp3UhsxtGgqcrqqcof/SGn+YS43eFKPL57dowwQ5qk3
ccAUgHtAdQXuCJFaQFsTISSEj1X07RA04mIMe7QZFh7AHsKmv+ctaTUO7uJsXJzi
aX7Z9rntTCnXvzZy7Y56XPCleXfi+yDzQPdDopZAEdLYT8hYUvebo6JGQUpg8iNd
YuvZsbkrpyV1uMY/2feSJ3Ns4ZTAj3I4F41Xbb7CqZt/BX60EnkZJXog4RSbdlri
cxMX7gPkrOXxNJbllmdN0nPdBP/atViRY7dDkE4Lv4YrmwL8oT4Mjfyb/TeINT2X
6NltSgc8+zSvQSkjWyKHzQ3ZQCQHIAheG+V2Cvnc1NIfX06AV9USRsSRzBMza+gW
cWNT2g/M0jjmLTVEoLR8MSLXAB9gfsBdRDEnvqEsZCqDh1idW1Ttuk3m/h3+BT8i
GMyCrswVgKLI7gBbdVFdLDarEIVtTJlYvPkGXxRyOzv1r5dM/MMmeay7P3WD+liE
CLF9nRVrekQA7Mh4Y61RSyFAntzBokNKL+FrSzSuseNtgYAM3Es0JgY1ndsczvVX
zUqULC0AEAEwmAIQmDlYFG+ut8nIvmk6aWHHlvLwUHgiDD+MEc4=
=dAKV
-END PGP SIGNATURE-

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.

[Samuel Li]

To improve cpu read performance. This is implemented for APUs currently.

v2: Adapt to change 
https://lists.freedesktop.org/archives/amd-gfx/2017-October/015174.html
v3: Adapt to change "forward begin_cpu_access callback to drivers"
v4: Instead of v3, reuse drm_gem dmabuf_ops here. Also some minor fixes as 
suggested.

Change-Id: I7a583e23a9ee706e0edd2a46f4e4186a609368e3

Signed-off-by: Samuel Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 67 +++
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f8657c3..193db70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -417,6 +417,8 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags);
+struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
 int amdgpu_gem_prime_pin(struct drm_gem_object *obj);
 void amdgpu_gem_prime_unpin(struct drm_gem_object *obj);
 struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 31383e0..df30b08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -868,7 +868,7 @@ static struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = amdgpu_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_pin = amdgpu_gem_prime_pin,
.gem_prime_unpin = amdgpu_gem_prime_unpin,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index ae9c106..283b523 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "amdgpu.h"
+#include "amdgpu_display.h"
 #include 
 #include 
 
@@ -164,6 +165,50 @@ struct reservation_object *amdgpu_gem_prime_res_obj(struct 
drm_gem_object *obj)
return bo->tbo.resv;
 }
 
+static int amdgpu_gem_begin_cpu_access(struct dma_buf *dma_buf,
+  enum dma_data_direction direction)
+{
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(dma_buf->priv);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct ttm_operation_ctx ctx = { true, false };
+   u32 domain = amdgpu_framebuffer_domains(adev);
+   int ret = 0;
+   bool reads = (direction == DMA_BIDIRECTIONAL ||
+ direction == DMA_FROM_DEVICE);
+
+   if (!reads || !(domain & AMDGPU_GEM_DOMAIN_GTT))
+   return 0;
+
+   /* move to gtt */
+   ret = amdgpu_bo_reserve(bo, false);
+   if (unlikely(ret != 0))
+   return ret;
+
+   if (!bo->pin_count && (bo->allowed_domains & AMDGPU_GEM_DOMAIN_GTT)) {
+   amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+   ret = ttm_bo_validate(>tbo, >placement, );
+   }
+
+   amdgpu_bo_unreserve(bo);
+   return ret;
+}
+
+static const struct dma_buf_ops amdgpu_dmabuf_ops = {
+   .attach = drm_gem_map_attach,
+   .detach = drm_gem_map_detach,
+   .map_dma_buf = drm_gem_map_dma_buf,
+   .unmap_dma_buf = drm_gem_unmap_dma_buf,
+   .release = drm_gem_dmabuf_release,
+   .begin_cpu_access = amdgpu_gem_begin_cpu_access,
+   .map = drm_gem_dmabuf_kmap,
+   .map_atomic = drm_gem_dmabuf_kmap_atomic,
+   .unmap = drm_gem_dmabuf_kunmap,
+   .unmap_atomic = drm_gem_dmabuf_kunmap_atomic,
+   .mmap = drm_gem_dmabuf_mmap,
+   .vmap = drm_gem_dmabuf_vmap,
+   .vunmap = drm_gem_dmabuf_vunmap,
+};
+
 struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags)
@@ -178,5 +223,27 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
buf = drm_gem_prime_export(dev, gobj, flags);
if (!IS_ERR(buf))
buf->file->f_mapping = dev->anon_inode->i_mapping;
+   buf->ops = _dmabuf_ops;
+
return buf;
 }
+
+struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf)
+{
+   struct drm_gem_object *obj;
+
+   if (dma_buf->ops == _dmabuf_ops) {
+   obj = 

Re: [PATCH 1/3] drm/amdgpu: allow framebuffer in GART memory as well

[Alex Deucher]

On Thu, Jan 4, 2018 at 4:11 PM, Samuel Li  wrote:
> From: Christian König 
>
> On CZ and newer APUs we can pin the fb into GART as well as VRAM.
>
> v2: Don't enable gpu_vm_support for Raven yet since it leads to
> a black screen. Need to debug this further before enabling.
>
> Change-Id: Id0f8af3110e54a3aabf7a258871867bc121cc1a2
> Signed-off-by: Christian König 
> Reviewed-by: Andrey Grodzovsky 
> Acked-by: Alex Deucher 
> Signed-off-by: Samuel Li 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 14 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.h   |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 10 ++
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
>  4 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index d704a45..d9fdc19 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -29,6 +29,7 @@
>  #include "amdgpu_i2c.h"
>  #include "atom.h"
>  #include "amdgpu_connectors.h"
> +#include "amdgpu_display.h"
>  #include 
>
>  #include 
> @@ -188,7 +189,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
> goto cleanup;
> }
>
> -   r = amdgpu_bo_pin(new_abo, AMDGPU_GEM_DOMAIN_VRAM, );
> +   r = amdgpu_bo_pin(new_abo, amdgpu_framebuffer_domains(adev), );
> if (unlikely(r != 0)) {
> DRM_ERROR("failed to pin new abo buffer before flip\n");
> goto unreserve;
> @@ -501,6 +502,17 @@ static const struct drm_framebuffer_funcs 
> amdgpu_fb_funcs = {
> .create_handle = amdgpu_user_framebuffer_create_handle,
>  };
>
> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev)

Please rename this amdgpu_display_framebuffer_domains() for consistency.

> +{
> +   uint32_t domain = AMDGPU_GEM_DOMAIN_VRAM;
> +
> +   if (adev->asic_type >= CHIP_CARRIZO && adev->asic_type < CHIP_RAVEN &&
> +   adev->flags & AMD_IS_APU)
> +   domain |= AMDGPU_GEM_DOMAIN_GTT;
> +
> +   return domain;
> +}
> +
>  int
>  amdgpu_framebuffer_init(struct drm_device *dev,
> struct amdgpu_framebuffer *rfb,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
> index 11ae4ab..f241949 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.h
> @@ -23,6 +23,7 @@
>  #ifndef __AMDGPU_DISPLAY_H__
>  #define __AMDGPU_DISPLAY_H__
>
> +uint32_t amdgpu_framebuffer_domains(struct amdgpu_device *adev);
>  struct drm_framebuffer *
>  amdgpu_user_framebuffer_create(struct drm_device *dev,
>struct drm_file *file_priv,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 90fa8e8..9be3228 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -38,6 +38,8 @@
>
>  #include 
>
> +#include "amdgpu_display.h"
> +
>  /* object hierarchy -
> this contains a helper + a amdgpu fb
> the helper contains a pointer to amdgpu framebuffer baseclass.
> @@ -124,7 +126,7 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
> struct drm_gem_object *gobj = NULL;
> struct amdgpu_bo *abo = NULL;
> bool fb_tiled = false; /* useful for testing */
> -   u32 tiling_flags = 0;
> +   u32 tiling_flags = 0, domain;
> int ret;
> int aligned_size, size;
> int height = mode_cmd->height;
> @@ -135,12 +137,12 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
> /* need to align pitch with crtc limits */
> mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
>   fb_tiled);
> +   domain = amdgpu_framebuffer_domains(adev);
>
> height = ALIGN(mode_cmd->height, 8);
> size = mode_cmd->pitches[0] * height;
> aligned_size = ALIGN(size, PAGE_SIZE);
> -   ret = amdgpu_gem_object_create(adev, aligned_size, 0,
> -  AMDGPU_GEM_DOMAIN_VRAM,
> +   ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain,
>AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED |
>AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS |
>AMDGPU_GEM_CREATE_VRAM_CLEARED,
> @@ -166,7 +168,7 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
> }
>
>
> -   ret = amdgpu_bo_pin(abo, AMDGPU_GEM_DOMAIN_VRAM, NULL);
> +   ret = amdgpu_bo_pin(abo, domain, NULL);
> if (ret) {
>   

[Bug 104497] radeon driver hangs : nothing else that static effect on display

[bugzilla-daemon]

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

Bug ID: 104497
   Summary: radeon driver hangs : nothing else that static effect
on display
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mago...@gmail.com

using latest mainline kernel I get static effect on display and no more (no
login manager)

Mine distro is ubuntu 17.10 but I'm facing the same issue also with mainline
kernel 4.15-rc6

from dmesg I can see, regarding drm:
$dmesg | grep drm
[2.659838] [drm] radeon kernel modesetting enabled.
[2.659890] fb: switching to radeondrmfb from VESA VGA
[2.661023] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9645
0x1043:0x84C8 0x00).
[2.661163] [drm] Detected VRAM RAM=512M, BAR=256M
[2.661164] [drm] RAM width 32bits DDR
[2.661454] [drm] radeon: 512M of VRAM memory ready
[2.661456] [drm] radeon: 1024M of GTT memory ready.
[2.661464] [drm] Loading SUMO2 Microcode
[2.661632] [drm] Internal thermal controller without fan control
[2.661678] [drm] Found smc ucode version: 0x00011200
[2.661834] [drm] radeon: dpm initialized
[2.662006] [drm] GART: num cpu pages 262144, num gpu pages 262144
[2.675003] [drm] PCIE GART of 1024M enabled (table at 0x00162000).
[2.675525] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.675525] [drm] Driver supports precise vblank timestamp query.
[2.675603] [drm] radeon: irq initialized.
[2.692149] [drm] ring test on 0 succeeded in 1 usecs
[2.692156] [drm] ring test on 3 succeeded in 3 usecs
[2.737845] [drm] ring test on 5 succeeded in 1 usecs
[2.757699] [drm] UVD initialized successfully.
[2.758193] [drm] ib test on ring 0 succeeded in 0 usecs
[2.758242] [drm] ib test on ring 3 succeeded in 0 usecs
[3.292477] [drm] ib test on ring 5 succeeded
[3.313397] [drm] Radeon Display Connectors
[3.313399] [drm] Connector 0:
[3.313399] [drm]   VGA-1
[3.313400] [drm]   HPD2
[3.313401] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c
0x644c
[3.313402] [drm]   Encoders:
[3.313402] [drm] CRT1: INTERNAL_UNIPHY2
[3.313403] [drm] CRT1: NUTMEG
[3.313403] [drm] Connector 1:
[3.313404] [drm]   DVI-D-1
[3.313404] [drm]   HPD1
[3.313406] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[3.313406] [drm]   Encoders:
[3.313406] [drm] DFP1: INTERNAL_UNIPHY2
[3.449737] [drm] fb mappable at 0xC0366000
[3.449738] [drm] vram apper at 0xC000
[3.449739] [drm] size 7299072
[3.449740] [drm] fb depth is 24
[3.449740] [drm]pitch is 6912
[3.449991] fbcon: radeondrmfb (fb0) is primary device
[3.527792] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[3.540468] [drm] Initialized radeon 2.50.0 20080528 for :00:01.0 on
minor 0
[   80.040354] [drm] Found smc ucode version: 0x00011200
[   80.047133] [drm] PCIE GART of 1024M enabled (table at 0x00162000).
[   80.063677] [drm] ring test on 0 succeeded in 1 usecs
[   80.063683] [drm] ring test on 3 succeeded in 3 usecs
[   80.109426] [drm] ring test on 5 succeeded in 1 usecs
[   80.129306] [drm] UVD initialized successfully.
[   81.208320] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed
out.
[   81.208392] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
testing IB on GFX ring (-110).

This bug existed since older versions, I tried also mainline 4.8 

Here you can see mine vga: 
lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Sumo
[Radeon HD 6410D]

that actually is "AMD - A4-3300 Llano" an APU.  

I'm at your disposal in case you need further information.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

[Laurent Pinchart]

Hi Maxime,

On Thursday, 4 January 2018 21:44:36 EET Maxime Ripard wrote:
> On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote:
> > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote:
> >> The power-supply property is used by a vast majority of panels,
> >> including panel-simple. Let's document it as a common property
> >> 
> >> Reviewed-by: Rob Herring 
> >> Signed-off-by: Maxime Ripard 
> >> ---
> >> 
> >> Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 
> >> Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
> >> Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
> >> 3 files changed, 8 insertions(+), 1 deletion(-)
> >> 
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> >> ec52c472c845..125ea68052af 100644
> >> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> @@ -78,6 +78,12 @@ used for panels that implement compatible control
> >> signals. while active. Active high reset signals can be supported by
> >> inverting the GPIO specifier polarity flag.
> >> 
> >> +Power
> >> +-
> >> +
> >> +- power-supply: many display panels need an additional power supply in
> >> +  order to be fully powered-up. For such panels, power-supply contains
> >> +  a phandle to the regulator powering the panel.
> > 
> > I think we should give more details here about the limitations of this
> > property. How about the following explanation ?
> > 
> > - power-supply: display panels require power to be supplied. While several
> > panels need more than one power supply with panel-specific constraints
> > governing the order and timings of the power supplies, in many cases a
> > single power supply is sufficient, either because the panel has a single
> > power rail, or because all its power rails can be driven by the same
> > supply. In that case the power-supply property specifies the supply
> > powering the panel as a phandle to a regulator.
> 
> That works for me. Do you want me to resend it with that text, or
> should I merge it (and if so, with your Reviewed-by or Acked-by?)?

No need to resend if it's just for me. With the above text,

Acked-by: Laurent Pinchart 

(on a side note, I wonder if it's more efficient to ask whether to resend 
instead of just resending :-))

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

[Maxime Ripard]

Hi,

On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
> We should check if the best match has been set before comparing it.
> 
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> index dc332ea56f6c..4d235e5ea31c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>   goto out;
>   }
>  
> - if (abs(rate - rounded / i) <
> + if (!best_parent || abs(rate - rounded / i) <

Why is that causing any issue?

If best_parent is set to 0...

>   abs(rate - best_parent / best_div)) {

... the value returned here is going to be rate, which is going to be
higher than the first part of the comparison meaning ...

>   best_parent = rounded;

... that best_parent is going to be set there.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

[Maxime Ripard]

Hi Laurent,

On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote:
> > The power-supply property is used by a vast majority of panels, including
> > panel-simple. Let's document it as a common property
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
> > Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
> > Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- 3
> > files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> > ec52c472c845..125ea68052af 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > @@ -78,6 +78,12 @@ used for panels that implement compatible control
> > signals. while active. Active high reset signals can be supported by
> > inverting the GPIO specifier polarity flag.
> > 
> > +Power
> > +-
> > +
> > +- power-supply: many display panels need an additional power supply in
> > +  order to be fully powered-up. For such panels, power-supply contains
> > +  a phandle to the regulator powering the panel.
> 
> I think we should give more details here about the limitations of this 
> property. How about the following explanation ?
> 
> - power-supply: display panels require power to be supplied. While several 
> panels need more than one power supply with panel-specific constraints 
> governing the order and timings of the power supplies, in many cases a single 
> power supply is sufficient, either because the panel has a single power rail, 
> or because all its power rails can be driven by the same supply. In that case 
> the power-supply property specifies the supply powering the panel as a 
> phandle 
> to a regulator.

That works for me. Do you want me to resend it with that text, or
should I merge it (and if so, with your Reviewed-by or Acked-by?)?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties

[Maxime Ripard]

Hi,

On Sat, Dec 30, 2017 at 12:45:19PM +0100, Jernej Škrabec wrote:
> Hi Maxime,
> 
> Dne četrtek, 21. december 2017 ob 12:02:29 CET je Maxime Ripard napisal(a):
> > Some clocks and resets supposed to drive the LVDS logic in the display
> > engine have been overlooked when the driver was first introduced.
> > 
> > Add those additional resources to the binding, and we'll deal with the ABI
> > stability in the code.
> > 
> > Reviewed-by: Chen-Yu Tsai 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt |  9 +++-
> > 1 file changed, 9 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 50cc72ee1168..1e21cfaac9e2 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -121,6 +121,15 @@ Required properties:
> >  On SoCs other than the A33 and V3s, there is one more clock required:
> > - 'tcon-ch1': The clock driving the TCON channel 1
> > 
> > +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
> > +need one more reset line:
> > +   - 'lvds': The reset line driving the LVDS logic
> > +
> > +And on the SoCs newer than the A31 (sun6i and sun8i families), you
> > +need one more clock line:
> > +   - 'lvds-alt': An alternative clock source, separate from the TCON
> > channel 0 + clock, that can be used to drive the LVDS clock
> 
> I think this wording is imprecise, since A83T is part of the sun8i family, 
> but 
> from the code (patch 7) and DT changes (patch 9) you do, it doesn't need this 
> property.
> 
> Maybe it would be just easier to enumerate all compatibles which needs this 
> property? 

You're right, but the rest of the document uses the SoC name
instead. In order to remain consistent, I listed the (currently
supported) SoCs that need that property and applied that patch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

[Maxime Ripard]

On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej Škrabec wrote:
> Hi Rob,
> 
> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
> > > This commit adds all necessary compatibles and descriptions needed to
> > > implement A83T HDMI pipeline.
> > > 
> > > Mixer is already properly described, so only compatible is added.
> > > 
> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,
> > > contrary to all TCONs currently described. Because of that, TCON
> > > documentation is extended.
> > > 
> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks
> > > like Synopsys Gen2 PHY with few additions. Since there is no
> > > documentation, needed properties were found out through experimentation
> > > and reading BSP code.
> > > 
> > > At the end, example is added for newer SoCs, which features DE2 and DW
> > > HDMI.
> > > 
> > > Signed-off-by: Jernej Skrabec 
> > > ---
> > > 
> > >  .../bindings/display/sunxi/sun4i-drm.txt   | 188
> > >  - 1 file changed, 181 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > 9f073af4c711..3eca258096a5 100644
> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > 
> > > @@ -64,6 +64,40 @@ Required properties:
> > >  first port should be the input endpoint. The second should be the
> > >  output, usually to an HDMI connector.
> > > 
> > > +DWC HDMI TX Encoder
> > > +-
> > > +
> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> > > +
> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> > > +following device-specific properties.
> > > +
> > > +Required properties:
> > > +
> > > +  - compatible: value must be one of:
> > > +* "allwinner,sun8i-a83t-dw-hdmi"
> > > +  - reg: two pairs of base address and size of memory-mapped region,
> > > first
> > > +for controller and second for PHY
> > > +registers.
> > 
> > Seems like the phy should be a separate node and use the phy binding.
> > You can use the phy binding even if you don't use the kernel phy
> > framework...
> 
> Unfortunately, it's not so straighforward. Phy is actually accessed through 
> I2C implemented in HDMI controller. Second memory region in this case has 
> small influence on phy. However, it has big influence on controller. For 
> example, magic number has to be written in one register in second memory 
> region in order to unlock read access to any register from first memory 
> region 
> (controller). However, they shouldn't be merged to one region, because first 
> memory region requires byte access while second memory region can be accessed 
> per byte or word.
> 
> To complicate things more, later I want to add support for another SoC which 
> has same glue layer (unlocking read access, etc.) and uses memory mapped phy 
> registers in second memory region.
> 
> I think current binding is the least complicated way to represent this.

I agree with Rob here. I did a similar thing for the DSI patches I've
sent a few monthes ago and it turned out to not be that difficult, so
I'm sure you can come up with something :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

florian.w...@googlemail.com changed:

   What|Removed |Added

Version|17.2|git

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

--- Comment #3 from florian.w...@googlemail.com ---
Hi Ilia,

unfortunately updating to 17.4~git1801031930.ad2187~oibaf~a  (apparently a Jan
3 commit) did not fix this test case. I'll downgrade again because that package
breaks renderdoc and the gnome login screen (wayland-based) on my system,
probably packaging-related.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/3] README: Add note about meson

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 README | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 26cab9d..58e55bc 100644
--- a/README
+++ b/README
@@ -15,9 +15,24 @@ with an older kernel.
 Compiling
 -
 
-libdrm  is  a  standard  autotools  package and  follows  the  normal
-configure, build  and install steps.   The first step is  to configure
-the package, which is done by running the configure shell script:
+libdrm has two build systems, a legacy autotools build system, and a newer
+meson build system. The meson build system is much faster, and offers a 
+slightly different interface, but otherwise provides much the same 
+feature set.
+
+To use it:
+
+meson builddir
+
+By default this will install into /usr/local, you can change your prefix
+with --prefix=/usr (or -Dprefix=/usr to meson configure).
+
+Then use ninja to build and install:
+
+ninja -C builddir install
+
+
+Alternatively you can invoke autotools configure:
 
./configure
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] Add meson build system

[Dylan Baker]

This patch adds a complete meson build system, including tests and
install. It has the necessary hooks to allow it be used as a subproject
for other meson based builds such as mesa.

v4: - fix freedreno kgls check

Signed-off-by: Dylan Baker 
---
 .editorconfig   |   4 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 376 +-
 meson_options.txt   | 143 ++-
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  86 -
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 31 files changed, 1892 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/.editorconfig b/.editorconfig
index 893b7be..bbad3e6 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
 [*.m4]
 indent_style = space
 indent_size = 2
+
+[meson.build,meson_options.txt]
+indent_style = space
+indent_size = 2
diff --git a/amdgpu/.editorconfig b/amdgpu/.editorconfig
index 2528d67..0c758d6 100644
--- a/amdgpu/.editorconfig
+++ b/amdgpu/.editorconfig
@@ -7,3 +7,8 @@ indent_style = tab
 indent_size = 8
 tab_width = 8
 insert_final_newline = true
+
+[meson.build]
+indent_style = space
+indent_size = 2
+insert_final_newline = false
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index 000..13bf88b
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,70 @@
+# Copyright © 2017 Intel Corporation
+
+# 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 FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+files_amdgpu = files(
+  'amdgpu_asic_id.c',
+  'amdgpu_bo.c',
+  'amdgpu_cs.c',
+  'amdgpu_device.c',
+  'amdgpu_gpu_info.c',
+  'amdgpu_internal.h',
+  'amdgpu_vamgr.c',
+  'amdgpu_vm.c',
+  'util_hash.c',
+  'util_hash.h',
+  'util_hash_table.c',
+  'util_hash_table.h',
+)
+
+libdrm_amdgpu = 

[PATCH v4 0/3] Meson build system

[Dylan Baker]

This is a third iteration of the meson build system for libdrm. This
version is significantly cleaned up from the last version and uses a
style more like the build system in mesa.

It builds all of the drivers and tests, and the tests can be run via
`ninja test`.

It has support for being used as a wrapped dependency wit ext_foo
variables. This means it can be used to build a mesa that requires a
newer libdrm than the system provides (which can be especially useful if
you can't install packages on that system) and for testing.

This has been build tested and mesa has been compiled against it, but
not functional testing has been done.

Changes since v3:
  - Fix freedreno kgsl check
  - Fix kgls -> kgsl typo
  - standardize meson options to use only `-` and not `_`
  - fix typo radoen -> radeon
  - add help messages to options
  - fix typo in kms-universal-planes binary
  - build and install modetest (this was missed in the first version for
some reason)
  - install amdgpu.ids as 644 instead of 444

Dylan Baker (3):
  Add meson build system
  autotools: Include meson.build files in tarball
  README: Add note about meson

 .editorconfig   |   4 +-
 Makefile.am |  30 ++-
 README  |  21 +-
 amdgpu/.editorconfig|   5 +-
 amdgpu/meson.build  |  70 +++-
 data/meson.build|  27 +++-
 etnaviv/meson.build |  64 ++-
 exynos/meson.build  |  53 +-
 freedreno/meson.build   |  82 -
 intel/meson.build   | 111 +++-
 libkms/meson.build  |  75 +++-
 man/meson.build |  66 ++-
 meson.build | 376 +-
 meson_options.txt   | 143 ++-
 nouveau/meson.build |  65 ++-
 omap/meson.build|  53 +-
 radeon/meson.build  |  65 ++-
 tegra/meson.build   |  52 +-
 tests/amdgpu/meson.build|  40 -
 tests/etnaviv/meson.build   |  54 +-
 tests/exynos/meson.build|  54 +-
 tests/kms/meson.build   |  54 +-
 tests/kmstest/meson.build   |  28 +++-
 tests/meson.build   |  86 -
 tests/modeprint/meson.build |  29 +++-
 tests/modetest/meson.build  |  29 +++-
 tests/nouveau/meson.build   |  30 +++-
 tests/proptest/meson.build  |  30 +++-
 tests/radeon/meson.build|  27 +++-
 tests/tegra/meson.build |  27 +++-
 tests/util/meson.build  |  37 -
 tests/vbltest/meson.build   |  28 +++-
 vc4/meson.build |  28 +++-
 33 files changed, 1939 insertions(+), 4 deletions(-)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/modetest/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

base-commit: 831036a6f62005da9fb4a75fe043bd96ce672d27
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/3] autotools: Include meson.build files in tarball

[Dylan Baker]

Signed-off-by: Dylan Baker 
---
 Makefile.am | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b86214..66f70ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -135,7 +135,35 @@ if HAVE_VMWGFX
 klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
 endif
 
-EXTRA_DIST = include/drm/README
+EXTRA_DIST = \
+   include/drm/README \
+   amdgpu/meson.build \
+   etnaviv/meson.build \
+   exynos/meson.build \
+   freedreno/meson.build \
+   intel/meson.build \
+   libkms/meson.build \
+   man/meson.build \
+   nouveau/meson.build \
+   omap/meson.build \
+   radeon/meson.build \
+   tests/amdgpu/meson.build \
+   tests/etnaviv/meson.build \
+   tests/exynos/meson.build \
+   tests/kms/meson.build \
+   tests/kmstest/meson.build \
+   tests/modeprint/meson.build \
+   tests/nouveau/meson.build \
+   tests/proptest/meson.build \
+   tests/radeon/meson.build \
+   tests/tegra/meson.build \
+   tests/util/meson.build \
+   tests/vbltest/meson.build \
+   tests/meson.build \
+   vc4/meson.build \
+   data/meson.build \
+   meson.build \
+   meson_options.txt
 
 copy-headers :
cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #3 from Francesco Turco  ---
I can reproduce this bug by checking out tag v4.14 from linux-stable. It
includes the commit you mentioned.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [0/4] video-UDLFB: Adjustments for five function implementations

[SF Markus Elfring]

>> * Do you find a Linux allocation failure report insufficient in this use 
>> case?
> 
> Yes,

Interesting …


> there is more information available currently in the driver and
> I see no real improvement in removing it.
> 
>> * Are you looking for any more clarification?
> 
> I will not apply any of such patches for now. The only exception
> being drivers that support hardware that can have only one instance
> in the system …

Thanks for your feedback.


> and the patch needs to be reviewed by a someone else than the author).

I am curious if this will ever happen again for my update suggestions
in such a software area.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwcomposer PATCH] Take Connection state into account. (v2)

[Rob Herring]

On Wed, Jan 3, 2018 at 6:40 AM, Mauro Rossi  wrote:
>
>
> 2018-01-03 12:16 GMT+01:00 Robert Foss :
>>
>> Hey Mauro,
>>
>> Thanks for the patch! It builds and looks good to me, but I have some
>> suggestions however.
>>
>>
>> On Wed, 2018-01-03 at 11:10 +0100, Mauro Rossi wrote:
>> > These changes avoid following logcat error on integrated and
>> > dedicated GPUs:
>> >
>> > ... 2245  2245 E hwc-drm-resources: Could not find a suitable
>> > encoder/crtc for display 2
>> > ... 2245  2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with
>> > -19
>> > ... 2245  2245 E hwcomposer-drm: Can't initialize Drm object -19
>>
>> It isn't quite clear clear which errors belong to which changes,
>> to make this patch a bit more bisectable it would be nice to see
>> independent commits created for each error.
>
>
> Hi Robert,
>
> In this case I honestly do not think that splitting would add too much
> value,
> original commit (v1) is  well documented in [1] and tackles with bug in
> drmresources.cpp
> which currently fails to find workable crtc -> encoder -> display output
> combination
> for integrated and dedicated GPUs. Besides that it was also adding
> DisplayPort drm mode connector type
>
> So changes in drmresources.cpp belong to solving "Could not find a suitable
> encoder/crtc for display X" problem,
> which is a show stopper for enabling mainline graphics in android-x86
>
> Other developers observed independently that the current implementation is
> "embedded oriented" and only checks the first display output,
> isn't it?
>
> The only change I did in drmconnector.cpp is to account for the additional
> external drm mode connectors types
> which were missing (DVID, DVII, VGA) . One question on my side: Do we need
> more?
>
> Besides these minor types lists discussions, I would propose you to check
> with Jim Bish if he should have the credit for the patch
> and review the coding of his changes.
>
>
>>
>> >
>> > (v1) There are various places where we should be really taking
>> > connection
>> > state into account before querying the properties or assuming it
>> > as primary. This patch fixes them.
>> >
>> > BUG=None.
>> > TEST=System boots up and shows UI.
>> >
>> > (v1) Signed-off-by: Jim Bish 
>> >
>> > (v2) porting of original commit 76fb87e675 of android-ia master
>> > with additional external connector types (DisplayPort, DVID, DVII,
>> > VGA)
>> > Tested with i965 on Sandybridge and nouveau on GT120, GT610
>>
>> The commit message isn't really following the usual format. It doesn't
>> need to include a changelog (that is typically placed between the "---"
>> markers in the email instead),
>> and it is missing a signoff from the submitter (you).
>
>
> Sorry I don't have a signature, as usually my patches need sign-off from
> professionals,
> I'm a (crash test dummy) hobbyist..really :-)

That's not what S-o-b means.

> Maybe Rob Herring, Qiang Yu  or Chih-Wei could review and sign-off the
> proposed patch

The S-o-b is the Developer's Certificate of Origin[1]. It's tracking
the author(s) and vouching that the code has the appropriate license.
It can be the original author (Jim), modifier (you), and/or committer
(Robert or me).

Rob

[1] https://developercertificate.org/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [0/4] video-UDLFB: Adjustments for five function implementations

[Bartlomiej Zolnierkiewicz]

On Friday, December 29, 2017 07:10:00 PM SF Markus Elfring wrote:
> >>   Delete an error message for a failed memory allocation in two functions
> > 
> > This patch removes the information about the device for which the 
> > allocation fails.
> 
> * Do you find a Linux allocation failure report insufficient in this use case?

Yes, there is more information available currently in the driver and
I see no real improvement in removing it.

> * Are you looking for any more clarification?

I will not apply any of such patches for now. The only exception
being drivers that support hardware that can have only one instance
in the system (but it needs to be explicitly stated in the patch
description and the patch needs to be reviewed by a someone else
than the author).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
Can you see if this is fixed on master? I fixed a seemingly related issue with

https://cgit.freedesktop.org/mesa/mesa/commit/?id=0332c7484b712e56ce1a6648c5fa04c90e286c37

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #3 from Mike Lothian  ---
I'm wondering if this has been the issue I've been seeing on Bioshock

Will let out an older Mesa when I get home and bisect if that's the case

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
(In reply to Sebastian Parborg from comment #0)
> [...] there seems to be some kind of cached behaviour (not the mesa shader
> cache as I removed the directory [...]

Which directory exactly did you remove? Have you tried setting the environment
variable MESA_GLSL_CACHE_DISABLE=true to see if that avoids the problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix some comments in drm_crtc.c

[Alex Deucher]

On Wed, Jan 3, 2018 at 3:39 PM, Randy Dunlap  wrote:
> From: Randy Dunlap 
>
> Fix typos, punctuation, and one function reference (change
> atomic_check two times to be atomic_check and atomic_commit).
>
> Signed-off-by: Randy Dunlap 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> ---
>
> I was looking for what CRTC means, but I still haven't found it. :(
>
>  drivers/gpu/drm/drm_crtc.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> --- lnx-415-rc6.orig/drivers/gpu/drm/drm_crtc.c
> +++ lnx-415-rc6/drivers/gpu/drm/drm_crtc.c
> @@ -55,16 +55,16 @@
>   * to one or more _encoder, which are then each connected to one
>   * _connector.
>   *
> - * To create a CRTC, a KMS drivers allocates and zeroes an instances of
> + * To create a CRTC, a KMS driver allocates and zeroes an instances of

s/instances/instance/

Alex


>   *  drm_crtc (possibly as part of a larger structure) and registers it
>   * with a call to drm_crtc_init_with_planes().
>   *
> - * The CRTC is also the entry point for legacy modeset operations, see
> - * _crtc_funcs.set_config, legacy plane operations, see
> - * _crtc_funcs.page_flip and _crtc_funcs.cursor_set2, and other 
> legacy
> + * The CRTC is also the entry point for legacy modeset operations (see
> + * _crtc_funcs.set_config), legacy plane operations (see
> + * _crtc_funcs.page_flip and _crtc_funcs.cursor_set2), and other 
> legacy
>   * operations like _crtc_funcs.gamma_set. For atomic drivers all these
>   * features are controlled through _property and
> - * _mode_config_funcs.atomic_check and 
> _mode_config_funcs.atomic_check.
> + * _mode_config_funcs.atomic_check and 
> _mode_config_funcs.atomic_commit.
>   */
>
>  /**
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: specify DMA_ATTR_NO_WARN for huge page pools

[Alex Deucher]

On Thu, Jan 4, 2018 at 9:16 AM, Christian König
 wrote:
> Suppress warning messages when allocating huge pages fails since we can
> always fall back to normal pages.
>
> Signed-off-by: Christian König 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 3ac53918881e..4c659405a008 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -333,14 +333,18 @@ static void __ttm_dma_free_page(struct dma_pool *pool, 
> struct dma_page *d_page)
>  static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool)
>  {
> struct dma_page *d_page;
> +   unsigned long attrs = 0;
> void *vaddr;
>
> d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
> if (!d_page)
> return NULL;
>
> -   vaddr = dma_alloc_coherent(pool->dev, pool->size, _page->dma,
> -  pool->gfp_flags);
> +   if (pool->type & IS_HUGE)
> +   attrs = DMA_ATTR_NO_WARN;
> +
> +   vaddr = dma_alloc_attrs(pool->dev, pool->size, _page->dma,
> +   pool->gfp_flags, attrs);
> if (vaddr) {
> if (is_vmalloc_addr(vaddr))
> d_page->p = vmalloc_to_page(vaddr);
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes for 4.15-rc6

[Jani Nikula]

On Fri, 29 Dec 2017, Jani Nikula  wrote:
> On Thu, 28 Dec 2017, Randy Dunlap  wrote:
>> It would be good to get this documentation build error patch
>> merged into 4.15.  Daniel Vetter says that he merged (applied) it.
>>
>> [PATCH] documentation/gpu/i915: fix docs build error after file rename
>>   https://marc.info/?l=linux-kernel=151234419425847=2
>
> Hi Randy, didn't look too closely but I presume our scripts tripped over
> the Fixes: tag that's split to two lines in that patch. I'll pick it up
> for our next fixes batch.

I just sent the pull request with this to Dave.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, some more i915 fixes for the new year.

drm-intel-fixes-2018-01-04:
drm/i915 fixes for v4.15-rc7
- couple of documentation build fixes
- serialize non-blocking modesets
- prevent DMC from messing up GMBUS transfers
- PSR regression fix

BR,
Jani.

The following changes since commit 30a7acd573899fd8b8ac39236eff6468b195ac7d:

  Linux 4.15-rc6 (2017-12-31 14:47:43 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-04

for you to fetch changes up to 30414f3010aff95ffdb6bed7b9dce62cde94fdc7:

  drm/i915: Apply Display WA #1183 on skl, kbl, and cfl (2018-01-04 14:39:08 
+0200)


drm/i915 fixes for v4.15-rc7
- couple of documentation build fixes
- serialize non-blocking modesets
- prevent DMC from messing up GMBUS transfers
- PSR regression fix


Dhinakaran Pandiyan (1):
  drm/i915/psr: Fix register name mess up.

Lucas De Marchi (1):
  drm/i915: Apply Display WA #1183 on skl, kbl, and cfl

Markus Heiser (1):
  docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

Randy Dunlap (1):
  documentation/gpu/i915: fix docs build error after file rename

Ville Syrjälä (2):
  drm/i915: Disable DC states around GMBUS on GLK
  drm/i915: Put all non-blocking modesets onto an ordered wq

 Documentation/gpu/i915.rst  |  5 +
 drivers/gpu/drm/i915/i915_drv.h |  3 +++
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_cdclk.c  | 35 -
 drivers/gpu/drm/i915/intel_display.c| 14 ++---
 drivers/gpu/drm/i915/intel_psr.c| 16 +++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
 7 files changed, 62 insertions(+), 24 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: auo_k190x: Use zeroing memory allocator than allocator/memset

[Bartlomiej Zolnierkiewicz]

On Sunday, December 31, 2017 05:55:57 PM Himanshu Jha wrote:
> Use vzalloc for allocating zeroed memory and remove unnecessary
> memset function.
> 
> Done using Coccinelle.
> Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

Use of "Generated-by:" triggers checkpatch.pl warning + error:

WARNING: Non-standard signature: Generated-by:
#8: 
Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

ERROR: Unrecognized email address: 
'scripts/coccinelle/api/alloc/kzalloc-simple.cocci'
#8: 
Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

I've changed it to "Generate-by" to silence checkpatch.pl.

> 0-day tested with no failures.
> 
> Suggested-by: Luis R. Rodriguez 
> Signed-off-by: Himanshu Jha 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer

[Maxime Ripard]

On Sat, Dec 30, 2017 at 10:02:00PM +0100, Jernej Skrabec wrote:
> It supports 1 VI and 1 UI plane and HW scaling on both planes.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/11] drm/sun4i: Add support for A83T second TCON

[Maxime Ripard]

Hi,

On Sat, Dec 30, 2017 at 10:01:59PM +0100, Jernej Skrabec wrote:
> This TCON doesn't have channel 0, so quirk has_channel_0 is added in the
> process.
> 
> Signed-off-by: Jernej Skrabec 

Ideally, this should be split in two patches, one to add the new flag,
and one to add the support for the A83t TCON-TV.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 09/12] drm/sun4i: backend: Add a custom atomic_check for the frontend

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> Now that we have everything in place, we can start enabling the frontend.
> This is more difficult than one would assume since there can only be one
> plane using the frontend per-backend.
>
> We therefore need to make sure that the userspace will not try to setup
> multiple planes using it, since that would be impossible. In order to
> prevent that, we can create an atomic_check callback that will check that
> only one plane will effectively make use of the frontend in a given
> configuration, and will toggle the switch in that plane state so that the
> proper setup function can do their role.
>
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/12] drm/sun4i: backend: Wire in the frontend

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not perform the DMA but
> receive its data from the frontend.
>
> Note that we're still not making any use of the frontend itself, as no one
> is setting the flag yet.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 90 -
>  drivers/gpu/drm/sun4i/sun4i_backend.h |  8 ++-
>  drivers/gpu/drm/sun4i/sun4i_crtc.c|  1 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.c   | 33 +-
>  drivers/gpu/drm/sun4i/sun4i_layer.h   |  1 +-
>  5 files changed, 130 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index f971d3fb5ee4..29e1ca7e01fe 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -26,6 +26,7 @@
>
>  #include "sun4i_backend.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
>  #include "sun4i_layer.h"
>  #include "sunxi_engine.h"
>
> @@ -203,6 +204,30 @@ int sun4i_backend_update_layer_formats(struct 
> sun4i_backend *backend,
> return 0;
>  }
>
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> +   int layer, uint32_t fmt)
> +{
> +   u32 val;
> +   int ret;
> +
> +   ret = sun4i_backend_drm_format_to_layer(NULL, fmt, );
> +   if (ret) {
> +   DRM_DEBUG_DRIVER("Invalid format\n");
> +   return ret;
> +   }
> +
> +   regmap_update_bits(backend->engine.regs,
> +  SUN4I_BACKEND_ATTCTL_REG0(layer),
> +  SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
> +  SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);

You also need to select which frontend to use by setting LAY_VDOSEL.

> +
> +   regmap_update_bits(backend->engine.regs,
> +  SUN4I_BACKEND_ATTCTL_REG1(layer),
> +  SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
> +
> +   return 0;
> +}
> +
>  int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
>   int layer, struct drm_plane *plane)
>  {
> @@ -246,6 +271,36 @@ int sun4i_backend_update_layer_buffer(struct 
> sun4i_backend *backend,
> return 0;
>  }
>
> +static void sun4i_backend_vblank_quirk(struct sunxi_engine *engine)
> +{
> +   struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
> +   struct sun4i_frontend *frontend = backend->frontend;
> +
> +   if (!frontend)
> +   return;
> +
> +   /*
> +* In a teardown scenario with the frontend involved, we have
> +* to keep the frontend enabled until the next vblank, and
> +* only then disable it.
> +*
> +* This is due to the fact that the backend will not take into
> +* account the new configuration (with the plane that used to
> +* be fed by the frontend now disabled) until we write to the
> +* commit bit and the hardware fetches the new configuration
> +* during the next vblank.
> +*
> +* So we keep the frontend around in order to prevent any
> +* visual artifacts.
> +*/
> +   spin_lock(>frontend_lock);
> +   if (backend->frontend_teardown) {
> +   sun4i_frontend_exit(frontend);
> +   backend->frontend_teardown = false;
> +   }
> +   spin_unlock(>frontend_lock);
> +};
> +
>  static int sun4i_backend_init_sat(struct device *dev) {
> struct sun4i_backend *backend = dev_get_drvdata(dev);
> int ret;
> @@ -330,11 +385,40 @@ static int sun4i_backend_of_get_id(struct device_node 
> *node)
> return ret;
>  }
>
> +static struct sun4i_frontend *sun4i_backend_find_frontend(struct sun4i_drv 
> *drv,
> + struct device_node 
> *node)
> +{
> +   struct device_node *port, *ep, *remote;
> +   struct sun4i_frontend *frontend;
> +
> +   port = of_graph_get_port_by_id(node, 0);
> +   if (!port)
> +   return ERR_PTR(-EINVAL);
> +
> +   for_each_available_child_of_node(port, ep) {
> +   remote = of_graph_get_remote_port_parent(ep);
> +   if (!remote)
> +   continue;
> +
> +   /* does this node match any registered engines? */
> +   list_for_each_entry(frontend, >frontend_list, list) {
> +   if (remote == frontend->node) {
> +   of_node_put(remote);
> +   of_node_put(port);
> +   return 

Re: [PATCH v2 07/12] drm/sun4i: Add a driver for the display frontend

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> The display frontend is an hardware block that can be used to implement
> some more advanced features like hardware scaling or colorspace
> conversions. It can also be used to implement the output format of the VPU.
>
> Let's create a minimal driver for it that will only enable the hardware
> scaling features.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   3 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  16 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.h  |   1 +-
>  drivers/gpu/drm/sun4i/sun4i_frontend.c | 392 ++-
>  drivers/gpu/drm/sun4i/sun4i_frontend.h |  96 ++-
>  5 files changed, 503 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.c
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0c2f8c7facae..b660d82011f4 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  sun4i-backend-y+= sun4i_backend.o sun4i_layer.o
> +sun4i-frontend-y   += sun4i_frontend.o
>
>  sun4i-drm-y+= sun4i_drv.o
>  sun4i-drm-y+= sun4i_framebuffer.o
> @@ -21,6 +22,6 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-tcon.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
>  obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
>
> -obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o sun4i-frontend.o
>  obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
>  obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 75c76cdd82bc..17bf9bfd98ba 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -98,6 +98,7 @@ static int sun4i_drv_bind(struct device *dev)
> goto free_drm;
> }
> drm->dev_private = drv;
> +   INIT_LIST_HEAD(>frontend_list);
> INIT_LIST_HEAD(>engine_list);
> INIT_LIST_HEAD(>tcon_list);
>
> @@ -239,9 +240,11 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> int count = 0;
>
> /*
> -* We don't support the frontend for now, so we will never
> -* have a device bound. Just skip over it, but we still want
> -* the rest our pipeline to be added.
> +* The frontend has been disabled in all of our old device

Not quite... I left them enabled in all the ones I did (A10/A20/A31)...

> +* trees. If we find a node that is the frontend and is
> +* disabled, we should just follow through and parse its
> +* child, but without adding it to the component list.
> +* Otherwise, we obviously want to add it to the list.
>  */
> if (!sun4i_drv_node_is_frontend(node) &&
> !of_device_is_available(node))
> @@ -254,7 +257,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> if (sun4i_drv_node_is_connector(node))
> return 0;
>
> -   if (!sun4i_drv_node_is_frontend(node)) {
> +   /*
> +* If the device is either just a regular device, or an
> +* enabled frontend, we add it to our component list.
> +*/
> +   if (!sun4i_drv_node_is_frontend(node) ||
> +   (sun4i_drv_node_is_frontend(node) && 
> of_device_is_available(node))) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %pOF\n", node);
> drm_of_component_match_add(dev, match, compare_of, node);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h 
> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> index a960c89270cc..9c26a345f85c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> @@ -19,6 +19,7 @@
>
>  struct sun4i_drv {
> struct list_headengine_list;
> +   struct list_headfrontend_list;
> struct list_headtcon_list;
>
> struct drm_fbdev_cma*fbdev;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> new file mode 100644
> index ..fb3e96ab57f7
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -0,0 +1,392 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Free Electrons
> + * Maxime Ripard 
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
> +
> +static const u32 sun4i_frontend_vert_coef[32] = {
> +   0x4000, 0x000140ff, 0x00033ffe, 

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Thomas Hellstrom]

Hi,

On 01/04/2018 02:52 PM, Lukasz Spintzyk wrote:




On 28/12/2017 10:03, Thomas Hellstrom wrote:

Hi, Lukasz!

(Sorry for top-posting).

We have Deepak from our team working on the same subject. I think 
he's in over the holidays so I'll add him to the CC list.

Great!


Adding damage to the plane state is, IMO the correct way to do it. 
However, from your proposal it's not clear whether damage is given in 
the plane-, crtc- or framebuffer coordinates. The last conclusion 
from our email thread discussion was that they should be given in 
framebuffer coordinates with helpers to compute plane coordinates or 
crtc coordinates. The reason being that it's easier for user-space 
apps to send damage that way, and again, we have the full information 
that we can clip and scale if necessary. Most drivers probably want 
the damage in clipped plane- or crtc coordinates. Helpers could for 
example be in the form of region iterators.
Personally i don't know the difference between plane rects and 
framebuffer rects. I don't know what would be better. I was thinking 
about coordinates of framebuffer that is attached to drm_plane_state.


A given point with coordinates (0, 0) in the plane coordinate system 
would have (state->crtc_x, state->crtc_y) in the crtc coordinate system 
and (state->src_x, state->src_y) in the framebuffer coordinate system.


So the question is, which is the suitable coordinate system, and where 
is the origin for the damage rects?




Full (multi-rect) damage regions are OK with us, although we should 
keep in mind that we won't be able to compute region unions in the 
kernel (yet?). Implying: Should we forbid overlapping rects at the 
interface level or should we just recommend rects not to be 
overlapping? The former would be pretty hard to enforce efficiently.
I would be for recommendation. We can add some helper functions to 
combine rects and set some limits on number of rects to prevent abuse 
of that interface.


I agree.



Another thing we should think about is how to use this interface for 
the legacy "dirtyfb" call. Probably we need to clear the damage 
property on each state-update, or set a flag that "this is a dirtyfb 
state update".


IMO we should also have as an end goal of this work to have 
gnome-shell on drm sending damage regions on page-flip, which means 
either porting gnome-shell to atomic or set up a new legacy 
page-flip-with-atomic ioctl.
Can't we reuse dirtyfb ioctl for this purpose? It would be called 
before page_flip ioctl?


No we can't. The dirtyfb ioctl causes an immediate repaint of the 
damaged region.


/Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

[David Howells]

Arnd Bergmann  wrote:

> - mn10300 appears to be wrong, broken by David Howells in
>   commit 83c2dc15ce82 ("MN10300: Handle cacheable PCI regions
>   in pci_iomap()") for any driver calling ioremap() by to get uncached
>   memory,

It's not clear what the right thing to do was, given that there's an ioremap()
and an ioremap_uncached().

But the asb2305's pci_iomap() will use ioremap() (the cacheable window) if
IORESOURCE_CACHEABLE is set, but IORESOURCE_IO is not and ioremap_uncached()
otherwise.

The other supported units don't have PCI buses.

> if I understand the comment for commit 34f1bdee1910 ("mn10300: switch to
> GENERIC_PCI_IOMAP") correctly: it seems that PCI addresses include the
> 'uncached' bit by default to get the right behavior, but dropping that bit
> breaks it.

Not exactly.  The CPU has a window in the range 0xa000-0xbfff which is
an uncached view of its hardware buses.  It has another window in the range
0x8000-0x9fff which is a cached view of that region.  These windows
cannot be changed and addresses above 0x8000 are statically mapped and are
only accessible by the kernel (this is hardwired in the MMU).

So the arch has two subwindows to the PCI bus, one cached and one uncached.
These subwindows are further subdivided into ioport and iomem spaces, an SRAM
and some control registers for the CPU-PCI bridge.

David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 12/12] ARM: dts: sun8i: a33 Enable our display frontend

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> The display frontend can be used to do hardware scaling, colorspaces
> conversion or to implement the buffer format output by the Cedar VPU.
>
> Since we're starting to have some support for it in the DRM driver, let's
> enable its DT node.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/12] drm/sun4i: backend: Make sure we don't have a commit pending

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> If we try to read the backend registers while it fetches the new values, we
> end up with the value of some random register instead of the one we asked
> for.
>
> In order to prevent that, let's make sure that the very first thing we do
> during our atomic modesetting is to let the commit bit come to a rest.
>
> We don't have to worry about anything else since the only time we will
> trigger a new transaction is during the atomic_commit which comes much
> later.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 10/12] drm/sun4i: backend: Use runtime_pm variant of atomic_commit_tail

[Chen-Yu Tsai]

On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
 wrote:
> During a hardware commit, the commit bit in the backend will only be
> cleared if the TCON is enabled. Use the runtime_pm variant of the
> atomic_commit_tail hook that makes sure that the CRTC, our TCON, is enabled
> when we perform an atomic_commit.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

--- Comment #1 from florian.w...@googlemail.com ---
Created attachment 136548
  --> https://bugs.freedesktop.org/attachment.cgi?id=136548=edit
RADEON_DUMP_SHADERS=1 output.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

[Chen-Yu Tsai]

On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec  wrote:
> For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> is not specified, it has offset 0, shift 0 and lowest value 1. This
> means that LSB bit is always set to 1, which may change clock rate.
>
> Fix that by applying k factor only if k width is greater than 0.
>
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> index e58c95787f94..709f528af2b3 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
>  {
> struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> -   unsigned long n, m, k, p;
> +   unsigned long n, m, k = 1, p;
> u32 reg;
>
> reg = readl(nkmp->common.base + nkmp->common.reg);
> @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw 
> *hw,
> if (!n)
> n++;
>
> -   k = reg >> nkmp->k.shift;
> -   k &= (1 << nkmp->k.width) - 1;
> -   k += nkmp->k.offset;
> -   if (!k)
> -   k++;
> +   if (nkmp->k.width) {
> +   k = reg >> nkmp->k.shift;
> +   k &= (1 << nkmp->k.width) - 1;
> +   k += nkmp->k.offset;
> +   if (!k)
> +   k++;
> +   }

The conditional shouldn't be necessary. With nkmp->k.width = 0,
you'd simply get k & 0, which is 0, which then gets bumped up to 1,
unless k.offset > 1, which would be a bug.

>
> m = reg >> nkmp->m.shift;
> m &= (1 << nkmp->m.width) - 1;
> @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>
> reg = readl(nkmp->common.base + nkmp->common.reg);
> reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
> -   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> +   if (nkmp->k.width)
> +   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> +   nkmp->k.shift);
> reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
> reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
>
> reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> -   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> +   if (nkmp->k.width)
> +   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;

I think a better way would be

reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
   GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);

And do this for all the factors, not just k. This pattern is what
regmap_update_bits does, which seems much safer. I wonder what
GENMASK() with a negative value would do though...

ChenYu

> reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> reg |= ilog2(_nkmp.p) << nkmp->p.shift;
>
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon]

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

Bug ID: 104492
   Summary: Compute Shader: Wrong alignment when assigning struct
value to structured SSBO
   Product: Mesa
   Version: 17.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: florian.w...@googlemail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136547
  --> https://bugs.freedesktop.org/attachment.cgi?id=136547=edit
Code to reproduce this issue. Requires SDL2.

Hi,

I'm trying to get the Banshee 3D engine
 working on my hardware (HD 7870)
using Mesa radeonsi (amdgpu kernel module). I use 17.2.4-0ubuntu1~17.10.1 from
the Ubuntu artful-proposed archive.

It uses a compute shader that reads a texture cube and writes 6 sets of
coefficients into a shader storage buffer object. Details are not important as
I have isolated the (probably) incorrect driver behaviour and created a much
simpler program that triggers the same issue.

In short: Let's say we have a GLSL struct and access the SSBO through a
dynamically-sized array of that struct type using the std430 layout, like this:

struct ResultRecord
{
float a[10];
float b[10];
float c[10];
float weight;
};

layout(std430) buffer gOutput
{
ResultRecord ssb[];
};

Then a simple assignment of a local variable of the same struct type to ssb[i]
writes the floats into incorrect buffer offsets, because b, c and "weight" are
placed as if the array elements in a, b and c were vec4-aligned instead of
float-aligned, tripling the size of a, b and c.

Code that triggers it is like this, which should hopefully be valid GLSL (and
makes more sense the way it is used in Banshee 3D):
ResultRecord result;
// ... populate result ...
ssb[gl_LocalInvocationIndex] = result;

The test program is available here and contains a (maybe too) detailed
explanation and three program variations that fix the issue:
https://gist.github.com/w-flo/b1a5791749eea5f36cb54628037ba2bf
But I'll also attach it to this bug report.


Looking at the RADEON_DUMP_SHADERS=1 output, I think that the bug is already
visible in the TGSI dump, as explained in the comment at the top of my
reproducer program. I'll attach the output (it's possibly based on an older
version of the reproducer).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: arm64 use __raw I/O memory api

[Bartlomiej Zolnierkiewicz]

On Thursday, November 30, 2017 04:17:22 PM Ji Zhang wrote:
> Since arm64 also has __raw I/O accessors, add __aarch64__ in fb.h.
> This is a supplement for commmit
> 981409b25e2a99409b26daa67293ca1cfd5ea0a0
> 
> Signed-off-by: Ji Zhang 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

[maxime . ripard]

Hi,

On Sat, Dec 30, 2017 at 10:01:53PM +0100, Jernej Skrabec wrote:
> For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> is not specified, it has offset 0, shift 0 and lowest value 1. This
> means that LSB bit is always set to 1, which may change clock rate.
> 
> Fix that by applying k factor only if k width is greater than 0.
> 
> Signed-off-by: Jernej Skrabec 

This looks fine...

> ---
>  drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> index e58c95787f94..709f528af2b3 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
>  {
>   struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> - unsigned long n, m, k, p;
> + unsigned long n, m, k = 1, p;
>   u32 reg;
>  
>   reg = readl(nkmp->common.base + nkmp->common.reg);
> @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw 
> *hw,
>   if (!n)
>   n++;
>  
> - k = reg >> nkmp->k.shift;
> - k &= (1 << nkmp->k.width) - 1;
> - k += nkmp->k.offset;
> - if (!k)
> - k++;
> + if (nkmp->k.width) {
> + k = reg >> nkmp->k.shift;
> + k &= (1 << nkmp->k.width) - 1;
> + k += nkmp->k.offset;
> + if (!k)
> + k++;
> + }

... but could you add a comment there to explain why you're using a
different construct than the one used for the other factors?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: specify DMA_ATTR_NO_WARN for huge page pools

[Christian König]

Suppress warning messages when allocating huge pages fails since we can
always fall back to normal pages.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 3ac53918881e..4c659405a008 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -333,14 +333,18 @@ static void __ttm_dma_free_page(struct dma_pool *pool, 
struct dma_page *d_page)
 static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool)
 {
struct dma_page *d_page;
+   unsigned long attrs = 0;
void *vaddr;
 
d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
if (!d_page)
return NULL;
 
-   vaddr = dma_alloc_coherent(pool->dev, pool->size, _page->dma,
-  pool->gfp_flags);
+   if (pool->type & IS_HUGE)
+   attrs = DMA_ATTR_NO_WARN;
+
+   vaddr = dma_alloc_attrs(pool->dev, pool->size, _page->dma,
+   pool->gfp_flags, attrs);
if (vaddr) {
if (is_vmalloc_addr(vaddr))
d_page->p = vmalloc_to_page(vaddr);
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: omap2: Use PTR_ERR_OR_ZERO()

[Bartlomiej Zolnierkiewicz]

On Wednesday, November 29, 2017 05:22:48 PM Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:676:1-3: WARNING: 
> PTR_ERR_OR_ZERO can be used
> 
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> 
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
> 
> Signed-off-by: Vasyl Gomonovych 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Lukasz Spintzyk]

On 28/12/2017 10:03, Thomas Hellstrom wrote:

Hi, Lukasz!

(Sorry for top-posting).

We have Deepak from our team working on the same subject. I think he's 
in over the holidays so I'll add him to the CC list.

Great!


Adding damage to the plane state is, IMO the correct way to do it. 
However, from your proposal it's not clear whether damage is given in 
the plane-, crtc- or framebuffer coordinates. The last conclusion from 
our email thread discussion was that they should be given in 
framebuffer coordinates with helpers to compute plane coordinates or 
crtc coordinates. The reason being that it's easier for user-space 
apps to send damage that way, and again, we have the full information 
that we can clip and scale if necessary. Most drivers probably want 
the damage in clipped plane- or crtc coordinates. Helpers could for 
example be in the form of region iterators.
Personally i don't know the difference between plane rects and 
framebuffer rects. I don't know what would be better. I was thinking 
about coordinates of framebuffer that is attached to drm_plane_state.


Full (multi-rect) damage regions are OK with us, although we should 
keep in mind that we won't be able to compute region unions in the 
kernel (yet?). Implying: Should we forbid overlapping rects at the 
interface level or should we just recommend rects not to be 
overlapping? The former would be pretty hard to enforce efficiently.
I would be for recommendation. We can add some helper functions to 
combine rects and set some limits on number of rects to prevent abuse of 
that interface.


Another thing we should think about is how to use this interface for 
the legacy "dirtyfb" call. Probably we need to clear the damage 
property on each state-update, or set a flag that "this is a dirtyfb 
state update".


IMO we should also have as an end goal of this work to have 
gnome-shell on drm sending damage regions on page-flip, which means 
either porting gnome-shell to atomic or set up a new legacy 
page-flip-with-atomic ioctl.
Can't we reuse dirtyfb ioctl for this purpose? It would be called before 
page_flip ioctl?


/Thomas


On 12/21/2017 12:10 PM, Lukasz Spintzyk wrote:

Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
Signed-off-by: Lukasz Spintzyk 
---
  drivers/gpu/drm/drm_atomic.c  | 10 ++
  drivers/gpu/drm/drm_mode_config.c |  6 ++
  drivers/gpu/drm/drm_plane.c   |  1 +
  include/drm/drm_mode_config.h |  5 +
  include/drm/drm_plane.h   |  3 +++
  5 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b76d49218cf1..cd3b4ed7b04c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct 
drm_plane *plane,

  state->rotation = val;
  } else if (property == plane->zpos_property) {
  state->zpos = val;
+    } else if (property == config->dirty_rects_property) {
+    bool replaced = false;
+    int ret = drm_atomic_replace_property_blob_from_id(dev,
+    >dirty_blob,
+    val,
+    -1,
+    );
+    return ret;
  } else if (plane->funcs->atomic_set_property) {
  return plane->funcs->atomic_set_property(plane, state,
  property, val);
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane 
*plane,

  *val = state->rotation;
  } else if (property == plane->zpos_property) {
  *val = state->zpos;
+    } else if (property == config->dirty_rects_property) {
+    *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
  } else if (plane->funcs->atomic_get_property) {
  return plane->funcs->atomic_get_property(plane, state, 
property, val);

  } else {
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c

index bc5c46306b3d..d5f1021c6ece 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -293,6 +293,12 @@ static int 
drm_mode_create_standard_properties(struct drm_device *dev)

  return -ENOMEM;
  dev->mode_config.prop_crtc_id = prop;
  +    prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+    "DIRTY_RECTS", 0);
+    if (!prop)
+    return -ENOMEM;
+    dev->mode_config.dirty_rects_property = prop;
+
  prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
  "ACTIVE");
  if (!prop)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 37a93cdffb4a..add110f025e5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device 
*dev, struct drm_plane *plane,
  drm_object_attach_property(>base, 
config->prop_src_y, 0);
  drm_object_attach_property(>base, 
config->prop_src_w, 0);
  drm_object_attach_property(>base, 

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #2 from Chris Wilson  ---
Try (or confirm you have):

commit 1d033beb20d6d5885587a02a393b6598d766a382
Author: Chris Wilson 
Date:   Tue Oct 31 10:36:07 2017 +

drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

In case the object has changed tiling between calls to execbuf, we need
to check if the existing offset inside the GTT matches the new tiling
constraint. We even need to do this for "unfenced" tiled objects, where
the 3D commands use an implied fence and so the object still needs to
match the physical fence restrictions on alignment (only required for
gen2 and early gen3).

In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
the execobjects array"), the idea was to remove the second guessing and
only set the NEEDS_MAP flag when required. However, the entire check
for an unusable offset for fencing was removed and not just the
secondary check. I.e.

/* avoid costly ping-pong once a batch bo ended up non-mappable */
if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
!i915_vma_is_map_and_fenceable(vma))
return !only_mappable_for_reloc(entry->flags);

was entirely removed as the ping-pong between execbuf passes was fixed,
but its primary purpose in forcing unaligned unfenced access to be
rebound was forgotten.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the
execobjects array")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Link:
https://patchwork.freedesktop.org/patch/msgid/20171031103607.17836-1-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen 

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 09/11] clk: sunxi-ng: add support for Allwinner A64 DE2 CCU

[Maxime Ripard]

On Fri, Dec 22, 2017 at 08:22:41PM +0800, Icenowy Zheng wrote:
> Allwinner A64's DE2 needs to claim a section of SRAM (SRAM C) to work.
> 
> Add support for it.

That's highly suspicious that the clocks need an SRAM to operate
properly.

Can you elaborate?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/11] ARM: sun8i: h3/h5: add DE2 CCU device node for H3

[maxime . ripard]

On Fri, Dec 22, 2017 at 08:22:37PM +0800, Icenowy Zheng wrote:
> The DE2 in H3/H5 has a clock control unit in it, and the behavior is
> slightly different between H3 and H5.
> 
> Add the common parts in H3/H5 DTSI, and add the compatible string in H3
> DTSI.
> 
> The compatible string of H5 DE2 CCU will be added in a separated patch.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Use H3 DE2 CCU compatible as it's discovered that H3 and A83T DE2 CCU are
>   not equal.
> 
>  arch/arm/boot/dts/sun8i-h3.dtsi|  4 
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 14 ++

Could you split that patch in half, with the common part in one patch,
and the H3 part in a second one?

This is a nightmare to merge otherwise.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: au1200fb: delete duplicate header contents

[Bartlomiej Zolnierkiewicz]

On Tuesday, November 28, 2017 04:22:22 PM Rasmus Villemoes wrote:
> This file has been copy-pasted-pasted:
> 
>   ~/linux$ x=drivers/video/fbdev/au1200fb.h; diff -u <(head -n 286 $x; head 
> -n 286 $x) $x
>   ~/linux$
> 
> Signed-off-by: Rasmus Villemoes 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #1 from Francesco Turco  ---
It seems this problem happens only when using SNA. I can't reproduce this bug
with UXA.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] fbdev: pxa3xx: use ktime_get_ts64 for time stamps

[Bartlomiej Zolnierkiewicz]

On Monday, November 27, 2017 05:46:14 PM Arnd Bergmann wrote:
> do_gettimeofday() is deprecated because it is not y2038 safe, so I'm
> changing the calculation for the diagnostic output over to using
> 'timespec64'.
> 
> We really only print time deltas here, so changing it to monotonic
> time makes this more robust, the correct accessor for this is
> ktime_get_ts64().
> 
> Signed-off-by: Arnd Bergmann 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/omap: plane zpos/zorder management improvements

[Peter Ujfalusi]

Use the plane index as default zpos for all planes. Even if the
application is not setting zpos/zorder explicitly we will have unique zpos
for each plane.

Enforce that all planes must have unique zpos on the given crtc.

Signed-off-by: Peter Ujfalusi 
---
Hi,

Changes since v2:
- The check for duplicate zpos is moved to omap_crtc

Changes since v1:
- Dropped the zpos normalization related patches
- New patch based on the discussion, see commit message.

Regards,
Peter

 drivers/gpu/drm/omapdrm/omap_crtc.c  | 24 +++-
 drivers/gpu/drm/omapdrm/omap_plane.c | 10 +-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e58d18..ff0b17f8bb76 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -486,6 +486,28 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
}
 }
 
+static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
+  struct drm_crtc_state *state)
+{
+   struct drm_plane *p1, *p2;
+   const struct drm_plane_state *pstate1, *pstate2;
+
+   drm_atomic_crtc_state_for_each_plane_state(p1, pstate1, state) {
+   drm_atomic_crtc_state_for_each_plane_state(p2, pstate2, state) {
+   if (drm_plane_index(p1) == drm_plane_index(p2))
+   continue;
+
+   if (pstate1->zpos == pstate2->zpos) {
+   DBG("crtc%u: zpos must be unique (zpos: %u)",
+   crtc->index, pstate1->zpos);
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+
 static int omap_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -509,7 +531,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
omap_crtc_state->rotation = pri_state->rotation;
}
 
-   return 0;
+   return omap_crtc_validate_zpos(crtc, state);
 }
 
 static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 7d789d1551a1..c1f93bfae7a5 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -31,6 +31,7 @@
 struct omap_plane {
struct drm_plane base;
enum omap_plane_id id;
+   int idx;
const char *name;
 };
 
@@ -97,8 +98,7 @@ static void omap_plane_atomic_disable(struct drm_plane *plane,
struct omap_plane *omap_plane = to_omap_plane(plane);
 
plane->state->rotation = DRM_MODE_ROTATE_0;
-   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
-  ? 0 : omap_plane->id;
+   plane->state->zpos = omap_plane->idx;
 
priv->dispc_ops->ovl_enable(omap_plane->id, false);
 }
@@ -194,8 +194,7 @@ static void omap_plane_reset(struct drm_plane *plane)
 * Set the zpos default depending on whether we are a primary or overlay
 * plane.
 */
-   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
-  ? 0 : omap_plane->id;
+   plane->state->zpos = omap_plane->idx;
 }
 
 static int omap_plane_atomic_set_property(struct drm_plane *plane,
@@ -282,6 +281,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
for (nformats = 0; formats[nformats]; ++nformats)
;
omap_plane->id = id;
+   omap_plane->idx = idx;
omap_plane->name = plane_id_to_name[id];
 
plane = _plane->base;
@@ -295,7 +295,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
drm_plane_helper_add(plane, _plane_helper_funcs);
 
omap_plane_install_properties(plane, >base);
-   drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1);
+   drm_plane_create_zpos_property(plane, idx, 0, num_planes - 1);
 
return plane;
 
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] fbdev: radeon: stop use ktime_get() for HZ calibration

[Bartlomiej Zolnierkiewicz]

On Tuesday, November 07, 2017 03:13:06 PM Arnd Bergmann wrote:
> do_gettimeofday() is deprecated and a bit clumsy. This changes
> radeon_probe_pll_params() over to using ktime_get() with monotonic
> times. There is no need to check for negative values any more
> since the monotonic clocksource cannot go backwards, but I'm
> adding a check for zero-division in case of a bad clocksource.
> 
> Signed-off-by: Arnd Bergmann 

Patch queued for 4.16, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

--- Comment #1 from Sebastian Parborg  ---
Forgot to mention:
As I stated in the github issue, only dota seems to have this problem. No other
program/game fails to create a opengl context for me. So I'm quite unsure why
it is just dota2 that has problem now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

Bug ID: 104490
   Summary: [radeonsi/290x] Dota2 fails to start (can't create
opengl context)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: darkdefe...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136546
  --> https://bugs.freedesktop.org/attachment.cgi?id=136546=edit
glxinfo

I've been trying to figure out the cause for this bug for quite some time now.
Here is the bug ticket on the dota2 github page:
https://github.com/ValveSoftware/Dota-2/issues/1368

Since about one week ago, I have been unable to start dota2 on my machine. This
happened after I updated my llvm and mesa git version.

If I downgrade to mesa 17.3.1 it works again (without reboot). But it seems to
be really hard to track down the commit that broke it as there seems to be some
kind of cached behaviour (not the mesa shader cache as I removed the directory
and rebooted several times).

For example I downgraded mesa to a commit from 2017-11-17 and it worked. The
next day I tried to figure out the commit that broke it. But I could then use
the git master version and it seemed to work fine again.

Then the next day I'm back to the same problem and I downgraded again and now
it won't start again even if I use mesa from 11-17 (and rebooted). But 17.3.1
still works if I downgrade to that... (no reboot)

I really do not know how to debug this further as I don't know when I'm on the
commit that broke it or not. However it seems to always break if I'm on a
commit that is newer than 1-2 weeks (after a reboot that is). However it will
not fix itself with reboots with commits older than that either...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/bar/gk20a: Avoid bar teardown during init

[Jon Hunter]

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.

This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.

Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker 
Signed-off-by: Jon Hunter 
---
I am not happy that we do not yet fully understand the cause of
the hang, but I am talking with a few people at NVIDIA about this
and have a few things to look into. However, given that we are
close to v4.15 being released and I am not sure we will have a
proper fix in place before, I think it is best to workaround
this for now.

 drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c  | 3 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c
index 9646adec57cb..243f0a5c8a62 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c
@@ -73,7 +73,8 @@ static int
 nvkm_bar_fini(struct nvkm_subdev *subdev, bool suspend)
 {
struct nvkm_bar *bar = nvkm_bar(subdev);
-   bar->func->bar1.fini(bar);
+   if (bar->func->bar1.fini)
+   bar->func->bar1.fini(bar);
return 0;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c
index b10077d38839..35878fb538f2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c
@@ -26,7 +26,6 @@ gk20a_bar_func = {
.dtor = gf100_bar_dtor,
.oneinit = gf100_bar_oneinit,
.bar1.init = gf100_bar_bar1_init,
-   .bar1.fini = gf100_bar_bar1_fini,
.bar1.wait = gf100_bar_bar1_wait,
.bar1.vmm = gf100_bar_bar1_vmm,
.flush = g84_bar_flush,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

[bugzilla-daemon]

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

--- Comment #2 from Alex Vorobyev  ---
Just did some research - this issue still persists in 17.3.1 and it's only
visible if shadows enabled. If I set "Shadow quality" in the in-game settings
to "Disabled", artifacts disappear.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] drm/omap: Make omapdss API more generic + related patches

[Tomi Valkeinen]

On 01/01/18 13:55, Jyri Sarha wrote:
> This the v2 rouns of a this RFC patch:
> https://patchwork.kernel.org/patch/10066245/
> 
> The first patch is a simple fix that should be applied in any case.
> 
> I did not split the mgr_has_framedone() callback as a separate patch. It
> quite literally replaces the mgr_get_framedone_irq() and makes no
> sense without the "drm/omap: Make omapdss API more generic"-patch.
> 
> The patches have been rebased on top of the latest drm-next
> (350877626faba5d60cbb8cef2bdeb524212c780b).
> 
> Best regards,
> Jyri
> 
> Jyri Sarha (3):
>   drm/omap: Fail probe if irq registration fails
>   drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops
>   drm/omap: Make omapdss API more generic

I think the first two patches look fine. The third patch is, of course,
the interesting one. I did have some comments for that.

To be honest, I'm not sure what kind of irqhandling we'll end up with
when we get the omapdss & omapdrm merge completed and add support for
DSS6. But I still think this cleans up things. So even if in the end
we'd end up not using common irq code, the way there will be easier with
these changes.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] drm/omap: Make omapdss API more generic

[Tomi Valkeinen]

Hi,

On 01/01/18 13:55, Jyri Sarha wrote:
> The new omapdss API is HW independent and cleans up some of the DSS5
> specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
> register bits and replace them with HW independent generic u64 based
> macros. This new macros make it more straight forward to implement the
> IRQ code for the future DSS versions that do not share the same
> register structure as DSS2 to DSS5 has.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 148 
> --
>  drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  64 +++
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  16 ++--
>  drivers/gpu/drm/omapdrm/omap_crtc.h   |   2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.h|   3 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c| 136 +++
>  drivers/gpu/drm/omapdrm/omap_irq.h|   2 +-
>  drivers/gpu/drm/omapdrm/omap_plane.c  |   7 ++
>  drivers/gpu/drm/omapdrm/omap_plane.h  |   1 +
>  10 files changed, 267 insertions(+), 145 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 070053f..a80ebe1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -698,27 +698,12 @@ static const char *dispc_get_mgr_name(enum omap_channel 
> channel)
>   return mgr_desc[channel].name;
>  }
>  
> -static u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
> -{
> - return mgr_desc[channel].vsync_irq;
> -}
> -
> -static u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
> +static bool dispc_mgr_has_framedone(enum omap_channel channel)
>  {
>   if (channel == OMAP_DSS_CHANNEL_DIGIT && dispc.feat->no_framedone_tv)
> - return 0;
> -
> - return mgr_desc[channel].framedone_irq;
> -}
> -
> -static u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel)
> -{
> - return mgr_desc[channel].sync_lost_irq;
> -}
> + return false;
>  
> -u32 dispc_wb_get_framedone_irq(void)
> -{
> - return DISPC_IRQ_FRAMEDONEWB;
> + return true;
>  }

You can just do

return channel != OMAP_DSS_CHANNEL_DIGIT || !dispc.feat->no_framedone_tv;

>  
>  static void dispc_mgr_enable(enum omap_channel channel, bool enable)
> @@ -3604,6 +3589,121 @@ static void dispc_write_irqenable(u32 mask)
>   dispc_read_reg(DISPC_IRQENABLE);
>  }
>  
> +static u64 dispc_hw_to_api_irq(u32 hw)
> +{
> + u64 api = 0;
> +
> + if (hw & DISPC_IRQ_OCP_ERR)
> + api |= DSS_IRQ_DEVICE_OCP_ERR;
> +
> + if (hw & DISPC_IRQ_FRAMEDONE)
> + api |= DSS_IRQ_MGR_FRAME_DONE(0);
> + if (hw & DISPC_IRQ_VSYNC)
> + api |= DSS_IRQ_MGR_VSYNC_EVEN(0);
> + if (hw & DISPC_IRQ_SYNC_LOST)
> + api |= DSS_IRQ_MGR_SYNC_LOST(0);
> +
> + if (hw & DISPC_IRQ_EVSYNC_EVEN)
> + api |= DSS_IRQ_MGR_VSYNC_EVEN(1);
> + if (hw & DISPC_IRQ_EVSYNC_ODD)
> + api |= DSS_IRQ_MGR_VSYNC_ODD(1);
> + if (hw & DISPC_IRQ_SYNC_LOST_DIGIT)
> + api |= DSS_IRQ_MGR_SYNC_LOST(1);
> + if (hw & DISPC_IRQ_FRAMEDONETV)
> + api |= DSS_IRQ_MGR_FRAME_DONE(1);
> +
> + if (hw & DISPC_IRQ_SYNC_LOST2)
> + api |= DSS_IRQ_MGR_SYNC_LOST(2);
> + if (hw & DISPC_IRQ_VSYNC2)
> + api |= DSS_IRQ_MGR_VSYNC_EVEN(2);
> + if (hw & DISPC_IRQ_FRAMEDONE2)
> + api |= DSS_IRQ_MGR_FRAME_DONE(2);
> +
> + if (hw & DISPC_IRQ_SYNC_LOST3)
> + api |= DSS_IRQ_MGR_SYNC_LOST(3);
> + if (hw & DISPC_IRQ_VSYNC3)
> + api |= DSS_IRQ_MGR_VSYNC_EVEN(3);
> + if (hw & DISPC_IRQ_FRAMEDONE3)
> + api |= DSS_IRQ_MGR_FRAME_DONE(3);
> +
> + if (hw & DISPC_IRQ_GFX_FIFO_UNDERFLOW)
> + api |= DSS_IRQ_OVL_FIFO_UNDERFLOW(0);
> + if (hw & DISPC_IRQ_VID1_FIFO_UNDERFLOW)
> + api |= DSS_IRQ_OVL_FIFO_UNDERFLOW(1);
> + if (hw & DISPC_IRQ_VID2_FIFO_UNDERFLOW)
> + api |= DSS_IRQ_OVL_FIFO_UNDERFLOW(2);
> + if (hw & DISPC_IRQ_VID3_FIFO_UNDERFLOW)
> + api |= DSS_IRQ_OVL_FIFO_UNDERFLOW(3);
> +
> + return api;
> +}
> +
> +static u32 dispc_api_to_hw_irq(u64 api)
> +{
> + u32 hw = 0;
> +
> + if (api & DSS_IRQ_DEVICE_OCP_ERR)
> + hw |= DISPC_IRQ_OCP_ERR;
> +
> + if (api & DSS_IRQ_MGR_FRAME_DONE(0))
> + hw |= DISPC_IRQ_FRAMEDONE;
> + if (api & DSS_IRQ_MGR_VSYNC_EVEN(0))
> + hw |= DISPC_IRQ_VSYNC;
> + if (api & DSS_IRQ_MGR_SYNC_LOST(0))
> + hw |= DISPC_IRQ_SYNC_LOST;
> +
> + if (api & DSS_IRQ_MGR_VSYNC_EVEN(1))
> + hw |= DISPC_IRQ_EVSYNC_EVEN;
> + if (api & DSS_IRQ_MGR_VSYNC_ODD(1))
> + hw |= DISPC_IRQ_EVSYNC_ODD;
> + if (api & DSS_IRQ_MGR_SYNC_LOST(1))
> + hw |= DISPC_IRQ_SYNC_LOST_DIGIT;
> + if (api & DSS_IRQ_MGR_FRAME_DONE(1))
> + hw |= 

Re: [PATCH v2] drm/omap: plane zpos/zorder management improvements

[Tomi Valkeinen]

Hi,

On 03/01/18 11:16, Peter Ujfalusi wrote:
> Use the plane index as default zpos for all planes. Even if the
> application is not setting zpos/zorder explicitly we will have unique zpos
> for each plane.
> 
> Enforce that all planes must have unique zpos by refusing atomic update for
> planes with already used zpos.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Hi,
> 
> changes since v1:
> - Dropped the zpos normalization related patches
> - New patch based on the discussion, see commit message.
> 
> Regards,
> Peter
> 
>  drivers/gpu/drm/omapdrm/omap_plane.c | 26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 15e5d5d325c6..6aeda3cc2f8b 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -33,6 +33,7 @@
>  struct omap_plane {
>   struct drm_plane base;
>   enum omap_plane_id id;
> + int idx;
>   const char *name;
>  };
>  
> @@ -99,8 +100,7 @@ static void omap_plane_atomic_disable(struct drm_plane 
> *plane,
>   struct omap_plane *omap_plane = to_omap_plane(plane);
>  
>   plane->state->rotation = DRM_MODE_ROTATE_0;
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> -? 0 : omap_plane->id;
> + plane->state->zpos = omap_plane->idx;
>  
>   priv->dispc_ops->ovl_enable(omap_plane->id, false);
>  }
> @@ -109,15 +109,17 @@ static int omap_plane_atomic_check(struct drm_plane 
> *plane,
>  struct drm_plane_state *state)
>  {
>   struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_plane *p;
>  
>   if (!state->fb)
>   return 0;
>  
>   /* crtc should only be NULL when disabling (i.e., !state->fb) */
> - if (WARN_ON(!state->crtc))
> + if (WARN_ON(!crtc))
>   return 0;
>  
> - crtc_state = drm_atomic_get_existing_crtc_state(state->state, 
> state->crtc);
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
>   /* we should have a crtc state if the plane is attached to a crtc */
>   if (WARN_ON(!crtc_state))
>   return 0;
> @@ -125,6 +127,16 @@ static int omap_plane_atomic_check(struct drm_plane 
> *plane,
>   if (!crtc_state->enable)
>   return 0;
>  
> + drm_for_each_plane_mask(p, crtc->dev, crtc->state->plane_mask) {
> + if (plane->base.id == p->base.id)
> + continue;
> +
> + if (p->state->zpos == state->zpos) {
> + DBG("zpos must be unique (zpos: %u)", state->zpos);
> + return -EINVAL;
> + }
> + }

I think this should be done in omap_drv, or maybe in omap_crtc. You
don't want to check individual planes, but you want to ensure that none
of the planes have conflicting zpos'es. Strictly speaking, zpos is not
exactly a plane feature (even if it's set per-plane), it's more of a
composition feature.

Perhaps omap_crtc would be the best place, as the zpos must be unique on
a crtc, so in the crtc's atomic check you could check that all the
planes on that crtc have unique zpos.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/34] clk_ops: change round_rate() to return unsigned long

[Mauro Carvalho Chehab]

Em Mon,  1 Jan 2018 19:42:40 +
Bryan O'Donoghue  escreveu:

> Right now it is not possible to return a value larger than LONG_MAX on 32
> bit systems. You can pass a rate of ULONG_MAX but can't return anything
> past LONG_MAX due to the fact both the rounded_rate and negative error
> codes are represented in the return value of round_rate().
> 
> Most implementations either return zero on error or don't return error
> codes at all. A minority of implementations do return a negative number -
> typically -EINVAL or -ENODEV.
> 
> At the higher level then callers of round_rate() typically and rightly
> check for a value of <= 0.
> 
> It is possible then to convert round_rate() to an unsigned long return
> value and change error code indication for the minority from -ERRORCODE to
> a simple 0.
> 
> This patch is the first step in making it possible to scale round_rate past
> LONG_MAX, later patches will change the previously mentioned minority of
> round_rate() implementations to return zero only on error if those
> implementations currently return a negative error number. Implementations
> that do not return an error code of < 0 will be left as-is.
> 

>  drivers/media/platform/omap3isp/isp.c   |  4 ++--

Acked-by: Mauro Carvalho Chehab 

Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] drm/dp: Macro for DSC eDP Output BPP

[Manasi Navare]

This returns the maximum output BPP supported by the
eDP panel by reading the MAX_SUPPORTED_BPP DSC DPCD register.

Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 06e41b2..4e8f357 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -980,6 +980,16 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
 }
 
+/* DP/eDP DSC support */
+static inline u16
+drm_edp_dsc_get_output_bpp(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+   return dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - DP_DSC_SUPPORT] |
+   (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - DP_DSC_SUPPORT] &
+DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
+DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
+}
+
 /*
  * DisplayPort AUX channel
  */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4.15 0/4] Backport DC commits to fix display corruption

[Carlo Caione]

On Wed, Jan 3, 2018 at 5:32 PM, Harry Wentland  wrote:
> On 2018-01-03 12:11 PM, Carlo Caione wrote:
>> From: Carlo Caione 
>>
>> Hi,
>> on several laptops [0] we are seeing display corruption when using multiple /
>> external displays. We already opened an issue upstream [1].
>> The following 4 patches are taken from agd5f/amd-staging-drm-next and they 
>> seem
>> able to solve the issue.
>> Can those be included in 4.15?
>>
>> Thank you,
>>
>> [0] Acer Aspire E5-553G (AMD FX-9800P RADEON R7)
>> Acer Aspire E5-523G (AMD E2-9010 RADEON R2)
>> Acer Aspire A315-21 (AMD A4-9120 RADEON R3)
>> Acer Aspire A515-41G (AMD A10-9620 RADEON R5)
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=104319
>>
>> Harry Wentland (1):
>>   drm/amd/display: Both timing_sync and multisync need stream_count > 1
>>
>> Leo (Sunpeng) Li (1):
>>   drm/amd/display: Change frontend/backend programming sequence
>>
>> Mikita Lipski (2):
>>   drm/amd/display: Adding DCN1 registers
>>   drm/amd/display: Multi display synchronization logic
>>
>
> I'm surprised Mikita and my patches are required here. Are you sure they make 
> a difference for display corruption or did you simply add them to make pull 
> Leo's patch more cleanly?

Yes, the only strictly required patch is the patch by Leo. The others
are just pulled in to make that apply cleanly.

Thanks,

-- 
Carlo Caione  |  +44.7384.69.16.04  |  Endless
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

[Jernej Škrabec]

Hi Rob,

Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
> On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
> > This commit adds all necessary compatibles and descriptions needed to
> > implement A83T HDMI pipeline.
> > 
> > Mixer is already properly described, so only compatible is added.
> > 
> > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,
> > contrary to all TCONs currently described. Because of that, TCON
> > documentation is extended.
> > 
> > A83T features Synopsys DW HDMI controller with a custom PHY which looks
> > like Synopsys Gen2 PHY with few additions. Since there is no
> > documentation, needed properties were found out through experimentation
> > and reading BSP code.
> > 
> > At the end, example is added for newer SoCs, which features DE2 and DW
> > HDMI.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  .../bindings/display/sunxi/sun4i-drm.txt   | 188
> >  - 1 file changed, 181 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 9f073af4c711..3eca258096a5 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > 
> > @@ -64,6 +64,40 @@ Required properties:
> >  first port should be the input endpoint. The second should be the
> >  output, usually to an HDMI connector.
> > 
> > +DWC HDMI TX Encoder
> > +-
> > +
> > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> > +
> > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> > +following device-specific properties.
> > +
> > +Required properties:
> > +
> > +  - compatible: value must be one of:
> > +* "allwinner,sun8i-a83t-dw-hdmi"
> > +  - reg: two pairs of base address and size of memory-mapped region,
> > first
> > +for controller and second for PHY
> > +registers.
> 
> Seems like the phy should be a separate node and use the phy binding.
> You can use the phy binding even if you don't use the kernel phy
> framework...

Unfortunately, it's not so straighforward. Phy is actually accessed through 
I2C implemented in HDMI controller. Second memory region in this case has 
small influence on phy. However, it has big influence on controller. For 
example, magic number has to be written in one register in second memory 
region in order to unlock read access to any register from first memory region 
(controller). However, they shouldn't be merged to one region, because first 
memory region requires byte access while second memory region can be accessed 
per byte or word.

To complicate things more, later I want to add support for another SoC which 
has same glue layer (unlocking read access, etc.) and uses memory mapped phy 
registers in second memory region.

I think current binding is the least complicated way to represent this.

> 
> > +  - reg-io-width: See dw_hdmi.txt. Shall be 1.
> > +  - interrupts: HDMI interrupt number
> > +  - clocks: phandles to the clocks feeding the HDMI encoder
> > +* iahb: the HDMI bus clock
> > +* isfr: the HDMI register clock
> > +* tmds: the HDMI tmds clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the encoder
> > +* ctrl: the reset line for the controller
> > +* phy: the reset line for the PHY
> > +  - reset-names: the reset names mentioned above
> > +
> > +  - ports: A ports node with endpoint definitions as defined in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +first port should be the input endpoint. The second should be the
> > +output, usually to an HDMI connector.
> > +
> > 
> >  TV Encoder
> >  --
> > 
> > @@ -94,18 +128,17 @@ Required properties:
> > * allwinner,sun7i-a20-tcon
> > * allwinner,sun8i-a33-tcon
> > * allwinner,sun8i-a83t-tcon-lcd
> > 
> > +   * allwinner,sun8i-a83t-tcon-tv
> > 
> > * allwinner,sun8i-v3s-tcon
> >   
> >   - reg: base address and size of memory-mapped region
> >   - interrupts: interrupt associated to this IP
> > 
> > - - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > 
> > + - clocks: phandles to the clocks feeding the TCON. One is needed:
> > - 'ahb': the interface clocks
> > 
> > -   - 'tcon-ch0': The clock driving the TCON channel 0
> > 
> >   - resets: phandles to the reset controllers driving the encoder
> >   
> > - "lcd": the reset line for the TCON channel 0
> >   
> >   - clock-names: the clock names mentioned above
> >   - reset-names: the reset names mentioned above
> > 
> > - 

[PATCH v2 1/5] drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT

[Manasi Navare]

This patch defines the DP DSC receiver capability size that gives
total number of DP DSC DPCD registers.
This also adds a missing SHIFT define missed in the
commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature")

v2:
* Missed the SHIFT define that I mentioned in the message

Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Cc:  dri-devel@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..06e41b2 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -223,6 +223,8 @@
 #define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
 
 #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
+# define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
+# define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8
 
 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
 # define DP_DSC_RGB (1 << 0)
@@ -271,6 +273,7 @@
 # define DP_DSC_THROUGHPUT_MODE_1_1000  (14 << 4)
 
 #define DP_DSC_MAX_SLICE_WIDTH  0x06C
+#define DP_DSC_MAX_SLICE_WIDTH_VALUE2560
 
 #define DP_DSC_SLICE_CAP_2  0x06D
 # define DP_DSC_16_PER_DP_DSC_SINK  (1 << 0)
@@ -894,6 +897,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
+#define DP_DSC_RECEIVER_CAP_SIZE0xf
 #define EDP_PSR_RECEIVER_CAP_SIZE  2
 #define EDP_DISPLAY_CTL_CAP_SIZE   3
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4.15 4/4] drm/amd/display: Change frontend/backend programming sequence

[Carlo Caione]

From: "Leo (Sunpeng) Li" 

This is a follow-up to the following change:

Yongqiang Sun: Program front end first when set mode.

Due to pipe-splitting features, how we handle stream enabling and
disabling needs to change.

In the case of pipe split disable, two planes need to be combined back
into the same stream. This needs to be done before any stream
programming happens.

The previous patch addresses this, but breaks cross-platform
compatibility. It's not guaranteed that a dc commit will be called
separately to program planes and streams.

Therefore, we handle the combined commit case by doing plane programming
both before and after stream programming, to handle pipe split disable
and plane enable respectively.

Signed-off-by: Leo (Sunpeng) Li 
Reviewed-by: Tony Cheng 
Acked-by: Harry Wentland 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 41 ++--
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 5b3ca80d9401..8eeda0fb5c41 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -871,6 +871,33 @@ static enum dc_status dc_commit_state_no_check(struct dc 
*dc, struct dc_state *c
if (!dcb->funcs->is_accelerated_mode(dcb))
dc->hwss.enable_accelerated_mode(dc);
 
+   /* Combine planes if required, in case of pipe split disable */
+   for (i = 0; i < dc->current_state->stream_count; i++) {
+   dc->hwss.apply_ctx_for_surface(
+   dc, dc->current_state->streams[i],
+   dc->current_state->stream_status[i].plane_count,
+   dc->current_state);
+   }
+
+   /* Program hardware */
+   dc->hwss.ready_shared_resources(dc, context);
+
+   for (i = 0; i < dc->res_pool->pipe_count; i++) {
+   pipe = >res_ctx.pipe_ctx[i];
+   dc->hwss.wait_for_mpcc_disconnect(dc, dc->res_pool, pipe);
+   }
+
+   result = dc->hwss.apply_ctx_to_hw(dc, context);
+
+   if (result != DC_OK)
+   goto fail;
+
+   if (context->stream_count > 1) {
+   enable_timing_multisync(dc, context);
+   program_timing_sync(dc, context);
+   }
+
+   /* Program all planes within new context*/
for (i = 0; i < context->stream_count; i++) {
const struct dc_sink *sink = context->streams[i]->sink;
 
@@ -902,19 +929,7 @@ static enum dc_status dc_commit_state_no_check(struct dc 
*dc, struct dc_state *c
context->streams[i]->timing.pix_clk_khz);
}
 
-   dc->hwss.ready_shared_resources(dc, context);
-
-   for (i = 0; i < dc->res_pool->pipe_count; i++) {
-   pipe = >res_ctx.pipe_ctx[i];
-   dc->hwss.wait_for_mpcc_disconnect(dc, dc->res_pool, pipe);
-   }
-   result = dc->hwss.apply_ctx_to_hw(dc, context);
-
-   if (context->stream_count > 1) {
-   enable_timing_multisync(dc, context);
-   program_timing_sync(dc, context);
-   }
-
+fail:
dc_enable_stereo(dc, context, dc_streams, context->stream_count);
 
for (i = 0; i < context->stream_count; i++) {
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

[Christophe LEROY]

Le 25/12/2017 à 02:34, Yisheng Xie a écrit :



On 2017/12/24 17:05, christophe leroy wrote:



Le 23/12/2017 à 14:48, Greg KH a écrit :

On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:

Hi all,

When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache.


For all arches?  Really?  Look at MIPS, and x86, they have different
functions.


While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).

I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.


I don't think this can be done, what am I missing?  These functions are
not identical, sorry for missing that before.


devm_ioremap() and devm_ioremap_nocache() are quite similar, both use 
devm_ioremap_release() for the release, why not just defining:

static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size, bool nocache)
{
[...]
 if (nocache)
 addr = ioremap_nocache(offset, size);
 else
 addr = ioremap(offset, size);
[...]
}

then in include/linux/io.h

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, false);}

static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, true);}


Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc, 
devm_ioremap_nocache
May be we can use an enum like:
typedef enum {
DEVM_IOREMAP = 0,
DEVM_IOREMAP_NOCACHE,
DEVM_IOREMAP_WC,
} devm_ioremap_type;

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size)
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}

  static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}

  static inline void __iomem *devm_ioremap_wc(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}

  static void __iomem *__devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size, devm_ioremap_type type)
  {
  void __iomem **ptr, *addr = NULL;
  [...]
  switch (type){
  case DEVM_IOREMAP:
  addr = ioremap(offset, size);
  break;
  case DEVM_IOREMAP_NOCACHE:
  addr = ioremap_nocache(offset, size);
  break;
  case DEVM_IOREMAP_WC:
  addr = ioremap_wc(offset, size);
  break;
  }
  [...]
  }



That looks good to me, will you submit a v4 ?

Christophe



Thanks
Yisheng



Christophe



thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel