[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #14 from Bill Fraser (bill.fra...@gmail.com) ---
(In reply to Daniel Vetter from comment #13)
> Created attachment 273575 [details]
> test patch on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2, v2

That patch fixes it for me!

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

[Bug 103917] [gfx9/Vega] Performance regression in master, 17.3 works fine

[bugzilla-daemon]

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

--- Comment #2 from Vedran Miletić  ---
Last week I rechecked, but all I got on master was non-working mouse clicks
(weird, I know) under Wayland and crashes under Xorg. I'll recheck again.

-- 
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 104599] corrupted desktop graphics with latest git intel driver

[bugzilla-daemon]

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

--- Comment #3 from Mario Kleiner  ---
This is running the new GNOME based Ubuntu GUI with Gnome-Shell Wayland, right?

With "Windows control did not work" you mean it doesn't respond to
mouse-clicks?

In that case it is known bugs/limitations in gnome-shell for depth 30/10bpc
mode. GNOME Shells picking code can't handle 10 bit per color channel.

Additionally Gnome-Shells Wayland compositor doesn't handle anything but
bgrx or bgra framebuffers in its drm/kms backend. It takes whatever
framebuffer format it gets, e.g., bgrx1010102 and hands it to the kernel as
bgrx, so the gpu misinterprets a 10 bit image as a 8 bit image during
scanout, which ends badly.

-- 
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 v2 5/8] 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 
---
v2
- Change the SPDX identifier format
- Split drm properties into a separate patch
---
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 ++
 drivers/gpu/drm/xlnx/zynqmp_dp.h |   37 +
 2 files changed, 1775 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..9c9f4df
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -0,0 +1,1738 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DisplayPort Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#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  

[PATCH v2 6/8] 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 
---
- Change the SPDX identifier format
---
---
 drivers/gpu/drm/xlnx/Kconfig|  11 +++
 drivers/gpu/drm/xlnx/Makefile   |   3 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 149 
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h |  27 +++
 4 files changed, 190 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..517b492
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DP Subsystem Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#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);
+   

[PATCH v2 4/8] 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 controller and
DisplayPort encoder / transmitter. This driver handles the display
controller part of the pipeline that handles buffer management and
blending.

Signed-off-by: Hyun Kwon 
---
v2
- Use drm_fb_cma_get_gem_addr()
- Use drm_crtc_arm_vblank_event()
- Split drm properties into a separate patch
- Remove dummy funcs
- Don't add offset as it's already done by a new helper
- Change the SPDX identifier format
- Minor change of a commit message
---
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 2680 
 drivers/gpu/drm/xlnx/zynqmp_disp.h |   36 +
 2 files changed, 2716 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..4ca9db3
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -0,0 +1,2680 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Display Controller Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#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

[PATCH v2 8/8] drm: xlnx: zynqmp_dp: Add drm properties

[Hyun Kwon]

Add drm properties for DisplayPort synchronous mode and bpc
configurations.

Signed-off-by: Hyun Kwon 
---
v2
- Split from the original patch
---
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 116 ++-
 1 file changed, 114 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 9c9f4df..e1e8237 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -302,6 +302,8 @@ struct zynqmp_dp_config {
  * struct zynqmp_dp - Xilinx DisplayPort core
  * @encoder: the drm encoder structure
  * @connector: the drm connector structure
+ * @sync_prop: synchronous mode property
+ * @bpc_prop: bpc mode property
  * @dev: device structure
  * @dpsub: Display subsystem
  * @drm: DRM core
@@ -323,6 +325,8 @@ struct zynqmp_dp_config {
 struct zynqmp_dp {
struct drm_encoder encoder;
struct drm_connector connector;
+   struct drm_property *sync_prop;
+   struct drm_property *bpc_prop;
struct device *dev;
struct zynqmp_dpsub *dpsub;
struct drm_device *drm;
@@ -1116,6 +1120,37 @@ static void zynqmp_dp_update_misc(struct zynqmp_dp *dp)
 }

 /**
+ * zynqmp_dp_set_sync_mode - Set the sync mode bit in the software misc state
+ * @dp: DisplayPort IP core structure
+ * @mode: flag if the sync mode should be on or off
+ *
+ * Set the bit in software misc state. To apply to hardware,
+ * zynqmp_dp_update_misc() should be called.
+ */
+static void zynqmp_dp_set_sync_mode(struct zynqmp_dp *dp, bool mode)
+{
+   struct zynqmp_dp_config *config = >config;
+
+   if (mode)
+   config->misc0 |= ZYNQMP_DP_TX_MAIN_STREAM_MISC0_SYNC;
+   else
+   config->misc0 &= ~ZYNQMP_DP_TX_MAIN_STREAM_MISC0_SYNC;
+}
+
+/**
+ * zynqmp_dp_get_sync_mode - Get the sync mode state
+ * @dp: DisplayPort IP core structure
+ *
+ * Return: true if the sync mode is on, or false
+ */
+static bool zynqmp_dp_get_sync_mode(struct zynqmp_dp *dp)
+{
+   struct zynqmp_dp_config *config = >config;
+
+   return !!(config->misc0 & ZYNQMP_DP_TX_MAIN_STREAM_MISC0_SYNC);
+}
+
+/**
  * zynqmp_dp_set_bpc - Set bpc value in software misc state
  * @dp: DisplayPort IP core structure
  * @bpc: bits per component
@@ -1165,6 +1200,17 @@ static u8 zynqmp_dp_set_bpc(struct zynqmp_dp *dp, u8 bpc)
 }

 /**
+ * zynqmp_dp_get_bpc - Set bpc value from software state
+ * @dp: DisplayPort IP core structure
+ *
+ * Return: current bpc value
+ */
+static u8 zynqmp_dp_get_bpc(struct zynqmp_dp *dp)
+{
+   return dp->config.bpc;
+}
+
+/**
  * zynqmp_dp_encoder_mode_set_transfer_unit - Set the transfer unit values
  * @dp: DisplayPort IP core structure
  * @mode: requested display mode
@@ -1368,6 +1414,51 @@ static void zynqmp_dp_connector_destroy(struct 
drm_connector *connector)
drm_connector_cleanup(connector);
 }

+static int
+zynqmp_dp_connector_atomic_set_property(struct drm_connector *connector,
+   struct drm_connector_state *state,
+   struct drm_property *property,
+   uint64_t val)
+{
+   struct zynqmp_dp *dp = connector_to_dp(connector);
+   int ret;
+
+   if (property == dp->sync_prop) {
+   zynqmp_dp_set_sync_mode(dp, val);
+   } else if (property == dp->bpc_prop) {
+   u8 bpc;
+
+   bpc = zynqmp_dp_set_bpc(dp, val);
+   if (bpc) {
+   drm_object_property_set_value(>base,
+ property, bpc);
+   ret = -EINVAL;
+   }
+   } else {
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int
+zynqmp_dp_connector_atomic_get_property(struct drm_connector *connector,
+   const struct drm_connector_state *state,
+   struct drm_property *property,
+   uint64_t *val)
+{
+   struct zynqmp_dp *dp = connector_to_dp(connector);
+
+   if (property == dp->sync_prop)
+   *val = zynqmp_dp_get_sync_mode(dp);
+   else if (property == dp->bpc_prop)
+   *val =  zynqmp_dp_get_bpc(dp);
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
 static const struct drm_connector_funcs zynqmp_dp_connector_funcs = {
.detect = zynqmp_dp_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -1375,6 +1466,8 @@ static const struct drm_connector_funcs 
zynqmp_dp_connector_funcs = {
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
.reset  = drm_atomic_helper_connector_reset,
+   .atomic_set_property= 

[PATCH v2 1/8] dt-bindings: display: xlnx: Add bindings for Xilinx display pipeline

[Hyun Kwon]

The dt binding for Xilinx display pipeline. The pipeline can be
composed with multiple and different types of sub-devices. This node
is to represent the entire pipeline as a single entity.

Signed-off-by: Hyun Kwon 
---
v2
- Remove linux specific terms
- Elaborate details, ex regarding port binding
- Rename xlnx,kms to xlnx,display
- Rename the file name to xlnx,display.txt
- Add examples of hardware blocks
---
---
 .../bindings/display/xlnx/xlnx,display.txt | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/xlnx/xlnx,display.txt

diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,display.txt 
b/Documentation/devicetree/bindings/display/xlnx/xlnx,display.txt
new file mode 100644
index 000..fde1a35
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,display.txt
@@ -0,0 +1,68 @@
+Xilinx Display Pipeline
+---
+
+Xilinx display pipeline can be designed with various types of multiple IPs:
+IPs hardened on chip, ob board IPs, and soft IPs in programmable logic.
+While each component would need its own node, this node represents
+a whole display pipeline as a single entity by integrating individual subdevice
+with glue logics.
+
+The following illustrates some examples of topology:
+
+A linear pipeline with multiple blocks:
+
+   SoC DMA -> SoC display controller -> SoC display enc
+or,
+   FPGA DMA -> FPGA display controller -> FPGA display enc
+
+A pipeline with branches:
+
+   SoC DMA -> SoC display controller -> SoC display enc
+   |
+   FPGA DMA->
+or,
+   SoC DMA -> SoC display controller -> SoC display enc
+ |
+ -> FPAG display enc
+
+or,
+
+   SoC DMA -> SoC display controller -> SoC display enc
+   | |
+   FPGA display controller ->-> FPGA display enc
+
+Required properties:
+
+- compatible: Must be "xlnx,display".
+
+- ports: phandles for ports of display controller subdevice.
+  In the display controller port nodes, topology for entire pipeline
+  should be described using the DT bindings defined in
+  Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+   xlnx_display {
+   compatible = "xlnx,display";
+   ports = <_controller_port>;
+   };
+
+   display_controller {
+   ...
+   display_controller_port: port@0 {
+   display_controller_ep: endpoint {
+   remote-endpoint = <_controller_ep>;
+   };
+   };
+   ...
+   };
+
+   dp_controller {
+   ...
+   dp_controller_port: port@0 {
+   dp_controller_ep: endpoint {
+   remote-endpoint = <_controller_ep>;
+   };
+   };
+   ...
+   };
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/8] drm: xlnx: zynqmp_disp: Add drm properties

[Hyun Kwon]

Add drm properties for global alpha, output color, background color,
and test pattern generation.

Signed-off-by: Hyun Kwon 
---
v2
- Split from the original patch
- Some props are important feature to be included
---
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 193 -
 1 file changed, 192 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 4ca9db3..3308764 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -413,12 +413,19 @@ struct zynqmp_disp_aud {
  * @av_buf: AV buffer manager block
  * @aud:Audio block
  * @layers: layers
+ * @g_alpha_prop: global alpha property
  * @alpha: current global alpha value
+ * @g_alpha_en_prop: the global alpha enable property
  * @alpha_en: flag if the global alpha is enabled
+ * @color_prop: output color format property
  * @color: current output color value
+ * @bg_c0_prop: 1st component of background color property
  * @bg_c0: current value of 1st background color component
+ * @bg_c1_prop: 2nd component of background color property
  * @bg_c1: current value of 2nd background color component
+ * @bg_c2_prop: 3rd component of background color property
  * @bg_c2: current value of 3rd background color component
+ * @tpg_prop: Test Pattern Generation mode property
  * @tpg_on: current TPG mode state
  * @event: pending vblank event request
  * @_ps_pclk: Pixel clock from PS
@@ -442,12 +449,19 @@ struct zynqmp_disp {
struct zynqmp_disp_av_buf av_buf;
struct zynqmp_disp_aud aud;
struct zynqmp_disp_layer layers[ZYNQMP_DISP_NUM_LAYERS];
+   struct drm_property *g_alpha_prop;
u32 alpha;
+   struct drm_property *g_alpha_en_prop;
bool alpha_en;
+   struct drm_property *color_prop;
unsigned int color;
+   struct drm_property *bg_c0_prop;
u32 bg_c0;
+   struct drm_property *bg_c1_prop;
u32 bg_c1;
+   struct drm_property *bg_c2_prop;
u32 bg_c2;
+   struct drm_property *tpg_prop;
bool tpg_on;
struct drm_pending_vblank_event *event;
/* Don't operate directly on _ps_ */
@@ -1621,6 +1635,21 @@ static int zynqmp_disp_layer_set_tpg(struct zynqmp_disp 
*disp,
 }

 /**
+ * zynqmp_disp_get_tpg - Get the TPG mode status
+ * @disp: Display subsystem
+ * @layer: Video layer
+ *
+ * Return if the TPG is enabled or not.
+ *
+ * Return: true if TPG is on, otherwise false
+ */
+static bool zynqmp_disp_layer_get_tpg(struct zynqmp_disp *disp,
+ struct zynqmp_disp_layer *layer)
+{
+   return disp->tpg_on;
+}
+
+/**
  * zynqmp_disp_get_fmt - Get the supported DRM formats of the layer
  * @disp: Display subsystem
  * @layer: layer to get the formats
@@ -1879,7 +1908,7 @@ static int zynqmp_disp_layer_create(struct zynqmp_disp 
*disp)
  */

 /*
- * Output format enumeration
+ * Output format enumeration.
  * The ID should be aligned with blend_output_fmts.
  * The string should be aligned with how zynqmp_dp_set_color() decodes.
  */
@@ -1937,6 +1966,19 @@ static void zynqmp_disp_set_alpha(struct zynqmp_disp 
*disp, u32 alpha)
 }

 /**
+ * zynqmp_disp_get_alpha - Get the alpha value
+ * @disp: Display subsystem
+ *
+ * Get the alpha value for blending.
+ *
+ * Return: current alpha value.
+ */
+static u32 zynqmp_disp_get_alpha(struct zynqmp_disp *disp)
+{
+   return disp->alpha;
+}
+
+/**
  * zynqmp_disp_set_g_alpha - Enable/disable the global alpha blending
  * @disp: Display subsystem
  * @enable: flag to enable or disable alpha blending
@@ -1950,6 +1992,19 @@ static void zynqmp_disp_set_g_alpha(struct zynqmp_disp 
*disp, bool enable)
 }

 /**
+ * zynqmp_disp_get_g_alpha - Get the global alpha status
+ * @disp: Display subsystem
+ *
+ * Get the global alpha statue.
+ *
+ * Return: true if global alpha is enabled, or false.
+ */
+static bool zynqmp_disp_get_g_alpha(struct zynqmp_disp *disp)
+{
+   return disp->alpha_en;
+}
+
+/**
  * zynqmp_disp_enable - Enable the Display subsystem
  * @disp: Display subsystem
  *
@@ -2172,9 +2227,54 @@ static void zynqmp_disp_plane_destroy(struct drm_plane 
*plane)
drm_plane_cleanup(plane);
 }

+static int
+zynqmp_disp_plane_atomic_set_property(struct drm_plane *plane,
+ struct drm_plane_state *state,
+ struct drm_property *property, u64 val)
+{
+   struct zynqmp_disp_layer *layer = plane_to_layer(plane);
+   struct zynqmp_disp *disp = layer->disp;
+   int ret = 0;
+
+   if (property == disp->g_alpha_prop)
+   zynqmp_disp_set_alpha(disp, val);
+   else if (property == disp->g_alpha_en_prop)
+   zynqmp_disp_set_g_alpha(disp, val);
+   else if (property == disp->tpg_prop)
+   ret = zynqmp_disp_layer_set_tpg(disp, layer, val);
+   else
+   return -EINVAL;
+
+   return ret;
+}
+

[PATCH v2 3/8] 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 
---
v2
- Group multiple ports under 'ports'
- Replace linux specific terms with generic hardware descriptions
---
---
 .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 98 ++
 1 file changed, 98 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..dbcbde5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
@@ -0,0 +1,98 @@
+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: There are 2 logical blocks in the IP: display controller and
+  DisplayPort encoder. Each block can be used / connected independently with
+  external device, hence ports for each block are required using DT bindings
+  defined in Documentation/devicetree/bindings/graph.txt. Refer to
+  ./xlnx,display.txt for how topology for entire pipeline is described.
+
+- 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-names = "dp-phy0", "dp-phy1";
+
+   power-domains = <_dp>;
+
+   vid-layer {
+   dma-names = "vid0", "vid1", "vid2";
+   dmas = <_dpdma 0>,
+  <_dpdma 1>,
+  <_dpdma 2>;
+   };
+
+   gfx-layer {
+   dma-names = "gfx0";
+   dmas = <_dpdma 3>;
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   display_port: port@0 {
+   reg = <0>;
+   display_port: endpoint {
+   remote-endpoint = <_port>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   dp_port: endpoint {
+   remote-endpoint = <_port>;
+   };
+   };
+   }
+   };
+};
+
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/8] 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 to integrate multiple subdevices and to represent
the entire pipeline as a single DRM device. The driver includes helpers
(ex, framebuffer and gem helpers) and glue logics (ex, crtc interface).

Signed-off-by: Hyun Kwon 
---
v2
- Change the SPDX identifier format
- Merge patches(crtc, gem, fb) into single one
v2 of xlnx_drv
- Rename kms to display in xlnx_drv
- Replace some xlnx specific fb helper with common helpers in xlnx_drv
- Don't set the commit tail callback in xlnx_drv
- Support 'ports' graph binding in xlnx_drv
v2 of xlnx_fb
- Remove wrappers in xlnx_fb
- Replace some functions with drm core helpers in xlnx_fb
---
---
 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 | 203 ++
 drivers/gpu/drm/xlnx/xlnx_crtc.h |  78 +++
 drivers/gpu/drm/xlnx/xlnx_drv.c  | 447 +++
 drivers/gpu/drm/xlnx/xlnx_drv.h  |  30 +++
 drivers/gpu/drm/xlnx/xlnx_fb.c   | 352 ++
 drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
 drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
 drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 +++
 13 files changed, 1241 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_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

diff --git a/MAINTAINERS b/MAINTAINERS
index 40aea85..f2c4a6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4791,6 +4791,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
new file mode 100644
index 000..89beb9e
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx DRM crtc driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under 

[PATCH 2/6] drm/exynos: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_device->normalize_zpos.

Signed-off-by: Peter Ujfalusi 
CC: Inki Dae 
CC: Joonyoung Shim 
CC: Seung-Woo Kim 
CC: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 21 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  2 +-
 3 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b96bd5a781b2..181ebd42fc9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -38,26 +38,6 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
-int exynos_atomic_check(struct drm_device *dev,
-   struct drm_atomic_state *state)
-{
-   int ret;
-
-   ret = drm_atomic_helper_check_modeset(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_check_planes(dev, state);
-   if (ret)
-   return ret;
-
-   return ret;
-}
-
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv;
@@ -339,6 +319,7 @@ static int exynos_drm_bind(struct device *dev)
 
dev_set_drvdata(dev, drm);
drm->dev_private = (void *)private;
+   drm->normalize_zpos = true;
 
/* the first real CRTC device is used for all dma mapping operations */
private->dma_dev = exynos_drm_get_dma_device();
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 589d465a7f88..4585d9e00c87 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -276,7 +276,6 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
 
 int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
-int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);
 
 
 extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 0faaf829f5bf..d388231e43e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -206,7 +206,7 @@ static struct drm_mode_config_helper_funcs 
exynos_drm_mode_config_helpers = {
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
-   .atomic_check = exynos_atomic_check,
+   .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
-- 
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

[PATCH 3/6] drm/tegra: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_device->normalize_zpos.

Signed-off-by: Peter Ujfalusi 
CC: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 27 +++
 1 file changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d50bddb2e447..1ef9f4eede07 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -33,29 +33,6 @@ struct tegra_drm_file {
struct mutex lock;
 };
 
-static int tegra_atomic_check(struct drm_device *drm,
- struct drm_atomic_state *state)
-{
-   int err;
-
-   err = drm_atomic_helper_check_modeset(drm, state);
-   if (err < 0)
-   return err;
-
-   err = drm_atomic_normalize_zpos(drm, state);
-   if (err < 0)
-   return err;
-
-   err = drm_atomic_helper_check_planes(drm, state);
-   if (err < 0)
-   return err;
-
-   if (state->legacy_cursor_update)
-   state->async_update = !drm_atomic_helper_async_check(drm, 
state);
-
-   return 0;
-}
-
 static struct drm_atomic_state *
 tegra_atomic_state_alloc(struct drm_device *drm)
 {
@@ -90,7 +67,7 @@ static const struct drm_mode_config_funcs 
tegra_drm_mode_config_funcs = {
 #ifdef CONFIG_DRM_FBDEV_EMULATION
.output_poll_changed = drm_fb_helper_output_poll_changed,
 #endif
-   .atomic_check = tegra_atomic_check,
+   .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.atomic_state_alloc = tegra_atomic_state_alloc,
.atomic_state_clear = tegra_atomic_state_clear,
@@ -1230,6 +1207,8 @@ static int host1x_drm_probe(struct host1x_device *dev)
 
dev_set_drvdata(>dev, drm);
 
+   drm->normalize_zpos = true;
+
err = drm_dev_register(drm, 0);
if (err < 0)
goto unref;
-- 
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

[PATCH 6/6] drm/omap: Use normalized zpos for plane placement

[Peter Ujfalusi]

Planes with identical zpos value will result undefined behavior:
disappearing planes, screen flickering and it is not supported by the
hardware.

Use normalized zpos to make sure that we don't encounter invalid
configuration.

Signed-off-by: Peter Ujfalusi 
CC: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2c02b955dd52..25f06f09fbe2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -651,6 +651,7 @@ static int pdev_probe(struct platform_device *pdev)
return PTR_ERR(ddev);
 
ddev->dev_private = priv;
+   ddev->normalize_zpos = true;
platform_set_drvdata(pdev, ddev);
 
omap_crtc_pre_init();
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 7d789d1551a1..2c19d2239bc5 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane *plane,
info.rotation_type = OMAP_DSS_ROT_NONE;
info.rotation = DRM_MODE_ROTATE_0;
info.global_alpha = 0xff;
-   info.zorder = state->zpos;
+   info.zorder = state->normalized_zpos;
 
/* update scanout: */
omap_framebuffer_update_scanout(state->fb, state, );
-- 
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

[PATCH 1/6] drm: Add drm_device->normalize_zpos boolean

[Peter Ujfalusi]

Instead of drivers duplicating the drm_atomic_helper_check() code to be
able to normalize the zpos they can use the normalize_zpos flag to let the
drm core to do it.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/drm_atomic_helper.c | 6 ++
 include/drm/drm_device.h| 8 
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..143cab4b2a89 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -885,6 +885,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
 
+   if (dev->normalize_zpos) {
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+   }
+
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..9c45d1155bfd 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -121,6 +121,14 @@ struct drm_device {
 */
bool vblank_disable_immediate;
 
+   /**
+* @normalize_zpos:
+*
+* If true the drm core will call drm_atomic_normalize_zpos() as part of
+* atomic mode checking from drm_atomic_helper_check()
+*/
+   bool normalize_zpos;
+
/**
 * @vblank:
 *
-- 
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

[PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
  root of the overlay
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig |   2 +
 drivers/gpu/drm/rcar-du/Makefile|   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_of.c| 451 
 drivers/gpu/drm/rcar-du/rcar_du_of.h|  16 +
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts |  82 +
 5 files changed, 553 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..8ed569a0f462 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -5,10 +5,11 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_group.o \
 rcar_du_kms.o \
 rcar_du_lvdscon.o \
+rcar_du_of.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of_lvds.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..2bf91201fc93
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,451 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+#ifdef CONFIG_DRM_RCAR_LVDS
+
+struct rcar_du_of_overlay {
+   struct device_node *np;
+   void *data;
+   void *mem;
+};
+
+static void __init rcar_du_of_free_overlay(struct rcar_du_of_overlay *overlay)
+{
+   of_node_put(overlay->np);
+   kfree(overlay->data);
+   kfree(overlay->mem);
+}
+
+static int __init rcar_du_of_get_overlay(struct rcar_du_of_overlay *overlay,
+void *begin, void *end)
+{
+   const size_t size = end - begin;
+
+   memset(overlay, 0, sizeof(*overlay));
+
+   if (!size)
+   return -EINVAL;
+
+   overlay->data = kmemdup(begin, size, GFP_KERNEL);
+   if (!overlay->data)
+   return -ENOMEM;
+
+   overlay->mem = of_fdt_unflatten_tree(overlay->data, NULL, >np);
+   if (!overlay->mem) {
+   rcar_du_of_free_overlay(overlay);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static struct device_node __init *
+rcar_du_of_find_node_by_path(struct device_node *parent, const char *path)
+{
+   parent = of_node_get(parent);
+   if (!parent)
+   return NULL;
+
+   while (parent && *path == '/') {
+   struct device_node *child = NULL;
+   struct device_node *node;
+   const char *next;
+   size_t len;
+
+   /* Skip the initial '/' delimiter and find the next one. */
+   path++;
+   next = strchrnul(path, '/');
+   len = next - path;
+   if (!len)
+   goto error;
+
+   for_each_child_of_node(parent, node) {
+   const char *name = kbasename(node->full_name);
+
+   if (strncmp(path, name, len) == 0 &&
+   strlen(name) 

[PATCH v2 01/12] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- Fixed "renesas,r8a7743-lvds" description
- Document the resets property
- Fixed typo
---
 .../bindings/display/bridge/renesas,lvds.txt   | 56 ++
 MAINTAINERS|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..2b19ce51ec07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,56 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
+Gen2, R-Car Gen3 and RZ/G SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
+  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+- resets: A phandle + reset specifier for the module reset
+
+Required nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel RGB input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   resets = < 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 40aea858c7ea..5609a7f5ac4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4725,6 +4725,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 07/12] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
 arch/arm/boot/dts/r8a7791-porter.dts  | 16 +---
 arch/arm/boot/dts/r8a7791.dtsi| 34 --
 3 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index e164eda69baf..5a0f87ed7f16 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -332,8 +332,7 @@
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -341,6 +340,13 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index 9a02d03b23c2..e6d02839d636 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -419,10 +419,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -433,6 +432,17 @@
};
 };
 
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds_connector: endpoint {
+   };
+   };
+   };
+};
+
 _sound {
pinctrl-0 = <_pins _clk_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 67831d0405f3..b7fceb210de9 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1103,15 +1103,12 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7791";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -1126,6 +1123,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7791";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 02/12] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the LVDS reg range from the example
- Remove the reg-names property
---
 .../devicetree/bindings/display/renesas,du.txt | 31 --
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..e79cf9b0ad38 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -14,12 +14,7 @@ Required Properties:
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
 
-  - reg: A list of base address and length of each memory resource, one for
-each entry in the reg-names property.
-  - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+  - reg: the memory-mapped I/O registers base address and length
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +24,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 05/12] ARM: dts: porter: Fix HDMI output routing

[Laurent Pinchart]

The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index eb374956294f..9a02d03b23c2 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -425,7 +425,7 @@
  "dclkin.0", "dclkin.1";
 
ports {
-   port@1 {
+   port@0 {
endpoint {
remote-endpoint = <_in>;
};
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 12/12] arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the DU reg-names property
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 34 ++
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index daee1f1a3f68..21bd679062f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -33,10 +33,9 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 4088bea8d62c..ecbfbcb65df3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -32,11 +32,10 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f2b2e40c655e..169fd89fe093 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1826,17 +1826,14 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7796";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x7>;
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
-< CPG_MOD 722>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
vsps = <  >;
@@ -1859,6 +1856,31 @@
port@2 {
reg = <2>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7796";
+   reg = <0 0xfeb9 0 0x14>;
+   clocks = < CPG_MOD 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 06/12] ARM: dts: r8a7790: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7790-lager.dts | 22 ++
 arch/arm/boot/dts/r8a7790.dtsi  | 60 -
 2 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 7d5cd01069a3..f84963cb6785 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -317,10 +317,8 @@
status = "okay";
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
-< CPG_MOD 726>, < CPG_MOD 725>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "du.2", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -328,12 +326,26 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
endpoint {
remote-endpoint = <_in>;
};
};
-   port@2 {
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
lvds_connector: endpoint {
};
};
@@ -689,7 +701,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out_lvds0>;
+   remote-endpoint = <_out>;
};
};
 
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 62baabd757b6..0fcd5e34ef82 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1067,17 +1067,13 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7790";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x1c>,
- <0 0xfeb94000 0 0x1c>;
-   reg-names = "du", "lvds.0", "lvds.1";
+   reg = <0 0xfeb0 0 0x7>;
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>, < CPG_MOD 723>,
-< CPG_MOD 722>, < CPG_MOD 726>,
-< CPG_MOD 725>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
ports {
@@ -1092,11 +1088,61 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7790";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
+
+   lvds1: lvds@feb94000 {
+   compatible = "renesas,lvds-r8a7790";
+   reg = <0 0xfeb94000 0 0x1c>;
+   clocks = < CPG_MOD 725>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds1_in: endpoint {
+   remote-endpoint = <_out_lvds1>;
+   };
+   };
+

[PATCH v2 00/12] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 01/12 and 02/12 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patch 03/12 then patches the device
tree at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 04/12 then converts the LVDS support code to
a separate bridge driver. After a small fix to the Porter board device tree in
patch 05/12, patches 06/12 to 12/12 then update all the device tree sources to
the new DU and LVDS encoders bindings.

I decided to go for live DT patching in patch 03/12 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. I'm in a way both proud and 
ashamed of that patch that I would call a neat and dirty hack. It was fun to
write perhaps in a similar way that one would enjoy researching and developing
proof-of-concepts for security holes: they're good and bad at the same time.

Anyway, with this philosophical considerations aside, there were a few
shortcomings in the OF API that I worked around with local code in the driver.
If anyone is interested in performing similar live DT patching I think we
could move some of the code to the OF core. For instance I was surprised
to not find a device node lookup by path function that would start at a
given node instead of the root of the live device tree, and had to write
rcar_du_of_find_node_by_path(). Utility functions to add or modify properties
or to rename nodes could similarly be added.

Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
and incorporate review feedback as described by the changelogs of individual
patches.

Laurent Pinchart (12):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver
  ARM: dts: porter: Fix HDMI output routing
  ARM: dts: r8a7790: Convert to new LVDS DT bindings
  ARM: dts: r8a7791: Convert to new LVDS DT bindings
  ARM: dts: r8a7792: Convert to new DU DT bindings
  ARM: dts: r8a7793: Convert to new LVDS DT bindings
  ARM: dts: r8a7794: Convert to new DU DT bindings
  arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
  arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

 .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
 .../devicetree/bindings/display/renesas,du.txt |  31 +-
 MAINTAINERS|   1 +
 arch/arm/boot/dts/r8a7790-lager.dts|  22 +-
 arch/arm/boot/dts/r8a7790.dtsi |  60 ++-
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  10 +-
 arch/arm/boot/dts/r8a7791-porter.dts   |  18 +-
 arch/arm/boot/dts/r8a7791.dtsi |  34 +-
 arch/arm/boot/dts/r8a7792.dtsi |   1 -
 arch/arm/boot/dts/r8a7793-gose.dts |  10 +-
 arch/arm/boot/dts/r8a7793.dtsi |  34 +-
 arch/arm/boot/dts/r8a7794.dtsi |   1 -
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  34 +-
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  34 +-
 drivers/gpu/drm/rcar-du/Kconfig|   6 +-
 drivers/gpu/drm/rcar-du/Makefile   |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  93 
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |  24 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  | 264 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  64 ---
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 451 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  16 +
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts|  82 
 drivers/gpu/drm/rcar-du/rcar_lvds.c| 546 +
 35 files changed, 1421 insertions(+), 722 deletions(-)
 create 

[PATCH v2 04/12] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 264 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 546 ++
 12 files changed, 583 insertions(+), 642 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 3f83352a7313..edde8d4b87a3 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_FLATTREE
select OF_OVERLAY
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 8ed569a0f462..247df6a3c81d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,13 +4,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_of.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of_lvds.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 
-module_platform_driver(rcar_du_platform_driver);
+static int __init rcar_du_init(void)
+{
+   rcar_du_of_init(rcar_du_of_table);
+
+   return platform_driver_register(_du_platform_driver);
+}

[PATCH v2 10/12] ARM: dts: r8a7794: Convert to new DU DT bindings

[Laurent Pinchart]

The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7794.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 5643976c1356..cccdada9e4a4 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -992,7 +992,6 @@
du: display@feb0 {
compatible = "renesas,du-r8a7794";
reg = <0 0xfeb0 0 0x4>;
-   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>, < CPG_MOD 723>;
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 09/12] ARM: dts: r8a7793: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the DU reg-names property
---
 arch/arm/boot/dts/r8a7793-gose.dts | 10 +++---
 arch/arm/boot/dts/r8a7793.dtsi | 34 --
 2 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 51b3ffac8efa..c6121f9b72a8 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -303,10 +303,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -314,6 +313,11 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 0cd1035de1a4..c382a57df168 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -976,15 +976,12 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7793";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -999,6 +996,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7793";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 08/12] ARM: dts: r8a7792: Convert to new DU DT bindings

[Laurent Pinchart]

The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7792.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 3d080e07374c..d40325466aa8 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -678,7 +678,6 @@
du: display@feb0 {
compatible = "renesas,du-r8a7792";
reg = <0 0xfeb0 0 0x4>;
-   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 11/12] arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Remove the DU reg-names property
---
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 34 ++
 5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
index 9ef9a4e5f376..0dda1c0ed1ce 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 0afe777973de..f0d6528c05eb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -44,11 +44,10 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 4>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 00ad1ab53a7d..e34b986185d4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 79e8b65622db..31f2abaa90aa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 15ef292a8d9f..8e14873455b9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2077,9 +2077,7 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -2087,9 +2085,8 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0  0  0  1>;
status = "disabled";
 
@@ -2117,6 +2114,31 @@
port@3 {
reg = <3>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+

[PATCH v2 2/2] drm: rcar-du: lvds: Fix LVDS startup on R-Car gen2

[Laurent Pinchart]

From: Sergei Shtylyov 

According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
must be enabled and the bias crcuit enabled after the LVDS I/O pins are
enabled, not before. Fix the gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Laurent Pinchart 
[Set the mode and input at the same time as the BEN and LVEN bits]
Tested-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Hi Sergei,

For your convenience (and if you agree with bundling mode setup with the first
write as explained in my review of patch 1/2), here's the updated version of
patch 2/2 that I have taken in my development branch. If you're fine with it
I'll keep it, otherwise we can continue the review discussion.

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index abbb7b25129a..b37c255c3d93 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -59,20 +59,20 @@ static void rcar_du_lvdsenc_start_gen2(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
+   /* Turn all the channels on. */
+   rcar_lvds_write(lvds, LVDCR1,
+   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
+   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
+
/*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
+* Set the  LVDS mode, select the input, enable LVDS operation,
+* and turn bias circuitry on.
 */
lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
 
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
/*
 * Turn the PLL on, wait for the startup delay, and turn the output
 * on.
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Laurent Pinchart]

Hi Jernej,

Thank you for th epatch.

On Wednesday, 10 January 2018 21:25:04 EET Jernej Skrabec wrote:
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
> 
> Functions exported here are actually not specific to Synopsys PHYs but
> to DWC HDMI controller PHY interface. This means that even if the PHY is
> completely custom, i.e. not designed by Synopsys, exported functions can
> be useful.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 
>  include/drm/bridge/dw_hdmi.h  | 11 
>  2 files changed, 41 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 7ca14d7325b5..7d80f4b56683 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
> *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
>  }
> 
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> 
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> 
>  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
>  {
> @@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct
> dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
> 
> +void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
> +{
> + /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> + hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> + hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
> +
> +void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
> +
>  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
> 
> - /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_reset(hdmi);
> 
>   hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> 
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
> 
>   /* Write to the PHY as configured by the platform */
>   if (pdata->configure_phy)
> @@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
>  }
> 
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> -   void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
>  {
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> 
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
>  {
>   u8 old_mask = hdmi->phy_mask;
> 
> @@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> *hdmi, void *data, if (old_mask != hdmi->phy_mask)
>   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
> 
> -static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> +void dw_hdmi_phy_setup_hpd(struct dw_hdmi 

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #17 from Bong Cosca  ---
Disabling hardware acceleration isn't exactly the workaround I was looking for.
I use modesetting with "AccelMethod" "none" just to make this work and I am
forced to use Win10 to do 3D animation stuff which is not ideal for me.

If there's anything I can do to help isolate this bugger, let me know. As it
stands right now, the R5 graphics on this APU is practically inutile without
acceleration. Moreso with multiple monitors that I plan to set up.

-- 
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 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

  Component|DRM/Radeon  |DRM/AMDgpu

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

Error handling when vmalloc is too small

[Stefan Agner]

Hi there,

Error handling seems to be broken when allocating a framebuffer fails
(see below). Observed on a Apalis TK1 (Tegra K1 with 2GB RAM, seems to
allocate 240 MB for vmalloc) using Linux 4.15.0-rc7 connected to a 4K
TV:

[5.632659] [drm:drm_setup_crtcs]
[5.636227] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:46:HDMI-A-1]
[5.643811] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:46:HDMI-A-1] status updated from unknown to connected
[5.655003] [drm:drm_sysfs_hotplug_event] generating hotplug event
[5.919028] [drm:drm_add_display_info] non_desktop set to 0
[5.924664] [drm:drm_add_display_info] HDMI: DVI dual 0, max TMDS
clock 30 kHz
[5.932232] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does deep
color 30.
[5.939483] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does deep
color 36.
[5.946736] [drm:drm_add_display_info] HDMI-A-1: Assigning HDMI sink
color depth as 12 bpc.
[5.955114] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does
YCRCB444 in deep color.
[5.963147] [drm:drm_add_display_info] HF-VSDB: max TMDS clock 60
kHz
[5.969954] [drm:drm_add_display_info] non_desktop set to 0
[5.975561] [drm:drm_add_display_info] HDMI: DVI dual 0, max TMDS
clock 30 kHz
[5.983158] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does deep
color 30.
[5.990376] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does deep
color 36.
[5.997626] [drm:drm_add_display_info] HDMI-A-1: Assigning HDMI sink
color depth as 12 bpc.
[6.006003] [drm:drm_add_display_info] HDMI-A-1: HDMI sink does
YCRCB444 in deep color.
[6.014035] [drm:drm_add_display_info] HF-VSDB: max TMDS clock 60
kHz
[6.021749] [drm:drm_edid_to_eld] ELD monitor LG TV
[6.026668] [drm:drm_edid_to_eld] HDMI: latency present 0 0, video
latency 0 1, audio latency 128 2
[6.035740] [drm:drm_edid_to_eld] ELD size 40, SAD count 4
[6.041893] [drm:drm_mode_debug_printmodeline] Modeline
49:"3840x2160" 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48
0x5
[6.053568] [drm:drm_mode_prune_invalid] Not using 3840x2160 mode:
NOCLOCK
[6.060454] [drm:drm_mode_debug_printmodeline] Modeline
62:"3840x2160" 0 594000 3840 4896 4984 5280 2160 2168 2178 2250 0x40 0x5
[6.072038] [drm:drm_mode_prune_invalid] Not using 3840x2160 mode:
NOCLOCK
[6.078955] [drm:drm_mode_debug_printmodeline] Modeline
65:"4096x2160" 0 594000 4096 4184 4272 4400 2160 2168 2178 2250 0x40 0x5
[6.090687] [drm:drm_mode_prune_invalid] Not using 4096x2160 mode:
NOCLOCK
[6.097607] [drm:drm_mode_debug_printmodeline] Modeline
66:"4096x2160" 0 594000 4096 5064 5152 5280 2160 2168 2178 2250 0x40 0x5
[6.109192] [drm:drm_mode_prune_invalid] Not using 4096x2160 mode:
NOCLOCK
[6.116108] [drm:drm_mode_debug_printmodeline] Modeline
69:"1920x1080i" 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40
0x15
[6.127780] [drm:drm_mode_prune_invalid] Not using 1920x1080i mode:
NO_INTERLACE
[6.135216] [drm:drm_mode_debug_printmodeline] Modeline
70:"1920x1080i" 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40
0x15
[6.146887] [drm:drm_mode_prune_invalid] Not using 1920x1080i mode:
NO_INTERLACE
[6.154323] [drm:drm_mode_debug_printmodeline] Modeline 77:"720x576i"
0 13500 720 732 795 864 576 580 586 625 0x40 0x101a
[6.165301] [drm:drm_mode_prune_invalid] Not using 720x576i mode:
NO_INTERLACE
[6.172534] [drm:drm_mode_debug_printmodeline] Modeline
91:"3840x2160" 60 593407 3840 4016 4104 4400 2160 2168 2178 2250 0x40
0x5
[6.184205] [drm:drm_mode_prune_invalid] Not using 3840x2160 mode:
NOCLOCK
[6.191089] [drm:drm_mode_debug_printmodeline] Modeline
97:"4096x2160" 60 593407 4096 4184 4272 4400 2160 2168 2178 2250 0x40
0x5
[6.202761] [drm:drm_mode_prune_invalid] Not using 4096x2160 mode:
NOCLOCK
[6.209676] [drm:drm_mode_debug_printmodeline] Modeline
99:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40
0x15
[6.221433] [drm:drm_mode_prune_invalid] Not using 1920x1080i mode:
NO_INTERLACE
[6.228882] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:46:HDMI-A-1] probed modes :
[6.237701] [drm:drm_mode_debug_printmodeline] Modeline
84:"4096x2160" 30 297000 4096 4184 4272 4400 2160 2168 2178 2250 0x40
0x5
[6.249379] [drm:drm_mode_debug_printmodeline] Modeline
108:"4096x2160" 30 296703 4096 4184 4272 4400 2160 2168 2178 2250 0x40
0x5
[6.261143] [drm:drm_mode_debug_printmodeline] Modeline
83:"4096x2160" 25 297000 4096 5064 5152 5280 2160 2168 2178 2250 0x40
0x5
[6.272822] [drm:drm_mode_debug_printmodeline] Modeline
82:"4096x2160" 24 297000 4096 5116 5204 5500 2160 2168 2178 2250 0x40
0x5
[6.284500] [drm:drm_mode_debug_printmodeline] Modeline
107:"4096x2160" 24 296703 4096 5116 5204 5500 2160 2168 2178 2250 0x40
0x5
[6.296265] [drm:drm_mode_debug_printmodeline] Modeline
81:"3840x2160" 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40
0x5
[6.307944] [drm:drm_mode_debug_printmodeline] Modeline

Re: [PATCH 2/4 v7] drm/bridge: Provide a way to embed timing info in bridges

[Laurent Pinchart]

Hi Linus,

Thank you for the patch.

On Friday, 12 January 2018 09:48:52 EET Linus Walleij wrote:
> After some discussion and failed patch sets trying to convey
> the right timing information between the display engine and
> a bridge using the connector, I try instead to use an optional
> timing information container in the bridge itself, so that
> display engines can retrieve it from any bridge and use it to
> determine how to drive outputs.
> 
> Signed-off-by: Linus Walleij 

Reviewed-by: Laurent Pinchart 

> ---
> ChangeLog v6->v7:
> - Fix the comment style to use the new inline type of kerneldoc
>   for struct members.
> - Need an explicit ACK/review by someone on this patch to continue
>   with the series...
> ChangeLog v5->v6:
> - Sort forward struct declarations alphabetically
> - Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
>   positive or negatice clock samling edge
> ChangeLog ->v5:
> - New patch
> ---
>  include/drm/drm_bridge.h | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..d3c2eea0bb63 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -29,6 +29,7 @@
>  #include 
> 
>  struct drm_bridge;
> +struct drm_bridge_timings;
>  struct drm_panel;
> 
>  /**
> @@ -222,6 +223,35 @@ struct drm_bridge_funcs {
>   void (*enable)(struct drm_bridge *bridge);
>  };
> 
> +/**
> + * struct drm_bridge_timings - timing information for the bridge
> + */
> +struct drm_bridge_timings {
> + /**
> +  * @sampling_edge:
> +  *
> +  * Tells whether the bridge samples the digital input signal
> +  * from the display engine on the positive or negative edge of the 
> clock,
> +  * this should reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise
> +  * flags from the DRM connector (bit 2 and 3 valid).
> +  */
> + u32 sampling_edge;
> + /**
> +  * @setup_time_ps:
> +  *
> +  * Defines the time in picoseconds the input data lines must be
> +  * stable before the clock edge.
> +  */
> + u32 setup_time_ps;
> + /**
> +  * @hold_time_ps:
> +  *
> +  * Defines the time in picoseconds taken for the bridge to sample the
> +  * input signal after the clock edge.
> +  */
> + u32 hold_time_ps;
> +};
> +
>  /**
>   * struct drm_bridge - central DRM bridge control structure
>   * @dev: DRM device this bridge belongs to
> @@ -229,6 +259,8 @@ struct drm_bridge_funcs {
>   * @next: the next bridge in the encoder chain
>   * @of_node: device node pointer to the bridge
>   * @list: to keep track of all added bridges
> + * @timings: the timing specification for the bridge, if any (may
> + * be NULL)
>   * @funcs: control functions
>   * @driver_private: pointer to the bridge driver's internal context
>   */
> @@ -240,6 +272,7 @@ struct drm_bridge {
>   struct device_node *of_node;
>  #endif
>   struct list_head list;
> + const struct drm_bridge_timings *timings;
> 
>   const struct drm_bridge_funcs *funcs;
>   void *driver_private;


-- 
Regards,

Laurent Pinchart

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

[Bug 104611] [fiji] BUG: unable to handle kernel NULL pointer dereference when waking up displays with amdgpu.dc=1

[bugzilla-daemon]

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

Bug ID: 104611
   Summary: [fiji] BUG: unable to handle kernel NULL pointer
dereference when waking up displays with amdgpu.dc=1
   Product: DRI
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net

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

Using Fedora rawhide (28) with kernel 4.15.0-0.rc7.git4.1.fc28.x86_64 on

01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Fiji
HDMI/DP Audio [Radeon R9 Nano / FURY/FURY X] [1002:aae8]

If I let displays go to sleep and then wake them up, I get:

[ 1464.218367] BUG: unable to handle kernel NULL pointer dereference at
0208
[ 1464.218407] IP: create_stream_for_sink+0x1cc/0x3c0 [amdgpu]
[ 1464.218409] PGD 8003c89ae067 P4D 8003c89ae067 PUD 404d9d067 PMD 0 
[ 1464.218414] Oops:  [#1] SMP PTI
[ 1464.218415] Modules linked in: fuse rpcsec_gss_krb5 nfsv4 dns_resolver nfs
lockd grace fscache intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
joydev kvm irqbypass crct10dif_pclmul snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi crc32_pclmul ghash_clmulni_intel
snd_hda_intel snd_hda_codec snd_hda_core intel_cstate eeepc_wmi asus_wmi
iTCO_wdt mei_wdt iTCO_vendor_support sparse_keymap snd_seq snd_hwdep rfkill
intel_uncore snd_seq_device wmi_bmof ppdev snd_pcm intel_rapl_perf snd_timer
parport_pc parport shpchp snd i2c_i801 soundcore mei_me video mei lpc_ich wmi
auth_rpcgss binfmt_misc sunrpc amdkfd amd_iommu_v2 amdgpu chash i2c_algo_bit
drm_kms_helper ttm crc32c_intel drm r8169 mii hid_cherry
[ 1464.218465] CPU: 7 PID: 1474 Comm: Xorg Not tainted
4.15.0-0.rc7.git4.1.fc28.x86_64 #1
[ 1464.218467] Hardware name: Transtec AG/B85M-E, BIOS 3505 11/28/2016
[ 1464.218490] RIP: 0010:create_stream_for_sink+0x1cc/0x3c0 [amdgpu]
[ 1464.218491] RSP: 0018:adcac9c7b900 EFLAGS: 00010286
[ 1464.218493] RAX: 0870 RBX: 9063805b RCX:

[ 1464.218494] RDX: 0013 RSI: 0002 RDI:
906337f5b08c
[ 1464.218495] RBP: adcac9c7ba40 R08:  R09:
0f00
[ 1464.218497] R10: 906337f5b000 R11: 0870 R12:
906337f5b000
[ 1464.218498] R13:  R14: 906345723e80 R15:
906337f5d000
[ 1464.218499] FS:  7f3de9b77a80() GS:90638d40()
knlGS:
[ 1464.218500] CS:  0010 DS:  ES:  CR0: 80050033
[ 1464.218502] CR2: 0208 CR3: 000405d86001 CR4:
001606e0
[ 1464.218503] Call Trace:
[ 1464.218508]  ? __lock_is_held+0x65/0xb0
[ 1464.218534]  dm_update_crtcs_state+0xef/0x3a0 [amdgpu]
[ 1464.218555]  ? dm_update_crtcs_state+0xef/0x3a0 [amdgpu]
[ 1464.218577]  ? dc_resource_state_copy_construct+0xcc/0x110 [amdgpu]
[ 1464.218598]  amdgpu_dm_atomic_check+0x210/0x480 [amdgpu]
[ 1464.218611]  drm_atomic_check_only+0x387/0x560 [drm]
[ 1464.218618]  ? drm_connector_list_iter_end+0x5a/0x70 [drm]
[ 1464.218624]  drm_atomic_commit+0x18/0x50 [drm]
[ 1464.218630]  drm_atomic_connector_commit_dpms+0xef/0x100 [drm]
[ 1464.218637]  set_property_atomic+0xce/0x150 [drm]
[ 1464.218646]  drm_mode_obj_set_property_ioctl+0xf9/0x1b0 [drm]
[ 1464.218652]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[ 1464.218657]  drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
[ 1464.218663]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[ 1464.218669]  drm_ioctl+0x31b/0x3d0 [drm]
[ 1464.218674]  ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm]
[ 1464.218678]  ? trace_hardirqs_on_caller+0xf4/0x190
[ 1464.218679]  ? trace_hardirqs_on+0xd/0x10
[ 1464.218694]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[ 1464.218697]  do_vfs_ioctl+0xa6/0x6c0
[ 1464.218699]  ? __fget+0x124/0x210
[ 1464.218702]  SyS_ioctl+0x79/0x90
[ 1464.218706]  entry_SYSCALL_64_fastpath+0x25/0x9c
[ 1464.218707] RIP: 0033:0x7f3de6e72877
[ 1464.218708] RSP: 002b:7fffabff2c98 EFLAGS: 0246 ORIG_RAX:
0010
[ 1464.218710] RAX: ffda RBX: 0200 RCX:
7f3de6e72877
[ 1464.218712] RDX: 7fffabff2cd0 RSI: c01064ab RDI:
000c
[ 1464.218713] RBP: 0040 R08: 01fd7390 R09:
0018
[ 1464.218714] R10: 0004 R11: 0246 R12:
01bf1810
[ 1464.218715] R13:  R14: 01bf1a00 R15:
01bf0990
[ 1464.218719] Code: da 4c 89 e7 e8 56 fc ff ff 4c 89 f6 4c 89 ef 4c 89 e2 e8
28 f0 ff ff 4c 8b ab c0 04 00 00 49 8d bc 24 8c 00 00 00 ba 13 00 00 00 <41> 0f
b7 85 08 02 00 00 49 8d b5 12 02 00 00 41 89 84 24 a0 00 
[ 1464.218780] RIP: create_stream_for_sink+0x1cc/0x3c0 [amdgpu] RSP:
adcac9c7b900
[ 1464.218781] CR2: 0208
[ 1464.218783] ---[ end 

[PATCH 1/2] drm/ttm: Allow page allocations w/o triggering OOM..

[Andrey Grodzovsky]

This to allow drivers to choose to avoid OOM invocation and handle
page allocation failures instead.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/ttm/ttm_bo.c |  3 +++
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 ++
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +++
 drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
 include/drm/ttm/ttm_bo_api.h |  1 +
 include/drm/ttm/ttm_bo_driver.h  |  4 
 6 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2eb71ff..f32aab1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -234,6 +234,9 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
 
+   if (bdev->no_retry)
+   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0eab24e..f34c843 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -741,6 +741,9 @@ static int ttm_page_pool_get_pages(struct ttm_page_pool 
*pool,
if (ttm_flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (ttm_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
/* ttm_alloc_new_pages doesn't reference pool so we can run
 * multiple requests in parallel.
 **/
@@ -893,6 +896,9 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
if (flags & TTM_PAGE_FLAG_ZERO_ALLOC)
gfp_flags |= __GFP_ZERO;
 
+   if (flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
if (flags & TTM_PAGE_FLAG_DMA32)
gfp_flags |= GFP_DMA32;
else
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..6949ef7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -920,6 +920,9 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt 
*ttm_dma, bool huge)
gfp_flags &= ~__GFP_COMP;
}
 
+   if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+   gfp_flags |= __GFP_RETRY_MAYFAIL;
+
return gfp_flags;
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5a046a3..9e4d43d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -301,7 +301,11 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
-   from_page = shmem_read_mapping_page(swap_space, i);
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+   from_page = shmem_read_mapping_page_gfp(swap_space, i, 
gfp_mask);
+
if (IS_ERR(from_page)) {
ret = PTR_ERR(from_page);
goto out_err;
@@ -350,10 +354,15 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
swap_space = swap_storage->f_mapping;
 
for (i = 0; i < ttm->num_pages; ++i) {
+   gfp_t gfp_mask = mapping_gfp_mask(swap_space);
+
+   gfp_mask |= (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY ? 
__GFP_RETRY_MAYFAIL : 0);
+
from_page = ttm->pages[i];
if (unlikely(from_page == NULL))
continue;
-   to_page = shmem_read_mapping_page(swap_space, i);
+
+   to_page = shmem_read_mapping_page_gfp(swap_space, i, gfp_mask);
if (IS_ERR(to_page)) {
ret = PTR_ERR(to_page);
goto out_err;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2cd025c..099f24b 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -176,6 +176,7 @@ struct ttm_buffer_object {
unsigned long num_pages;
size_t acc_size;
 
+
/**
* Members not needing protection.
*/
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 94064b1..9b417eb 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -86,6 +86,7 @@ struct ttm_backend_func {
 #define TTM_PAGE_FLAG_ZERO_ALLOC  (1 << 6)
 #define TTM_PAGE_FLAG_DMA32   (1 << 7)
 #define TTM_PAGE_FLAG_SG  (1 << 8)
+#define TTM_PAGE_FLAG_NO_RETRY(1 << 9)
 
 enum ttm_caching_state {
 

[PATCH 2/2] drm/amdgpu: Use new TTM flag to avoid OOM triggering.

[Andrey Grodzovsky]

This to have a load time option to avoid OOM on RAM allocations.

Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index b7c181e..1387239 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -127,6 +127,7 @@ extern int amdgpu_job_hang_limit;
 extern int amdgpu_lbpw;
 extern int amdgpu_compute_multipipe;
 extern int amdgpu_gpu_recovery;
+extern int amdgpu_alloc_no_oom;
 
 #ifdef CONFIG_DRM_AMDGPU_SI
 extern int amdgpu_si_support;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index d96f9ac..6e98189 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -130,6 +130,7 @@ int amdgpu_job_hang_limit = 0;
 int amdgpu_lbpw = -1;
 int amdgpu_compute_multipipe = -1;
 int amdgpu_gpu_recovery = -1; /* auto */
+int amdgpu_alloc_no_oom = -1; /* auto */
 
 MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes");
 module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);
@@ -285,6 +286,9 @@ module_param_named(compute_multipipe, 
amdgpu_compute_multipipe, int, 0444);
 MODULE_PARM_DESC(gpu_recovery, "Enable GPU recovery mechanism, (1 = enable, 0 
= disable, -1 = auto");
 module_param_named(gpu_recovery, amdgpu_gpu_recovery, int, 0444);
 
+MODULE_PARM_DESC(alloc_no_oom, "Allocate RAM without triggering OOM killer, (1 
= enable, 0 = disable, -1 = auto");
+module_param_named(alloc_no_oom, amdgpu_alloc_no_oom, int, 0444);
+
 #ifdef CONFIG_DRM_AMDGPU_SI
 
 #if defined(CONFIG_DRM_RADEON) || defined(CONFIG_DRM_RADEON_MODULE)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5c4c3e0..fc27164 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -420,6 +420,10 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
 #endif
 
bo->tbo.bdev = >mman.bdev;
+
+   if (amdgpu_alloc_no_oom == 1)
+   bo->tbo.bdev->no_retry = true;
+
amdgpu_ttm_placement_from_domain(bo, domain);
 
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
-- 
2.7.4

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

Re: [PATCH 2/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen2

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 12 January 2018 22:12:05 EET Sergei Shtylyov wrote:
> According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
> must be enabled and the bias crcuit  enabled after the LVDS I/O pins are
> enabled, not before --  fix the gen2 LVDS startup sequence accordingly.
> 
> Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(s
> 
>   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> 
> - /*
> -  * Set the  LVDS mode, select the input, enable LVDS operation,
> -  * and turn bias circuitry on.
> -  */
> - lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
> + /* Select the input and set the LVDS mode. */
> + lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
>   if (rcrtc->index == 2)
>   lvdcr0 |= LVDCR0_DUSEL;
>   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> @@ -73,6 +70,10 @@ static void rcar_du_lvdsenc_start_gen2(s
>   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
>   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
> 
> + /* Enable LVDS operation and turn bias circuitry on. */
> + lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
> + rcar_lvds_write(lvds, LVDCR0, lvdcr0);

This change looks good, but for the reasons explained in my replies to patch 
1/2, I would set the mode here along with the BEN and LVEN bits.

>   /*
>* Turn the PLL on, wait for the startup delay, and turn the output
>* on.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Laurent Pinchart]

Hi Sergei,

On Friday, 12 January 2018 23:51:35 EET Laurent Pinchart wrote:
> On Friday, 12 January 2018 22:12:04 EET Sergei Shtylyov wrote:
> > According to the latest revisions of the R-Car gen3 manual, the LVDS mode
> > must be set before the LVDS I/O pins are enabled, not after --  fix  the
> > gen3 LVDS startup sequence accordingly...
> > 
> > While  at it,  also fix the comment  preceding the first LVDCR0 write in
> > the R-Car gen2 startup code that still talks about hardcoding the LVDS
> > mode 0...
> 
> How about fixing that in patch 2/2 that touches the Gen2 initialization
> sequence ? I think I'd even go as far as squashing both patches, I don't
> think there's a need to split them.
> 
> > Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
> > Signed-off-by: Sergei Shtylyov 
> 
> Is this really needed ? Does it fix a problem you've experienced, or is it
> theoretical only ? The mode shouldn't matter before the LVDS internal logic
> is turned on. Unless there's a real issue I'm not sure we should make the
> code more complex.

Furthermore the datasheet states

"3. This refers to settings other than those that are concerned with LVDS-IF 
startup. These items may be set while waiting for the conditions of step 6 to 
be met."

Doesn't this mean that the mode and input selector don't have to be set as the 
very first step, but can be programmed at any point before starting the LVDS 
encoder through the PWD bit (on Gen3) or the PLLON bit (on Gen2) ?

> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> > ===
> > --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> > +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> > @@ -60,8 +60,8 @@ static void rcar_du_lvdsenc_start_gen2(s
> > rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> > 
> > /*
> > -* Select the input, hardcode mode 0, enable LVDS operation and turn
> > -* bias circuitry on.
> > +* Set the  LVDS mode, select the input, enable LVDS operation,
> > +* and turn bias circuitry on.
> >  */
> > lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
> > if (rcrtc->index == 2)
> > @@ -106,6 +106,9 @@ static void rcar_du_lvdsenc_start_gen3(s
> > 
> > rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> > 
> > +   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
> > +   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> > +
> > /* Turn all the channels on. */
> > rcar_lvds_write(lvds, LVDCR1,
> > LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> > @@ -115,7 +118,8 @@ static void rcar_du_lvdsenc_start_gen3(s
> >  * Turn the PLL on, set it to LVDS normal mode, wait for the startup
> >  * delay and turn the output on.
> >  */
> > -   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
> > +
> > +   lvdcr0 = | LVDCR0_PLLON;
> > rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> > 
> > lvdcr0 |= LVDCR0_PWD;

-- 
Regards,

Laurent Pinchart

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

[Bug 103976] Regression: Videogame (Wakfu) no longer works with Mesa 17.2 (17.1 works)

[bugzilla-daemon]

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

Timo Aaltonen  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Timo Aaltonen  ---


*** This bug has been marked as a duplicate of bug 103078 ***

-- 
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 5/6] drm: rcar-du: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Set the drm_device->normalize_zpos and call drm_atomic_helper_check() from
rcar_du_atomic_check() instead of re implementing the function locally.

Signed-off-by: Peter Ujfalusi 
CC: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +-
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..61dc773b9df0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -405,6 +405,7 @@ static int rcar_du_probe(struct platform_device *pdev)
}
 
ddev->irq_enabled = 1;
+   ddev->normalize_zpos = true;
 
/*
 * Register the DRM device with the core and the connectors with
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..fa82adfe0982 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -234,15 +234,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_device *rcdu = dev->dev_private;
int ret;
 
-   ret = drm_atomic_helper_check_modeset(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_check_planes(dev, state);
+   ret = drm_atomic_helper_check(dev, state);
if (ret)
return ret;
 
-- 
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

[PATCH 0/6] drm: zpos normalization cleanup and omapdrm to use it

[Peter Ujfalusi]

Hi,

The first patch is adding a flag to drm_device that drivers can set if they want
the zpos to be normalized.

Then convert exynos, tegra, sti and rcar-du to use this flag instead of
re-implementing the drm_atomic_helper_check() locally just to add the call to
drm_atomic_normalize_zpos().

The last patch is moving omapdrm to use the zpos normalization as well to comply
with the UAPI documentation regarding to zpos.

Laurent's note in an earlier thread:
https://marc.info/?l=dri-devel=151567355225029=2

"The problem is that zpos normalization requires accessing the state of all 
enabled planes for a CRTC in order to compute (and store) the normalized zpos 
values. This thus forces all planes to be added to the commit state, even when 
the commit doesn't touch the zpos property. I assume this caused issues 
(possibly performance issues) in drivers that then performed hardware setup of 
all planes as a result."

can be addressed later in the core for all users of drm_atomic_normalize_zpos()

Regards,
Peter
---
Peter Ujfalusi (6):
  drm: Add drm_device->normalize_zpos boolean
  drm/exynos: Let core take care of normalizing the zpos
  drm/tegra: Let core take care of normalizing the zpos
  drm/sti: Let core take care of normalizing the zpos
  drm: rcar-du: Let core take care of normalizing the zpos
  drm/omap: Use normalized zpos for plane placement

 drivers/gpu/drm/drm_atomic_helper.c |  6 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 21 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |  1 +
 drivers/gpu/drm/omapdrm/omap_plane.c|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 10 +-
 drivers/gpu/drm/sti/sti_drv.c   | 23 ++-
 drivers/gpu/drm/tegra/drm.c | 27 +++
 include/drm/drm_device.h|  8 
 11 files changed, 25 insertions(+), 77 deletions(-)

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

[PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

[Dhinakaran Pandiyan]

drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.

Cc: Keith Packard 
Cc: Michel Dänzer 
Cc: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 32d9bcf5be7f..768a8e44d99b 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
 }
 
-static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
+static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
-- 
2.11.0

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

[PATCH 3/5] drm/vblank: Do not update vblank count if interrupts are already disabled.

[Dhinakaran Pandiyan]

Updating vblank counts requires register reads and these reads may not
return meaningful values if the device was in a low power state after
vblank interrupts were last disabled. So, update the count only if vblank
interrupts are enabled. Secondly, this means the registers should be read
before disabling vblank interrupts.

v2: Don't check vblank->enabled outside it's lock (Chris)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f2bf1f5dbaa5..2559d2d7b907 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -347,23 +347,25 @@ void drm_vblank_disable_and_save(struct drm_device *dev, 
unsigned int pipe)
spin_lock_irqsave(>vblank_time_lock, irqflags);
 
/*
-* Only disable vblank interrupts if they're enabled. This avoids
-* calling the ->disable_vblank() operation in atomic context with the
-* hardware potentially runtime suspended.
+* Update vblank count and disable vblank interrupts only if the
+* interrupts were enabled. This avoids calling the ->disable_vblank()
+* operation in atomic context with the hardware potentially runtime
+* suspended.
 */
-   if (vblank->enabled) {
-   __disable_vblank(dev, pipe);
-   vblank->enabled = false;
-   }
+   if (!vblank->enabled)
+   goto out;
 
/*
-* Always update the count and timestamp to maintain the
+* Update the count and timestamp to maintain the
 * appearance that the counter has been ticking all along until
 * this time. This makes the count account for the entire time
 * between drm_crtc_vblank_on() and drm_crtc_vblank_off().
 */
drm_update_vblank_count(dev, pipe, false);
+   __disable_vblank(dev, pipe);
+   vblank->enabled = false;
 
+out:
spin_unlock_irqrestore(>vblank_time_lock, irqflags);
 }
 
-- 
2.11.0

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

[PATCH 5/5] drm/i915: Estimate and update missed vblanks.

[Dhinakaran Pandiyan]

The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 state if PSR was
active. The frame counter also could have stalled if PSR is active in cases
where there is no DMC. The frame counter resetting as a user visible impact
of screen freezes. Use drm_vblank_restore() to compute missed vblanks
in the duration for which vblank interrupts are disabled. There's no need
particularly check if PSR was active in the interrupt disabled duration.

Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
from going back again as long as the there are pending interrupts. So, we
don't have to explicity disallow DC5/6 after enabling vblank interrupts
to keep the counter running.

Let's not apply this to CHV for now, as enabling interrupts does not
prevent the hardware from activating PSR and thereby stalling the counter.

Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_irq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c6548e2c..db3466ec6faa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2956,6 +2956,9 @@ static int ironlake_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
ilk_enable_display_irq(dev_priv, bit);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 
+   if (HAS_PSR(dev_priv))
+   drm_vblank_restore(dev, pipe);
+
return 0;
 }
 
@@ -2968,6 +2971,9 @@ static int gen8_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 
+   if (HAS_PSR(dev_priv))
+   drm_vblank_restore(dev, pipe);
+
return 0;
 }
 
-- 
2.11.0

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

[PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.

[Dhinakaran Pandiyan]

The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negative diffs altogther as there
could be legitimate wrap arounds. So, allow drivers to update vblank->count
with missed vblanks for the time interrupts were disabled. This is similar
to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
end as this function is expected to be called from the driver
_enable_vblank() vfunc.

v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
Add docs and sprinkle some asserts.

Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Michel Dänzer 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 59 
 include/drm/drm_vblank.h |  2 ++
 2 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 2559d2d7b907..2690966694f0 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1237,6 +1237,65 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_vblank_on);
 
+/**
+ * drm_vblank_restore - estimated vblanks using timestamps and update it.
+ *
+ * Power manamement features can cause frame counter resets between vblank
+ * disable and enable. Drivers can then use this function in their
+ * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
+ * the last _crtc_funcs.disable_vblank.
+ *
+ * This function is the legacy version of drm_crtc_vblank_restore().
+ */
+void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
+{
+   ktime_t t_vblank;
+   struct drm_vblank_crtc *vblank;
+   int framedur_ns;
+   u64 diff_ns;
+   u32 cur_vblank, diff = 1;
+   int count = DRM_TIMESTAMP_MAXRETRIES;
+
+   if (WARN_ON(pipe >= dev->num_crtcs))
+   return;
+
+   assert_spin_locked(>vbl_lock);
+   assert_spin_locked(>vblank_time_lock);
+
+   vblank = >vblank[pipe];
+   WARN_ONCE((drm_debug & DRM_UT_VBL) && !vblank->framedur_ns,
+ "Cannot compute missed vblanks without frame duration\n");
+   framedur_ns = vblank->framedur_ns;
+
+   do {
+   cur_vblank = __get_vblank_counter(dev, pipe);
+   drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
+   } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
+
+   diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
+   if (framedur_ns)
+   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
+
+
+   DRM_DEBUG_VBL("missed %d vblanks in %lld ns, frame duration=%d ns, 
hw_diff=%d\n",
+ diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
+   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
+}
+EXPORT_SYMBOL(drm_vblank_restore);
+
+/**
+ * drm_crtc_vblank_restore - estimate vblanks using timestamps and update it.
+ * Power manamement features can cause frame counter resets between vblank
+ * disable and enable. Drivers can then use this function in their
+ * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
+ * the last _crtc_funcs.disable_vblank.
+ */
+void drm_crtc_vblank_restore(struct drm_crtc *crtc)
+{
+   drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_restore);
+
 static void drm_legacy_vblank_pre_modeset(struct drm_device *dev,
  unsigned int pipe)
 {
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index a4c3b0a0a197..16d46e2a6854 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -180,6 +180,8 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
 u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
+void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
+void drm_crtc_vblank_restore(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.11.0

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

[PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

[Dhinakaran Pandiyan]

Now that drm_vblank_count() returns all bits of the vblank count, update
drm_crtc_arm_vblank_event() so that it queues the correct sequence.
Otherwise, this leads to prolonged waits for a vblank sequence when the
current count is >=2^32.

Cc: Keith Packard 
Cc: Michel Dänzer 
Cc: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 4 ++--
 include/drm/drm_vblank.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 768a8e44d99b..f2bf1f5dbaa5 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -292,11 +292,11 @@ static u64 drm_vblank_count(struct drm_device *dev, 
unsigned int pipe)
  * This is mostly useful for hardware that can obtain the scanout position, but
  * doesn't have a hardware frame counter.
  */
-u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
+u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
-   u32 vblank;
+   u64 vblank;
unsigned long flags;
 
WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 848b463a0af5..a4c3b0a0a197 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -179,7 +179,7 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
 void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
-u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
+u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.11.0

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

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #7 from Christoph Haag  ---
Created attachment 136701
  --> https://bugs.freedesktop.org/attachment.cgi?id=136701=edit
glxinfo

-- 
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 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #6 from Christoph Haag  ---
Created attachment 136700
  --> https://bugs.freedesktop.org/attachment.cgi?id=136700=edit
xdpyinfo

No need to add to drirc, you can also set drirc options with an environment
variable.

This indeed works fine, no color issue:
allow_rgb10_configs=false compton --backend glx

-- 
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 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Friday, 12 January 2018 22:12:04 EET Sergei Shtylyov wrote:
> According to the latest revisions of the R-Car gen3 manual, the LVDS mode
> must be set before the LVDS I/O pins are enabled, not after --  fix  the
> gen3 LVDS startup sequence accordingly...
> 
> While  at it,  also fix the comment  preceding the first LVDCR0 write in
> the R-Car gen2 startup code that still talks about hardcoding the LVDS
> mode 0...

How about fixing that in patch 2/2 that touches the Gen2 initialization 
sequence ? I think I'd even go as far as squashing both patches, I don't think 
there's a need to split them.

> Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
> Signed-off-by: Sergei Shtylyov 

Is this really needed ? Does it fix a problem you've experienced, or is it 
theoretical only ? The mode shouldn't matter before the LVDS internal logic is 
turned on. Unless there's a real issue I'm not sure we should make the code 
more complex.

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -60,8 +60,8 @@ static void rcar_du_lvdsenc_start_gen2(s
>   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> 
>   /*
> -  * Select the input, hardcode mode 0, enable LVDS operation and turn
> -  * bias circuitry on.
> +  * Set the  LVDS mode, select the input, enable LVDS operation,
> +  * and turn bias circuitry on.
>*/
>   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
>   if (rcrtc->index == 2)
> @@ -106,6 +106,9 @@ static void rcar_du_lvdsenc_start_gen3(s
> 
>   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> 
> + lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
> + rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> +
>   /* Turn all the channels on. */
>   rcar_lvds_write(lvds, LVDCR1,
>   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> @@ -115,7 +118,8 @@ static void rcar_du_lvdsenc_start_gen3(s
>* Turn the PLL on, set it to LVDS normal mode, wait for the startup
>* delay and turn the output on.
>*/
> - lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
> +
> + lvdcr0 = | LVDCR0_PLLON;
>   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> 
>   lvdcr0 |= LVDCR0_PWD;

-- 
Regards,

Laurent Pinchart

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

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #5 from Mario Kleiner  ---
Can you try what happens if you add the following snippet
inside the  section of your /etc/drirc and restart compton?





The output of xdpyinfo and glxinfo could also be useful.

To disable the new rgb10 support globally, one can add this snippet instead:



-- 
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: rcar-du: lvds: Fix LVDS clock frequency range

[Laurent Pinchart]

According to the latest versions of both the Gen2 and Gen3 datasheets,
the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all
SoCs. Update the driver accordingly.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index 553bab7b3b1e..abbb7b25129a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -201,17 +201,11 @@ int rcar_du_lvdsenc_enable(struct rcar_du_lvdsenc *lvds, 
struct drm_crtc *crtc,
 void rcar_du_lvdsenc_atomic_check(struct rcar_du_lvdsenc *lvds,
  struct drm_display_mode *mode)
 {
-   struct rcar_du_device *rcdu = lvds->dev;
-
/*
 * The internal LVDS encoder has a restricted clock frequency operating
-* range (30MHz to 150MHz on Gen2, 25.175MHz to 148.5MHz on Gen3). Clamp
-* the clock accordingly.
+* range (31MHz to 148.5MHz). Clamp the clock accordingly.
 */
-   if (rcdu->info->gen < 3)
-   mode->clock = clamp(mode->clock, 3, 15);
-   else
-   mode->clock = clamp(mode->clock, 25175, 148500);
+   mode->clock = clamp(mode->clock, 31000, 148500);
 }
 
 void rcar_du_lvdsenc_set_mode(struct rcar_du_lvdsenc *lvds,
-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/amdgpu: Use seq_putc() in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 12 Jan 2018 22:08:50 +0100

A few single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  | 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 10805edcf964..7ac233f5abe2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -806,8 +806,8 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr, 
void *data)
pin_count = READ_ONCE(bo->pin_count);
if (pin_count)
seq_printf(m, " pin count %d", pin_count);
-   seq_printf(m, "\n");
 
+   seq_putc(m, '\n');
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index 3144400435b7..57ce42d960ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -419,11 +419,8 @@ void amdgpu_sa_bo_dump_debug_info(struct amdgpu_sa_manager 
*sa_manager,
list_for_each_entry(i, _manager->olist, olist) {
uint64_t soffset = i->soffset + sa_manager->gpu_addr;
uint64_t eoffset = i->eoffset + sa_manager->gpu_addr;
-   if (>olist == sa_manager->hole) {
-   seq_printf(m, ">");
-   } else {
-   seq_printf(m, " ");
-   }
+
+   seq_putc(m, (>olist == sa_manager->hole) ? '>' : ' ');
seq_printf(m, "[0x%010llx 0x%010llx] size %8lld",
   soffset, eoffset, eoffset - soffset);
 
@@ -431,7 +428,7 @@ void amdgpu_sa_bo_dump_debug_info(struct amdgpu_sa_manager 
*sa_manager,
seq_printf(m, " protected by 0x%08x on context %llu",
   i->fence->seqno, i->fence->context);
 
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
}
spin_unlock(_manager->wq.lock);
 }
-- 
2.15.1

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

Daniel Vetter (dan...@ffwll.ch) changed:

   What|Removed |Added

 Attachment #273531|0   |1
is obsolete||
 Attachment #273553|0   |1
is obsolete||

--- Comment #13 from Daniel Vetter (dan...@ffwll.ch) ---
Created attachment 273575
  --> https://bugzilla.kernel.org/attachment.cgi?id=273575=edit
test patch on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2, v2

Sry my brain must have been offline, first test patch on top of b8e2b was crap,
and the 2nd patch is ... nonsense.

I hope this one has a bit better chances of giving us something to work with.

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

Re: [PATCH] drm/fb-helper: Fix of-by-one in setcmap_pseudo_palette

[Daniel Vetter]

On Fri, Jan 12, 2018 at 3:08 PM, Sean Paul  wrote:
> On Fri, Jan 12, 2018 at 4:48 AM, Daniel Vetter  wrote:
>> [Fair warning: This is pure conjecture right now.]
>>
>> In
>>
>> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
>> Author: Peter Rosin 
>> Date:   Tue Jul 4 12:36:57 2017 +0200
>>
>> drm/fb-helper: factor out pseudo-palette
>>
>> Peter extracted the pseudo palette computation, but seems to have done
>> an off-by-one. I spotted that +1, but then noticed that we've passed
>> start++ to (now gone) setcolreg function, so it seemed to all match
>> up. Except post vs. pre-increment ftw.
>>
>> Result is that the palette is off-by-one, and the forground color
>> (slot 0) ends up black, rendering a fairly unreadable console.
>>
>> What baffles me is that on some systems it still seems to work
>> somehow, which lead us all down a wild goose chase trying to add
>> load_lut calls back in in various places (which was also intentionally
>> removed, but really doesn't seem to be the real root cause).
>>
>> Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
>> Cc: Peter Rosin 
>> Cc: Daniel Vetter 
>> Cc: Daniel Vetter 
>> Cc: Gustavo Padovan 
>> Cc: Sean Paul 
>> Cc: David Airlie 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc:  # v4.14+
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
>> Reported-by: Deposite Pirate 
>> Reported-by: Bill Fraser 
>> Cc: Deposite Pirate 
>> Cc: Bill Fraser 
>> Cc: Michel Dänzer 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 035784ddd133..1c3a200c4a10 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1295,7 +1295,7 @@ static int setcmap_pseudo_palette(struct fb_cmap 
>> *cmap, struct fb_info *info)
>> mask <<= info->var.transp.offset;
>> value |= mask;
>> }
>> -   palette[cmap->start + i] = value;
>> +   palette[cmap->start] = value;
>
> I don't think this is equivalent to what was there before. Before
> there we set palette[cmap->start]->palette[cmap->start + cmap->len -
> 1], now we're only setting palette[cmap->start].
>
> In the previous version (before Peter's change), we wrote
> palette[cmap->start] twice. So while there is an off-by-one bug, I
> don't think this fixes the issue.

Well this patch is complete nonsense, no idea what I was thinking ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/msm/dsi: check msm_dsi and dsi pointers before use

[Lloyd Atkinson]

Move null checks of pointer arguments to the beginning of the
modeset init function since they are referenced immediately
instead of after they have already been used.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 98742d7..be855db 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -196,7 +196,7 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
struct drm_bridge *ext_bridge;
int ret;
 
-   if (WARN_ON(!encoder))
+   if (!encoder || !msm_dsi || !dev)
return -EINVAL;
 
msm_dsi->dev = dev;
@@ -245,19 +245,17 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
 
return 0;
 fail:
-   if (msm_dsi) {
-   /* bridge/connector are normally destroyed by drm: */
-   if (msm_dsi->bridge) {
-   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
-   msm_dsi->bridge = NULL;
-   }
+   /* bridge/connector are normally destroyed by drm: */
+   if (msm_dsi->bridge) {
+   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
+   msm_dsi->bridge = NULL;
+   }
 
-   /* don't destroy connector if we didn't make it */
-   if (msm_dsi->connector && !msm_dsi->external_bridge)
-   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
+   /* don't destroy connector if we didn't make it */
+   if (msm_dsi->connector && !msm_dsi->external_bridge)
+   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
 
-   msm_dsi->connector = NULL;
-   }
+   msm_dsi->connector = NULL;
 
return ret;
 }
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH 2/3] drm/msm/dsi: correct DSI id bounds check during registration

[Lloyd Atkinson]

Check DSI instance id argument against the proper boundary size
to protect against invalid configuration of the DSI id.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index d276358..dec2f74 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -862,7 +862,7 @@ int msm_dsi_manager_register(struct msm_dsi *msm_dsi)
int id = msm_dsi->id;
int ret;
 
-   if (id > DSI_MAX) {
+   if (id >= DSI_MAX) {
pr_err("%s: invalid id %d\n", __func__, id);
return -EINVAL;
}
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH 1/3] drm/msm/dsi: check src_pll for null in dsi manager

[Lloyd Atkinson]

Add checks for failure after retrieving the src_pll, since it
may fail. This prevents an invalid pointer dereference later in
msm_dsi_pll_get_clk_provider.

Signed-off-by: Lloyd Atkinson 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 8552481..d276358 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -88,6 +88,8 @@ static int dsi_mgr_setup_components(int id)
 
msm_dsi_phy_set_usecase(msm_dsi->phy, MSM_DSI_PHY_STANDALONE);
src_pll = msm_dsi_phy_get_pll(msm_dsi->phy);
+   if (!src_pll)
+   return -EINVAL;
ret = msm_dsi_host_set_src_pll(msm_dsi->host, src_pll);
} else if (!other_dsi) {
ret = 0;
@@ -116,6 +118,8 @@ static int dsi_mgr_setup_components(int id)
msm_dsi_phy_set_usecase(clk_slave_dsi->phy,
MSM_DSI_PHY_SLAVE);
src_pll = msm_dsi_phy_get_pll(clk_master_dsi->phy);
+   if (!src_pll)
+   return -EINVAL;
ret = msm_dsi_host_set_src_pll(msm_dsi->host, src_pll);
if (ret)
return ret;
-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH 0/3] drm/msm/dsi: improve pointer validation checks

[Lloyd Atkinson]

This series improves a few pointer validation checks around the
drm/msm/dsi driver.

Lloyd Atkinson (3):
  drm/msm/dsi: check src_pll for null in dsi manager
  drm/msm/dsi: correct DSI id bounds check during registration
  drm/msm/dsi: check msm_dsi and dsi pointers before use

 drivers/gpu/drm/msm/dsi/dsi.c | 22 ++
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  6 +-
 2 files changed, 15 insertions(+), 13 deletions(-)

-- 
QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

Hi Sergei,

On Friday, 12 January 2018 17:13:06 EET Sergei Shtylyov wrote:
> On 01/12/2018 03:58 AM, Laurent Pinchart wrote:
> > The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> > corresponding device tree bindings.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../bindings/display/bridge/renesas,lvds.txt   | 54 +
> >  MAINTAINERS|  1 +
> >   2 files changed, 55 insertions(+)
> >   create mode 100644
> >   Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt> 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt new
> > file mode 100644
> > index ..459c56822eda
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > @@ -0,0 +1,54 @@
> > +Renesas R-Car LVDS Encoder
> > +==
> > +
> > +These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> > Gen2
> > +and Gen3 SoCs.
> > +
> > +Required properties:
> > +
> > +- compatible : Shall contain one of
> > +  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS
> > encoders
> > +  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS
> > encoders
> > +  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS
> > encoders
> > +  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS
> > encoders
> > +  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> > encoders
> > +  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> > encoders
> > +
> > +- reg: Base address and length for the memory-mapped registers
> > +- clocks: A phandle + clock-specifier pair for the functional clock
> > +
> > +Requires nodes:
> > +
> > +The LVDS encoder has two video ports. Their connections are modelled
> > using the
> > +OF graph bindings specified in Documentation/devicetree/bindings/
> > graph.txt.
> > +
> > +- Video port 0 corresponds to the parallel input
> 
> s/parallel/RGB/, perhaps?

Strictly speaking the LVDS output also carries RGB. I'll replace "parallel" 
with "parallel RGB".

> > +- Video port 1 corresponds to the LVDS output
> > +
> > +Each port shall have a single endpoint.
> > +
> > +
> > +Example:
> > +
> > +   lvds0: lvds@feb9 {
> > +   compatible = "renesas,lvds-r8a7790";
> > +   reg = <0 0xfeb9 0 0x1c>;
> > +   clocks = < CPG_MOD 726>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds0_in: endpoint {
> > +   remote-endpoint = <_out_lvds0>;
> 
> Err, that "du_out_lvds0" label no longer reflects reality, no?

Well, it's the output of the DU connected to LVDS encoder 0, so I think the 
name still makes sense. If you can think of a better name feel free to propose 
one, otherwise I'll keep this one.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Sergei Shtylyov]

On 01/12/2018 11:12 PM, Sergei Shtylyov wrote:


According to the latest revisions of the R-Car gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after --  fix  the
gen3 LVDS startup sequence accordingly...

While  at it,  also fix the comment  preceding the first LVDCR0 write in
the R-Car gen2 startup code that still talks about hardcoding the LVDS
mode 0...

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c

[...]

@@ -115,7 +118,8 @@ static void rcar_du_lvdsenc_start_gen3(s
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
+
+   lvdcr0 = | LVDCR0_PLLON;


   Dunno how it slipped in -- I've surely built and tested the resulting 
kernel... should be |=, of course. Laurent, should I repost?


[...]

MBR, Sergei


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

[PATCH 2/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen2

[Sergei Shtylyov]

According to the latest revision 2.00 of the R-Car gen2 manual, the LVDS
must be enabled and the bias crcuit  enabled after the LVDS I/O pins are
enabled, not before --  fix the gen2 LVDS startup sequence accordingly.

Fixes: 90374b5c25c9 ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -59,11 +59,8 @@ static void rcar_du_lvdsenc_start_gen2(s
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
-   /*
-* Set the  LVDS mode, select the input, enable LVDS operation,
-* and turn bias circuitry on.
-*/
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
+   /* Select the input and set the LVDS mode. */
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
@@ -73,6 +70,10 @@ static void rcar_du_lvdsenc_start_gen2(s
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
 
+   /* Enable LVDS operation and turn bias circuitry on. */
+   lvdcr0 |= LVDCR0_BEN | LVDCR0_LVEN;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/*
 * Turn the PLL on, wait for the startup delay, and turn the output
 * on.

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

[PATCH 1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3

[Sergei Shtylyov]

According to the latest revisions of the R-Car gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after --  fix  the
gen3 LVDS startup sequence accordingly...

While  at it,  also fix the comment  preceding the first LVDCR0 write in
the R-Car gen2 startup code that still talks about hardcoding the LVDS
mode 0...

Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -60,8 +60,8 @@ static void rcar_du_lvdsenc_start_gen2(s
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
/*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
+* Set the  LVDS mode, select the input, enable LVDS operation,
+* and turn bias circuitry on.
 */
lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
if (rcrtc->index == 2)
@@ -106,6 +106,9 @@ static void rcar_du_lvdsenc_start_gen3(s
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
+   lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+
/* Turn all the channels on. */
rcar_lvds_write(lvds, LVDCR1,
LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
@@ -115,7 +118,8 @@ static void rcar_du_lvdsenc_start_gen3(s
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
+
+   lvdcr0 = | LVDCR0_PLLON;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
 
lvdcr0 |= LVDCR0_PWD;

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

[PATCH 0/2] Fix LVDS startup sequences in the R-Car DU driver...

[Sergei Shtylyov]

Hello!

Here's the set of 2 patches against the 'drmf-ixes' branch of David Airlie's
'linux.git' repo plus the patch fixing LVDCR1 for R-Car gen3 posted recently.
Documentation check against the recent manuals revealed that the LVDS startup
sequences don't match those. I was able to test the gen3 patch on V3M, gen2
patch remained untested because the DU support on the Porter board is borked,
hopefully Laurent can test the gen2 patch on Lager...

[1/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen3
[2/2] drm: rcar-du: lvds: fix LVDS startup on R-Car gen2

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

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

network...@rkmail.ru changed:

   What|Removed |Added

 CC||network...@rkmail.ru

--- Comment #4 from network...@rkmail.ru ---
*** Bug 104540 has been marked as a duplicate of this bug. ***

-- 
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 104540] Corrupted colors in OBS-Studio window capture

[bugzilla-daemon]

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

network...@rkmail.ru changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from network...@rkmail.ru ---


*** This bug has been marked as a duplicate of bug 104597 ***

-- 
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 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

--- Comment #3 from network...@rkmail.ru ---
bug 104540 is probably the very same issue, since OBS uses Xcomposite to
capture a window.

-- 
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 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

[bugzilla-daemon]

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

--- Comment #2 from network...@rkmail.ru ---
(In reply to Bas Nieuwenhuizen from comment #1)
> This patch is on the list and probably fixes it:
> 
> https://patchwork.freedesktop.org/patch/197359/

Thank you, it worked for me.

-- 
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 4/4 v7] drm/pl111: Support handling bridge timings

[Linus Walleij]

On Fri, Jan 12, 2018 at 10:25 AM, Archit Taneja  wrote:
> On 01/12/2018 01:18 PM, Linus Walleij wrote:
>>
>> If the bridge has a too strict setup time for the incoming
>> signals, we may not be fast enough and then we need to
>> compensate by outputting the signal on the inverse clock
>> edge so it is for sure stable when the bridge samples it.
>>
>> Since bridges in difference to panels does not expose their
>> connectors, make the connector optional in the display
>> setup code.
>>
>
> Since Eric has already Ack'ed it, queued to drm-misc-next so that
> the commits stay together.

Thanks man!

I have commit access but this is fine too, it's a bit like an
definitive external ACK :)

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

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

On 01/12/2018 07:12 PM, Hans Verkuil wrote:
> On 01/12/2018 06:52 PM, Ville Syrjälä wrote:
>> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote:
>>> On 01/12/2018 05:30 PM, Ville Syrjälä wrote:
 On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
> Hi Ville,
>
> For some strange reason your email disappeared from the Cc list. Perhaps 
> it's the
> ä that confuses something somewhere.
>
> So I'll just forward this directly to you.
>
> Can you please take a look? This patch series has been in limbo for too 
> long.

 IIRC last I looked we still had some ragistration race to deal with.
 Was that fixed?
>>>
>>> That was fixed in v5.
>>>

 Also I think we got stuck on leaving the zombie device lingering around
 when the display is disconnected. I couldn't understand why that is
 at all useful since you anyway remove the device eventually.
>>>
>>> It's not a zombie device. If you disconnect and reconnect the display then 
>>> the
>>> application using the CEC device will see the display disappear and reappear
>>> as expected.
>>>
>>> It helps if you think of the normal situation (as is present in most ARM 
>>> SoCs)
>>> where CEC is integral to the HDMI transmitter. I.e. it is not functionality 
>>> that
>>> can be removed. So the cec device is always there and an application opens 
>>> the
>>> device and can use it, regardless of whether a display is connected or not.
>>>
>>> If a display is detected, the EDID will be read and the CEC physical 
>>> address is
>>> set. The application is informed of that through an event and the CEC 
>>> adapter
>>> can be used. If the HPD disappears the physical address is reset to f.f.f.f 
>>> and
>>> again the application is informed. And in fact it still has to be able to 
>>> use
>>> the CEC adapter even if there is no HPD since some displays turn off the 
>>> HPD when
>>> in standby, but CEC can still be used to power them up again.
>>
>> Hmm. So you're saying there are DP devices out there that release HPD
>> but still respond to DPCD accesses? That sounds... wrong.
> 
> Not quite. To be precise: there are HDMI displays that release HPD when in 
> standby
> but still respond to CEC commands.
> 
> Such displays are still being made today so if you are building a product like
> a media streaming box, then this is something to take into account.
> 
> However, for this specific case (CEC tunneling) it is a non-issue since the
> DP CEC protocol simply doesn't support sending CEC commands without HPD.
> 
>> In general I don't think we can assume that a device has retained its
>> state if it has deasserted HPD, thus we have to reconfigure everything
>> again anyway.
>>
>>>
>>> Now consider a future Intel NUC with an HDMI connector on the backplane and
>>> working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the
>>> CEC support is always there (it's built in), but only becomes visible to the
>>> kernel when you connect a display. You don't want the cec device to 
>>> disappear
>>> whenever you unplug the display, that makes no sense. Applications would
>>> loose the CEC configuration and have to close and reopen (when it reappears)
>>> the cec device for no good reason since it is built in.
>>
>> If the application can't remember its settings across a disconnect it
>> sounds broken anwyay. This would anyway happen when you disconenct the
>> entire dongle.
> 
> Huh?
> 
>>
>>>
>>> The same situation is valid when using a USB-C to HDMI adapter: 
>>> disconnecting
>>> or reconnecting a display should not lead to the removal of the CEC device.
>>> Only when an adapter with different CEC capabilities is detected is there a
>>> need to actually unregister the CEC device.
>>>
>>> All this is really a workaround of the fact that when the HPD disappears the
>>> DP-to-HDMI adapter (either external or built-in) also disappears from the
>>> topology, even though it is physically still there.
>>
>> The dongles I've seen do not disappear. The downstream hpd is
>> signalled with short hpd pulses + SINK_COUNT instead.
>>
>> But I've not actually seen a dongle that implements the
>> BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would
>> actually do. The spec does say they should default to using long
>> hpd for downstream hpd handling.
> 
> I did a few more experiments and it appears that someone somewhere keeps
> track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter
> it still appears in i915_display_info. At least until something else is
> connected. I basically need to hook into the DP branch detection.
> 
> Something to look at this weekend.

I found a better place to do the CEC (un)registration: a long HPD pulse
indicates that the DPCD registers have changed, so that's when I should
detect whether there is a new branch device with CEC capabilities.

Regards,

Hans
___
dri-devel mailing 

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

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

--- Comment #1 from Vedran Miletić  ---
Created attachment 136692
  --> https://bugs.freedesktop.org/attachment.cgi?id=136692=edit
dmesg

-- 
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 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

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

Bug ID: 104608
   Summary: [r600, RV635] Removing radeon module results in BUG:
unable to handle kernel NULL pointer dereference at
0258
   Product: DRI
   Version: unspecified
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net

(Reported to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1534012)

Description of problem:
Removing radeon module using modprobe -r results in BUG: unable to handle
kernel NULL pointer dereference at 0258

Version-Release number of selected component (if applicable):
4.14.13-300.fc27.x86_64

How reproducible:
Didn't try.

Steps to Reproduce:
1. sudo modprobe -r radeon
2.
3.

Actual results:
[115942.917095] BUG: unable to handle kernel NULL pointer dereference at
0258  
[115942.917144] IP: mutex_lock+0x1d/0x40   
[115942.917174] PGD 0 P4D 0
[115942.917207] Oops: 0002 [#1] SMP PTI
[115942.917238] Modules linked in: tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security
ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_realtek
snd_hda_codec_generic sunrpc snd_hda_codec_hdmi ppdev snd_hda_intel iTCO_wdt
iTCO_vendor_support snd_hda_codec snd_hda_core coretemp snd_hwdep snd_pcm
i2c_i801 snd_timer snd parport_pc lpc_ich soundcore parport asus_atk0110 shpchp
acpi_cpufreq xfs libcrc32c ata_generic pata_acpi amdkfd amd_iommu_v2 radeon(-)
serio_raw r8169 firewire_ohci i2c_algo_bit firewire_core
[115942.917377]  pata_marvell mii crc_itu_t drm_kms_helper ttm drm  
[115942.917417] CPU: 0 PID: 6778 Comm: modprobe Not tainted
4.14.13-300.fc27.x86_64 #1 
[115942.917488] Hardware name: System manufacturer System Product Name/P5QL-EM,
BIOS 080205/12/2010
[115942.917558] task: 96b09a4b3c00 task.stack: b500c13b4000 
[115942.917610] RIP: 0010:mutex_lock+0x1d/0x40 
[115942.917659] RSP: 0018:b500c13b7cf0 EFLAGS: 00010246
[115942.917710] RAX:  RBX: 0258 RCX:
0001002f  
[115942.917779] RDX: 96b09a4b3c00 RSI: 96b095a0ef20 RDI:
0258  
[115942.917849] RBP: b500c13b7cf8 R08: 96b093a19a80 R09:
0001002f  
[115942.917918] R10: b500c13b7cc8 R11:  R12:
0258  
[115942.917987] R13: 96b095a0ef20 R14: c0625210 R15:
96b09a50f100  
[115942.918064] FS:  7faa7058c0c0() GS:96b09fc0()
knlGS:   
[115942.918065] CS:  0010 DS:  ES:  CR0: 80050033   
[115942.918065] CR2: 0258 CR3: 50256000 CR4:
06f0  
[115942.918065] Call Trace:
[115942.918065]  drm_mode_object_unregister+0x23/0x50 [drm]
[115942.918065]  drm_framebuffer_unregister_private+0x1a/0x20 [drm] 
[115942.918065]  radeon_fbdev_fini+0x56/0x80 [radeon]  
[115942.918065]  radeon_modeset_fini+0x72/0xb0 [radeon]
[115942.918065]  radeon_driver_unload_kms+0x43/0x80 [radeon]
[115942.918065]  drm_dev_unregister+0x43/0xf0 [drm]
[115942.918065]  drm_put_dev+0x32/0x70 [drm]   
[115942.918065]  radeon_pci_remove+0x15/0x20 [radeon]  
[115942.918065]  pci_device_remove+0x39/0xb0   
[115942.918065]  device_release_driver_internal+0x158/0x210
[115942.918065]  driver_detach+0x38/0x70   
[115942.918065]  bus_remove_driver+0x59/0xd0   
[115942.918065]  driver_unregister+0x2c/0x40   
[115942.918065]  pci_unregister_driver+0x22/0xb0   
[115942.918065]  radeon_exit+0x15/0x6f [radeon]
[115942.918065]  SyS_delete_module+0x1a8/0x2b0 
[115942.918065]  ? exit_to_usermode_loop+0x8f/0xb0 
[115942.918065]  entry_SYSCALL_64_fastpath+0x20/0x83   
[115942.918065] RIP: 0033:0x7faa6fa54077   
[115942.918065] RSP: 002b:7ffd42b9ccc8 EFLAGS: 0206 ORIG_RAX:
00b0 
[115942.918065] RAX: ffda RBX: 0003 RCX:
7faa6fa54077

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #25 from Direx  ---
The printks indeed only show up when the computer boots or when the display
comes back from DPMS. I don't get any printks when playing audio streams.

(In reply to Alex Deucher from comment #24)
> Can you see what channels is set to in dce110_se_audio_setup() in
> dce_stream_encoder.c?  Does forcing it to 0xff help?

Ok, here's my change:

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index e42b6eb1c1f0..19befbf594c2 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -1320,6 +1320,9 @@ static void dce110_se_audio_setup(
speakers = audio_info->flags.info.ALLSPEAKERS;
channels = speakers_to_channels(audio_info->flags.speaker_flags).all;

+printk(KERN_WARNING "hbrlog: channels set to %d, forcing 0xff", channels);
+channels = 0xff;
+
/* setup the audio stream source select (audio -> dig mapping) */
REG_SET(AFMT_AUDIO_SRC_CONTROL, 0, AFMT_AUDIO_SRC_SELECT, az_inst);


And that's what I get in dmesg:

[   10.920144] hbrlog: channels set to 255, forcing 0xff

-> So unfortunately no change here.

//BTW: my DP monitor is reporting 3 channels, which also sounds good to me

-- 
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 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

[bugzilla-daemon]

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

--- Comment #1 from Bas Nieuwenhuizen  ---
This patch is on the list and probably fixes it:

https://patchwork.freedesktop.org/patch/197359/

-- 
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 104607] Mesa fails to build in OBS after c797cd605ac9cb42795a40b1967b6dd10184b763

[bugzilla-daemon]

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

Bug ID: 104607
   Summary: Mesa fails to build in OBS after
c797cd605ac9cb42795a40b1967b6dd10184b763
   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: network...@rkmail.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136691
  --> https://bugs.freedesktop.org/attachment.cgi?id=136691=edit
Don't look at me

Mesa fails to build with openSUSE build service after the commit
c797cd605ac9cb42795a40b1967b6dd10184b763 with message 'I: Program returns
random data in a function \n E: Mesa no-return-in-nonvoid-function
si_shader.c:1967'

I had to make some changes to si_shader.c to make it build again, however I had
no idea what I was doing.

-- 
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 104507] Unable to set "Content Type" bit for HDMI and DisplayPort

[bugzilla-daemon]

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

--- Comment #2 from N. W.  ---
Any update?

-- 
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 104508] Unable to set "Content Type" bit for HDMI and DisplayPort

[bugzilla-daemon]

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

--- Comment #2 from N. W.  ---
Any update?

-- 
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: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

On 01/12/2018 06:52 PM, Ville Syrjälä wrote:
> On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote:
>> On 01/12/2018 05:30 PM, Ville Syrjälä wrote:
>>> On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
 Hi Ville,

 For some strange reason your email disappeared from the Cc list. Perhaps 
 it's the
 ä that confuses something somewhere.

 So I'll just forward this directly to you.

 Can you please take a look? This patch series has been in limbo for too 
 long.
>>>
>>> IIRC last I looked we still had some ragistration race to deal with.
>>> Was that fixed?
>>
>> That was fixed in v5.
>>
>>>
>>> Also I think we got stuck on leaving the zombie device lingering around
>>> when the display is disconnected. I couldn't understand why that is
>>> at all useful since you anyway remove the device eventually.
>>
>> It's not a zombie device. If you disconnect and reconnect the display then 
>> the
>> application using the CEC device will see the display disappear and reappear
>> as expected.
>>
>> It helps if you think of the normal situation (as is present in most ARM 
>> SoCs)
>> where CEC is integral to the HDMI transmitter. I.e. it is not functionality 
>> that
>> can be removed. So the cec device is always there and an application opens 
>> the
>> device and can use it, regardless of whether a display is connected or not.
>>
>> If a display is detected, the EDID will be read and the CEC physical address 
>> is
>> set. The application is informed of that through an event and the CEC adapter
>> can be used. If the HPD disappears the physical address is reset to f.f.f.f 
>> and
>> again the application is informed. And in fact it still has to be able to use
>> the CEC adapter even if there is no HPD since some displays turn off the HPD 
>> when
>> in standby, but CEC can still be used to power them up again.
> 
> Hmm. So you're saying there are DP devices out there that release HPD
> but still respond to DPCD accesses? That sounds... wrong.

Not quite. To be precise: there are HDMI displays that release HPD when in 
standby
but still respond to CEC commands.

Such displays are still being made today so if you are building a product like
a media streaming box, then this is something to take into account.

However, for this specific case (CEC tunneling) it is a non-issue since the
DP CEC protocol simply doesn't support sending CEC commands without HPD.

> In general I don't think we can assume that a device has retained its
> state if it has deasserted HPD, thus we have to reconfigure everything
> again anyway.
> 
>>
>> Now consider a future Intel NUC with an HDMI connector on the backplane and
>> working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the
>> CEC support is always there (it's built in), but only becomes visible to the
>> kernel when you connect a display. You don't want the cec device to disappear
>> whenever you unplug the display, that makes no sense. Applications would
>> loose the CEC configuration and have to close and reopen (when it reappears)
>> the cec device for no good reason since it is built in.
> 
> If the application can't remember its settings across a disconnect it
> sounds broken anwyay. This would anyway happen when you disconenct the
> entire dongle.

Huh?

> 
>>
>> The same situation is valid when using a USB-C to HDMI adapter: disconnecting
>> or reconnecting a display should not lead to the removal of the CEC device.
>> Only when an adapter with different CEC capabilities is detected is there a
>> need to actually unregister the CEC device.
>>
>> All this is really a workaround of the fact that when the HPD disappears the
>> DP-to-HDMI adapter (either external or built-in) also disappears from the
>> topology, even though it is physically still there.
> 
> The dongles I've seen do not disappear. The downstream hpd is
> signalled with short hpd pulses + SINK_COUNT instead.
> 
> But I've not actually seen a dongle that implements the
> BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would
> actually do. The spec does say they should default to using long
> hpd for downstream hpd handling.

I did a few more experiments and it appears that someone somewhere keeps
track of DP branch devices. I.e. after disconnecting my usb-c to hdmi adapter
it still appears in i915_display_info. At least until something else is
connected. I basically need to hook into the DP branch detection.

Something to look at this weekend.

Regards,

Hans

> 
>> If there was a way to
>> detect the adapter when there is no display connected, then this workaround
>> wouldn't be needed.
>>
>> This situation is specific to DisplayPort, this is the only case where the
>> HDMI connector disappears in a puff of smoke when you disconnect the HDMI
>> cable, even though the actual physical connector is obviously still there.
>>
>> Regards,
>>
>>  Hans
>>
>>>
>>> Adding the lists back to cc so I don't have to repeat 

Re: [Intel-gfx] [PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

[Colin Ian King]

On 12/01/18 17:48, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 12/01/2018 17:36, Colin King wrote:
>> From: Colin Ian King 
>>
>> I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately
>> the current code works because sizeof(struct attribute **) is the same
>> as sizeof(struct attribute *) for x86.
> 
> Thanks, kbuild also reported it and I just pushed a fix.
> 
> Out of curiosity, there are platforms where size of pointer is different
> from the size of a pointer to a pointer?

None that I know of.

> 
> Regards,
> 
> Tvrtko
> 
>>
>> Detected by CoverityScan, CID#1463854 ("Sizeof not portable")
>>
>> Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters
>> in sysfs")
>> Signed-off-by: Colin Ian King 
>> ---
>>   drivers/gpu/drm/i915/i915_pmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c
>> b/drivers/gpu/drm/i915/i915_pmu.c
>> index 95ab5e28f5be..9be4f5201e41 100644
>> --- a/drivers/gpu/drm/i915/i915_pmu.c
>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
>> @@ -794,7 +794,7 @@ create_event_attributes(struct drm_i915_private
>> *i915)
>>   goto err_alloc;
>>     /* Max one pointer of each attribute type plus a termination
>> entry. */
>> -    attr = kzalloc((count * 2 + 1) * sizeof(attr), GFP_KERNEL);
>> +    attr = kzalloc((count * 2 + 1) * sizeof(*attr), GFP_KERNEL);
>>   if (!attr)
>>   goto err_alloc;
>>  

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #24 from Alex Deucher  ---
Can you see what channels is set to in dce110_se_audio_setup() in
dce_stream_encoder.c?  Does forcing it to 0xff help?

-- 
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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #23 from Alex Deucher  ---
(In reply to lethalwp from comment #22)
> Thank you for the printks.
> 
> If the code is only ran at initialization of gpu:
> 
> could this explain the lpcm noise issue?: The reserved bandwidth at gpu init
> isn't enough anymore when video+more audio comes through?

The audio configuration only needs to run once per modeset.  It basically just 
forwards the display info to the audio device and tells the audio device what
it can support given the current display mode and enables the audio stream
within the display stream.  At that point, the display device is just a conduit
for the audio device.

-- 
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: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Ville Syrjälä]

On Fri, Jan 12, 2018 at 06:14:53PM +0100, Hans Verkuil wrote:
> On 01/12/2018 05:30 PM, Ville Syrjälä wrote:
> > On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
> >> Hi Ville,
> >>
> >> For some strange reason your email disappeared from the Cc list. Perhaps 
> >> it's the
> >> ä that confuses something somewhere.
> >>
> >> So I'll just forward this directly to you.
> >>
> >> Can you please take a look? This patch series has been in limbo for too 
> >> long.
> > 
> > IIRC last I looked we still had some ragistration race to deal with.
> > Was that fixed?
> 
> That was fixed in v5.
> 
> > 
> > Also I think we got stuck on leaving the zombie device lingering around
> > when the display is disconnected. I couldn't understand why that is
> > at all useful since you anyway remove the device eventually.
> 
> It's not a zombie device. If you disconnect and reconnect the display then the
> application using the CEC device will see the display disappear and reappear
> as expected.
> 
> It helps if you think of the normal situation (as is present in most ARM SoCs)
> where CEC is integral to the HDMI transmitter. I.e. it is not functionality 
> that
> can be removed. So the cec device is always there and an application opens the
> device and can use it, regardless of whether a display is connected or not.
> 
> If a display is detected, the EDID will be read and the CEC physical address 
> is
> set. The application is informed of that through an event and the CEC adapter
> can be used. If the HPD disappears the physical address is reset to f.f.f.f 
> and
> again the application is informed. And in fact it still has to be able to use
> the CEC adapter even if there is no HPD since some displays turn off the HPD 
> when
> in standby, but CEC can still be used to power them up again.

Hmm. So you're saying there are DP devices out there that release HPD
but still respond to DPCD accesses? That sounds... wrong.

In general I don't think we can assume that a device has retained its
state if it has deasserted HPD, thus we have to reconfigure everything
again anyway.

> 
> Now consider a future Intel NUC with an HDMI connector on the backplane and
> working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the
> CEC support is always there (it's built in), but only becomes visible to the
> kernel when you connect a display. You don't want the cec device to disappear
> whenever you unplug the display, that makes no sense. Applications would
> loose the CEC configuration and have to close and reopen (when it reappears)
> the cec device for no good reason since it is built in.

If the application can't remember its settings across a disconnect it
sounds broken anwyay. This would anyway happen when you disconenct the
entire dongle.

> 
> The same situation is valid when using a USB-C to HDMI adapter: disconnecting
> or reconnecting a display should not lead to the removal of the CEC device.
> Only when an adapter with different CEC capabilities is detected is there a
> need to actually unregister the CEC device.
> 
> All this is really a workaround of the fact that when the HPD disappears the
> DP-to-HDMI adapter (either external or built-in) also disappears from the
> topology, even though it is physically still there.

The dongles I've seen do not disappear. The downstream hpd is
signalled with short hpd pulses + SINK_COUNT instead.

But I've not actually seen a dongle that implements the
BRANCH_DEVICE_CTRL DPCD register, so not quite sure what those would
actually do. The spec does say they should default to using long
hpd for downstream hpd handling.

> If there was a way to
> detect the adapter when there is no display connected, then this workaround
> wouldn't be needed.
> 
> This situation is specific to DisplayPort, this is the only case where the
> HDMI connector disappears in a puff of smoke when you disconnect the HDMI
> cable, even though the actual physical connector is obviously still there.
> 
> Regards,
> 
>   Hans
> 
> > 
> > Adding the lists back to cc so I don't have to repeat myself there...
> > 
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>
> >>  Forwarded Message 
> >> Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort 
> >> CEC-Tunneling-over-AUX support
> >> Date: Tue, 9 Jan 2018 13:46:44 +0100
> >> From: Hans Verkuil 
> >> To: linux-me...@vger.kernel.org
> >> CC: Daniel Vetter , Carlos Santa 
> >> , dri-devel@lists.freedesktop.org
> >>
> >> First of all a Happy New Year for all of you!
> >>
> >> And secondly: can this v5 patch series be reviewed/merged? It's been 
> >> waiting
> >> for that for a very long time now...
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >> On 12/11/17 09:57, Hans Verkuil wrote:
> >>> Ping again. Added a CC to Ville whom I inexplicably forgot to add when
> >>> I sent the v5 patch series.
> >>>
> >>> Regards,
> >>>
> >>>   Hans
> >>>
> >>> On 01/12/17 08:23, Hans 

Re: [Intel-gfx] [PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

[Tvrtko Ursulin]

Hi,

On 12/01/2018 17:36, Colin King wrote:

From: Colin Ian King 

I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately
the current code works because sizeof(struct attribute **) is the same
as sizeof(struct attribute *) for x86.


Thanks, kbuild also reported it and I just pushed a fix.

Out of curiosity, there are platforms where size of pointer is different 
from the size of a pointer to a pointer?


Regards,

Tvrtko



Detected by CoverityScan, CID#1463854 ("Sizeof not portable")

Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")
Signed-off-by: Colin Ian King 
---
  drivers/gpu/drm/i915/i915_pmu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 95ab5e28f5be..9be4f5201e41 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -794,7 +794,7 @@ create_event_attributes(struct drm_i915_private *i915)
goto err_alloc;
  
  	/* Max one pointer of each attribute type plus a termination entry. */

-   attr = kzalloc((count * 2 + 1) * sizeof(attr), GFP_KERNEL);
+   attr = kzalloc((count * 2 + 1) * sizeof(*attr), GFP_KERNEL);
if (!attr)
goto err_alloc;
  


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

[radeon-alex:drm-next-4.16-wip 77/81] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple definition of `amdgpu_dm_crtc_handle_crc_irq'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.16-wip
head:   d9c47236f500494614a0d3a8e24d70e3c4da9efd
commit: df6b3c876d2467ea000ab97d986fac1b45436fb2 [77/81] drm/amd/display: 
Implement interface for CRC on CRTC
config: x86_64-randconfig-r0-01122329 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout df6b3c876d2467ea000ab97d986fac1b45436fb2
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/atombios_crtc.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/atom.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_gart.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_display.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   

Re: [RFC][PATCH 5/5] drm_hwcomposer: HACK: Fix tearing on hikey/hikey960

[Rob Herring]

On Thu, Jan 11, 2018 at 11:20 PM, John Stultz  wrote:
> On Tue, Jan 9, 2018 at 10:05 PM, John Stultz  wrote:
>> When using drm_hwcomposer with the hikey/hikey960 boards, the
>> resulting display shows lots of tearing.
>>
>> I'm not much of an expert in how this code should work, but it
>> seems that we never call sync_wait(), and thus don't seem to be
>> handling the fences properly? I'm not sure.
>>
>> Anyway, in a daze, I started cutting out code trying to make
>> sure we call the CreateNextTimelineFence() and
>> fb.set_release_fence_fd().
>>
>> After doing so the tearing went away. I'm really not sure
>> what is wrong that requires these hacks. It may be the
>> hikey/hikey960 drm driver is incorrectly reporting or
>> handling something?
>>
>> We do only have a single plane and no hardware compositing on
>> the boards, so we are having to force the gpu to do all the
>> compositing.
>>
>> Any ideas for what a proper fix here would be? Or even just
>> hints on why this might make things work?
>
> So I've maybe started to understand things a bit (though probably not
> much) more here. Again, my apologies for being very new to all this.
>
> This patch actually isn't necessary on the HiKey960, as in the mix of
> testing both boards, I didn't get it working until after the HiKey
> board so I incorrectly assumed this would be needed.
>
> This patch is really only useful to avoid the tearing I see with the
> HiKey board.
>
> The core issue on HiKey is that in
> DrmDisplayCompositor::PrepareFrame(), when we initialize the
> precompositor_ to a new GLWorkerCompositor, the eglCreateContext()
> call fails because we're asking for version 3, which the HiKey's
> utgard mali implementation doesn't support (thus why the
> pre_compositor_->Composite() call always fails in ApplySquash() -
> though still need to figure out why squash_regions are empty).
>
> Asking for version 2 gets us along a bit further, but then I hit other
> trouble with the eglMakeCurrent() call in BeginContext, as passing
> EGL_NO_SURFACE, EGL_NO_SURFACE without EGL_NO_CONTEXT seems to trigger
> an error in the mali GL implementation. However, using EGL_NO_CONTEXT
> causes surfaceflinger to crash, so I just hacked it up to skip the
> eglMakeCurrent call to keep things going.
>
> The next issue that I run into is maybe the more problematic one: The
> vertex and fragment shaders in the glworker.c are marked as "#version
> 300 es", which utgard can't handle (apparently it maxes out at
> "#version 100", but can't seemingly handle other syntax like "in").
>
> So the bigger question I guess I have is: Is the drm_hwcomposer as a
> project targeting a certain minimal GLES version, or is it open to
> supporting older/limited hardware like the utgard level mali?  I can
> look into trying to figure out if what needs to be done can be done in
> a simpler shader language, or alternatively we can add fallback code
> to still allow for fence handling for tear-free functionality w/o the
> GL compositor (which is basically what this hack patch in-effect
> allows).

It requires ES 3.0 'cause no one has implemented anything else...
Doesn't passing CTS since N at least require ES 3.0?

I think having a fallback path that requires no GL is needed. The
fence handling there should be simple pass thru to/from the kernel
display driver.

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

[PATCH][next] drm/i915/pmu: fix sizeof on attr, should be *attr

[Colin King]

From: Colin Ian King 

I believe the sizeof(attr) should be in fact sizeof(*attr), fortunately
the current code works because sizeof(struct attribute **) is the same
as sizeof(struct attribute *) for x86.

Detected by CoverityScan, CID#1463854 ("Sizeof not portable")

Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/i915_pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 95ab5e28f5be..9be4f5201e41 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -794,7 +794,7 @@ create_event_attributes(struct drm_i915_private *i915)
goto err_alloc;
 
/* Max one pointer of each attribute type plus a termination entry. */
-   attr = kzalloc((count * 2 + 1) * sizeof(attr), GFP_KERNEL);
+   attr = kzalloc((count * 2 + 1) * sizeof(*attr), GFP_KERNEL);
if (!attr)
goto err_alloc;
 
-- 
2.15.1

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

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

[Eric Engestrom]

On Friday, 2018-01-05 12:01:00 -0800, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> ---
>  README | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/README b/README
> index 26cab9d..f3df9ac 100644
> --- a/README
> +++ b/README
> @@ -15,9 +15,27 @@ 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 an equivalent feature 
> set.
> +
> +To use it:
> +
> +meson builddir/
> +
> +By default this will install into /usr/local, you can change your prefix
> +with --prefix=/usr (or `meson configure builddir/ -Dprefix=/usr` after 
> +the initial meson setup).
> +
> +Then use ninja to build and install:
> +
> +ninja -C builddir/ install
> +
> +If you are installing into a system location you will need to run install
> +separately, and as root.
> +
> +
> +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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH 2/3] autotools: Include meson.build files in tarball

[Eric Engestrom]

On Friday, 2018-01-05 12:00:59 -0800, Dylan Baker wrote:
> 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

You're missing a couple meson.builds:
tegra/meson.build
tests/modetest/meson.build

with those two added:
Reviewed-by: Eric Engestrom 

>  
>  copy-headers :
>   cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
> -- 
> git-series 0.9.1
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] Add meson build system

[Eric Engestrom]

On Friday, 2018-01-05 12:00:58 -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.
> 
> Signed-off-by: Dylan Baker 
> Reviewed-and-tested-by: Igor Gnatenko 
> ---
>  .editorconfig   |   4 +-
>  amdgpu/.editorconfig|   4 +-
>  amdgpu/meson.build  |  65 +++-
>  data/meson.build|  27 +++-
>  etnaviv/meson.build |  59 ++-
>  exynos/meson.build  |  53 +-
>  freedreno/meson.build   |  76 -
>  intel/meson.build   | 105 +++-
>  libkms/meson.build  |  74 -
>  man/meson.build |  67 +++-
>  meson.build | 364 +-
>  meson_options.txt   | 143 +++-
>  nouveau/meson.build |  58 ++-
>  omap/meson.build|  53 +-
>  radeon/meson.build  |  63 ++-
>  tegra/meson.build   |  52 +-
>  tests/amdgpu/meson.build|  34 +++-
>  tests/etnaviv/meson.build   |  45 +-
>  tests/exynos/meson.build|  54 +-
>  tests/kms/meson.build   |  49 +-
>  tests/kmstest/meson.build   |  30 +++-
>  tests/meson.build   |  86 +-
>  tests/modeprint/meson.build |  29 +++-
>  tests/modetest/meson.build  |  29 +++-
>  tests/nouveau/meson.build   |  30 +++-
>  tests/proptest/meson.build  |  28 +++-
>  tests/radeon/meson.build|  27 +++-
>  tests/tegra/meson.build |  27 +++-
>  tests/util/meson.build  |  28 +++-
>  tests/vbltest/meson.build   |  28 +++-
>  vc4/meson.build |  28 +++-
>  31 files changed, 1819 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..29b4f39 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..426273f 100644
> --- a/amdgpu/.editorconfig
> +++ b/amdgpu/.editorconfig
> @@ -7,3 +7,7 @@ indent_style = tab
>  indent_size = 8
>  tab_width = 8
>  insert_final_newline = true
> +
> +[meson.build]
> +indent_style = space
> +indent_size = 2
> diff --git a/amdgpu/meson.build b/amdgpu/meson.build
> new file mode 100644
> index 000..55ab9d1
> --- /dev/null
> +++ b/amdgpu/meson.build
> @@ -0,0 +1,65 @@
> +# Copyright © 2017-2018 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 

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

On 01/12/2018 05:30 PM, Ville Syrjälä wrote:
> On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
>> Hi Ville,
>>
>> For some strange reason your email disappeared from the Cc list. Perhaps 
>> it's the
>> ä that confuses something somewhere.
>>
>> So I'll just forward this directly to you.
>>
>> Can you please take a look? This patch series has been in limbo for too long.
> 
> IIRC last I looked we still had some ragistration race to deal with.
> Was that fixed?

That was fixed in v5.

> 
> Also I think we got stuck on leaving the zombie device lingering around
> when the display is disconnected. I couldn't understand why that is
> at all useful since you anyway remove the device eventually.

It's not a zombie device. If you disconnect and reconnect the display then the
application using the CEC device will see the display disappear and reappear
as expected.

It helps if you think of the normal situation (as is present in most ARM SoCs)
where CEC is integral to the HDMI transmitter. I.e. it is not functionality that
can be removed. So the cec device is always there and an application opens the
device and can use it, regardless of whether a display is connected or not.

If a display is detected, the EDID will be read and the CEC physical address is
set. The application is informed of that through an event and the CEC adapter
can be used. If the HPD disappears the physical address is reset to f.f.f.f and
again the application is informed. And in fact it still has to be able to use
the CEC adapter even if there is no HPD since some displays turn off the HPD 
when
in standby, but CEC can still be used to power them up again.

Now consider a future Intel NUC with an HDMI connector on the backplane and
working DP CEC-Tunneling-over-AUX support (e.g. the Megachips MCDP2900): the
CEC support is always there (it's built in), but only becomes visible to the
kernel when you connect a display. You don't want the cec device to disappear
whenever you unplug the display, that makes no sense. Applications would
loose the CEC configuration and have to close and reopen (when it reappears)
the cec device for no good reason since it is built in.

The same situation is valid when using a USB-C to HDMI adapter: disconnecting
or reconnecting a display should not lead to the removal of the CEC device.
Only when an adapter with different CEC capabilities is detected is there a
need to actually unregister the CEC device.

All this is really a workaround of the fact that when the HPD disappears the
DP-to-HDMI adapter (either external or built-in) also disappears from the
topology, even though it is physically still there. If there was a way to
detect the adapter when there is no display connected, then this workaround
wouldn't be needed.

This situation is specific to DisplayPort, this is the only case where the
HDMI connector disappears in a puff of smoke when you disconnect the HDMI
cable, even though the actual physical connector is obviously still there.

Regards,

Hans

> 
> Adding the lists back to cc so I don't have to repeat myself there...
> 
>>
>> Regards,
>>
>>  Hans
>>
>>
>>  Forwarded Message 
>> Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX 
>> support
>> Date: Tue, 9 Jan 2018 13:46:44 +0100
>> From: Hans Verkuil 
>> To: linux-me...@vger.kernel.org
>> CC: Daniel Vetter , Carlos Santa 
>> , dri-devel@lists.freedesktop.org
>>
>> First of all a Happy New Year for all of you!
>>
>> And secondly: can this v5 patch series be reviewed/merged? It's been waiting
>> for that for a very long time now...
>>
>> Regards,
>>
>>  Hans
>>
>> On 12/11/17 09:57, Hans Verkuil wrote:
>>> Ping again. Added a CC to Ville whom I inexplicably forgot to add when
>>> I sent the v5 patch series.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> On 01/12/17 08:23, Hans Verkuil wrote:
 Ping!

 I really like to get this in for 4.16 so I can move forward with hooking
 this up for nouveau/amd.

 Regards,

Hans

 On 11/20/2017 12:42 PM, Hans Verkuil wrote:
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature. This patch series is based on the 4.14 mainline release but 
> applies
> as well to drm-next.
>
> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to 
> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI
> adapter (where the CEC pin is wired up).
>
> Please note this comment at the start of drm_dp_cec.c:
>
> --
> Unfortunately it turns out that we have a chicken-and-egg situation
> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> Parade PS176 or MegaChips MCDP2900), but 

Re: [Mesa-dev] [PATCH 0/3] Meson build system

[Eric Engestrom]

On Monday, 2018-01-08 16:14:43 -0800, Dylan Baker wrote:
> I forgot to CC you on this like you asked,

Thanks for the ping :)

I noticed a couple issues on patches 1 & 2, but those are easy to fix,
and with that the series is r-b me.

Thanks for the effort of writing the whole thing!
I'll be glad to ditch autotools once this lands :P

> 
> Dylan
> 
> Quoting Dylan Baker (2018-01-05 12:00:57)
> > This is a fifth 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 with ext_foo
> > variables (I have a branch of mesa that will build this code as a wrap,
> > which has also been useful for testing). 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), or to build libdrm support that your distro doesn't ship (like
> > arm only drivers on x86), cross compiling, and for testing.
> > 
> > This has been build tested and mesa has been compiled against it, but
> > only minimal functional testing has been done, since I only have i965
> > machines, and i965 only uses libdrm lightly.
> > 
> > Some reviewers of the previous versions have done some additional
> > testing.
> > 
> > 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
> > 
> > Changes since v4:
> >   - Fix minor nits in options descriptions (Igor)
> >   - Fix editorconfig settings
> >   - Fix amdgpu.ids searh path
> >   - Style nits for Eric E.
> >   - Remove more tabs
> >   - Ensure that 1/0 defines are always defined, instead of only when
> > their value is 1
> >   - Don't add header files into file lists. (Meson figures out header
> > dependencies automatically using graphs that the compiler generates
> > during compilation)
> >   - Don't assign file lists to variables when possible. In a few cases
> > files need to be conditionally added, but if we're not in one of
> > those cases just put the lists directly in the exectuable or library
> > declaration.
> > 
> > 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  |  24 +-
> >  amdgpu/.editorconfig|   4 +-
> >  amdgpu/meson.build  |  65 +++-
> >  data/meson.build|  27 +++-
> >  etnaviv/meson.build |  59 ++-
> >  exynos/meson.build  |  53 +-
> >  freedreno/meson.build   |  76 -
> >  intel/meson.build   | 105 +++-
> >  libkms/meson.build  |  74 -
> >  man/meson.build |  67 +++-
> >  meson.build | 364 +-
> >  meson_options.txt   | 143 +++-
> >  nouveau/meson.build |  58 ++-
> >  omap/meson.build|  53 +-
> >  radeon/meson.build  |  63 ++-
> >  tegra/meson.build   |  52 +-
> >  tests/amdgpu/meson.build|  34 +++-
> >  tests/etnaviv/meson.build   |  45 +-
> >  tests/exynos/meson.build|  54 +-
> >  tests/kms/meson.build   |  49 +-
> >  tests/kmstest/meson.build   |  30 +++-
> >  tests/meson.build   |  86 +-
> >  tests/modeprint/meson.build |  29 +++-
> >  tests/modetest/meson.build  |  29 +++-
> >  tests/nouveau/meson.build   |  30 +++-
> >  tests/proptest/meson.build  |  28 +++-
> >  tests/radeon/meson.build|  27 +++-
> >  tests/tegra/meson.build |  27 +++-
> >  tests/util/meson.build  |  28 +++-
> >  tests/vbltest/meson.build   |  28 +++-
> >  vc4/meson.build |  28 +++-
> >  33 files changed, 1869 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 

[PATCH libdrm 0/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding 

These UABI changes have now been merged into drm-next, so synchronize
the libdrm headers and fixup the format modifiers in modetest.

Thierry

Thierry Reding (2):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers

 include/drm/drm_fourcc.h  | 38 --
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 34 insertions(+), 32 deletions(-)

-- 
2.15.1

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

[PATCH libdrm 2/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding 

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_fourcc.h  | 36 +++-
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 33 insertions(+), 31 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 62d933272423..701547f4b648 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -278,20 +278,20 @@ static const char *modifier_to_string(uint64_t modifier)
return "VIVANTE_SPLIT_TILED";
case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
return "VIVANTE_SPLIT_SUPER_TILED";
-   case NV_FORMAT_MOD_TEGRA_TILED:
-   return "MOD_TEGRA_TILED";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(0):
-   return "MOD_TEGRA_16BX2_BLOCK(0)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(1):
-   return "MOD_TEGRA_16BX2_BLOCK(1)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(2):
-   return "MOD_TEGRA_16BX2_BLOCK(2)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(3):
-   return "MOD_TEGRA_16BX2_BLOCK(3)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(4):
-   return "MOD_TEGRA_16BX2_BLOCK(4)";
-  

[PATCH libdrm 1/2] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding 

Avoid compiler warnings when the val parameter is an expression.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.15.1

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

Re: [PATCH 02/10] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

Hi Sergei,

On Friday, 12 January 2018 17:14:33 EET Sergei Shtylyov wrote:
> On 01/12/2018 03:58 AM, Laurent Pinchart wrote:
> > The internal LVDS encoders now have their own DT bindings, representing
> > them as part of the DU is deprecated.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../devicetree/bindings/display/renesas,du.txt | 26 -
> >  1 file changed, 11 insertions(+), 15 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
> > cd48aba3bc8c..8f6e0e118e3e 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> > 
> > @@ -17,9 +17,7 @@ Required Properties:
> > - reg: A list of base address and length of each memory resource, one
> > for
> >   each entry in the reg-names property.
> > - reg-names: Name of the memory resources. The DU requires one memory
> > 
> > -resource for the DU core (named "du") and one memory resource for
> > each
> > -LVDS encoder (named "lvds.x" with "x" being the LVDS controller
> > numerical
> > -index).
> > +resource for the DU core (named "du").
> 
> Could we get rid of this prop altogether?

Actually yes, as unlike what I thought the driver doesn't use it. I'll drop it 
in v2.

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha

[Ayan Halder]

Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
display color formats that do not contain alpha bits per pixel

Signed-off-by: Ayan Kumar Halder 
---
 drivers/gpu/drm/arm/malidp_planes.c | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index e741979..4d7d564 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -35,6 +35,9 @@
 #define   LAYER_COMP_MASK  (0x3 << 12)
 #define   LAYER_COMP_PIXEL (0x3 << 12)
 #define   LAYER_COMP_PLANE (0x2 << 12)
+#define   LAYER_ALPHA_OFFSET   (16)
+#define   LAYER_ALPHA_MASK (0xff)
+#define  LAYER_ALPHA(x)(((x) & LAYER_ALPHA_MASK) << 
LAYER_ALPHA_OFFSET)
 #define MALIDP_LAYER_COMPOSE   0x008
 #define MALIDP_LAYER_SIZE  0x00c
 #define   LAYER_H_VAL(x)   (((x) & 0x1fff) << 0)
@@ -268,6 +271,7 @@ static void malidp_de_plane_update(struct drm_plane *plane,
struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
u32 src_w, src_h, dest_w, dest_h, val;
int i;
+   u8 alpha_bits = plane->state->fb->format->alpha;
 
mp = to_malidp_plane(plane);
 
@@ -319,12 +323,25 @@ static void malidp_de_plane_update(struct drm_plane 
*plane,
if (plane->state->rotation & DRM_MODE_REFLECT_Y)
val |= LAYER_V_FLIP;
 
-   /*
-* always enable pixel alpha blending until we have a way to change
-* blend modes
-*/
val &= ~LAYER_COMP_MASK;
-   val |= LAYER_COMP_PIXEL;
+   if (alpha_bits > 0) {
+
+   /*
+* always enable pixel alpha blending until we have a way to 
change
+* blend modes
+*/
+   val |= LAYER_COMP_PIXEL;
+   } else {
+
+   /*
+* do not enable pixel alpha blending as the color channel does 
not
+* have any alpha information
+*/
+   val |= LAYER_COMP_PLANE;
+
+   /* Set layer alpha coefficient to 0xff ie fully opaque */
+   val |= LAYER_ALPHA(0xff);
+   }
 
val &= ~LAYER_FLOWCFG(LAYER_FLOWCFG_MASK);
if (plane->state->crtc) {
-- 
2.7.4

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

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Ville Syrjälä]

On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote:
> Hi Ville,
> 
> For some strange reason your email disappeared from the Cc list. Perhaps it's 
> the
> ä that confuses something somewhere.
> 
> So I'll just forward this directly to you.
> 
> Can you please take a look? This patch series has been in limbo for too long.

IIRC last I looked we still had some ragistration race to deal with.
Was that fixed?

Also I think we got stuck on leaving the zombie device lingering around
when the display is disconnected. I couldn't understand why that is
at all useful since you anyway remove the device eventually.

Adding the lists back to cc so I don't have to repeat myself there...

> 
> Regards,
> 
>   Hans
> 
> 
>  Forwarded Message 
> Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX 
> support
> Date: Tue, 9 Jan 2018 13:46:44 +0100
> From: Hans Verkuil 
> To: linux-me...@vger.kernel.org
> CC: Daniel Vetter , Carlos Santa 
> , dri-devel@lists.freedesktop.org
> 
> First of all a Happy New Year for all of you!
> 
> And secondly: can this v5 patch series be reviewed/merged? It's been waiting
> for that for a very long time now...
> 
> Regards,
> 
>   Hans
> 
> On 12/11/17 09:57, Hans Verkuil wrote:
> > Ping again. Added a CC to Ville whom I inexplicably forgot to add when
> > I sent the v5 patch series.
> > 
> > Regards,
> > 
> > Hans
> > 
> > On 01/12/17 08:23, Hans Verkuil wrote:
> >> Ping!
> >>
> >> I really like to get this in for 4.16 so I can move forward with hooking
> >> this up for nouveau/amd.
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >> On 11/20/2017 12:42 PM, Hans Verkuil wrote:
> >>> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> >>> feature. This patch series is based on the 4.14 mainline release but 
> >>> applies
> >>> as well to drm-next.
> >>>
> >>> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to 
> >>> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI
> >>> adapter (where the CEC pin is wired up).
> >>>
> >>> Please note this comment at the start of drm_dp_cec.c:
> >>>
> >>> --
> >>> Unfortunately it turns out that we have a chicken-and-egg situation
> >>> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> >>> have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> >>> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin,
> >>> thus making CEC useless.
> >>>
> >>> Sadly there is no way for this driver to know this. What happens is
> >>> that a /dev/cecX device is created that is isolated and unable to see
> >>> any of the other CEC devices. Quite literally the CEC wire is cut
> >>> (or in this case, never connected in the first place).
> >>>
> >>> I suspect that the reason so few adapters support this is that this
> >>> tunneling protocol was never supported by any OS. So there was no
> >>> easy way of testing it, and no incentive to correctly wire up the
> >>> CEC pin.
> >>>
> >>> Hopefully by creating this driver it will be easier for vendors to
> >>> finally fix their adapters and test the CEC functionality.
> >>>
> >>> I keep a list of known working adapters here:
> >>>
> >>> https://hverkuil.home.xs4all.nl/cec-status.txt
> >>>
> >>> Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> >>> and is not yet listed there.
> >>>
> >>> Note that the current implementation does not support CEC over an MST hub.
> >>> As far as I can see there is no mechanism defined in the DisplayPort
> >>> standard to transport CEC interrupts over an MST device. It might be
> >>> possible to do this through polling, but I have not been able to get that
> >>> to work.
> >>> --
> >>>
> >>> I really hope that this work will provide an incentive for vendors to
> >>> finally connect the CEC pin. It's a shame that there are so few adapters
> >>> that work (I found only two USB-C to HDMI adapters that work, and no
> >>> (mini-)DP to HDMI adapters at all).
> >>>
> >>> Hopefully if this gets merged there will be an incentive for vendors
> >>> to make adapters where this actually works. It is a very nice feature
> >>> for HTPC boxes.
> >>>
> >>> The main reason why this v5 is delayed by 2 months is due to the fact
> >>> that I needed some dedicated time to investigate what happens when an
> >>> MST hub is in use. It turns out that this is not working. There is no
> >>> mechanism defined in the DisplayPort standard to transport the CEC
> >>> interrupt back up the MST chain. I was actually able to send a CEC
> >>> message but the interrupt that tells when the transmit finished is
> >>> unavailable.
> >>>
> >>> I attempted to implement this via polling, but I got weird errors
> >>> and was not able to read the 

[PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock

[Philippe Cornu]

The pixel clock is optional. When available, it offers a better
preciseness for timing computations and allows to reduce the extra dsi
bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependent).

Signed-off-by: Philippe Cornu 
---
Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
(thanks to Philipp Zabel & Andrzej Hajda comments)

 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index c39c7dce20ed..62fcff881b98 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -225,6 +225,7 @@ struct dw_mipi_dsi {
void __iomem *base;
 
struct clk *pclk;
+   struct clk *px_clk;
 
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge 
*bridge,
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
void *priv_data = dsi->plat_data->priv_data;
+   struct drm_display_mode px_clk_mode = *mode;
int ret;
 
clk_prepare_enable(dsi->pclk);
 
-   ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
+   if (dsi->px_clk)
+   px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
+
+   ret = phy_ops->get_lane_mbps(priv_data, _clk_mode, dsi->mode_flags,
 dsi->lanes, dsi->format, >lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
 
pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
-   dw_mipi_dsi_dpi_config(dsi, mode);
+   dw_mipi_dsi_dpi_config(dsi, _clk_mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
-   dw_mipi_dsi_video_packet_config(dsi, mode);
+   dw_mipi_dsi_video_packet_config(dsi, _clk_mode);
dw_mipi_dsi_command_mode_config(dsi);
-   dw_mipi_dsi_line_timer_config(dsi, mode);
-   dw_mipi_dsi_vertical_timing_config(dsi, mode);
+   dw_mipi_dsi_line_timer_config(dsi, _clk_mode);
+   dw_mipi_dsi_vertical_timing_config(dsi, _clk_mode);
 
dw_mipi_dsi_dphy_init(dsi);
dw_mipi_dsi_dphy_timing_config(dsi);
@@ -784,7 +789,7 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
 
dw_mipi_dsi_dphy_enable(dsi);
 
-   dw_mipi_dsi_wait_for_two_frames(mode);
+   dw_mipi_dsi_wait_for_two_frames(_clk_mode);
 
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
@@ -878,6 +883,15 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
return ERR_PTR(ret);
}
 
+   dsi->px_clk = devm_clk_get(dev, "px_clk");
+   if (PTR_ERR(dsi->px_clk) == -ENOENT) {
+   dsi->px_clk = NULL;
+   } else if (IS_ERR(dsi->px_clk)) {
+   ret = PTR_ERR(dsi->px_clk);
+   dev_err(dev, "Unable to get optional px_clk: %d\n", ret);
+   dsi->px_clk = NULL;
+   }
+
/*
 * Note that the reset was not defined in the initial device tree, so
 * we have to be prepared for it not being found.
-- 
2.15.1

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

Re: [PATCH] drm: add drm_format_alpha_bits

[Ville Syrjälä]

On Fri, Jan 12, 2018 at 04:11:38PM +, Ayan Halder wrote:
> On Fri, Jan 12, 2018 at 05:53:33PM +0200, Ville Syrj?l? wrote:
> > On Fri, Jan 12, 2018 at 03:43:49PM +, Ayan Halder wrote:
> > > On Fri, Jan 12, 2018 at 04:28:34PM +0200, Ville Syrj?l? wrote:
> > > > On Fri, Jan 12, 2018 at 02:21:16PM +, Ayan Halder wrote:
> > > > > drm_format_info does not describe the number of bits used for the 
> > > > > alpha
> > > > > channel. That information is useful in a central place like 
> > > > > drm_fourcc.c
> > > > > where it can be queried by the drivers that want to determine if 
> > > > > 'alpha
> > > > > blending' is to be enabled or not.
> > > > > 
> > > > > Signed-off-by: Ayan Kumar Halder 
> > > > > Reviewed-by: Liviu Dudau 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_fourcc.c | 154 
> > > > > ---
> > > > >  include/drm/drm_fourcc.h |   3 +
> > > > >  2 files changed, 89 insertions(+), 68 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c 
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index 9c0152d..073001b 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > 
> > > > > @@ -348,3 +348,21 @@ int drm_format_plane_height(int height, uint32_t 
> > > > > format, int plane)
> > > > >   return height / info->vsub;
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_format_plane_height);
> > > > > +
> > > > > +/**
> > > > > + * drm_format_alpha_bits - get the number of bits per pixel
> > > > > + * representing alpha for format
> > > > > + * @format: pixel format (DRM_FORMAT_*)
> > > > > + *
> > > > > + * Returns:
> > > > > + * The number of bits per pixel representing alpha used by the
> > > > > + * specified pixel format.
> > > > > + */
> > > > > +int drm_format_alpha_bits(uint32_t format)
> > > > > +{
> > > > > + const struct drm_format_info *info;
> > > > > +
> > > > > + info = drm_format_info(format);
> > > > > + return info ? info->alpha : 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_format_alpha_bits);
> > > > 
> > > > Do you have an actual use for this function somewhere?
> > > Currently, we do not have a usage for this function.
> > 
> > No point in adding the function then IMO.
> We have helper functions for the other fields so I followed the same
> and added the helper function for the new field ('alpha') too.

Those helpers are mostly there for legacy reasons. Ideally someone would
go over all the code and clean up the cases where using those helpers
makes no sense (ie. when you already have the format structure around)
and then remove the helpers if/when they're no longer needed. This sort
of stuff tends to linger around for a while after bigger mechanical
conversions like the addition of the format info structure.

> > 
> > > We need 'alpha'
> > > field for each entry in 'drm_format_info' so as to determine whether
> > > to enable/disable alpha blending in Mali display processor for the
> > > particular color format. 
> > 
> > I think that's OK. Not sure if it really helps much though since you
> > generally have to configure other things based on the format as well, so
> > I would expect almost everyone will end up with some kind of
> > swicth/table to configure the hardware based on the format. Based on a
> > quick look this doesn't really help i915 at least.
> 
> My understanding was based on the fact that alpha blending could be a
> common feature for all the drivers (I might be wrong). So, if we keep
> the number of 'alpha' bits in 'drm_format_info', it would be useful to
> fetch this info similar to the existing fields.

I'm just saying that ut doesn't really provide much extra help if
the driver already has eg. a switch statement for all the formats
anyway.

> > > > 
> > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > > index 6942e84..5513510 100644
> > > > > --- a/include/drm/drm_fourcc.h
> > > > > +++ b/include/drm/drm_fourcc.h
> > > > > @@ -38,6 +38,7 @@ struct drm_mode_fb_cmd2;
> > > > >   * @cpp: Number of bytes per pixel (per plane)
> > > > >   * @hsub: Horizontal chroma subsampling factor
> > > > >   * @vsub: Vertical chroma subsampling factor
> > > > > + * @alpha: Number of bits per pixel representing alpha
> > > > >   */
> > > > >  struct drm_format_info {
> > > > >   u32 format;
> > > > > @@ -46,6 +47,7 @@ struct drm_format_info {
> > > > >   u8 cpp[3];
> > > > >   u8 hsub;
> > > > >   u8 vsub;
> > > > > + u8 alpha;
> > > > >  };
> > > > >  
> > > > >  /**
> > > > > @@ -57,6 +59,7 @@ struct drm_format_name_buf {
> > > > >  };
> > > > >  
> > > > >  const struct drm_format_info *__drm_format_info(u32 format);
> > > > > +int drm_format_alpha_bits(u32 format);
> > > > >  const struct drm_format_info *drm_format_info(u32 format);
> > > > >  const struct drm_format_info *
> > > > >  drm_get_format_info(struct drm_device *dev,
> > > > > -- 
> > > > > 2.7.4
> 

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

Christoph Haag  changed:

   What|Removed |Added

Summary|Compton weird colors|[bisected] Compton weird
   ||colors

--- Comment #2 from Christoph Haag  ---
e5ff036c6751c39ee008ca7db47b3ce4d7a38a15 is the first bad commit
commit e5ff036c6751c39ee008ca7db47b3ce4d7a38a15
Author: Mario Kleiner 
Date:   Fri Dec 15 23:05:07 2017 +0100

st/dri: Add support for BGR[A/X]1010102 formats.

Exposes RGBA 10 10 10 2 and 10 10 10 0 visuals and
fbconfigs for rendering.

Signed-off-by: Mario Kleiner 
Reviewed-by: Marek Olšák 
Signed-off-by: Marek Olšák 

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