Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Benson Leung]

On Thu, Mar 15, 2018 at 02:08:51PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> V7: typo
> V8: Style
> 
> Signed-off-by: Matt Atwood 

Tested-by: Benson Leung 

This version still passes link training on the panel with 8th bit set in
DPCD 0x000e.

Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


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

[Bug 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #9 from Edward Kigwana  ---
Created attachment 138164
  --> https://bugs.freedesktop.org/attachment.cgi?id=138164=edit
dmesg

This is with options amdgpu dpm=0 dc=1 dc_log=1

[drm:amdgpu_device_ip_set_powergating_state [amdgpu]] *ERROR*
set_powergating_state of IP block  failed 52428

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #8 from Edward Kigwana  ---
(In reply to Alex Deucher from comment #7)
> Does disabling the Intel gfx chip or booting with the AMD card as the
> primary help?  Can you also try booting with amdgpu.dc=1?

options amdgpu dpm=0 dc=1 dc_log=1

Still boots and the AMD GPU comes up. I have the AMD GPU is the first card.

-- 
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: Add PSR version 3 macro

[José Roberto de Souza]

eDP 1.4a specification defines PSR version 3, it PSR2 with the
addition of Y-coordinate support when doing selective update.

Signed-off-by: José Roberto de Souza 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4de97e94ef9d..62903bae0221 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -288,6 +288,7 @@
 #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
 # define DP_PSR_IS_SUPPORTED1
 # define DP_PSR2_IS_SUPPORTED  2   /* eDP 1.4 */
+# define DP_PSR2_WITH_Y_COORD_IS_SUPPORTED  3  /* eDP 1.4a */
 
 #define DP_PSR_CAPS 0x071   /* XXX 1.2? */
 # define DP_PSR_NO_TRAIN_ON_EXIT1
-- 
2.16.2

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

[Bug 105569] sw_init of IP block failed -2

[bugzilla-daemon]

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

Bug ID: 105569
   Summary: sw_init of IP block  failed -2
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: wraithofcthu...@gmail.com

I have next issue, when trying to load Ubuntu 18.04b1 with kernels up to
4.16rc5
My computer has hybrid AMD graphics and kernels loaded with parameters
"radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1
amdgpu.cik_support=1".

lspci -k:
#
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Richland [Radeon HD 8510G]
Subsystem: ASUSTeK Computer Inc. Richland [Radeon HD 8510G]
Kernel driver in use: radeon
Kernel modules: radeon
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars
[Radeon HD 8730M]
Subsystem: ASUSTeK Computer Inc. Mars [Radeon HD 8730M]
Kernel modules: radeon, amdgpu

dmesg section with error:
#
[  592.249652] [drm] amdgpu kernel modesetting enabled.
[  592.249692] vga_switcheroo: detected switching method \_SB_.PCI0.VGA_.ATPX
handle
[  592.249986] ATPX version 1, functions 0x0003
[  592.250795] [drm] initializing kernel modesetting (OLAND 0x1002:0x6601
0x1043:0x2134 0x00).
[  592.251291] [drm] register mmio base: 0xFEA0
[  592.251293] [drm] register mmio size: 262144
[  592.251303] vga_switcheroo: enabled
[  592.547558] ATOM BIOS: BR43789.002
[  592.549043] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment
size is 9-bit
[  592.579114] amdgpu :01:00.0: Direct firmware load for
radeon/oland_mc.bin failed with error -2
[  592.579124] amdgpu :01:00.0: si_mc: Failed to load firmware
"radeon/oland_mc.bin"
[  592.579133] amdgpu :01:00.0: Failed to load mc firmware!
[  592.579305] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block
 failed -2
[  592.579311] amdgpu :01:00.0: amdgpu_device_ip_init failed
[  592.579320] amdgpu :01:00.0: Fatal error during GPU init
[  592.579327] [drm] amdgpu: finishing device.
[  592.580752] vga_switcheroo: disabled
[  592.581246] amdgpu: probe of :01:00.0 failed with error -2

-- 
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 v6 3/5] 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 
Acked-by: Daniel Vetter 
---
v6
- Use the new crtc op struct
- Clean up the duplicated license paragraphs
- Declare function pointer structures as static const
- Do complete forward declaration in headers
v4
- Use drm_crtc_funcs for vblank
- Remove child nodes for layer
v3
- Fix a small typo
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 | 2671 
 drivers/gpu/drm/xlnx/zynqmp_disp.h |   29 +
 2 files changed, 2700 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..cc16cdc
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -0,0 +1,2671 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Display Controller Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ */
+
+#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  0x60
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF8  0x64
+#define ZYNQMP_DISP_V_BLEND_NUM_OFFSET 3
+#define 

[PATCH v6 5/5] 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 
Acked-by: Daniel Vetter 
---
v6
- Accomodate the migration of logical master from platform device to device
- Remove the duplicate license paragraphs
- Do complete forward declaration in the header
v5
- Add an error handling of pipeline initialization
v4
- Use the newly added xlnx pipeline calls to initialize drm device
v2
- Change the SPDX identifier format
---
---
 drivers/gpu/drm/xlnx/Kconfig|  11 +++
 drivers/gpu/drm/xlnx/Makefile   |   3 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 152 
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h |  23 ++
 4 files changed, 189 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..7c6981b
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DP Subsystem Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_drv.h"
+
+#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;
+   }
+
+   dpsub->master = xlnx_drm_pipeline_init(>dev);
+   if (IS_ERR(dpsub->master)) {
+   dev_err(>dev, "failed to initialize the drm pipeline\n");
+   goto err_populate;
+   }
+
+   dev_info(>dev, "ZynqMP DisplayPort Subsystem driver probed");
+
+   return 0;
+
+err_populate:
+   of_platform_depopulate(>dev);
+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);
+  

[PATCH v6 2/5] 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 
Reviewed-by: Rob Herring 
---
v6
- Add more descriptions and references
- Remove the description for child node
v4
- Specify phy related descriptions
- Specify dma related descriptions
- Remove ports
- Remove child nodes for layers
- Update the example accordingly
v2
- Group multiple ports under 'ports'
- Replace linux specific terms with generic hardware descriptions
---
---
 .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 77 ++
 1 file changed, 77 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..ec8a58a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
@@ -0,0 +1,77 @@
+Xilinx ZynqMP DisplayPort subsystem
+---
+
+The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC) implements
+the display and audio pipelines based on the DisplayPort v1.2 standard.
+The subsystem includes multiple functional blocks as below:
+
+   buffer manager <-> blender & mixer <-> DP Tx
+
+The buffer manager interacts with external interface such as DMA engines or
+live streams. The blender and mixer blends the incoming video / audio streams
+into single stream. The DP Tx converts and transmits the stream into 
DisplayPort
+protocol through external phy. The subsystem supports 2 video and 2 audio
+streams, and various pixel formats / depths up to 4K@30 resolution.
+
+Please refer to "Zynq UltraScale+ Device Technical Reference Manual" [UG1085]
+for more details.
+
+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. The number of lanes is configurable
+  between 1 and 2. The number of phandles should be 1 or 2.
+- phy-names: The identifier strings. "dp-phy" followed by index, 0 or 1.
+  For single lane, only "dp-phy0" is required. For dual lane, both "dp-phy0"
+  and "dp-phy1" are required where "dp-phy0" is the primary lane.
+
+- power-domains: phandle for the corresponding power domain
+
+- dmas: phandles for DMA channels as defined in
+  Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names: The identifier strings are required. "gfx0" for graphics layer
+  dma channel. "vid" followed by index (0 - 2) for video layer dma channels.
+
+Example:
+   zynqmp-display-subsystem@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>;
+
+   dma-names = "vid0", "vid1", "vid2", "gfx0";
+   dmas = <_dpdma 0>,
+  <_dpdma 1>,
+  <_dpdma 2>,
+  <_dpdma 3>;
+   };
+};
+
+[UG1085] 
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
-- 
2.7.4

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

[PATCH v6 4/5] 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 
Acked-by: Daniel Vetter 
---
v6
- Constify all function pointers
- Clean up the duplicated license paragraphs
- Do complete forward declaration in the header
v2
- Change the SPDX identifier format
- Split drm properties into a separate patch
---
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 1730 ++
 drivers/gpu/drm/xlnx/zynqmp_dp.h |   30 +
 2 files changed, 1760 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..9ed55dd
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -0,0 +1,1730 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DisplayPort Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dpsub.h"
+
+static uint zynqmp_dp_aux_timeout_ms = 50;
+module_param_named(aux_timeout_ms, zynqmp_dp_aux_timeout_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in msec (default: 50)");
+
+/*
+ * Some sink requires a delay after power on request
+ */
+static uint zynqmp_dp_power_on_delay_ms = 4;
+module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
+
+/* Link configuration registers */
+#define ZYNQMP_DP_TX_LINK_BW_SET   0x0
+#define ZYNQMP_DP_TX_LANE_CNT_SET  0x4
+#define ZYNQMP_DP_TX_ENHANCED_FRAME_EN 0x8
+#define ZYNQMP_DP_TX_TRAINING_PATTERN_SET  0xc
+#define ZYNQMP_DP_TX_SCRAMBLING_DISABLE0x14
+#define ZYNQMP_DP_TX_DOWNSPREAD_CTL0x18
+#define ZYNQMP_DP_TX_SW_RESET  0x1c
+#define ZYNQMP_DP_TX_SW_RESET_STREAM1  BIT(0)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM2  BIT(1)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM3  BIT(2)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM4  BIT(3)
+#define ZYNQMP_DP_TX_SW_RESET_AUX  BIT(7)
+#define ZYNQMP_DP_TX_SW_RESET_ALL  
(ZYNQMP_DP_TX_SW_RESET_STREAM1 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM2 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM3 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM4 | \
+
ZYNQMP_DP_TX_SW_RESET_AUX)
+
+/* Core enable registers */
+#define ZYNQMP_DP_TX_ENABLE0x80
+#define ZYNQMP_DP_TX_ENABLE_MAIN_STREAM0x84
+#define ZYNQMP_DP_TX_FORCE_SCRAMBLER_RESET 0xc0
+#define ZYNQMP_DP_TX_VERSION   0xf8
+#define ZYNQMP_DP_TX_VERSION_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_VERSION_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_VERSION_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_VERSION_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_VERSION_REVISION_MASK GENMASK(15, 12)
+#define ZYNQMP_DP_TX_VERSION_REVISION_SHIFT12
+#define ZYNQMP_DP_TX_VERSION_PATCH_MASKGENMASK(11, 8)
+#define ZYNQMP_DP_TX_VERSION_PATCH_SHIFT   8
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_MASK GENMASK(7, 0)
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_SHIFT0
+
+/* Core ID registers */
+#define ZYNQMP_DP_TX_CORE_ID   0xfc
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_MASK GENMASK(15, 8)
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_SHIFT8
+#define ZYNQMP_DP_TX_CORE_ID_DIRECTION GENMASK(1)
+
+/* AUX channel interface registers */
+#define ZYNQMP_DP_TX_AUX_COMMAND   0x100
+#define ZYNQMP_DP_TX_AUX_COMMAND_CMD_SHIFT 8
+#define ZYNQMP_DP_TX_AUX_COMMAND_ADDRESS_ONLY  BIT(12)
+#define ZYNQMP_DP_TX_AUX_COMMAND_BYTES_SHIFT   0
+#define ZYNQMP_DP_TX_AUX_WRITE_FIFO0x104
+#define ZYNQMP_DP_TX_AUX_ADDRESS   0x108
+#define ZYNQMP_DP_TX_CLK_DIVIDER   0x10c
+#define ZYNQMP_DP_TX_CLK_DIVIDER_MHZ   

[PATCH v6 1/5] drm: xlnx: Xilinx DRM KMS module

[Hyun Kwon]

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

The Xilinx DRM KMS module is to integrate multiple subdevices and
to represent the entire pipeline as a single DRM device. The module
includes helper (ex, framebuffer and gem helpers) and glue logic
(ex, crtc interface) functions.

Signed-off-by: Hyun Kwon 
Acked-by: Daniel Vetter 
---
v6
- Fix the function desc for pipeline calls
- Rebase on drm-misc-next
- Fix typos in documentation
- Match types for return and internal variables
- Remove use of 'tmp' variables
- Protect any crtc list iteration with mutex
- Remove a check for drm device in crtc unregistration
- Split the crtc ops as a separate struct to constify
- Embed xlnx_crtc_helper into xlnx_drm
- Move to_xlnx_crtc macro close to xlnx_crtc
- Remove unneeded include
- Replace custom vres module param with CONFIG_DRM_FBDEV_OVERALLOC
- Rename crtc to crtc_helper to make it clearer
- Use 'DRM device' instead of 'DRM core'
- Remove unused function, xlnx_get_format()
- Use device instead of platform device for the logical master
- Inline xlnx_of_component_probe()
- Use of_get_parent()
- Remove the port binding handling in the driver
- Do complete forward-declarations in headers
- Constify all function pointers
- Use the default ioctl from fb helper
- Return the minimum pitch always
- Clean up the duplicate license paragraphs
- Get common bits for dma mask instead of minimum value
- Remove dummy function declaration from header
- Fix a typo in the commit message with some re-organization
v5
- Redefine xlnx_pipeline_init()
v4
- Fix a bug in of graph binding handling
- Remove vblank callbacks from xlnx_crtc
- Remove the dt binding. This module becomes more like a library.
- Rephrase the commit message
v3
- Add Laurent as a maintainer
- Fix multiple-reference on gem objects
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  |   9 +
 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 | 142 +
 drivers/gpu/drm/xlnx/xlnx_crtc.h |  83 
 drivers/gpu/drm/xlnx/xlnx_drv.c  | 430 +++
 drivers/gpu/drm/xlnx/xlnx_drv.h  |  23 +++
 drivers/gpu/drm/xlnx/xlnx_fb.c   | 249 +++
 drivers/gpu/drm/xlnx/xlnx_fb.h   |  27 +++
 drivers/gpu/drm/xlnx/xlnx_gem.c  |  36 
 drivers/gpu/drm/xlnx/xlnx_gem.h  |  21 ++
 13 files changed, 1037 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 2afba90..44cac79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4810,6 +4810,15 @@ 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 
+M: Laurent Pinchart 
+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 deeefa7..5a3ec66 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -289,6 +289,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 50093ff..f93557e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
 obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
 

[PATCH] drm/i915: Disable some extra clang warnings

[Matthias Kaehlcke]

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enabled some additional clang-only warnings, as a
result building i915 with clang currently is extremely noisy. For now
also disable the clang warnings sign-compare, sometimes-uninitialized,
unneeded-internal-declaration and initializer-overrides. If desired
they can be re-enabled after the code has been fixed.

Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full")
Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/i915/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 091aef281963..ad05796a96ba 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -17,6 +17,10 @@ subdir-ccflags-y += $(call cc-disable-warning, 
unused-parameter)
 subdir-ccflags-y += $(call cc-disable-warning, type-limits)
 subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
 subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
+subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
+subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
+subdir-ccflags-y += $(call cc-disable-warning, unneeded-internal-declaration)
+subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
 subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
 
 # Fine grained warnings disable
-- 
2.16.2.804.g6dcf76e118-goog

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

[PATCH v4 8/8] drm/i915: Add context priority & priority offset to debugfs (v2)

[Matt Roper]

Update i915_context_status to include priority information.

v2:
 - Clarify that the offset is based on cgroup (Chris)

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5378863e3238..02d1983b8581 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1959,6 +1959,9 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
seq_putc(m, '\n');
 
+   seq_printf(m, "Priority %d (cgroup offset = %d)\n",
+  ctx->priority, ctx->priority_offset);
+
for_each_engine(engine, dev_priv, id) {
struct intel_context *ce = >engine[engine->id];
 
-- 
2.14.3

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

[PATCH v4 7/8] drm/i915: Introduce per-cgroup display boost setting

[Matt Roper]

Usually display-boosted contexts get treated as
I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular
GPU contexts.  Now that we allow a much larger range of effective
priority values via per-cgroup priority offsets, a system administrator
may want more detailed control over how much a process should be boosted
by display operations (i.e., can a context from a cgroup with a low
priority offset still be display boosted above contexts from a cgroup
with a much higher priority offset?  or are come cgroups more important
than maintaining display rate?).

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cgroup.c   | 17 +
 drivers/gpu/drm/i915/i915_drv.h  |  6 ++
 drivers/gpu/drm/i915/i915_request.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  5 +++--
 include/uapi/drm/i915_drm.h  |  1 +
 5 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
index b58b243aef20..868d455ffeb6 100644
--- a/drivers/gpu/drm/i915/i915_cgroup.c
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -11,6 +11,7 @@
 
 struct i915_cgroup_data {
int priority_offset;
+   int display_boost;
 
struct kref ref;
 };
@@ -75,6 +76,8 @@ get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
goto out;
}
 
+   priv->display_boost = I915_PRIORITY_DEFAULT_DISPBOOST;
+
kref_init(>ref);
cgroup_priv_install(cgrp, dev_priv->cgroup_priv_key,
>ref);
@@ -150,6 +153,19 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
}
break;
 
+   case I915_CGROUP_PARAM_DISPBOOST_PRIORITY:
+   if (req->value < I915_PRIORITY_MAX_DISPBOOST &&
+   req->value > I915_PRIORITY_MIN) {
+   DRM_DEBUG_DRIVER("Setting cgroup display boost priority 
to %lld\n",
+req->value);
+   cgrpdata->display_boost = req->value;
+   } else {
+   DRM_DEBUG_DRIVER("Invalid cgroup display boost priority 
%lld\n",
+req->value);
+   ret = -EINVAL;
+   }
+   break;
+
default:
DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n", req->param);
ret = -EINVAL;
@@ -184,5 +200,6 @@ int i915_cgroup_get_current_##name(struct drm_i915_private 
*dev_priv)   \
 }
 
 CGROUP_GET(prio_offset, priority_offset, 0)
+CGROUP_GET(dispboost, display_boost, I915_PRIORITY_DEFAULT_DISPBOOST);
 
 #undef CGROUP_GET
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd5629593f4b..fe787cfcef72 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2689,6 +2689,7 @@ int i915_cgroup_setparam_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file);
 void i915_cgroup_shutdown(struct drm_i915_private *dev_priv);
 int i915_cgroup_get_current_prio_offset(struct drm_i915_private *dev_priv);
+int i915_cgroup_get_current_dispboost(struct drm_i915_private *dev_priv);
 #else
 static inline void i915_cgroup_init(struct drm_i915_private *dev_priv) {}
 static inline void i915_cgroup_shutdown(struct drm_i915_private *dev_priv) {}
@@ -2702,6 +2703,11 @@ i915_cgroup_get_current_prio_offset(struct 
drm_i915_private *dev_priv)
 {
return 0;
 }
+static inline int
+i915_cgroup_get_current_dispboost(struct drm_i915_private *dev_priv)
+{
+   return I915_PRIORITY_DEFAULT_DISPBOOST;
+}
 #endif
 
 /* i915_drv.c */
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index cf7a7147daf3..db300d93fd08 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -90,6 +90,7 @@ enum {
/* Range reachable by combining user priority + cgroup offset */
I915_PRIORITY_MAX = 0x7f,
I915_PRIORITY_MIN = -I915_PRIORITY_MAX,
+   I915_PRIORITY_MAX_DISPBOOST = I915_PRIORITY_MAX + 1,
 
/* Special case priority values */
I915_PRIORITY_INVALID = INT_MIN,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b053a21f682b..1d0245e2fd75 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12731,7 +12731,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
-   int ret;
+   int boost, ret;
 
if (old_obj) {
struct drm_crtc_state *crtc_state =
@@ -12783,7 +12783,8 @@ intel_prepare_plane_fb(struct drm_plane 

[PATCH v4 2/8] cgroup: Introduce task_get_dfl_cgroup() (v2)

[Matt Roper]

Wraps task_dfl_cgroup() to also take a reference to the cgroup.

v2:
 - Eliminate cgroup_mutex and make lighter-weight (Tejun)

Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 63d22dfa00bd..74b435f913c1 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -527,6 +527,35 @@ static inline struct cgroup *task_dfl_cgroup(struct 
task_struct *task)
return task_css_set(task)->dfl_cgrp;
 }
 
+/**
+ * task_get_dfl_cgroup() - find and get the cgroup for a task
+ * @task: the target task
+ *
+ * Find the cgroup in the v2 hierarchy that a task belongs to, increment its
+ * reference count, and return it.
+ *
+ * Returns:
+ * The appropriate cgroup from the default hierarchy.
+ */
+static inline struct cgroup *
+task_get_dfl_cgroup(struct task_struct *task)
+{
+   struct cgroup *cgrp;
+
+   rcu_read_lock();
+   while (true) {
+   cgrp = task_dfl_cgroup(task);
+
+   if (likely(cgroup_tryget(cgrp)))
+   break;
+
+   cpu_relax();
+   }
+   rcu_read_unlock();
+
+   return cgrp;
+}
+
 static inline struct cgroup *cgroup_parent(struct cgroup *cgrp)
 {
struct cgroup_subsys_state *parent_css = cgrp->self.parent;
-- 
2.14.3

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

[PATCH v4 6/8] drm/i915: Introduce 'priority offset' for GPU contexts (v3)

[Matt Roper]

There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-level configuration.

Normally GPU contexts start with a priority value of 0
(I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
there via other mechanisms.  We'd like to provide a system-level input
to the priority decision that will be taken into consideration, even
when userspace later attempts to set an absolute priority value via
I915_CONTEXT_PARAM_PRIORITY.  The priority offset introduced here
provides a base value that will always be added to (or subtracted from)
the software's self-assigned priority value.

This patch makes priority offset a cgroup-specific value; contexts will
be created with a priority offset based on the cgroup membership of the
process creating the context at the time the context is created.  Note
that priority offset is assigned at context creation time; migrating a
process to a different cgroup or changing the offset associated with a
cgroup will only affect new context creation and will not alter the
behavior of existing contexts previously created by the process.

v2:
 - Rebase onto new cgroup_priv API
 - Use current instead of drm_file->pid to determine which process to
   lookup priority for. (Chris)
 - Don't forget to subtract priority offset in context_getparam ioctl to
   make it match setparam behavior. (Chris)

v3:
 - Rebase again onto new idr/kref-based cgroup_priv API
 - Bound priority offset such that effective priority from settings
   on context + cgroup fall within [-0x7f, 0x7f]. (Chris)

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_cgroup.c  | 52 +++--
 drivers/gpu/drm/i915/i915_drv.h | 15 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  7 +++--
 drivers/gpu/drm/i915/i915_gem_context.h |  9 ++
 drivers/gpu/drm/i915/i915_request.h |  4 +++
 include/uapi/drm/i915_drm.h |  1 +
 6 files changed, 76 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
index eaa540b65efd..b58b243aef20 100644
--- a/drivers/gpu/drm/i915/i915_cgroup.c
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -10,6 +10,8 @@
 #include "i915_drv.h"
 
 struct i915_cgroup_data {
+   int priority_offset;
+
struct kref ref;
 };
 
@@ -54,7 +56,6 @@ i915_cgroup_shutdown(struct drm_i915_private *dev_priv)
  * Return i915 cgroup private data, creating and registering it if one doesn't
  * already exist for this cgroup.
  */
-__maybe_unused
 static struct i915_cgroup_data *
 get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
  struct cgroup *cgrp)
@@ -98,9 +99,11 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
   void *data,
   struct drm_file *file)
 {
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_cgroup_param *req = data;
struct cgroup *cgrp;
-   int ret;
+   struct i915_cgroup_data *cgrpdata;
+   int ret = 0;
 
/* We don't actually support any flags yet. */
if (req->flags) {
@@ -127,14 +130,59 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev,
goto out;
}
 
+   cgrpdata = get_or_create_cgroup_data(dev_priv, cgrp);
+   if (IS_ERR(cgrpdata)) {
+   ret = PTR_ERR(cgrpdata);
+   goto out;
+   }
+
switch (req->param) {
+   case I915_CGROUP_PARAM_PRIORITY_OFFSET:
+   if (req->value + I915_CONTEXT_MAX_USER_PRIORITY <= 
I915_PRIORITY_MAX &&
+   req->value - I915_CONTEXT_MIN_USER_PRIORITY >= 
I915_PRIORITY_MIN) {
+   DRM_DEBUG_DRIVER("Setting cgroup priority offset to 
%lld\n",
+req->value);
+   cgrpdata->priority_offset = req->value;
+   } else {
+   DRM_DEBUG_DRIVER("Invalid cgroup priority offset 
%lld\n",
+req->value);
+   ret = -EINVAL;
+   }
+   break;
+
default:
DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n", req->param);
ret = -EINVAL;
}
 
+   kref_put(>ref, i915_cgroup_free);
+
 out:
cgroup_put(cgrp);
 
return ret;
 }
+
+/*
+ * Generator for simple getter functions that look up a cgroup private data
+ * field for the current task's cgroup.  It's safe to call these before
+ * a cgroup private data key has been registered; they'll just return the
+ * default value in that case.
+ */
+#define CGROUP_GET(name, field, def) \
+int 

[PATCH v4 3/8] cgroup: Introduce cgroup_priv_get_current

[Matt Roper]

Getting cgroup private data for the current process' cgroup is such a
common pattern that we should add a convenience wrapper for it.

Signed-off-by: Matt Roper 
---
 include/linux/cgroup.h |  1 +
 kernel/cgroup/cgroup.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 74b435f913c1..64d3dc45efd0 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -867,6 +867,7 @@ int cgroup_priv_getkey(void (*free)(struct kref *));
 void cgroup_priv_destroykey(int key);
 int cgroup_priv_install(struct cgroup *cgrp, int key, struct kref *ref);
 struct kref *cgroup_priv_get(struct cgroup *cgrp, int key);
+struct kref *cgroup_priv_get_current(int key);
 void cgroup_priv_release(struct cgroup *cgrp, int key);
 
 #endif /* _LINUX_CGROUP_H */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index a5e2017c9a94..56ed910beb8a 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -6079,6 +6079,29 @@ cgroup_priv_get(struct cgroup *cgrp, int key)
 }
 EXPORT_SYMBOL_GPL(cgroup_priv_get);
 
+/**
+ * cgroup_priv_get_current - looks up cgroup private data for current task
+ * @key: key uniquely identifying owner of private data to lookup
+ *
+ * Convenience function that performs cgroup_priv_get() on the cgroup that owns
+ * %current.
+ *
+ * Returns:
+ * A pointer to the private data's kref field, or NULL if no private data has
+ * been registered.
+ */
+struct kref *
+cgroup_priv_get_current(int key)
+{
+   struct cgroup *cgrp = task_get_dfl_cgroup(current);
+   struct kref *ref = cgroup_priv_get(cgrp, key);
+
+   cgroup_put(cgrp);
+
+   return ref;
+}
+EXPORT_SYMBOL_GPL(cgroup_priv_get_current);
+
 /**
  * cgroup_priv_free - free cgroup private data
  * @cgrp: cgroup to release private data for
-- 
2.14.3

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

[PATCH v4 4/8] drm/i915: Adjust internal priority definitions

[Matt Roper]

In preparation for adding cgroup-based priority adjustments, let's
define the driver's priority values a little more clearly.

Cc: Chris Wilson 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem_context.c |  4 ++--
 drivers/gpu/drm/i915/i915_request.h | 13 ++---
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e27ba8fb64e6..6ce7d0662bb6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3150,7 +3150,6 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
  unsigned int flags,
  int priority);
-#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
 
 int __must_check
 i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..551c1d75fe24 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -474,7 +474,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
ida_init(_priv->contexts.hw_ida);
 
/* lowest priority; idle task */
-   ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN);
+   ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_IDLE);
if (IS_ERR(ctx)) {
DRM_ERROR("Failed to create default global context\n");
return PTR_ERR(ctx);
@@ -488,7 +488,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
 
/* highest priority; preempting task */
if (needs_preempt_context(dev_priv)) {
-   ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
+   ctx = i915_gem_context_create_kernel(dev_priv, 
I915_PRIORITY_PREEMPT);
if (!IS_ERR(ctx))
dev_priv->preempt_context = ctx;
else
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 7d6eb82eeb91..72b13fc2b72b 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -78,12 +78,19 @@ struct i915_priotree {
int priority;
 };
 
+/*
+ * Userspace can only assign priority values of [-1023,1023] via context param,
+ * but the effective priority value can fall in a larger range once we add in
+ * a cgroup-provided offset.
+ */
 enum {
-   I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
-   I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
+   I915_PRIORITY_DEFAULT_DISPBOOST = I915_CONTEXT_MAX_USER_PRIORITY + 1,
 
-   I915_PRIORITY_INVALID = INT_MIN
+   /* Special case priority values */
+   I915_PRIORITY_INVALID = INT_MIN,
+   I915_PRIORITY_IDLE = INT_MIN + 1,
+   I915_PRIORITY_PREEMPT = INT_MAX,
 };
 
 struct i915_capture_list {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e7ab75e1b41..b053a21f682b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12783,7 +12783,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 
ret = intel_plane_pin_fb(to_intel_plane_state(new_state));
 
-   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DEFAULT_DISPBOOST);
 
mutex_unlock(_priv->drm.struct_mutex);
i915_gem_object_unpin_pages(obj);
-- 
2.14.3

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

[PATCH v4 5/8] drm/i915: cgroup integration (v3)

[Matt Roper]

Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups.  i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.

v2:
 - Large rebase/rewrite for new cgroup_priv interface
v3:
 - Another rebase/rewrite for ida-based keys and kref-based storage
 - Access control no longer follows cgroup filesystem permissions;
   instead we restrict access to either DRM master or
   capable(CAP_SYS_RESOURCE).

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_cgroup.c | 140 +
 drivers/gpu/drm/i915/i915_drv.c|   7 ++
 drivers/gpu/drm/i915/i915_drv.h|  25 +++
 include/uapi/drm/i915_drm.h|  12 
 5 files changed, 185 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 552e43e9663f..26031185cf0e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -48,6 +48,7 @@ i915-y := i915_drv.o \
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
 i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
+i915-$(CONFIG_CGROUPS) += i915_cgroup.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_cgroup.c 
b/drivers/gpu/drm/i915/i915_cgroup.c
new file mode 100644
index ..eaa540b65efd
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -0,0 +1,140 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * i915_cgroup.c - Linux cgroups integration for i915
+ *
+ * Copyright (C) 2018 Intel Corporation
+ */
+
+#include 
+
+#include "i915_drv.h"
+
+struct i915_cgroup_data {
+   struct kref ref;
+};
+
+static inline struct i915_cgroup_data *
+cgrp_ref_to_i915(struct kref *ref)
+{
+   return container_of(ref, struct i915_cgroup_data, ref);
+}
+
+static void
+i915_cgroup_free(struct kref *ref)
+{
+   struct i915_cgroup_data *priv;
+
+   priv = cgrp_ref_to_i915(ref);
+   kfree(priv);
+}
+
+int
+i915_cgroup_init(struct drm_i915_private *dev_priv)
+{
+   int ret = 0;
+
+   dev_priv->cgroup_priv_key = cgroup_priv_getkey(i915_cgroup_free);
+   if (dev_priv->cgroup_priv_key < 0) {
+   DRM_DEBUG_DRIVER("Failed to get a cgroup private data key\n");
+   ret = dev_priv->cgroup_priv_key;
+   }
+
+   mutex_init(_priv->cgroup_lock);
+
+   return ret;
+}
+
+void
+i915_cgroup_shutdown(struct drm_i915_private *dev_priv)
+{
+   cgroup_priv_destroykey(dev_priv->cgroup_priv_key);
+}
+
+/*
+ * Return i915 cgroup private data, creating and registering it if one doesn't
+ * already exist for this cgroup.
+ */
+__maybe_unused
+static struct i915_cgroup_data *
+get_or_create_cgroup_data(struct drm_i915_private *dev_priv,
+ struct cgroup *cgrp)
+{
+   struct kref *ref;
+   struct i915_cgroup_data *priv;
+
+   mutex_lock(_priv->cgroup_lock);
+
+   ref = cgroup_priv_get(cgrp, dev_priv->cgroup_priv_key);
+   if (ref) {
+   priv = cgrp_ref_to_i915(ref);
+   } else {
+   priv = kzalloc(sizeof *priv, GFP_KERNEL);
+   if (!priv) {
+   priv = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+
+   kref_init(>ref);
+   cgroup_priv_install(cgrp, dev_priv->cgroup_priv_key,
+   >ref);
+   }
+
+out:
+   mutex_unlock(_priv->cgroup_lock);
+
+   return priv;
+}
+
+/**
+ * i915_cgroup_setparam_ioctl - ioctl to alter i915 settings for a cgroup
+ * @dev: DRM device
+ * @data: data pointer for the ioctl
+ * @file_priv: DRM file handle for the ioctl call
+ *
+ * Allows i915-specific parameters to be set for a Linux cgroup.
+ */
+int
+i915_cgroup_setparam_ioctl(struct drm_device *dev,
+  void *data,
+  struct drm_file *file)
+{
+   struct drm_i915_cgroup_param *req = data;
+   struct cgroup *cgrp;
+   int ret;
+
+   /* We don't actually support any flags yet. */
+   if (req->flags) {
+   DRM_DEBUG_DRIVER("Invalid flags\n");
+   return -EINVAL;
+   }
+
+   /*
+* Make sure the file descriptor really is a cgroup fd and is on the
+* v2 hierarchy.
+*/
+   cgrp = cgroup_get_from_fd(req->cgroup_fd);
+   if (IS_ERR(cgrp)) {
+   DRM_DEBUG_DRIVER("Invalid cgroup file descriptor\n");
+   return PTR_ERR(cgrp);
+   }
+
+   /*
+* Access control:  For now we grant access via CAP_SYS_RESOURCE _or_
+* DRM master status.
+*/
+   if (!capable(CAP_SYS_RESOURCE) && !drm_is_current_master(file)) {
+   DRM_DEBUG_DRIVER("Insufficient permissions to adjust i915 
cgroup settings\n");
+   goto out;
+   

[PATCH v4 1/8] cgroup: Allow registration and lookup of cgroup private data (v2)

[Matt Roper]

There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller.  Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.

A kernel system (e.g., a driver) that wishes to register private data
for a cgroup should start by obtaining a unique private data key by
calling cgroup_priv_getkey().  It may then associate private data
with a cgroup by calling cgroup_priv_install(cgrp, key, ref) where 'ref'
is a pointer to a kref field inside the private data structure.  The
private data may later be looked up by calling cgroup_priv_get(cgrp,
key) to obtain a new reference to the private data.  Private data may be
unregistered via cgroup_priv_release(cgrp, key).

If a cgroup is removed, the reference count for all private data objects
will be decremented.

v2:  Significant overhaul suggested by Tejun, Alexei, and Roman
 - Rework interface to make consumers obtain an ida-based key rather
   than supplying their own arbitrary void*
 - Internal implementation now uses per-cgroup radixtrees which should
   allow much faster lookup than the previous hashtable approach
 - Private data is registered via kref, allowing a single private data
   structure to potentially be assigned to multiple cgroups.

Cc: Tejun Heo 
Cc: Alexei Starovoitov 
Cc: Roman Gushchin 
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup-defs.h |   8 ++
 include/linux/cgroup.h  |   7 ++
 kernel/cgroup/cgroup.c  | 185 +++-
 3 files changed, 197 insertions(+), 3 deletions(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 9f242b876fde..465006274a84 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -427,6 +427,14 @@ struct cgroup {
/* used to store eBPF programs */
struct cgroup_bpf bpf;
 
+   /*
+* cgroup private data registered by other non-controller parts of the
+* kernel.  Insertions are protected by privdata_lock, lookups by
+* rcu_read_lock().
+*/
+   struct radix_tree_root privdata;
+   spinlock_t privdata_lock;
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
 };
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 473e0c0abb86..63d22dfa00bd 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -833,4 +833,11 @@ static inline void put_cgroup_ns(struct cgroup_namespace 
*ns)
free_cgroup_ns(ns);
 }
 
+/* cgroup private data handling */
+int cgroup_priv_getkey(void (*free)(struct kref *));
+void cgroup_priv_destroykey(int key);
+int cgroup_priv_install(struct cgroup *cgrp, int key, struct kref *ref);
+struct kref *cgroup_priv_get(struct cgroup *cgrp, int key);
+void cgroup_priv_release(struct cgroup *cgrp, int key);
+
 #endif /* _LINUX_CGROUP_H */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 8cda3bc3ae22..a5e2017c9a94 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -81,10 +81,17 @@ EXPORT_SYMBOL_GPL(css_set_lock);
 #endif
 
 /*
- * Protects cgroup_idr and css_idr so that IDs can be released without
- * grabbing cgroup_mutex.
+ * ID allocator for cgroup private data keys; the ID's allocated here will
+ * be used to index all per-cgroup radix trees.  The radix tree built into
+ * the IDR itself will store a key-specific function to be passed to kref_put.
  */
-static DEFINE_SPINLOCK(cgroup_idr_lock);
+static DEFINE_IDR(cgroup_priv_idr);
+
+/*
+ * Protects cgroup_idr, css_idr, and cgroup_priv_idr so that IDs can be
+ * released without grabbing cgroup_mutex.
+ */
+DEFINE_SPINLOCK(cgroup_idr_lock);
 
 /*
  * Protects cgroup_file->kn for !self csses.  It synchronizes notifications
@@ -1839,6 +1846,8 @@ static void init_cgroup_housekeeping(struct cgroup *cgrp)
INIT_LIST_HEAD(>cset_links);
INIT_LIST_HEAD(>pidlists);
mutex_init(>pidlist_mutex);
+   INIT_RADIX_TREE(>privdata, GFP_NOWAIT);
+   spin_lock_init(>privdata_lock);
cgrp->self.cgroup = cgrp;
cgrp->self.flags |= CSS_ONLINE;
cgrp->dom_cgrp = cgrp;
@@ -4578,6 +4587,8 @@ static void css_release_work_fn(struct work_struct *work)
container_of(work, struct cgroup_subsys_state, destroy_work);
struct cgroup_subsys *ss = css->ss;
struct cgroup *cgrp = css->cgroup;
+   struct radix_tree_iter iter;
+   void **slot;
 
mutex_lock(_mutex);
 
@@ -4617,6 +4628,12 @@ static void css_release_work_fn(struct work_struct *work)
 NULL);
 
cgroup_bpf_put(cgrp);
+
+   /* Drop reference on any private data */
+   rcu_read_lock();
+   radix_tree_for_each_slot(slot, >privdata, , 0)
+   

[PATCH v4 0/8] cgroup private data and DRM/i915 integration

[Matt Roper]

This is the fourth iteration of the work previously posted here:
  (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
  (v2) 
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
  (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html

The high level goal of this work is to allow non-cgroup-controller parts
of the kernel (e.g., device drivers) to register their own private
policy data for specific cgroups.  That mechanism is then made use of in
the i915 graphics driver to allow GPU priority to be assigned according
to the cgroup membership of the owning process.  Please see the v1 cover
letter linked above for a more in-depth explanation and justification.

v4 of this series brings large changes to the cgroup core half of the
series and moderate changes to the i915 side.

cgroup core changes:

 * The cgroup private data interface and implementation has changed
   again.  The internal implementation is ida+radixtree based to allow
   much faster lookups than the previous hashtable approach.  Private
   data is now registered and looked up via kref, which should allow
   the same private data to be set on multiple cgroups at the same
   time.  The interface now looks like:

- cgroup_priv_getkey()
 Obtain an integer key that will be used to store/lookup
 cgroup private data.  This only needs to be called once
 at startup, driver init, etc.; after that the same key
 is used to store private data against any cgroup

- cgroup_priv_destroykey(key)
 Release a private data key and drop references to any
 private data associated with the key on all cgroups.  This
 function is very heavy, but will generally only be called
 by module-based users of the interface when the module is
 unloaded.

- cgroup_priv_install(cgrp, key, ref)
 Store private data for a cgroup under the given key and
 increment the reference count.

- cgroup_priv_get(cgrp, key)
 Take and return a reference to a cgroup's private data
 associated with the given key.

- cgroup_priv_get_current(key)
 Same as cgroup_priv_get, but operates on the current
 task's cgroup.

- cgroup_priv_release(cgrp, key)
 Remove private data from a cgroup and decrement its
 reference count.

 * Dropped the cgroup_permission() function.  My i915 usage of this
   functionality will take a different approach for determining access
   control.

i915 cgroup-based priority changes:

 * cgroup priority offset is now bounded such that (context+cgroup)
   adjustments fall within the range [-0x7f,0x7f].  This
   only takes 24 bits, leaving several effective priority bits for
   future flags or bookkeeping.

 * Display boost is added as a second cgroup parameter; each cgroup's
   processes can get differing boosts if a display operation is waiting
   on their completion.  If we have non-overlapping cgroup priority
   ranges, this allows a system administrator to decide whether
   workloads from the lower priority cgroup(s) should still jump past
   the workloads in some/all of the higher priority cgroups.

 * Access control for cgroup settings has been changed.  Instead of
   following cgroup filesystem permissions, we now restrict the access
   to either the DRM master or capable(CAP_SYS_RESOURCE).

Cc: Tejun Heo 
Cc: Alexei Starovoitov 
Cc: Roman Gushchin 
Cc: Chris Wilson 

Matt Roper (8):
  cgroup: Allow registration and lookup of cgroup private data (v2)
  cgroup: Introduce task_get_dfl_cgroup() (v2)
  cgroup: Introduce cgroup_priv_get_current
  drm/i915: Adjust internal priority definitions
  drm/i915: cgroup integration (v3)
  drm/i915: Introduce 'priority offset' for GPU contexts (v3)
  drm/i915: Introduce per-cgroup display boost setting
  drm/i915: Add context priority & priority offset to debugfs (v2)

 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_cgroup.c  | 205 +++
 drivers/gpu/drm/i915/i915_debugfs.c |   3 +
 drivers/gpu/drm/i915/i915_drv.c |   7 ++
 drivers/gpu/drm/i915/i915_drv.h |  33 -
 drivers/gpu/drm/i915/i915_gem_context.c |  11 +-
 drivers/gpu/drm/i915/i915_gem_context.h |   9 ++
 drivers/gpu/drm/i915/i915_request.h |  18 ++-
 drivers/gpu/drm/i915/intel_display.c|   5 +-
 include/linux/cgroup-defs.h |   8 ++
 include/linux/cgroup.h  |  37 ++
 include/uapi/drm/i915_drm.h |  14 +++
 kernel/cgroup/cgroup.c  | 208 +++-
 13 files changed, 545 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c

-- 
2.14.3

Re: [PATCH v3 1/2] spi: Split spi message into chunks of <65535 in the spi subsystem

[Eric Anholt]

Meghana Madhyastha  writes:

> Split spi messages into chunks of <65535 in the spi subsystem and remove the 
> message
> length warning in bcm2835_spi_can_dma. This is so that the messages can be 
> transferred
> via dma and that the tinydrm drivers need not split it. The current chunk 
> size is 65532.
> This is because the scatter gather segment is required to be multiple of 4. 
> The size
> has to be <65535 due to hardware limitations.
>
> Signed-off-by: Meghana Madhyastha 
> ---
>  drivers/spi/spi-bcm2835.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
> index f35cc10772f6..280ffa5aef7e 100644
> --- a/drivers/spi/spi-bcm2835.c
> +++ b/drivers/spi/spi-bcm2835.c
> @@ -365,19 +365,6 @@ static bool bcm2835_spi_can_dma(struct spi_master 
> *master,
>   if (tfr->len < BCM2835_SPI_DMA_MIN_LENGTH)
>   return false;
>  
> - /* BCM2835_SPI_DLEN has defined a max transfer size as
> -  * 16 bit, so max is 65535
> -  * we can revisit this by using an alternative transfer
> -  * method - ideally this would get done without any more
> -  * interaction...
> -  */
> - if (tfr->len > 65535) {
> - dev_warn_once(>dev,
> -   "transfer size of %d too big for dma-transfer\n",
> -   tfr->len);
> - return false;
> - }
> -
>   /* if we run rx/tx_buf with word aligned addresses then we are OK */
>   if size_t)tfr->rx_buf & 3) == 0) &&
>   (((size_t)tfr->tx_buf & 3) == 0))
> @@ -461,7 +448,7 @@ static void bcm2835_dma_init(struct spi_master *master, 
> struct device *dev)
>  
>   /* all went well, so set can_dma */
>   master->can_dma = bcm2835_spi_can_dma;
> - master->max_dma_len = 65535; /* limitation by BCM2835_SPI_DLEN */
> + master->max_dma_len = 65532; /* limitation by BCM2835_SPI_DLEN */
>   /* need to do TX AND RX DMA, so we need dummy buffers */
>   master->flags = SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX;
>  
> @@ -597,7 +584,14 @@ static int bcm2835_spi_prepare_message(struct spi_master 
> *master,
>  {
>   struct spi_device *spi = msg->spi;
>   struct bcm2835_spi *bs = spi_master_get_devdata(master);
> + gfp_t gfp_flags = GFP_KERNEL | GFP_DMA;
>   u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
> + size_t max_transfer_size = 65532;
> + int ret;
> +
> + ret = spi_split_transfers_maxsize(master, msg, max_transfer_size, 
> gfp_flags);
> + if (ret)
> +return ret;

Mark: is this how spi_split_transfers_maxsize() is supposed to be used?
If so, I'm happy to see our hardware have fewer limitations, and it gets
my:

Reviewed-by: Eric Anholt 


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

Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[kbuild test robot]

Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/matthew-s-atwood-intel-com/drm-dp-Correctly-mask-DP_TRAINING_AUX_RD_INTERVAL-values-for-DP-1-4/20180316-222756
config: x86_64-federa-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:29:0,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:42:
>> include/drm/drm_dp_helper.h:67:45: error: expected identifier before numeric 
>> constant
# define DPCD_REV_100x10
^
   drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:32:2: note: in 
expansion of macro 'DPCD_REV_10'
 DPCD_REV_10 = 0x10,
 ^~~

vim +67 include/drm/drm_dp_helper.h

63  
64  /* AUX CH addresses */
65  /* DPCD */
66  #define DP_DPCD_REV 0x000
  > 67  # define DPCD_REV_100x10
68  # define DPCD_REV_110x11
69  # define DPCD_REV_120x12
70  # define DPCD_REV_130x13
71  # define DPCD_REV_140x14
72  

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


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

Re: [PATCH] drm/vc4_validate: Remove VLA usage

[Eric Anholt]

"Gustavo A. R. Silva"  writes:

> In preparation to enabling -Wvla, remove VLA. In this particular
> case use macro ARRAY_SIZE so the length of array _bo_ can be
> computed at preprocessing time.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/vc4/vc4_validate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_validate.c 
> b/drivers/gpu/drm/vc4/vc4_validate.c
> index 2db485a..eec76af 100644
> --- a/drivers/gpu/drm/vc4/vc4_validate.c
> +++ b/drivers/gpu/drm/vc4/vc4_validate.c
> @@ -753,7 +753,7 @@ validate_gl_shader_rec(struct drm_device *dev,
>   28, /* cs */
>   };
>   uint32_t shader_reloc_count = ARRAY_SIZE(shader_reloc_offsets);
> - struct drm_gem_cma_object *bo[shader_reloc_count + 8];
> + struct drm_gem_cma_object *bo[ARRAY_SIZE(shader_reloc_offsets) + 8];
>   uint32_t nr_attributes, nr_relocs, packet_size;
>   int i;
>  
> -- 
> 2.7.4

It's a shame that the compiler is warning about this when it's obviously
a compile-time constant.  Regardless, reviewed and applied.


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

[GIT PULL] drm/tegra: Fixes for v4.16-rc7

[Thierry Reding]

Hi Dave,

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc7

for you to fetch changes up to 48519232bea9230d1c5dbbb680d9257d4861bb4c:

  drm/tegra: plane: Correct legacy blending (2018-03-15 15:56:46 +0100)

Thanks,
Thierry


drm/tegra: Fixes for v4.16-rc7

This contains two small fixes for the alpha blending support that was
merged into v4.16-rc1.


Dmitry Osipenko (1):
  drm/tegra: plane: Correct legacy blending

Thierry Reding (1):
  drm/tegra: plane: Fix RGB565 format on older Tegra

 drivers/gpu/drm/tegra/plane.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjälä  writes:

> On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
>> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
>> > > Ville Syrjala  writes:
>> > > 
>> > > > From: Ville Syrjälä 
>> > > >
>> > > > To make life easier for drivers, let's have the core check that the
>> > > > requested pixel format is supported by at least one plane when creating
>> > > > a new framebuffer.
>> > > >
>> > > > This eases the burden on drivers by making sure they'll never get
>> > > > requests to create fbs with unsupported pixel formats. Thanks to the
>> > > > new .fb_modifier() hook this check can now be done whether the request
>> > > > specifies the modifier directly or driver has to deduce it from the
>> > > > gem bo tiling (or via any other method really).
>> > > >
>> > > > v0: Accept anyformat if the driver doesn't do planes (Eric)
>> > > > s/planes_have_format/any_plane_has_format/ (Eric)
>> > > > Check the modifier as well since we already have a function
>> > > > that does both
>> > > > v3: Don't do the check in the core since we may not know the
>> > > > modifier yet, instead export the function and let drivers
>> > > > call it themselves
>> > > > v4: Unexport the functiona and put the format_default check back
>> > > > since this will again be called by the core, ie. undo v3 ;)
>> > > >
>> > > > Cc: Eric Anholt 
>> > > > Testcase: igt/kms_addfb_basic/expected-formats
>> > > > Signed-off-by: Ville Syrjälä 
>> > > > ---
>> > > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++
>> > > >  1 file changed, 30 insertions(+)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > > > b/drivers/gpu/drm/drm_framebuffer.c
>> > > > index 21d3d51eb261..e618a6b728d4 100644
>> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
>> > > >return DIV_ROUND_UP(height, format->vsub);
>> > > >  }
>> > > >  
>> > > > +static bool any_plane_has_format(struct drm_device *dev,
>> > > > +   u32 format, u64 modifier)
>> > > > +{
>> > > > +  struct drm_plane *plane;
>> > > > +
>> > > > +  drm_for_each_plane(plane, dev) {
>> > > > +  /*
>> > > > +   * In case the driver doesn't really do
>> > > > +   * planes we have to accept any format here.
>> > > > +   */
>> > > > +  if (plane->format_default)
>> > > > +  return true;
>> > > > +
>> > > > +  if (drm_plane_check_pixel_format(plane, format, 
>> > > > modifier) == 0)
>> > > > +  return true;
>> > > > +  }
>> > > > +
>> > > > +  return false;
>> > > > +}
>> > > 
>> > > This drm_plane_check_pixel_format() will always fail for VC4's SAND
>> > > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
>> > > as a bit of metadata (like how we have horizontal stride passed outside
>> > > of the modifier) and you can't list all of the possible values in an
>> > > array on the plane.
>> > 
>> > Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
>> > that manage to work currently?
>> 
>> Maybe it doesn't. I added the modifier checks in
>> 
>> commit 23163a7d4b032489d375099d56571371c0456980
>> Author: Ville Syrjälä 
>> AuthorDate: Fri Dec 22 21:22:30 2017 +0200
>> Commit: Ville Syrjälä 
>> CommitDate: Mon Feb 26 16:29:47 2018 +0200
>> 
>> drm: Check that the plane supports the request format+modifier combo
>> 
>> Maybe that broke vc4?
>> 
>> Hmm. So either we need to stop checking against the modifiers array and
>> rely purely or .format_mod_supported(), or we need to somehow get the
>> driver to reduce the modifier to its base form. I guess we could make
>> .fb_modifier() do that and call it also for addfb with modifiers. And
>> I'd need to undo some of the modifier[0] vs. deduced modifier changes
>> I did to framebuffer_check(), and we'd need to preserve the original
>> modifier in the request for .fb_create(). Oh, but that wouldn't allow
>> returning a non-base modifier from .fb_modifuer() for the !modifiers
>> case. This is turning slightly more tricky than I had hoped...
>> 
>> I guess relying on .format_mod_supported() might be what we need to 
>> do. Unfortunately it does mean that the .format_mod_supported()
>> implementations must be prepared for modifiers that were not
>> registered with the plane. Which does feel quite a bit more
>> fragile.
>
> And that last apporach would be annoying for i915. So I think the other
> apporach is better.
>
> Fortunately it seems your SAND modifiers aren't upstream yet so I didn't

Re: [PATCH] drm/vc4: Add support for SAND modifier.

[Eric Anholt]

Daniel Stone  writes:

> Hey Eric,
>
> On 3 March 2018 at 01:34, Eric Anholt  wrote:
>> Ccing a couple of folks who are likely to have opinions about
>> drm_fourcc.h additions (Do we have enough docs?  Are the macros OK?),
>> and Bootlin who are likely reviewers.
>>
>> The plan is to use these modifiers in VC4 GL imports as well, and for
>> buffers coming from the v4l2 mmal camera driver.  You can find a demo
>> using this in KMS planes at
>> https://github.com/anholt/drm_mmal/commit/sand for now.
>
> I had a dig through and this seems like the most sensible thing to do
> if you have a reasonable variety of tile heights. If you only see a
> couple of combinations in the wild, then hardcoding them as separate
> modifiers might make things easier than hiving off 24 bits. If you do
> keep the split though, and especially if you're envisioning future
> flexible tile formats, maybe something like an 8 code / 48 params
> split would make more sense.
>
> Either way, those are just my opinions (you did ask), and I don't see
> anything really objectionable, so if you think that's a good split
> then this is:
> Acked-by: Daniel Stone 

I had been thinking of potentially specifying a meaning for the other 24
bits (separate U/V plane v stride if set, if we ever get a component
that needs to do that), so I went ahead and did this, along with a
couple of fixes due to Ville's patch.


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

[PATCH 1/3] drm: Trust format_mod_supported() when it OKs a plane modifier.

[Eric Anholt]

For parameterized modifiers (Broadcom's SAND and UIF), we need to
allow the parameter fields to be filled in, while exposing only the
variant of the modifier with the parameter unfilled in the internal
arrays and the format blob.

Signed-off-by: Eric Anholt 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_plane.c | 23 ---
 include/drm/drm_plane.h |  5 -
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 46fbd019a337..5bb501f1aae8 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -561,19 +561,20 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
if (i == plane->format_count)
return -EINVAL;
 
-   if (!plane->modifier_count)
-   return 0;
+   if (plane->funcs->format_mod_supported) {
+   if (!plane->funcs->format_mod_supported(plane, format, 
modifier))
+   return -EINVAL;
+   } else {
+   if (!plane->modifier_count)
+   return 0;
 
-   for (i = 0; i < plane->modifier_count; i++) {
-   if (modifier == plane->modifiers[i])
-   break;
+   for (i = 0; i < plane->modifier_count; i++) {
+   if (modifier == plane->modifiers[i])
+   break;
+   }
+   if (i == plane->modifier_count)
+   return -EINVAL;
}
-   if (i == plane->modifier_count)
-   return -EINVAL;
-
-   if (plane->funcs->format_mod_supported &&
-   !plane->funcs->format_mod_supported(plane, format, modifier))
-   return -EINVAL;
 
return 0;
 }
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..6b1b51645f75 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -420,7 +420,10 @@ struct drm_plane_funcs {
 * This optional hook is used for the DRM to determine if the given
 * format/modifier combination is valid for the plane. This allows the
 * DRM to generate the correct format bitmask (which formats apply to
-* which modifier).
+* which modifier), and to valdiate modifiers at atomic_check time.
+*
+* If not present, then any modifier in the plane's modifier
+* list is allowed with any of the plane's formats.
 *
 * Returns:
 *
-- 
2.16.2

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

[PATCH 2/3] drm/vc4: Add missing formats to vc4_format_mod_supported().

[Eric Anholt]

Daniel's format_mod_supported() patch predated Dave's for NV21/61, and
I didn't catch that when rebasing.  This is a problem since the
formats are now getting validated before being passed to the driver's
atomic hooks.

Signed-off-by: Eric Anholt 
Cc: Daniel Stone 
Cc: Dave Stevenson 
Fixes: 423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes")
---
 drivers/gpu/drm/vc4/vc4_plane.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ce39390be389..ba00c14f989a 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -884,7 +884,9 @@ static bool vc4_format_mod_supported(struct drm_plane 
*plane,
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV21:
case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV61:
default:
return (modifier == DRM_FORMAT_MOD_LINEAR);
}
-- 
2.16.2

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

[PATCH 3/3] drm/vc4: Add support for SAND modifier.

[Eric Anholt]

From: Dave Stevenson 

This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well.  By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.

This is a joint effort by Dave Stevenson (who wrote the initial patch
and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety
checks, RGBA support).

v2: Make the parameter macro give all of the middle 48 bits (suggested
by Daniels).  Fix fourcc_mod_broadcom_mod()'s bits/shift being
swapped.  Mark NV12/21 as supported, not YUV420.

Signed-off-by: Dave Stevenson 
Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Boris Brezillon 
Cc: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 84 +
 drivers/gpu/drm/vc4/vc4_regs.h  |  6 +++
 include/uapi/drm/drm_fourcc.h   | 59 +
 3 files changed, 142 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ba00c14f989a..06ec6fb08fe4 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -466,11 +466,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
struct drm_framebuffer *fb = state->fb;
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format = 
vc4_get_hvs_format(fb->format->format);
+   u64 base_format_mod = fourcc_mod_broadcom_mod(fb->modifier);
int num_planes = drm_format_num_planes(format->drm);
bool covers_screen;
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
unsigned long irqflags;
+   u32 hvs_format = format->hvs;
int ret, i;
 
ret = vc4_plane_setup_clipping_and_scaling(state);
@@ -510,7 +512,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
scl1 = vc4_get_scl_field(state, 0);
}
 
-   switch (fb->modifier) {
+   switch (base_format_mod) {
case DRM_FORMAT_MOD_LINEAR:
tiling = SCALER_CTL0_TILING_LINEAR;
pitch0 = VC4_SET_FIELD(fb->pitches[0], SCALER_SRC_PITCH);
@@ -533,6 +535,49 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
break;
}
 
+   case DRM_FORMAT_MOD_BROADCOM_SAND64:
+   case DRM_FORMAT_MOD_BROADCOM_SAND128:
+   case DRM_FORMAT_MOD_BROADCOM_SAND256: {
+   uint32_t param = fourcc_mod_broadcom_param(fb->modifier);
+
+   /* Column-based NV12 or RGBA.
+*/
+   if (fb->format->num_planes > 1) {
+   if (hvs_format != HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE) 
{
+   DRM_DEBUG_KMS("SAND format only valid for 
NV12/21");
+   return -EINVAL;
+   }
+   hvs_format = HVS_PIXEL_FORMAT_H264;
+   } else {
+   if (base_format_mod == DRM_FORMAT_MOD_BROADCOM_SAND256) 
{
+   DRM_DEBUG_KMS("SAND256 format only valid for 
H.264");
+   return -EINVAL;
+   }
+   }
+
+   switch (base_format_mod) {
+   case DRM_FORMAT_MOD_BROADCOM_SAND64:
+   tiling = SCALER_CTL0_TILING_64B;
+   break;
+   case DRM_FORMAT_MOD_BROADCOM_SAND128:
+   tiling = SCALER_CTL0_TILING_128B;
+   break;
+   case DRM_FORMAT_MOD_BROADCOM_SAND256:
+   tiling = SCALER_CTL0_TILING_256B_OR_T;
+   break;
+   default:
+   break;
+   }
+
+   if (param > SCALER_TILE_HEIGHT_MASK) {
+   DRM_DEBUG_KMS("SAND height too large (%d)\n", param);
+   return -EINVAL;
+   }
+
+   pitch0 = VC4_SET_FIELD(param, SCALER_TILE_HEIGHT);
+   break;
+   }
+
default:
DRM_DEBUG_KMS("Unsupported FB tiling flag 0x%16llx",
  (long long)fb->modifier);
@@ -543,7 +588,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_dlist_write(vc4_state,
SCALER_CTL0_VALID |
(format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
-   (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
+   (hvs_format << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |
(vc4_state->is_unity ? SCALER_CTL0_UNITY : 0) |
VC4_SET_FIELD(scl0, SCALER_CTL0_SCL0) |
@@ -597,8 +642,13 @@ static int 

[PATCH 0/3] drm/vc4: Atomic color management support

[Stefan Schake]

This series adds support for the gamma and CTM properties to VC4.
Patches 2 and 3 need the register definitions from here:

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

The CTM support is somewhat limited in that we can only enable it for one
CRTC at a time and coefficients are S0.9 in hardware. The latter still
seem good enough for the various color corrections Android offers.

Stefan Schake (3):
  drm/vc4: Expose gamma as atomic property
  drm/vc4: Add color transformation matrix (CTM) support
  drm/vc4: Restrict active CTM to one CRTC

 drivers/gpu/drm/vc4/vc4_crtc.c | 124 ++---
 1 file changed, 115 insertions(+), 9 deletions(-)

-- 
2.7.4

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

[PATCH 1/3] drm/vc4: Expose gamma as atomic property

[Stefan Schake]

We are an atomic driver so the gamma LUT should also be exposed as a
CRTC property through the DRM atomic color management. This will also
take care of the legacy path for us.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index bf46674..8d71098 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -298,23 +298,21 @@ vc4_crtc_lut_load(struct drm_crtc *crtc)
HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_b[i]);
 }
 
-static int
-vc4_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
-  uint32_t size,
-  struct drm_modeset_acquire_ctx *ctx)
+static void
+vc4_crtc_update_gamma_lut(struct drm_crtc *crtc)
 {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct drm_color_lut *lut = crtc->state->gamma_lut->data;
+   u32 length = crtc->state->gamma_lut->length / sizeof(*lut);
u32 i;
 
-   for (i = 0; i < size; i++) {
-   vc4_crtc->lut_r[i] = r[i] >> 8;
-   vc4_crtc->lut_g[i] = g[i] >> 8;
-   vc4_crtc->lut_b[i] = b[i] >> 8;
+   for (i = 0; i < length; i++) {
+   vc4_crtc->lut_r[i] = drm_color_lut_extract(lut[i].red, 8);
+   vc4_crtc->lut_g[i] = drm_color_lut_extract(lut[i].green, 8);
+   vc4_crtc->lut_b[i] = drm_color_lut_extract(lut[i].blue, 8);
}
 
vc4_crtc_lut_load(crtc);
-
-   return 0;
 }
 
 static u32 vc4_get_fifo_full_level(u32 format)
@@ -699,6 +697,9 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
if (crtc->state->active && old_state->active)
vc4_crtc_update_dlist(crtc);
 
+   if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
+   vc4_crtc_update_gamma_lut(crtc);
+
if (debug_dump_regs) {
DRM_INFO("CRTC %d HVS after:\n", drm_crtc_index(crtc));
vc4_hvs_dump_state(dev);
@@ -909,7 +910,7 @@ static const struct drm_crtc_funcs vc4_crtc_funcs = {
.reset = vc4_crtc_reset,
.atomic_duplicate_state = vc4_crtc_duplicate_state,
.atomic_destroy_state = vc4_crtc_destroy_state,
-   .gamma_set = vc4_crtc_gamma_set,
+   .gamma_set = drm_atomic_helper_legacy_gamma_set,
.enable_vblank = vc4_enable_vblank,
.disable_vblank = vc4_disable_vblank,
 };
@@ -1035,6 +1036,7 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
primary_plane->crtc = crtc;
vc4_crtc->channel = vc4_crtc->data->hvs_channel;
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
+   drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
 
/* Set up some arbitrary number of planes.  We're not limited
 * by a set number of physical registers, just the space in
-- 
2.7.4

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

[PATCH 2/3] drm/vc4: Add color transformation matrix (CTM) support

[Stefan Schake]

The hardware supports a CTM with S0.9 values. We therefore only allow
a value of 1.0 or fractional only and reject all others with integer
parts. This restriction is mostly inconsequential in practice since
commonly used transformation matrices have all scalars <= 1.0.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 99 --
 1 file changed, 96 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 8d71098..5c83fd2 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -315,6 +315,81 @@ vc4_crtc_update_gamma_lut(struct drm_crtc *crtc)
vc4_crtc_lut_load(crtc);
 }
 
+/* Converts a DRM S31.32 value to the HW S0.9 format. */
+static u16 vc4_crtc_s31_32_to_s0_9(u64 in)
+{
+   u16 r;
+
+   /* Sign bit. */
+   r = in & BIT_ULL(63) ? BIT(9) : 0;
+   /* We have zero integer bits so we can only saturate here. */
+   if ((in & GENMASK_ULL(62, 32)) > 0)
+   r |= GENMASK(8, 0);
+   /* Otherwise take the 9 most important fractional bits. */
+   else
+   r |= (in >> 22) & GENMASK(8, 0);
+   return r;
+}
+
+static void
+vc4_crtc_update_ctm(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct drm_color_ctm *ctm = crtc->state->ctm->data;
+
+   HVS_WRITE(SCALER_OLEDCOEF2,
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
+   SCALER_OLEDCOEF2_R_TO_R) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[3]),
+   SCALER_OLEDCOEF2_R_TO_G) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[6]),
+   SCALER_OLEDCOEF2_R_TO_B));
+   HVS_WRITE(SCALER_OLEDCOEF1,
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[1]),
+   SCALER_OLEDCOEF1_G_TO_R) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[4]),
+   SCALER_OLEDCOEF1_G_TO_G) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[7]),
+   SCALER_OLEDCOEF1_G_TO_B));
+   HVS_WRITE(SCALER_OLEDCOEF0,
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[2]),
+   SCALER_OLEDCOEF0_B_TO_R) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[5]),
+   SCALER_OLEDCOEF0_B_TO_G) |
+ VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[8]),
+   SCALER_OLEDCOEF0_B_TO_B));
+
+   /* Channel is 0-based but for DISPFIFO, 0 means disabled. */
+   HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
+SCALER_OLEDOFFS_DISPFIFO));
+}
+
+/* Check if the CTM contains valid input.
+ *
+ * DRM exposes CTM with S31.32 scalars, but the HW only supports S0.9.
+ * We don't allow integer values >1, and 1 only without fractional part
+ * to handle the common 1.0 value.
+ */
+static int vc4_crtc_atomic_check_ctm(struct drm_crtc_state *state)
+{
+   struct drm_color_ctm *ctm = state->ctm->data;
+   u32 i;
+
+   for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
+   u64 val = ctm->matrix[i];
+
+   val &= ~BIT_ULL(63);
+   if ((val >> 32) > 1)
+   return -EINVAL;
+   if ((val >> 32) == 1 && (val & GENMASK_ULL(31, 0)) != 0)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static u32 vc4_get_fifo_full_level(u32 format)
 {
static const u32 fifo_len_bytes = 64;
@@ -621,6 +696,15 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
if (hweight32(state->connector_mask) > 1)
return -EINVAL;
 
+   if (state->ctm) {
+   /* The CTM hardware has no integer bits, so we check
+* and reject scalars >1.0 that we have no chance of
+* approximating.
+*/
+   if (vc4_crtc_atomic_check_ctm(state))
+   return -EINVAL;
+   }
+
drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
dlist_count += vc4_plane_dlist_size(plane_state);
 
@@ -697,8 +781,17 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
if (crtc->state->active && old_state->active)
vc4_crtc_update_dlist(crtc);
 
-   if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
-   vc4_crtc_update_gamma_lut(crtc);
+   if (crtc->state->color_mgmt_changed) {
+   if (crtc->state->gamma_lut)
+   vc4_crtc_update_gamma_lut(crtc);
+
+   if (crtc->state->ctm)
+ 

[PATCH 3/3] drm/vc4: Restrict active CTM to one CRTC

[Stefan Schake]

We only have one hardware block to do the CTM and need to reject
attempts to enable it for multiple CRTCs simultaneously.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 5c83fd2..64ff293 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -678,10 +678,17 @@ static enum drm_mode_status vc4_crtc_mode_valid(struct 
drm_crtc *crtc,
return MODE_OK;
 }
 
+static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4)
+{
+   return VC4_GET_FIELD(HVS_READ(SCALER_OLEDOFFS),
+SCALER_OLEDOFFS_DISPFIFO);
+}
+
 static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
 {
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
+   struct drm_crtc_state *old_state = crtc->state;
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane;
@@ -703,6 +710,10 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
 */
if (vc4_crtc_atomic_check_ctm(state))
return -EINVAL;
+
+   /* We can only enable CTM for one fifo or CRTC at a time */
+   if (!old_state->ctm && vc4_crtc_get_ctm_fifo(vc4))
+   return -EINVAL;
}
 
drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
-- 
2.7.4

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

[RFC][PATCH] drm_hwcomposer: Rework platformdrmgeneric.cpp to use libdrm's gralloc handle

[John Stultz]

Rework the platformdrmgeneric buffer importer to use the libdrm
generic gralloc handle definition.

This is just to get the drm_hwcomposer project building in AOSP
along with the libdrm freedesktop/master branch. Similar changes
may also be needed to gbm_gralloc and other projects not used
in AOSP.

Mostly just sending this out for review feedback.

Cc: Robert Foss 
Cc: Rob Herring 
Cc: Sean Paul 
Signed-off-by: John Stultz 
---
 Android.mk |  2 +-
 platformdrmgeneric.cpp | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Android.mk b/Android.mk
index 1add286..383de1c 100644
--- a/Android.mk
+++ b/Android.mk
@@ -47,7 +47,7 @@ LOCAL_SHARED_LIBRARIES := \
 LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
 
 LOCAL_C_INCLUDES := \
-   external/drm_gralloc \
+   external/libdrm/android \
system/core/libsync
 
 LOCAL_SRC_FILES := \
diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
index 741d42b..2a6773c 100644
--- a/platformdrmgeneric.cpp
+++ b/platformdrmgeneric.cpp
@@ -25,7 +25,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -85,23 +85,23 @@ uint32_t DrmGenericImporter::ConvertHalFormatToDrm(uint32_t 
hal_format) {
 }
 
 EGLImageKHR DrmGenericImporter::ImportImage(EGLDisplay egl_display, 
buffer_handle_t handle) {
-  gralloc_drm_handle_t *gr_handle = gralloc_drm_handle(handle);
+  gralloc_handle_t *gr_handle = gralloc_handle(handle);
   if (!gr_handle)
 return NULL;
   EGLint attr[] = {
-EGL_WIDTH, gr_handle->width,
-EGL_HEIGHT, gr_handle->height,
+EGL_WIDTH, (EGLint)gr_handle->width,
+EGL_HEIGHT, (EGLint)gr_handle->height,
 EGL_LINUX_DRM_FOURCC_EXT, (EGLint)ConvertHalFormatToDrm(gr_handle->format),
 EGL_DMA_BUF_PLANE0_FD_EXT, gr_handle->prime_fd,
 EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
-EGL_DMA_BUF_PLANE0_PITCH_EXT, gr_handle->stride,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, (EGLint)gr_handle->stride,
 EGL_NONE,
   };
   return eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, 
NULL, attr);
 }
 
 int DrmGenericImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) 
{
-  gralloc_drm_handle_t *gr_handle = gralloc_drm_handle(handle);
+  gralloc_handle_t *gr_handle = gralloc_handle(handle);
   if (!gr_handle)
 return -EINVAL;
 
-- 
2.7.4

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

[RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android

[John Stultz]

In trying to integrate the new gralloc_handle.h with the
drm_hwcomposer, I started seeing the following compilation
errors:

In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return 
object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of 
type 'struct gralloc_handle_t *'
return handle;
   ^~
1 error generated.

This seems to be due to the gralloc_handle_create() definition
claiming to return a native_handle_t * type, rather then a
gralloc_handle_t *, which is what the code actually returns.

This function isn't actually used in the current drm_hwcomposer,
so I'm not totally sure that this fix is correct (rather then
returning the gralloc_handle_t's embadedded native_handle_t ptr).

But it seems something like this is needed.

Cc: Robert Foss 
Cc: Rob Herring 
Cc: Sean Paul 
Signed-off-by: John Stultz 
---
 android/gralloc_handle.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index 9cb5a5d..6e925c9 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -84,7 +84,7 @@ static inline struct gralloc_handle_t 
*gralloc_handle(buffer_handle_t handle)
 /**
  * Create a buffer handle.
  */
-static inline native_handle_t *gralloc_handle_create(int32_t width,
+static inline gralloc_handle_t *gralloc_handle_create(int32_t width,
  int32_t height,
  int32_t hal_format,
  int32_t usage)
@@ -107,5 +107,4 @@ static inline native_handle_t 
*gralloc_handle_create(int32_t width,
 
return handle;
 }
-
 #endif
-- 
2.7.4

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

[pull] radeon, amdgpu, amd ttm drm-next-4.17

[Alex Deucher]

Hi Dave,

Updates for 4.17.  Highlights:
- Continued cleanup and restructuring of powerplay
- Fetch VRAM type from vbios rather than hardcoding for SOC15 asics
- Allow ttm to drop its backing store when drivers don't need it
- DC bandwidth calc updates
- Enable DC backlight control pre-DCE11 asics
- Enable DC on all supported asics
- DC Fixes for planes due to the way our hw is ordered vs what drm expects
- DC CTM/regamma fixes
- Misc cleanup and bug fixes

The following changes since commit 963976cfe9c54d4d9e725e61c90c47a4af6b5ea2:

  Merge tag 'drm-intel-next-2018-03-08' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-14 14:53:01 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.17

for you to fetch changes up to 6da2b9332c572fcda94de9631f8fa514f574388a:

  amdgpu/dm: Default PRE_VEGA ASIC support to 'y' (2018-03-16 16:16:50 -0500)


Alex Deucher (9):
  drm/amdgpu: save/restore backlight level in legacy dce code
  drm/amdgpu/psp: add a few more fw load type checks
  drm/amdgpu: move firmware loading type setup to common code
  drm/amdgpu: use adev->firmware to determine whether to load the PSP module
  drm/amdgpu/soc15: always load the psp module
  drm/amdgpu: move getting pcie info to common code
  drm/amdgpu/powerplay/vega10: fix memory leak in error path
  drm/amdgpu: remove trailing whitespace from soc15ip.h
  drm/amdgpu/sdma4: use num_instances for clock/powergating config

Andrey Grodzovsky (2):
  drm/amd/powerplay: Fix KASAN user after free on driver unload.
  drm/amdgpu: Improve documentation of bo_ptr in amdgpu_bo_create_kernel

Anthony Koo (2):
  drm/amd/display: Implement stats logging
  drm/amd/display: Add variable refresh rate parameters to DC structures

Bhawanpreet Lakha (3):
  drm/amd/display: Fix takover from VGA mode
  drm/amd/display: Move DTRACE and dml_print defines
  drm/amd/display: Use MACROS instead of dm_logger

Christian König (11):
  drm/ttm: move ttm_tt defines into ttm_tt.h
  drm/ttm: add ttm_sg_tt_init
  drm/amdgpu: stop allocating a page array for prime shared BOs
  drm/ttm: add ttm_bo_pipeline_gutting
  drm/ttm: add bo as parameter to the ttm_tt_create callback
  drm/ttm: move initializing ttm->sg into ttm_tt_init_fields
  drm/amdgpu: drop the backing store when DMA-buf imports are evicted
  drm/amdgpu: initial validate the prime BOs into the CPU domain
  drm/amdgpu: explicit give BO type to amdgpu_bo_create
  drm/amdgpu: fix prime teardown order
  drm/radeon: fix prime teardown order

Clark Zheng (1):
  drm/amd/display: Refine disable VGA

Colin Ian King (1):
  drm/amd/pp: remove redundant pointer internal_buf

Dmytro Laktyushkin (2):
  drm/amd/display: update dce_calcs to latest version
  drm/amd/display: clean up dcn pplib notification call

Emily Deng (2):
  drm/amdgpu: Correct the place of amdgpu_pm_sysfs_fini
  drm/amdgpu: Correct the amdgpu_ucode_fini_bo place for Tonga

Eric Yang (2):
  drm/amd/display: fix check condition for edp power control
  drm/amd/display: early return if not in vga mode in disable_vga

Feifei Xu (1):
  drm/amdgpu/sdma4: Remove unused header file from sdma_v4_0.c

Harry Wentland (3):
  drm/amdgpu: Remove some unused elements from amdgpu_connector struct
  drm/amd/display: Check for HW blocks in HWSS, rather than DC core for 
cursor
  amdgpu/dm: Default PRE_VEGA ASIC support to 'y'

Hawking Zhang (1):
  drm/amdgpu: query vram type from atombios

Jerry (Fangzhi) Zuo (2):
  drm/amd/display: Allow passing of syspll id to get_smu_clock_info
  drm/amd/display: Use actual TG instance instead of pipe instance

Krunoslav Kovac (1):
  drm/amd/display: use HW hdr mult for brightness boost

Leo (Sunpeng) Li (3):
  drm/amd/display: Fix memleaks when atomic check fails.
  drm/amd/display: Use correct error codes
  drm/amd/display: Convert CTM to 2's complement

Michel Dänzer (2):
  drm/amdgpu/dce: Don't turn off DP sink when disconnected
  drm/radeon: Don't turn off DP sink when disconnected

Mikita Lipski (1):
  drm/amd/display: Enable backlight support for pre-DCE11 ASICs

Monk Liu (2):
  drm/amdgpu: implement mmio byte access helper for MB
  drm/amdgpu: refactoring mailbox to fix TDR handshake bugs(v2)

Oak Zeng (1):
  drm/amdgpu: Move IH clientid defs to separate file

Rex Zhu (23):
  drm/amd/pp: Simplified the avfs btc state on smu7
  drm/amd/pp: Fix memory leak in error path in smumgr
  drm/amd/pp: Clean up header file include
  drm/amd/pp: Delete is_smc_ram_running function on RV
  drm/amd/pp: Remove meanless return value check in RV
  drm/amd/pp: Add rv_read_arg_from_smc to smu backend function table
  drm/amd/pp: Mark internal functions as static in rv_smumgr.c
  

Re: [PATCH libdrm 4/4] meson: replace `if(compiles) have=true` with `have=compiles`

[Dylan Baker]

Quoting Eric Engestrom (2018-03-16 10:12:27)
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 0fe04a1411963c70cf80..74a541e8d835ae27c7f4 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -187,9 +187,8 @@ else
>  endif
>  dep_m = cc.find_library('m', required : false)
>  foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
> -  if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header))
> -config.set10('HAVE_' + header.underscorify().to_upper(), true)
> -  endif
> +  config.set('HAVE_' + header.underscorify().to_upper(),
> +cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header)))
>  endforeach
>  if cc.has_header_symbol('sys/sysmacros.h', 'major')
>config.set10('MAJOR_IN_SYSMACROS', true)
> -- 
> Cheers,
>   Eric
> 

for the series:
Reviewed-by: Dylan Baker 


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

Re: [DPU PATCH v2] drm/msm: Don't duplicate modeset_enables atomic helper

[Jeykumar Sankaran]

On 2018-03-16 12:45, Sean Paul wrote:
Instead, shuffle things around so we kickoff crtc after enabling 
encoder

during modesets. Also moves the vblank wait to after the frame.

Changes in v2:
- Remove the encoder.commit hack, it's not required (Jeykumar)

Cc: Jeykumar Sankaran 
Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   9 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |   8 +-
 drivers/gpu/drm/msm/msm_atomic.c | 132 ++-
 3 files changed, 19 insertions(+), 130 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a3ab6ed2bf1d..94fab2dcca5b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc 
*crtc,

DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);

+   if (msm_is_mode_seamless(>state->adjusted_mode) ||
+   msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
+   DPU_DEBUG("Skipping crtc enable, seamless mode\n");
+   return;
+   }
+
pm_runtime_get_sync(crtc->dev->dev);

drm_for_each_encoder(encoder, crtc->dev) {
@@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc 
*crtc,

DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE
|
DPU_POWER_EVENT_PRE_DISABLE,
dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
+
+   if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
+   drm_crtc_wait_one_vblank(crtc);
 }

 struct plane_state {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5ba345395b82..2c4c7fe1affe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -422,14 +422,14 @@ static void dpu_kms_prepare_commit(struct msm_kms
*kms,
dpu_encoder_prepare_commit(encoder);
 }

-static void dpu_kms_commit(struct msm_kms *kms,
-   struct drm_atomic_state *old_state)
+static void dpu_kms_commit(struct msm_kms *kms, struct 
drm_atomic_state

*state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state;
+   struct drm_crtc_state *crtc_state;
+   struct dpu_crtc_state *cstate;
int i;

-   for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (crtc->state->active) {
DPU_EVT32(DRMID(crtc));
dpu_crtc_commit_kickoff(crtc);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 5cfb80345052..f5794dce25dd 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,131 +84,6 @@ static void msm_atomic_wait_for_commit_done(
}
 }

-/**
- * msm_atomic_helper_commit_modeset_enables - modeset commit to enable
outputs
- * @dev: DRM device
- * @old_state: atomic state object with old state structures
- *
- * This function enables all the outputs with the new configuration 
which

had to
- * be turned off for the update.
- *
- * For compatibility with legacy crtc helpers this should be called 
after

- * drm_atomic_helper_commit_planes(), which is what the default commit
function
- * does. But drivers with different needs can group the modeset 
commits

together
- * and do the plane commits at the end. This is useful for drivers 
doing

runtime
- * PM since planes updates then only happen when the CRTC is actually
enabled.
- */
-static void msm_atomic_helper_commit_modeset_enables(struct drm_device
*dev,
-   struct drm_atomic_state *old_state)
-{
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state;
-   struct drm_crtc_state *new_crtc_state;
-   struct drm_connector *connector;
-   struct drm_connector_state *new_conn_state;
-   struct msm_drm_private *priv = dev->dev_private;
-   struct msm_kms *kms = priv->kms;
-   int bridge_enable_count = 0;
-   int i;
-
-   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
-   new_crtc_state, i) {
-   const struct drm_crtc_helper_funcs *funcs;
-
-   /* Need to filter out CRTCs where only planes change. */
-   if (!drm_atomic_crtc_needs_modeset(new_crtc_state))
-   continue;
-
-   if (!new_crtc_state->active)
-   continue;
-
-   if (msm_is_mode_seamless(_crtc_state->mode) ||
-   msm_is_mode_seamless_vrr(
-   _crtc_state->adjusted_mode))
-   continue;
-
-   funcs = crtc->helper_private;
-
-   if 

[PATCH] drm: Reduce object size of DRM_DEV_ uses

[Joe Perches]

These macros are similar to the DRM_ with the addition
of a struct device * to the arguments.

Convert the single drm_dev_printk function into 2 separate functions.
drm_dev_printk with a KERN_ * for generic use and drm_dev_dbg
for conditional masked use.

Remove the __func__ argument and use __builtin_return_address(0) to be
similar to the DRM_ macros uses.

Convert the DRM_DEV_ macros to remove now unnecessary arguments
and use a consistent style.

These macros are rarely used in the generic gpu/drm code so the code
size does not change much for a defconfig, but when more drivers are
enabled, there is ~4k savings.

Many of these macros have no existing use at all.

$ size -t drivers/gpu/drm/built-in.a | tail -1
1877530   44651 995 1923176  1d5868 (TOTALS)

$ size -t drivers/gpu/drm/built-in.a | tail -1
1877527   44651 995 1923173  1d5865 (TOTALS)

$ size -t drivers/gpu/drm/built-in.a | tail -1
171667502689238  108352 19964340130a1b4 (TOTALS)

$ size -t drivers/gpu/drm/built-in.a | tail -1
17162691734  108352 19968974130b3ce (TOTALS)

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_print.c | 37 +-
 include/drm/drm_print.h | 94 ++---
 2 files changed, 74 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 79abf6d5b4db..b25f98f33f6c 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -63,16 +63,34 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
-
 void drm_dev_printk(const struct device *dev, const char *level,
-   unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...)
+   const char *format, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, format);
+   vaf.fmt = format;
+   vaf.va = 
+
+   if (dev)
+   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
+  __builtin_return_address(0), );
+   else
+   printk("%s" "[" DRM_NAME ":%ps] %pV",
+  level, __builtin_return_address(0), );
+
+   va_end(args);
+}
+EXPORT_SYMBOL(drm_dev_printk);
+
+void drm_dev_dbg(const struct device *dev, unsigned int category,
+const char *format, ...)
 {
struct va_format vaf;
va_list args;
 
-   if (category != DRM_UT_NONE && !(drm_debug & category))
+   if (!(drm_debug & category))
return;
 
va_start(args, format);
@@ -80,14 +98,15 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
vaf.va = 
 
if (dev)
-   dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
-  );
+   dev_printk(KERN_DEBUG, dev, "[" DRM_NAME ":%ps] %pV",
+  __builtin_return_address(0), );
else
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
+   printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
+  __builtin_return_address(0), );
 
va_end(args);
 }
-EXPORT_SYMBOL(drm_dev_printk);
+EXPORT_SYMBOL(drm_dev_dbg);
 
 void drm_dbg(unsigned int category, const char *format, ...)
 {
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 3a40c5a3a5fa..e1a46e9991cc 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -196,10 +196,13 @@ static inline struct drm_printer drm_debug_printer(const 
char *prefix)
 #define DRM_UT_STATE   0x40
 #define DRM_UT_LEASE   0x80
 
-__printf(6, 7)
+__printf(3, 4)
 void drm_dev_printk(const struct device *dev, const char *level,
-   unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...);
+   const char *format, ...);
+__printf(3, 4)
+void drm_dev_dbg(const struct device *dev, unsigned int category,
+const char *format, ...);
+
 __printf(2, 3)
 void drm_dbg(unsigned int category, const char *format, ...);
 __printf(1, 2)
@@ -208,10 +211,7 @@ void drm_err(const char *format, ...);
 /* Macros to make printk easier */
 
 #define _DRM_PRINTK(once, level, fmt, ...) \
-   do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
-   } while (0)
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
 
 #define DRM_INFO(fmt, ...) \
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
@@ -234,8 +234,7 @@ void drm_err(const char *format, ...);
  * @fmt: printf() like format string.
  */
 #define 

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #7 from philipmor...@gmail.com ---
There are 3 physical motherboard sockets: HDMI, DVI DL, and D-SUB.
xrandr reports the D-SUB as DisplayPort-0.

In kernel versions before 4.10 I used to have to hack the i915 code as follows
 (in intel_hdmi.c):

@@ -849,7 +849,7 @@ static int hdmi_portclock_limit(struct intel_hdmi *hdmi,
bool respect_dvi_limit)
{
struct drm_device *dev = intel_hdmi_to_dev(hdmi);

-   if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
+   if (IS_G4X(dev))
   return 165000;
else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
   return 30;

After 4.10 came out the hack became unnecessary.

-- 
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 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #6 from Ville Syrjala  ---
(In reply to Alex Deucher from comment #5)
> (In reply to Christian König from comment #3)
> > What you can use is either an active DP to dual DVI converter (probably
> > rather expensive if such a thing even exists) or native DP/HDMI (if the
> > monitor has connectors for that).
> 
> They are actually relatively common for just these sorts of scenarios.  Not
> sure about cost however.
> 
> (In reply to philipmorant from comment #4)
> > Thanks for replies. My monitor is DVI DL only.
> > 
> > My old Haswell i5 4670 with HD4600 graphics was also single link DVI only
> > (https://communities.intel.com/thread/44135), and it worked at 60Hz. Could
> > somebody please explain why haswell can do it but raven can't ?
> 
> I'm not sure how the intel hw is designed.  I can't comment on exactly what
> is happening.  I suspect what is happening is that the intel driver is not
> validating the link requirements and treating the DVI port like HDMI and
> sending the high bandwidth mode over a single TMDS link.  The monitor just
> happens to accept it.

FYI in i915 we validate everything when enumerating the modes, but during a
modeset we allow the user mode to exceed the DP++ dongle and sink limitations
for just these sort of cases (source limitations we enforce always). The user
has manually added the out-of-spec mode so presumably they know what they're
doing...

Also we can't reliably tell what kind of connector is present on the board so
we treat DVI and HDMI the same. DP++ we treat a little special because we can't
actually read out the state of the CONFIG1 pin so we can't tell whether a type1
DVI DP++ dongle is present or not. So if we can't read out the dongle registers
and the connector *looks* like a DP++ in the video BIOS tables we assume the
dongle to be present. But again the user can still override this by forcing an
out-of-spec mode.

-- 
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 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
(In reply to Christian König from comment #3)
> What you can use is either an active DP to dual DVI converter (probably
> rather expensive if such a thing even exists) or native DP/HDMI (if the
> monitor has connectors for that).

They are actually relatively common for just these sorts of scenarios.  Not
sure about cost however.

(In reply to philipmorant from comment #4)
> Thanks for replies. My monitor is DVI DL only.
> 
> My old Haswell i5 4670 with HD4600 graphics was also single link DVI only
> (https://communities.intel.com/thread/44135), and it worked at 60Hz. Could
> somebody please explain why haswell can do it but raven can't ?

I'm not sure how the intel hw is designed.  I can't comment on exactly what is
happening.  I suspect what is happening is that the intel driver is not
validating the link requirements and treating the DVI port like HDMI and
sending the high bandwidth mode over a single TMDS link.  The monitor just
happens to accept it.

> 
> Otherwise I find myself assuming that the hardware is capable of DL DVI,
> just that the manufacturers aren't validating for it, ergo fixable in
> software.

No.  DL DVI requires two digital transmitters, one for each TMDS link.  We only
wire a single transmitter to each physical connector.  For DL DVI, you need two
transmitters connected to the physical connector.

> 
> I understand if AMD object to coding for something that hasn't been
> validated (I'd do the same myself).  Would it be possible alternatively to
> provide hints in log output or code comments or on a wiki somewhere, such
> that people in my position can hack the source themselves ?

You could try hacking the driver to treat the monitor as HDMI even through it's
DL DVI.  Maybe your monitor will accept the timing over a single TMDS link.

> 
> Secondly, even accepting the single link limitation, shouldn't it be
> possible to run at 33 refresh rate ?  I tried at 30 and got nothing.
> 

It depends on the hardware and the panel in the monitor.  The monitor hardware
may not like 30 Hz refresh rates.  

> Thirdly, why does amdgpu refer to the connection as HDMI-A-3 ?  There's no
> HDMI in the setup at all.

The display connectors are read from a table in the bios and are determined by
the OEM that designs the board.  It our case the OEM seems to have set it up as
3 HDMI connectors and a DP connector.  What physical connectors are actually on
the board?

-- 
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 libdrm 0/5] improve reuse implementation

[Xiong, James]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
>Daniel Vetter
>Sent: Friday, March 16, 2018 1:43 AM
>To: Xiong, James 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH libdrm 0/5] improve reuse implementation
>
>On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
>> From: "Xiong, James" 
>> 
>> With gem_reuse enabled, when a buffer size is different than the sizes 
>> of buckets, it is aligned to the next bucket's size, which means about 
>> 25% more memory than the requested is allocated in the worst senario. 
>> For example:
>> 
>> Orignal sizeActual
>> 32KB+1Byte  40KB
>> .
>> .
>> .
>> 8MB+1Byte   10MB
>> .
>> .
>> .
>> 96MB+1Byte  112MB
>> 
>> This is very memory expensive and make the reuse feature less 
>> favorable than it deserves to be.
>> 
>> This series aligns the reuse buffer size on page size instead to save 
>> memory. Performed gfxbench tests on Gen9 without LLC, the performances 
>> and reuse ratioes (reuse count/allocation count) were same as before, 
>> saved memory usage by 1% ~ 7%(gl_manhattan: peak allocated memory size 
>> was reduced from 448401408 to 419078144).
>> 
>> v2: split the patch to a series of small functional changes (Chris)
>
>Mesa gen driver stopped using the libdrm buffer allocator. The gen2/3 driver 
>still uses it, but I think that's not the one you benchmarked. The
>17.1 release was the first one with that change.
>
Thanks for the tip, Daniel. I tested it on mesa 13.0.5.
>I think you want to port your changes over to mesa to future proof it, merging 
>this to upstream makes little sense.
>-Daniel
I am not sure about mesa and other components that use embedded libdrm, at 
least for the project I am currently working on, though we have
our owner libdrm repo, we heavily rely on the open source community, and we 
keep an eye on the upstream and pull in fixes we think might help
 with our customers, actually that's the only way we merge a libdrm patch to 
our repo. I think it would help to merge the patches to upstream(only
 if the patches make sense of course) so that the component owner can decide 
themselves whether to take and rebase it to their own, IMHO.
>
>> 
>> Xiong, James (5):
>>   drm: add a macro DRMLISTFOREACHENTRYREVERSE
>>   intel: reorganize internal function
>>   intel: get a cached bucket by size
>>   intel: get a cached buffer by size for reuse
>>   intel: purge cached bucket when its cached buffer is evicted
>> 
>>  intel/intel_bufmgr_gem.c | 180 
>> +--
>>  libdrm_lists.h   |   6 ++
>>  2 files changed, 100 insertions(+), 86 deletions(-)
>> 
>> --
>> 2.7.4
>> 
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>___
>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

[DPU PATCH v2] drm/msm: Don't duplicate modeset_enables atomic helper

[Sean Paul]

Instead, shuffle things around so we kickoff crtc after enabling encoder
during modesets. Also moves the vblank wait to after the frame.

Changes in v2:
- Remove the encoder.commit hack, it's not required (Jeykumar)

Cc: Jeykumar Sankaran 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   9 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |   8 +-
 drivers/gpu/drm/msm/msm_atomic.c | 132 ++-
 3 files changed, 19 insertions(+), 130 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index a3ab6ed2bf1d..94fab2dcca5b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);
 
+   if (msm_is_mode_seamless(>state->adjusted_mode) ||
+   msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
+   DPU_DEBUG("Skipping crtc enable, seamless mode\n");
+   return;
+   }
+
pm_runtime_get_sync(crtc->dev->dev);
 
drm_for_each_encoder(encoder, crtc->dev) {
@@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE |
DPU_POWER_EVENT_PRE_DISABLE,
dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
+
+   if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
+   drm_crtc_wait_one_vblank(crtc);
 }
 
 struct plane_state {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5ba345395b82..2c4c7fe1affe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -422,14 +422,14 @@ static void dpu_kms_prepare_commit(struct msm_kms *kms,
dpu_encoder_prepare_commit(encoder);
 }
 
-static void dpu_kms_commit(struct msm_kms *kms,
-   struct drm_atomic_state *old_state)
+static void dpu_kms_commit(struct msm_kms *kms, struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state;
+   struct drm_crtc_state *crtc_state;
+   struct dpu_crtc_state *cstate;
int i;
 
-   for_each_old_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (crtc->state->active) {
DPU_EVT32(DRMID(crtc));
dpu_crtc_commit_kickoff(crtc);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5cfb80345052..f5794dce25dd 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,131 +84,6 @@ static void msm_atomic_wait_for_commit_done(
}
 }
 
-/**
- * msm_atomic_helper_commit_modeset_enables - modeset commit to enable outputs
- * @dev: DRM device
- * @old_state: atomic state object with old state structures
- *
- * This function enables all the outputs with the new configuration which had 
to
- * be turned off for the update.
- *
- * For compatibility with legacy crtc helpers this should be called after
- * drm_atomic_helper_commit_planes(), which is what the default commit function
- * does. But drivers with different needs can group the modeset commits 
together
- * and do the plane commits at the end. This is useful for drivers doing 
runtime
- * PM since planes updates then only happen when the CRTC is actually enabled.
- */
-static void msm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
-   struct drm_atomic_state *old_state)
-{
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *old_crtc_state;
-   struct drm_crtc_state *new_crtc_state;
-   struct drm_connector *connector;
-   struct drm_connector_state *new_conn_state;
-   struct msm_drm_private *priv = dev->dev_private;
-   struct msm_kms *kms = priv->kms;
-   int bridge_enable_count = 0;
-   int i;
-
-   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
-   new_crtc_state, i) {
-   const struct drm_crtc_helper_funcs *funcs;
-
-   /* Need to filter out CRTCs where only planes change. */
-   if (!drm_atomic_crtc_needs_modeset(new_crtc_state))
-   continue;
-
-   if (!new_crtc_state->active)
-   continue;
-
-   if (msm_is_mode_seamless(_crtc_state->mode) ||
-   msm_is_mode_seamless_vrr(
-   _crtc_state->adjusted_mode))
-   continue;
-
-   funcs = crtc->helper_private;
-
-   if (crtc->state->enable) {
-   DRM_DEBUG_ATOMIC("enabling [CRTC:%d]\n",
-  

Re: [PATCH] drm/doc: Put all driver docs into a separate chapter

[Alex Deucher]

On Fri, Mar 16, 2018 at 3:59 AM, Daniel Vetter  wrote:
> We have quite a few driver docs now, which is great, but having them
> all in the top-level gpu documentation chapter makes it harder to spot
> the core/shared bits.
>
> Stuff them into a separate chapter and ecourage people to add even
> more!
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  Documentation/gpu/drivers.rst | 21 +
>  Documentation/gpu/index.rst   |  9 +
>  2 files changed, 22 insertions(+), 8 deletions(-)
>  create mode 100644 Documentation/gpu/drivers.rst
>
> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
> new file mode 100644
> index ..e8c84419a2a1
> --- /dev/null
> +++ b/Documentation/gpu/drivers.rst
> @@ -0,0 +1,21 @@
> +
> +GPU Driver Documentation
> +
> +
> +.. toctree::
> +
> +   i915
> +   meson
> +   pl111
> +   tegra
> +   tinydrm
> +   tve200
> +   vc4
> +   bridge/dw-hdmi
> +
> +.. only::  subproject and html
> +
> +   Indices
> +   ===
> +
> +   * :ref:`genindex`
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c36586dad29d..00288f34c5a6 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -10,16 +10,9 @@ Linux GPU Driver Developer's Guide
> drm-kms
> drm-kms-helpers
> drm-uapi
> -   i915
> -   meson
> -   pl111
> -   tegra
> -   tinydrm
> -   tve200
> -   vc4
> +   drivers
> vga-switcheroo
> vgaarbiter
> -   bridge/dw-hdmi
> todo
>
>  .. only::  subproject and html
> --
> 2.16.2
>
> ___
> 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

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

[bugzilla-daemon]

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

--- Comment #41 from Alex Deucher (alexdeuc...@gmail.com) ---
Maybe something will jump out if we look at the register differences?  You can
use radeonreg (https://cgit.freedesktop.org/~airlied/radeontool/) to dump the
display registers. e.g., radeonreg regs dce5 > working.out.  And then diff the
working and non-working cases.  At least if we can narrow down the register(s),
we can trace that back to the code.

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

[PATCH] drm: Don't pass the index to drm_property_add_enum()

[Ville Syrjala]

From: Ville Syrjälä 

drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.

Cc: Patrik Jakobsson 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c   |  6 +++---
 drivers/gpu/drm/drm_property.c| 27 +--
 drivers/gpu/drm/gma500/cdv_device.c   |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +---
 include/drm/drm_property.h|  2 +-
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..dfc8ca1e9413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
goto nomem;
 
for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property, i,
+   drm_property_add_enum(dev->mode_config.tv_mode_property,
  i, modes[i]);
 
dev->mode_config.tv_brightness_property =
@@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
-   int i, j = 0;
+   int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;
 
@@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
if (!(BIT(i) & scaling_mode_mask))
continue;
 
-   ret = drm_property_add_enum(scaling_mode_property, j++,
+   ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);
 
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 8f4672daac7f..1f8031e30f53 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev,
return NULL;
 
for (i = 0; i < num_values; i++) {
-   ret = drm_property_add_enum(property, i,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret, index = 0;
+   int i, ret;
int num_values = hweight64(supported_bits);
 
flags |= DRM_MODE_PROP_BITMASK;
@@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
if (!(supported_bits & (1ULL << props[i].type)))
continue;
 
-   if (WARN_ON(index >= num_values)) {
-   drm_property_destroy(dev, property);
-   return NULL;
-   }
-
-   ret = drm_property_add_enum(property, index++,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -376,7 +371,6 @@ EXPORT_SYMBOL(drm_property_create_bool);
 /**
  * drm_property_add_enum - add a possible value to an enumeration property
  * @property: enumeration property to change
- * @index: index of the new enumeration
  * @value: value of the new enumeration
  * @name: symbolic name of the new enumeration
  *
@@ -388,10 +382,11 @@ EXPORT_SYMBOL(drm_property_create_bool);
  * Returns:
  * Zero on success, error code on failure.
  */
-int drm_property_add_enum(struct drm_property *property, int index,
+int drm_property_add_enum(struct drm_property *property,
  uint64_t value, const char *name)
 {
struct drm_property_enum *prop_enum;
+   int index = 0;
 
if (WARN_ON(strlen(name) 

[Bug 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
Does disabling the Intel gfx chip or booting with the AMD card as the primary
help?  Can you also try booting with amdgpu.dc=1?

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher  ---
(In reply to Edward Kigwana from comment #5)
> options msi=1 exp_hw_support=0 ppfeaturemask=0

The msi and exp_hw_support shouldn't have any effect in your case and
ppfeaturemask is pretty much irrelevant if dpm is disabled.

-- 
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 1/2] dt-bindings: Document qcom,adreno-gmu

[Jordan Crouse]

Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.

Signed-off-by: Jordan Crouse 
---
 .../devicetree/bindings/display/msm/gmu.txt| 54 ++
 .../devicetree/bindings/display/msm/gpu.txt| 10 +++-
 2 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..f65bb49fff36
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,54 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible:
+  * "qcom,adreno-gmu"
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+  * "gmu"
+  * "gmu_pdc"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+  * "hfi"
+  * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+   * "gmu"
+   * "cxo"
+   * "axi"
+   * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+   ...
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+   ;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+   <_gpucc GPU_CC_CXO_CLK>,
+   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   i   operating-points-v2 = <_opp_table>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..544a7510166b 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,12 +8,18 @@ Required properties:
   with the chip-id.
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+
+Optional properties.
+- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
+  newer with a GMU attached do not have direct clock control from the CPU and
+  do not need to provide clock properties.
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks can be provided:
   * "core"
   * "iface"
   * "mem_iface"
+- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
+  control the power for the GPU
 
 Example:
 
-- 
2.16.1

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

[v2 PATCH 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Jordan Crouse]

(resend because I forgot to CC everybody on the patches)

Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the companion
arm-smmu-v2 compatible SMMU.

This builds on the following dependencies -
https://patchwork.kernel.org/patch/10286369/ - bindings for qcom,level
https://patchwork.kernel.org/patch/10281599/ - qcom,smmu-v2 bindings

Please refer to https://patchwork.freedesktop.org/series/37428/ for the driver
code.

[v2 - changed qcom,arc-level to qcom,level following discussion with Viresh;
change gmu phandle to qcom,gmu per Rob]

Jordan Crouse (2):
  dt-bindings: Document qcom,adreno-gmu
  arm64: dts: sdm845: Add gpu and gmu device nodes

 .../devicetree/bindings/display/msm/gmu.txt|  54 ++
 .../devicetree/bindings/display/msm/gpu.txt|  10 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi   | 119 +
 3 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

-- 
2.16.1

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

[PATCH 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Jordan Crouse]

Add the nodes to describe the Adreno GPU and GMU devices.

Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 119 +++
 1 file changed, 119 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 16b5f356ec96..854da6604417 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -312,4 +312,123 @@
};
};
};
+
+   adreno_smmu: arm,smmu-adreno@504 {
+   compatible = "qcom,msm8996-smmu-v2";
+   reg = <0x504 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = <_gcc GCC_GPU_MEMNOC_GFX_CLK>,
+<_gcc GCC_GPU_CFG_AHB_CLK>;
+   clock-names = "bus", "iface";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   };
+
+   gpu_opp_table: adreno-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-71000 {
+   opp-hz = /bits/ 64 <71000>;
+   qcom,level = <416>;
+   };
+
+   opp-67500 {
+   opp-hz = /bits/ 64 <67500>;
+   qcom,level = <384>;
+   };
+
+   opp-59600 {
+   opp-hz = /bits/ 64 <59600>;
+   qcom,level = <320>;
+   };
+
+   opp-52000 {
+   opp-hz = /bits/ 64 <52000>;
+   qcom,level = <256>;
+   };
+
+   opp-41400 {
+   opp-hz = /bits/ 64 <41400>;
+   qcom,level = <192>;
+   };
+
+   opp-34200 {
+   opp-hz = /bits/ 64 <34200>;
+   qcom,level = <128>;
+   };
+
+   opp-25700 {
+   opp-hz = /bits/ 64 <25700>;
+   qcom,level = <64>;
+   };
+   };
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are controlled
+* entirely by the GMU
+*/
+
+   interrupts = <0 300 0>;
+   interrupt-names = "kgsl_3d0_irq";
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   gmu = <>;
+   };
+
+   gmu_opp_table: adreno-gmu-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   qcom,level = <128>;
+   };
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   qcom,level = <48>;
+   };
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>, <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+   <_gpucc GPU_CC_CXO_CLK>,
+   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+   };
 };
-- 
2.16.1

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

Re: [PATCH v8 07/11] drm: Handle aspect-ratio info in getblob

[kbuild test robot]

Hi Ankit,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180309]
[also build test WARNING on v4.16-rc5]
[cannot apply to linus/master v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nautiyal-Ankit-K/Aspect-ratio-support-in-DRM-layer/20180316-204825
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/drm_property.c:776:71: sparse: incorrect type in argument 2 
>> (different address spaces) @@expected struct drm_mode_modeinfo *umode @@ 
>>got struct drm_mode_mstruct drm_mode_modeinfo *umode @@
   drivers/gpu/drm/drm_property.c:776:71:expected struct drm_mode_modeinfo 
*umode
   drivers/gpu/drm/drm_property.c:776:71:got struct drm_mode_modeinfo 
[noderef] *mode

vim +776 drivers/gpu/drm/drm_property.c

   751  
   752  int drm_mode_getblob_ioctl(struct drm_device *dev,
   753 void *data, struct drm_file *file_priv)
   754  {
   755  struct drm_mode_get_blob *out_resp = data;
   756  struct drm_property_blob *blob;
   757  int ret = 0;
   758  
   759  if (!drm_core_check_feature(dev, DRIVER_MODESET))
   760  return -EINVAL;
   761  
   762  blob = drm_property_lookup_blob(dev, out_resp->blob_id);
   763  if (!blob)
   764  return -ENOENT;
   765  
   766  if (out_resp->length == blob->length) {
   767  if (copy_to_user(u64_to_user_ptr(out_resp->data),
   768   blob->data,
   769   blob->length)) {
   770  ret = -EFAULT;
   771  goto unref;
   772  }
   773  if (blob->is_video_mode) {
   774  struct drm_mode_modeinfo __user *mode =
   775  u64_to_user_ptr(out_resp->data);
 > 776  drm_mode_filter_aspect_ratio_flags(file_priv, 
 > mode);
   777  }
   778  }
   779  out_resp->length = blob->length;
   780  unref:
   781  drm_property_blob_put(blob);
   782  
   783  return ret;
   784  }
   785  

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

[v2 PATCH 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU

[Jordan Crouse]

Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the companion
arm-smmu-v2 compatible SMMU.

This builds on the following dependencies -
https://patchwork.kernel.org/patch/10286369/ - bindings for qcom,level
https://patchwork.kernel.org/patch/10281599/ - qcom,smmu-v2 bindings

Please refer to https://patchwork.freedesktop.org/series/37428/ for the driver
code.

[v2 - changed qcom,arc-level to qcom,level following discussion with Viresh;
change gmu phandle to qcom,gmu per Rob]

Jordan Crouse (2):
  dt-bindings: Document qcom,adreno-gmu
  arm64: dts: sdm845: Add gpu and gmu device nodes

 .../devicetree/bindings/display/msm/gmu.txt|  54 ++
 .../devicetree/bindings/display/msm/gpu.txt|  10 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi   | 119 +
 3 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

-- 
2.16.1

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

[PATCH 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Jordan Crouse]

Add the nodes to describe the Adreno GPU and GMU devices.

Signed-off-by: Jordan Crouse 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 119 +++
 1 file changed, 119 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 16b5f356ec96..854da6604417 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -312,4 +312,123 @@
};
};
};
+
+   adreno_smmu: arm,smmu-adreno@504 {
+   compatible = "qcom,msm8996-smmu-v2";
+   reg = <0x504 0x1>;
+   #iommu-cells = <1>;
+   #global-interrupts = <2>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = <_gcc GCC_GPU_MEMNOC_GFX_CLK>,
+<_gcc GCC_GPU_CFG_AHB_CLK>;
+   clock-names = "bus", "iface";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   };
+
+   gpu_opp_table: adreno-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-71000 {
+   opp-hz = /bits/ 64 <71000>;
+   qcom,level = <416>;
+   };
+
+   opp-67500 {
+   opp-hz = /bits/ 64 <67500>;
+   qcom,level = <384>;
+   };
+
+   opp-59600 {
+   opp-hz = /bits/ 64 <59600>;
+   qcom,level = <320>;
+   };
+
+   opp-52000 {
+   opp-hz = /bits/ 64 <52000>;
+   qcom,level = <256>;
+   };
+
+   opp-41400 {
+   opp-hz = /bits/ 64 <41400>;
+   qcom,level = <192>;
+   };
+
+   opp-34200 {
+   opp-hz = /bits/ 64 <34200>;
+   qcom,level = <128>;
+   };
+
+   opp-25700 {
+   opp-hz = /bits/ 64 <25700>;
+   qcom,level = <64>;
+   };
+   };
+
+   gpu@500 {
+   compatible = "qcom,adreno-630.2", "qcom,adreno";
+   #stream-id-cells = <16>;
+
+   reg = <0x500 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   /*
+* Look ma, no clocks! The GPU clocks and power are controlled
+* entirely by the GMU
+*/
+
+   interrupts = <0 300 0>;
+   interrupt-names = "kgsl_3d0_irq";
+
+   iommus = <_smmu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   gmu = <>;
+   };
+
+   gmu_opp_table: adreno-gmu-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   qcom,level = <128>;
+   };
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   qcom,level = <48>;
+   };
+   };
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>, <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+   <_gpucc GPU_CC_CXO_CLK>,
+   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   operating-points-v2 = <_opp_table>;
+   };
 };
-- 
2.16.1

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

[PATCH 1/2] dt-bindings: Document qcom,adreno-gmu

[Jordan Crouse]

Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.

Signed-off-by: Jordan Crouse 
---
 .../devicetree/bindings/display/msm/gmu.txt| 54 ++
 .../devicetree/bindings/display/msm/gpu.txt| 10 +++-
 2 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..f65bb49fff36
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,54 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible:
+  * "qcom,adreno-gmu"
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+  * "gmu"
+  * "gmu_pdc"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+  * "hfi"
+  * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+   * "gmu"
+   * "cxo"
+   * "axi"
+   * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+   ...
+
+   gmu: gmu@506a000 {
+   compatible="qcom,adreno-gmu";
+
+   reg = <0x506a000 0x3>,
+   <0xb20 0x30>;
+   reg-names = "gmu", "gmu_pdc";
+
+   interrupts = ,
+   ;
+   interrupt-names = "hfi", "gmu";
+
+   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+   <_gpucc GPU_CC_CXO_CLK>,
+   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+   clock-names = "gmu", "cxo", "axi", "memnoc";
+
+   power-domains = <_gpucc GPU_CX_GDSC>;
+   iommus = <_smmu 5>;
+
+   i   operating-points-v2 = <_opp_table>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..544a7510166b 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,12 +8,18 @@ Required properties:
   with the chip-id.
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+
+Optional properties.
+- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
+  newer with a GMU attached do not have direct clock control from the CPU and
+  do not need to provide clock properties.
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks can be provided:
   * "core"
   * "iface"
   * "mem_iface"
+- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
+  control the power for the GPU
 
 Example:
 
-- 
2.16.1

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

Re: [PATCH 1/2] dt-bindings: Document qcom,adreno-gmu

[Jordan Crouse]

On Mon, Mar 05, 2018 at 01:38:59PM -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 3:56 PM, Jordan Crouse  wrote:
> > Document the device tree bindings for the Adreno GMU device
> > available on Adreno a6xx targets.
> >
> > Change-Id: I3cfd5fb35ab0045e39905ff12393006e60f1a124
> 
> Gerrit!
> 
> > Signed-off-by: Jordan Crouse 
> > ---
> >  .../devicetree/bindings/display/msm/gmu.txt| 54 
> > ++
> >  .../devicetree/bindings/display/msm/gpu.txt| 10 +++-
> >  2 files changed, 62 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > new file mode 100644
> > index ..f65bb49fff36
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > @@ -0,0 +1,54 @@
> > +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> > +
> > +The GMU is a programmable power controller for the GPU. the CPU controls 
> > the
> > +GMU which in turn handles power controls for the GPU.
> > +
> > +Required properties:
> > +- compatible:
> > +  * "qcom,adreno-gmu"
> 
> Kind of generic. All the features are discoverable?

I was just prepping a new version and I realized I never responded to this.
Sorry.

Yes, all the features are discoverable. Since the GMU is on the same die as the
GPU we would use the GPU revision as the criteria for applying hardware
workarounds and whatnot. I can't think of any current situation that would
require us to uniquely identify the GMU from DT.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 3/4] meson,configure: always define UDEV

[Eric Engestrom]

On March 16, 2018 5:25:12 PM UTC, Emil Velikov  wrote:
> On 16 March 2018 at 17:12, Eric Engestrom 
> wrote:
> > Signed-off-by: Eric Engestrom 
> > ---
> >  configure.ac | 2 ++
> >  meson.build  | 2 +-
> >  xf86drm.c| 8 
> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 14baa1c87f9078f336fa..619af49726d198c5d685 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -347,6 +347,8 @@ AC_SUBST(PCIACCESS_LIBS)
> >
> >  if test "x$UDEV" = xyes; then
> > AC_DEFINE(UDEV, 1, [Have UDEV support])
> > +else
> > +   AC_DEFINE(UDEV, 0)
> >  fi
> >
> >  AC_CANONICAL_HOST
> > diff --git a/meson.build b/meson.build
> > index 8d4d38b46ebcf75b9fb6..0fe04a1411963c70cf80 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -165,9 +165,9 @@ if _libkms != 'false'
> >with_libkms = _libkms == 'true' or ['linux', 'freebsd',
> 'dragonfly'].contains(host_machine.system())
> >  endif
> >
> > +config.set10('UDEV', with_udev)
> This looks fine.
> 
> 
> >  if with_udev
> >dep_udev = dependency('udev')
> > -  config.set10('UDEV', true)
> >  else
> >dep_udev = []
> >  endif
> Does this pull udev.pc or libudev.pc?

udev.pc, which I think is libudev (not on a computer right now, too complicated 
to double check)

> 
> In either case the whole thing can go - see
> 0ec7252a1deba3bac78b5ba1ebd2898f6bbf0332 + parent commit.

Sure; I'll double check that this is true for meson as well, and make another 
patch atop this series for that next week :)

> 
> The series is
> Reviewed-by: Emil Velikov 

Thanks; I'll push it next week though :)

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

[PATCH 1/2] drm/msm: Add generated headers for A6XX

[Jordan Crouse]

From: Sharat Masetty 

Add initial register headers for A6XX targets.

Signed-off-by: Sharat Masetty 
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h |  382 +++
 2 files changed, 1982 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
new file mode 100644
index ..17d12414f347
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -0,0 +1,1600 @@
+#ifndef A6XX_XML
+#define A6XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://github.com/freedreno/envytools/
+git clone https://github.com/freedreno/envytools.git
+
+The rules-ng-ng source files this header was generated from are:
+- /local3/projects/drm/envytools/rnndb//adreno.xml   (501 
bytes, from 2017-11-20 17:36:01)
+- /local3/projects/drm/envytools/rnndb//freedreno_copyright.xml  (   1572 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/a2xx.xml  (  32901 
bytes, from 2016-10-24 21:12:27)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_common.xml (  11792 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/adreno_pm4.xml(  17205 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a3xx.xml  (  83693 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a4xx.xml  ( 110372 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a5xx.xml  (  66793 
bytes, from 2017-11-17 23:22:22)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx.xml  (  44551 
bytes, from 2017-11-20 19:30:19)
+- /local3/projects/drm/envytools/rnndb//adreno/a6xx_gmu.xml  (  10431 
bytes, from 2017-11-20 17:59:44)
+- /local3/projects/drm/envytools/rnndb//adreno/ocmem.xml (   1773 
bytes, from 2016-10-24 21:12:27)
+
+Copyright (C) 2013-2017 by the following authors:
+- Rob Clark  (robclark)
+- Ilia Mirkin  (imirkin)
+
+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 (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a6xx_cp_perfcounter_select {
+   PERF_CP_ALWAYS_COUNT = 0,
+};
+
+enum a6xx_event_write {
+   PC_CCU_INVALIDATE_DEPTH = 24,
+   PC_CCU_INVALIDATE_COLOR = 25,
+};
+
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPU_IDLE 0x0001
+#define A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR  0x0002
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW   0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_GPC_ERROR0x0080
+#define A6XX_RBBM_INT_0_MASK_CP_SW 0x0100
+#define A6XX_RBBM_INT_0_MASK_CP_HW_ERROR   0x0200
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_DEPTH_TS 0x0400
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_FLUSH_COLOR_TS 0x0800
+#define A6XX_RBBM_INT_0_MASK_CP_CCU_RESOLVE_TS 0x1000
+#define A6XX_RBBM_INT_0_MASK_CP_IB20x2000
+#define A6XX_RBBM_INT_0_MASK_CP_IB10x4000
+#define A6XX_RBBM_INT_0_MASK_CP_RB 0x8000
+#define A6XX_RBBM_INT_0_MASK_CP_RB_DONE_TS 0x0002
+#define A6XX_RBBM_INT_0_MASK_CP_WT_DONE_TS 0x0004
+#define A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS 0x0010
+#define A6XX_RBBM_INT_0_MASK_RBBM_ATB_BUS_OVERFLOW 0x0040
+#define A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT  0x0080
+#define 

[PATCH 2/2] drm/msm: Add A6XX device support

[Jordan Crouse]

Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself.  Add support for the
A6XX core code, the GMU and the HFI (hardware firmware interface)
queue that the CPU uses to communicate with the GMU.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1225 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  808 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 11 files changed, 2838 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..4affc665c0de 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -10,6 +10,9 @@ msm-y := \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
adreno/a5xx_preempt.o \
+   adreno/a6xx_gpu.o \
+   adreno/a6xx_gmu.o \
+   adreno/a6xx_hfi.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
new file mode 100644
index ..9d72f5a6d2ba
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -0,0 +1,1225 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "a6xx_gpu.h"
+#include "a6xx_gmu.xml.h"
+
+static irqreturn_t a6xx_gmu_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_STATUS);
+   gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, status);
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_WDOG_BITE) {
+   dev_err_ratelimited(gmu->dev, "GMU watchdog expired\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   if (status &  A6XX_GMU_AO_HOST_INTERRUPT_STATUS_HOST_AHB_BUS_ERROR)
+   dev_err_ratelimited(gmu->dev, "GMU AHB bus error\n");
+
+   if (status & A6XX_GMU_AO_HOST_INTERRUPT_STATUS_FENCE_ERR)
+   dev_err_ratelimited(gmu->dev, "GMU fence error: 0x%x\n",
+   gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS));
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t a6xx_hfi_irq(int irq, void *data)
+{
+   struct a6xx_gmu *gmu = data;
+   u32 status;
+
+   status = gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO);
+   gmu_write(gmu, REG_A6XX_GMU_GMU2HOST_INTR_CLR, status);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_MSGQ)
+   tasklet_schedule(>hfi_tasklet);
+
+   if (status & A6XX_GMU_GMU2HOST_INTR_INFO_CM3_FAULT) {
+   dev_err_ratelimited(gmu->dev, "GMU firmware fault\n");
+
+   /* Temporary until we can recover safely */
+   BUG();
+   }
+
+   return IRQ_HANDLED;
+}
+
+/* Check to see if the GX rail is still powered */
+static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+{
+   u32 val  = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+   return !(val &
+   (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF |
+   A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
+}
+
+static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
+{
+   u32 val;
+   int local = gmu->idle_level;
+
+   /* SPTP and IFPC both report as IFPC */
+   if (gmu->idle_level == GMU_IDLE_STATE_SPTP)
+   local = GMU_IDLE_STATE_IFPC;
+
+   val = gmu_read(gmu, REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE);
+
+   if (val == local) {
+   if (gmu->idle_level != GMU_IDLE_STATE_IFPC ||
+   !a6xx_gmu_gx_is_on(gmu))
+   return true;
+   }
+
+   return false;
+}
+
+/* Wait for the GMU to get to its most idle state */
+int a6xx_gmu_wait_for_idle(struct a6xx_gpu *a6xx_gpu)
+{
+   struct a6xx_gmu *gmu = _gpu->gmu;
+
+   return 

[v3 RFC 0/2] drm/msm: Add support for Adreno a6xx

[Jordan Crouse]

This is an RFC for the initial version of a6xx support for the Adreno a6xx GPU
family as found on the sdm845 SoC.  This code is ahead of most of the rest of
the sdm845 code that would be needed to actually bring up a device and it is
definitely far in advance of any user side support for the a6xx GPU so this is
mainly just a chance to look over the code structure and get a feel for the
direction that the hardware is going in.

The a6xx GPU is an iteration of the a5xx family so most of the GPU side code
looks pretty close to the same except for the usual register differences. The
big different is in power control.  On the a5xx there was a rudimentary device
called the GMU that did some basic power stuff but left most of the complexity
to the kernel.  On the a6xx the power complexity is being moved to a component
called the GMU (graphics management unit).

The kernel is responsible for powering the GMU and in turn the GMU is
responsible for powering the GPU and handling power collapse and advance power
saving techniques. Of course the devil is in the details and what we save in
power management complexity is unfortunately replaced by the complexity involved
in communicating with and controlling the GMU.

This version stack depends on the following dependencies:

https://patchwork.kernel.org/patch/10286375/ - dev_pm_opp_get_of_node
https://patchwork.kernel.org/patch/10283073/ - command DB driver
https://patchwork.kernel.org/patch/10281613/ - smmu pm_runtime/sleep opps

[v3 - fix inverted register definition for GMU_SPTPRAC_CLK_STATUS; fix incorrect
register check in a5xx_gmu_gx_is_on(), use dev_pm_opp_get_of_node() from
Rajendra and Viresh to read the qcom,level from the device tree; read qcom,level
from the DT to get the voltage level to pass to the GMU, fix issues
identified by smatch]

[v2 - addressed comments from Lucas Stach; added pm_runtime_get_supplier calls
for accesses to the GMU IOMMU; moved to SPDX headers for new files]

Jordan Crouse (1):
  drm/msm: Add A6XX device support

Sharat Masetty (1):
  drm/msm: Add generated headers for A6XX

 drivers/gpu/drm/msm/Makefile   |3 +
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  | 1600 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 1225 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  162 +++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h  |  382 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  808 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   60 ++
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  |  435 
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  127 +++
 drivers/gpu/drm/msm/adreno/adreno_device.c |   12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|5 +-
 drivers/gpu/drm/msm/msm_gpu.c  |2 +-
 13 files changed, 4820 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_hfi.h

-- 
2.16.1

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

[radeon-alex:drm-next-4.17-wip 83/87] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:333:36: sparse: cast to restricted __le32

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   61deb7d0941d1e3ffee0d799396ac93b0e90
commit: 34e40f6338c730572874bc3d6fe330c7f2b63013 [83/87] drm/amd/pp: Rename 
file name cz_* to smu8_*
reproduce:
# apt-get install sparse
git checkout 34e40f6338c730572874bc3d6fe330c7f2b63013
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:333:36: sparse: 
>> cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:336:33: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:339:36: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:342:38: sparse: 
cast to restricted __le32
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:345:35: sparse: 
>> cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:361:34: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:366:27: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:369:29: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:374:41: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:380:30: sparse: 
cast to restricted __le16
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:396:13: sparse: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:1840:5: sparse: 
symbol 'smu8_dpm_update_uvd_dpm' was not declared. Should it be static?
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c:1986:5: sparse: 
symbol 'smu8_init_function_pointers' was not declared. Should it be static?

vim +333 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu8_hwmgr.c

bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
307  
47ce4a9f drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Rex Zhu2018-03-14  
308  static int smu8_get_system_info_data(struct pp_hwmgr *hwmgr)
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
309  {
47ce4a9f drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Rex Zhu2018-03-14  
310  struct smu8_hwmgr *data = hwmgr->backend;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
311  ATOM_INTEGRATED_SYSTEM_INFO_V1_9 *info = NULL;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
312  uint32_t i;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
313  int result = 0;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
314  uint8_t frev, crev;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
315  uint16_t size;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
316  
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
317  info = (ATOM_INTEGRATED_SYSTEM_INFO_V1_9 *) cgs_atom_get_data_table(
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
318  hwmgr->device,
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
319  GetIndexIntoMasterTable(DATA, IntegratedSystemInfo),
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
320  , , );
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
321  
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
322  if (crev != 9) {
b5c11b8e drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Huang Rui  2016-12-26  
323  pr_err("Unsupported IGP table: %d %d\n", frev, crev);
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
324  return -EINVAL;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
325  }
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
326  
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
327  if (info == NULL) {
b5c11b8e drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Huang Rui  2016-12-26  
328  pr_err("Could not retrieve the Integrated System Info 
Table!\n");
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
329  return -EINVAL;
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
330  }
bdecc20a drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Jammy Zhou 2015-07-22  
331  
47ce4a9f drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c Rex Zhu2018-03-14  
332  data->sys_info.bootup_uma_clock =
bdecc20a 

Re: [PATCH libdrm 3/4] meson,configure: always define UDEV

[Emil Velikov]

On 16 March 2018 at 17:12, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>  configure.ac | 2 ++
>  meson.build  | 2 +-
>  xf86drm.c| 8 
>  3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 14baa1c87f9078f336fa..619af49726d198c5d685 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -347,6 +347,8 @@ AC_SUBST(PCIACCESS_LIBS)
>
>  if test "x$UDEV" = xyes; then
> AC_DEFINE(UDEV, 1, [Have UDEV support])
> +else
> +   AC_DEFINE(UDEV, 0)
>  fi
>
>  AC_CANONICAL_HOST
> diff --git a/meson.build b/meson.build
> index 8d4d38b46ebcf75b9fb6..0fe04a1411963c70cf80 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -165,9 +165,9 @@ if _libkms != 'false'
>with_libkms = _libkms == 'true' or ['linux', 'freebsd', 
> 'dragonfly'].contains(host_machine.system())
>  endif
>
> +config.set10('UDEV', with_udev)
This looks fine.


>  if with_udev
>dep_udev = dependency('udev')
> -  config.set10('UDEV', true)
>  else
>dep_udev = []
>  endif
Does this pull udev.pc or libudev.pc?

In either case the whole thing can go - see
0ec7252a1deba3bac78b5ba1ebd2898f6bbf0332 + parent commit.

The series is
Reviewed-by: Emil Velikov 

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

[PATCH libdrm 2/4] meson,configure: always define HAVE_VISIBILITY

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 configure.ac| 2 ++
 libdrm_macros.h | 2 +-
 meson.build | 7 +++
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5751a8113635ce6a1c48..14baa1c87f9078f336fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -535,6 +535,8 @@ AC_LINK_IFELSE([AC_LANG_PROGRAM([
 
 if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
 AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports 
__attribute__(("hidden"))])
+else
+AC_DEFINE(HAVE_VISIBILITY, 0)
 fi
 
 CFLAGS="$CFLAGS -include config.h"
diff --git a/libdrm_macros.h b/libdrm_macros.h
index 639d09047efcd5619ae3..211fab21986f55745ad9 100644
--- a/libdrm_macros.h
+++ b/libdrm_macros.h
@@ -23,7 +23,7 @@
 #ifndef LIBDRM_LIBDRM_H
 #define LIBDRM_LIBDRM_H
 
-#if defined(HAVE_VISIBILITY)
+#if HAVE_VISIBILITY
 #  define drm_private __attribute__((visibility("hidden")))
 #else
 #  define drm_private
diff --git a/meson.build b/meson.build
index f7986af9bb5259be5da5..8d4d38b46ebcf75b9fb6 100644
--- a/meson.build
+++ b/meson.build
@@ -256,10 +256,9 @@ with_man_pages = with_man_pages != 'false' and 
prog_xslt.found() and prog_sed.fo
 # Used for tets
 prog_bash = find_program('bash')
 
-if cc.compiles('''int foo_hidden(void) 
__attribute__((visibility(("hidden";''',
-   name : 'compiler supports __attribute__(("hidden"))')
-  config.set10('HAVE_VISIBILITY', true)
-endif
+config.set10('HAVE_VISIBILITY',
+  cc.compiles('''int foo_hidden(void) 
__attribute__((visibility(("hidden";''',
+  name : 'compiler supports __attribute__(("hidden"))'))
 
 foreach t : [
  [with_exynos, 'EXYNOS'],
-- 
Cheers,
  Eric

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

[PATCH libdrm 3/4] meson,configure: always define UDEV

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 configure.ac | 2 ++
 meson.build  | 2 +-
 xf86drm.c| 8 
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 14baa1c87f9078f336fa..619af49726d198c5d685 100644
--- a/configure.ac
+++ b/configure.ac
@@ -347,6 +347,8 @@ AC_SUBST(PCIACCESS_LIBS)
 
 if test "x$UDEV" = xyes; then
AC_DEFINE(UDEV, 1, [Have UDEV support])
+else
+   AC_DEFINE(UDEV, 0)
 fi
 
 AC_CANONICAL_HOST
diff --git a/meson.build b/meson.build
index 8d4d38b46ebcf75b9fb6..0fe04a1411963c70cf80 100644
--- a/meson.build
+++ b/meson.build
@@ -165,9 +165,9 @@ if _libkms != 'false'
   with_libkms = _libkms == 'true' or ['linux', 'freebsd', 
'dragonfly'].contains(host_machine.system())
 endif
 
+config.set10('UDEV', with_udev)
 if with_udev
   dep_udev = dependency('udev')
-  config.set10('UDEV', true)
 else
   dep_udev = []
 endif
diff --git a/xf86drm.c b/xf86drm.c
index 117b0fc9e4a0158cf384..689e8fe9fe356957f03e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -290,7 +290,7 @@ static int drmMatchBusID(const char *id1, const char *id2, 
int pci_domain_ok)
  * If any other failure happened then it will output error mesage using
  * drmMsg() call.
  */
-#if !defined(UDEV)
+#if !UDEV
 static int chown_check_return(const char *path, uid_t owner, gid_t group)
 {
 int rv;
@@ -329,7 +329,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
 int fd;
 mode_t  devmode = DRM_DEV_MODE, serv_mode;
 gid_t   serv_group;
-#if !defined(UDEV)
+#if !UDEV
 int isroot  = !geteuid();
 uid_t   user= DRM_DEV_UID;
 gid_t   group   = DRM_DEV_GID;
@@ -358,7 +358,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
 devmode &= ~(S_IXUSR|S_IXGRP|S_IXOTH);
 }
 
-#if !defined(UDEV)
+#if !UDEV
 if (stat(DRM_DIR_NAME, )) {
 if (!isroot)
 return DRM_ERR_NOT_ROOT;
@@ -411,7 +411,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
 if (fd >= 0)
 return fd;
 
-#if !defined(UDEV)
+#if !UDEV
 /* Check if the device node is not what we expect it to be, and recreate it
  * and try again if so.
  */
-- 
Cheers,
  Eric

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

[PATCH libdrm 4/4] meson: replace `if(compiles) have=true` with `have=compiles`

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 0fe04a1411963c70cf80..74a541e8d835ae27c7f4 100644
--- a/meson.build
+++ b/meson.build
@@ -187,9 +187,8 @@ else
 endif
 dep_m = cc.find_library('m', required : false)
 foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
-  if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
works'.format(header))
-config.set10('HAVE_' + header.underscorify().to_upper(), true)
-  endif
+  config.set('HAVE_' + header.underscorify().to_upper(),
+cc.compiles('#include <@0@>'.format(header), name : '@0@ 
works'.format(header)))
 endforeach
 if cc.has_header_symbol('sys/sysmacros.h', 'major')
   config.set10('MAJOR_IN_SYSMACROS', true)
-- 
Cheers,
  Eric

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

[PATCH libdrm 1/4] meson, configure: always define HAVE_OPEN_MEMSTREAM

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 configure.ac| 4 +++-
 intel/test_decode.c | 4 ++--
 meson.build | 4 +---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5d3a20ffd3e7b38db5f1..5751a8113635ce6a1c48 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,7 +189,9 @@ AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=],
  [AC_MSG_ERROR([Couldn't find clock_gettime])])])
 AC_SUBST([CLOCK_LIB])
 
-AC_CHECK_FUNCS([open_memstream], [HAVE_OPEN_MEMSTREAM=yes])
+AC_CHECK_FUNCS([open_memstream],
+   [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 1, [Have open_memstream()])],
+   [AC_DEFINE([HAVE_OPEN_MEMSTREAM], 0)])
 
 dnl Use lots of warning flags with with gcc and compatible compilers
 
diff --git a/intel/test_decode.c b/intel/test_decode.c
index e25bbf10319b641e2c69..b9f5b92791d5ff0c8052 100644
--- a/intel/test_decode.c
+++ b/intel/test_decode.c
@@ -87,7 +87,7 @@ compare_batch(struct drm_intel_decode *ctx, const char 
*batch_filename)
 {
FILE *out = NULL;
void *ptr, *ref_ptr, *batch_ptr;
-#ifdef HAVE_OPEN_MEMSTREAM
+#if HAVE_OPEN_MEMSTREAM
size_t size;
 #endif
size_t ref_size, batch_size;
@@ -105,7 +105,7 @@ compare_batch(struct drm_intel_decode *ctx, const char 
*batch_filename)
 * figure out how to output to a file in a safe and sane way
 * inside of an automake project's test infrastructure.
 */
-#ifdef HAVE_OPEN_MEMSTREAM
+#if HAVE_OPEN_MEMSTREAM
out = open_memstream((char **), );
 #else
fprintf(stderr, "platform lacks open_memstream, skipping.\n");
diff --git a/meson.build b/meson.build
index 5e0840750d2b3ff8c608..f7986af9bb5259be5da5 100644
--- a/meson.build
+++ b/meson.build
@@ -196,9 +196,7 @@ if cc.has_header_symbol('sys/sysmacros.h', 'major')
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
   config.set10('MAJOR_IN_MKDEV', true)
 endif
-if cc.has_function('open_memstream')
-  config.set10('HAVE_OPEN_MEMSTREAM', true)
-endif
+config.set10('HAVE_OPEN_MEMSTREAM', cc.has_function('open_memstream'))
 
 warn_c_args = []
 foreach a : ['-Wall', '-Wextra', '-Wsign-compare', '-Werror=undef',
-- 
Cheers,
  Eric

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

Re: [Intel-gfx] [PATCH libdrm 0/5] improve reuse implementation

[Emil Velikov]

On 16 March 2018 at 08:43, Daniel Vetter  wrote:
> On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
>> From: "Xiong, James" 
>>
>> With gem_reuse enabled, when a buffer size is different than
>> the sizes of buckets, it is aligned to the next bucket's size,
>> which means about 25% more memory than the requested is allocated
>> in the worst senario. For example:
>>
>> Orignal sizeActual
>> 32KB+1Byte  40KB
>> .
>> .
>> .
>> 8MB+1Byte   10MB
>> .
>> .
>> .
>> 96MB+1Byte  112MB
>>
>> This is very memory expensive and make the reuse feature less
>> favorable than it deserves to be.
>>
>> This series aligns the reuse buffer size on page size instead to
>> save memory. Performed gfxbench tests on Gen9 without LLC, the
>> performances and reuse ratioes (reuse count/allocation count) were
>> same as before, saved memory usage by 1% ~ 7%(gl_manhattan: peak
>> allocated memory size was reduced from 448401408 to 419078144).
>>
>> v2: split the patch to a series of small functional changes (Chris)
>
> Mesa gen driver stopped using the libdrm buffer allocator. The gen2/3
> driver still uses it, but I think that's not the one you benchmarked. The
> 17.1 release was the first one with that change.
>
> I think you want to port your changes over to mesa to future proof it,
> merging this to upstream makes little sense.

Perhaps it can have in both? After all i915, libva and beignet still
make use of libdrm_intel.
The Mesa copy has changed drastically so this series might need serious rework.

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

Re: [PATCH 0/2] Add backlight-pwm-passthru in analogix DP driver

[Sean Paul]

On Thu, Mar 15, 2018 at 07:56:57PM -0700, Alexandru M Stan wrote:
> I noticed that the backlight on the ASUS Chromebook Flip C101 (bob) is
> flickering.
> 
> We're sending it a high frequency pwm signal, but the EDP panel decided to
> "parse" the signal, read the duty cycle, then make its own signal that
> it sends to the LEDs.
> 
> So even though we send a nice high refresh rate at 1200Hz, the panel backlight
> flickers at 200Hz (which is not even divisible by the 60Hz refresh rate).
> 
> The fix for that is to enable the EDP_BACKLIGHT_FREQ_PWM_PIN_PASSTHRU bit from
> the DPCD EDP registers. This makes the panel actually follow the signal
> we're giving it.
> 
> This series includes the optional dt binding to enable this fix
> (backlight-pwm-passthru) and the corresponding code in the analogix
> drm/bridge driver.
> 

Thanks for sending these patches!

With Archit and Daniel's comments addressed, feel free to add my 

Reviewed-by: Sean Paul 

> 
> Alexandru M Stan (2):
>   dt-bindings: analogix-dp: Add backlight-pwm-passthru
>   drm/bridge: analogix: Enable EDP_BACKLIGHT_FREQ_PWM_PIN_PASSTHRU
> 
>  .../bindings/display/bridge/analogix_dp.txt|  4 ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48 
> ++
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  1 +
>  3 files changed, 53 insertions(+)
> 
> -- 
> 2.13.5
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

[Ville Syrjälä]

On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Do the refresh rate calculation with a single division. This gives
> > us slightly more accurate results, especially for interlaced since
> > we don't just double the final truncated result.
> > 
> > We do lose one bit compared to the old way, so with an interlaced
> > mode the new code can only handle ~2GHz instead of the ~4GHz the
> > old code handeled.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> I kinda want special integers here that Oops on overflow, I thought
> they're coming. That aside:
> 
> Reviewed-by: Daniel Vetter 

Thanks. Patches 1-2 pushed to drm-misc-next.

> > ---
> >  drivers/gpu/drm/drm_modes.c | 19 +--
> >  1 file changed, 9 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 4157250140b0..f6b7c0e36a1a 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -773,24 +773,23 @@ EXPORT_SYMBOL(drm_mode_hsync);
> >  int drm_mode_vrefresh(const struct drm_display_mode *mode)
> >  {
> > int refresh = 0;
> > -   unsigned int calc_val;
> >  
> > if (mode->vrefresh > 0)
> > refresh = mode->vrefresh;
> > else if (mode->htotal > 0 && mode->vtotal > 0) {
> > -   int vtotal;
> > -   vtotal = mode->vtotal;
> > -   /* work out vrefresh the value will be x1000 */
> > -   calc_val = (mode->clock * 1000);
> > -   calc_val /= mode->htotal;
> > -   refresh = (calc_val + vtotal / 2) / vtotal;
> > +   unsigned int num, den;
> > +
> > +   num = mode->clock * 1000;
> > +   den = mode->htotal * mode->vtotal;
> >  
> > if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > -   refresh *= 2;
> > +   num *= 2;
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > -   refresh /= 2;
> > +   den *= 2;
> > if (mode->vscan > 1)
> > -   refresh /= mode->vscan;
> > +   den *= mode->vscan;
> > +
> > +   refresh = DIV_ROUND_CLOSEST(num, den);
> > }
> > return refresh;
> >  }
> > -- 
> > 2.16.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[Emil Velikov]

On 16 March 2018 at 14:35, Rob Herring  wrote:
> On Wed, Mar 14, 2018 at 12:21 PM, Emil Velikov  
> wrote:
>> On 14 March 2018 at 16:47, John Stultz  wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop/master branch, I've seen the following build errors:
>>>
>>> external/libdrm/intel/Android.mk: error: libdrm_intel
>>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>>> (SHARED_LIBRARIES android-arm64) You can set
>>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>>> intentional, but that may defer real problems until later in the
>>> build.
>>>
>>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>>> things to function properly, but is not ideal.
>>>
>>> So basically, while I'm not including the libdrm_intel package
>>> into the build, just the fact that the Android.mk file references
>>> libpciaccess which isn't a repo included in AOSP causes the build
>>> failure.
>>>
>>> So it seems we need some sort of conditional filter in the
>>> Android.mk to skip over it if we're not building for intel.
>>>
>> Could swear I asked a few times already, but cannot see an answer.
>> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?
>>
>> One way to avoid this kind of clutches like is to have meta drivers
>> like "arm-all" or "x86-all".
>>
>> Some examples:
>>  - the Mesa i965/anv drivers will not build for arm
>
> They used to...
>
There are still

Fair enough. Guess the compiler produced


>>  - the Mesa vc4 (even vc5?) driver has some perf. sensitive arm/thumb 
>> assembly
>>  - building the following combinations is waste of resources -
>> i915/i965/i915g on !x86, freedreno/etnaviv/imx on !arm
>
> I disagree. To use the kernel as an example, it is very valuable to
> have your driver code build for x86 allmodconfig even if it is
> something that never runs on x86 because lots of people and bots build
> that.
>
> If you require having ARM cross compilers and environment setup to
> build test "arm" drivers in mesa/libdrm, then you've really cut down
> the number of people doing build testing. Just look at Android build
> testing. I can count the number of people that do that on one hand.
>
FWIW I had suggested the same thing (build test everything) a few
times in the past.
For one reason or another the wider Mesa community did not agree :-\

>> Without something like my earlier suggestion all of the above will
>> need to be special cased. And more are to come with time :-\
>>
>> That is, unless I'm loosing my marbles. In which case don't be shy and
>> let me know, please.
>
> I think this has been beaten to death and will apply it. It's an easy
> revert if someone has an itch to come up with something better.
>
You have to admit though - evaluating dependencies for something that
is not build is fairly counter-intuitive.

Regardless - yes, I had a dull moment.
I deeply appreciate the patience and help.

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

Re: [Intel-gfx] [PATCH v2] i915: Re-use DEFINE_SHOW_ATTRIBUTE() macro

[Chris Wilson]

Quoting Andy Shevchenko (2018-03-16 14:12:13)
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
> 
> Reviewed-by: Chris Wilson 
> Signed-off-by: Andy Shevchenko 

And pushed, thanks very much for the patch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[Emil Velikov]

On 14 March 2018 at 17:30, John Stultz  wrote:
> On Wed, Mar 14, 2018 at 10:21 AM, Emil Velikov  
> wrote:
>> On 14 March 2018 at 16:47, John Stultz  wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop/master branch, I've seen the following build errors:
>>>
>>> external/libdrm/intel/Android.mk: error: libdrm_intel
>>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>>> (SHARED_LIBRARIES android-arm64) You can set
>>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>>> intentional, but that may defer real problems until later in the
>>> build.
>>>
>>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>>> things to function properly, but is not ideal.
>>>
>>> So basically, while I'm not including the libdrm_intel package
>>> into the build, just the fact that the Android.mk file references
>>> libpciaccess which isn't a repo included in AOSP causes the build
>>> failure.
>>>
>>> So it seems we need some sort of conditional filter in the
>>> Android.mk to skip over it if we're not building for intel.
>>>
>> Could swear I asked a few times already, but cannot see an answer.
>> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?
>
> Again, this is from the Android build, as the top level Android.mk calls:
> include $(call all-makefiles-under,$(LOCAL_PATH))
>
> Which includes all Android.mk files in all the sub directories
> (regardless of any BOARD_GPU_DRIVERS value).
>
> The error is that while we don't build the libdrm_intel module, the
> android build system still throws a error when any
> LOCAL_SHARED_LIBRARIES files aren't present in the larger build
> environment.
>
So Android would evaluate dependencies, even when the object is not
build/required.
That is fairly counter intuitive, hence why I've been stuck in suck a loop.

Fwiw the patch is
Reviewed-by: Emil Velikov 

Thanks for the explanation and patience!
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] mali-dp: fixes for drm-next

[Liviu Dudau]

Hi Dave,

I have accumulated some patches as we went through some internal testing
for mali-dp and I was waiting for the YUV2RGB patches to land in your
tree, so I would like to get them into drm-next at your earliest
convenient time.

Please note that after you pull Dan Carpenter's patch f2f2c85c6620
("drm: mali-dp: Uninitialized variable in malidp_se_check_scaling()")

you will get a conflict with Ville's commit 81af63a4af82 ("drm: Don't pass
clip to drm_atomic_helper_check_plane_state()") in drm-misc-next. The way it was
fixed in linux-next was:

diff --cc drivers/gpu/drm/arm/malidp_planes.c
index ee32361c87ac,b2d11df6b5e1..
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@@ -147,7 -147,13 +146,9 @@@ static int malidp_se_check_scaling(stru
if (!crtc_state)
return -EINVAL;
  
 -  if (crtc_state->enable)
 -  drm_mode_get_hv_timing(_state->mode,
 - , );
 -
+   mc = to_malidp_crtc_state(crtc_state);
+ 
 -  ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
 +  ret = drm_atomic_helper_check_plane_state(state, crtc_state,
  0, INT_MAX, true, true);
if (ret)
return ret;

Please pull.

Best regards,
Liviu


The following changes since commit 963976cfe9c54d4d9e725e61c90c47a4af6b5ea2:

  Merge tag 'drm-intel-next-2018-03-08' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-14 14:53:01 
+1000)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/mali-dp

for you to fetch changes up to 6e810eb508f4b937bc2a718bd4e5cd74cca55500:

  drm: mali-dp: Add YUV->RGB conversion support for video layers (2018-03-14 
11:41:01 +)


Ayan Halder (2):
  drm: mali-dp: Fix bug on scaling with rotation
  drm/arm/malidp: Disable pixel alpha blending for colors that do not have 
alpha

Dan Carpenter (1):
  drm: mali-dp: Uninitialized variable in malidp_se_check_scaling()

Laurent Pinchart (2):
  drm: arm: malidp: Don't destroy planes manually in error handlers
  drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes on 
removal

Liviu Dudau (5):
  drm/mali-dp: Rotated planes need a larger pitch size.
  drm/mali-dp: Align pitch size to be multiple of bus burst read size.
  drm/mali-dp: Don't enable scaling engine for planes that only rotate.
  drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.
  drm: mali-dp: Turn off CRTC vblank when removing module.

Mihail Atanassov (1):
  drm: mali-dp: Add YUV->RGB conversion support for video layers

 drivers/gpu/drm/arm/malidp_crtc.c   |  20 ++---
 drivers/gpu/drm/arm/malidp_drv.c|  51 -
 drivers/gpu/drm/arm/malidp_drv.h|   2 +-
 drivers/gpu/drm/arm/malidp_hw.c |  26 ---
 drivers/gpu/drm/arm/malidp_hw.h |  15 +++-
 drivers/gpu/drm/arm/malidp_planes.c | 141 +---
 drivers/gpu/drm/arm/malidp_regs.h   |  11 +--
 7 files changed, 189 insertions(+), 77 deletions(-)

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.17-wip 72/87] drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup: first occurrence line 1004, second occurrence line 1031 (fwd)

[Julia Lawall]

The same field name appears on two differnt lines, with different values.

julia

-- Forwarded message --
Date: Fri, 16 Mar 2018 22:35:29 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [radeon-alex:drm-next-4.17-wip 72/87]
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup:
first occurrence line 1004, second occurrence line 1031

CC: kbuild-...@01.org
CC: dri-devel@lists.freedesktop.org
TO: Rex Zhu 
CC: Alex Deucher 

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   61deb7d0941d1e3ffee0d799396ac93b0e90
commit: c425688520990d6cec769faaa97f4af45d361fd1 [72/87] drm/amd/pp: Replace 
rv_* with smu10_*
:: branch date: 19 hours ago
:: commit date: 24 hours ago

>> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c:1001:52-53: asic_setup: 
>> first occurrence line 1004, second occurrence line 1031

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout c425688520990d6cec769faaa97f4af45d361fd1
vim +1001 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c

b01a4f489 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.cEric Huang 
2018-02-06  1000
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06 @1001  static const struct pp_hwmgr_func smu10_hwmgr_funcs = {
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1002 .backend_init = smu10_hwmgr_backend_init,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1003 .backend_fini = smu10_hwmgr_backend_fini,
a960d61cb drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.cRex Zhu
2017-05-11 @1004 .asic_setup = NULL,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1005 .apply_state_adjust_rules = 
smu10_apply_state_adjust_rules,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1006 .force_dpm_level = smu10_dpm_force_dpm_level,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1007 .get_power_state_size = smu10_get_power_state_size,
a960d61cb drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.cRex Zhu
2017-05-11  1008 .powerdown_uvd = NULL,
a960d61cb drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.cRex Zhu
2017-05-11  1009 .powergate_uvd = NULL,
a960d61cb drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.cRex Zhu
2017-05-11  1010 .powergate_vce = NULL,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1011 .get_mclk = smu10_dpm_get_mclk,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1012 .get_sclk = smu10_dpm_get_sclk,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1013 .patch_boot_state = smu10_dpm_patch_boot_state,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1014 .get_pp_table_entry = smu10_dpm_get_pp_table_entry,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1015 .get_num_of_pp_table_entries = 
smu10_dpm_get_num_of_pp_table_entries,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1016 .set_cpu_power_state = smu10_set_cpu_power_state,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1017 .store_cc6_data = smu10_store_cc6_data,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1018 .force_clock_level = smu10_force_clock_level,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1019 .print_clock_levels = smu10_print_clock_levels,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1020 .get_dal_power_level = smu10_get_dal_power_level,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1021 .get_performance_level = smu10_get_performance_level,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1022 .get_current_shallow_sleep_clocks = 
smu10_get_current_shallow_sleep_clocks,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1023 .get_clock_by_type_with_latency = 
smu10_get_clock_by_type_with_latency,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1024 .get_clock_by_type_with_voltage = 
smu10_get_clock_by_type_with_voltage,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu
2018-03-06  1025 .get_max_high_clocks = smu10_get_max_high_clocks,
c42568852 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c Rex Zhu

Re: [PATCH] drm/imx: move arming of the vblank event to atomic_flush

[Philipp Zabel]

On Thu, 2018-03-15 at 10:11 +0100, Lucas Stach wrote:
> Right now the vblank event completion is racing with the atomic update,
> which is especially bad when the PRE is in use, as one of the hardware
> issue workaround might extend the atomic commit for quite some time.
> 
> If the vblank IRQ happens to trigger during that time, we will prematurely
> signal the atomic commit completion to userspace, which causes tearing
> when userspace re-uses a framebuffer we haven't managed to flip away from
> yet.
> 
> Signed-off-by: Lucas Stach 

This trades the tiny (on i.MX6Q) or not so tiny (on i.MX6QP) risk of
returning a vblank event completion too early for the tiny risk to miss
a vsync interrupt, and to return a vblank event completion a frame too
late. Applied to imx-drm/fixes.

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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #60 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #59)
> Hi Andrey
> 
> Testing with llvm7 setup:
> 
> 
> R600_DEBUG=notiling,norbplus xinit
> 
> does not avoid the hang :(
> 
> [   31.200134] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
> last signaled seq=7, last emitted seq=8
> [   31.200147] [drm] IP block:gfx_v8_0 is hung!
> [   31.200152] [drm] GPU recovery disabled.
> 
> 
> 
> GALLIUM_DDEBUG=flush xinit
> 
> Seems to have a (good) impact. Hang happened after around 20 boots.
> 
> [   13.389894] NET: Registered protocol family 39
> [   28.640142] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
> last signaled seq=652, last emitted seq=654
> [   28.640154] [drm] IP block:gfx_v8_0 is hung!
> [   28.640160] [drm] GPU recovery disabled.
> [  246.752083] INFO: task amdgpu_cs:0:636 blocked for more than 120 seconds.
> [  246.752092]   Not tainted 4.16.0-rc4-qtec-standard #1
> [  246.752095] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [  246.752099] amdgpu_cs:0 D0   636543 0x0008
> [  246.752099] amdgpu_cs:0 D0   636543 0x0008
> [  246.752103] Call Trace:
> [  246.752115]  ? __schedule+0x25c/0x860
> [  246.752122]  ? dma_fence_default_wait+0x10c/0x280
> [  246.752124]  ? dma_fence_default_wait+0x1c8/0x280
> [  246.752127]  schedule+0x2f/0x90
> [  246.752130]  schedule_timeout+0x1f1/0x440
> [  246.752220]  ? amdgpu_cs_bo_validate+0x7f/0x120 [amdgpu]
> [  246.752276]  ? amdgpu_ttm_alloc_gart+0x5d/0x270 [amdgpu]
> [  246.752284]  ? dma_fence_default_wait+0x10c/0x280
> [  246.752287]  ? dma_fence_default_wait+0x1c8/0x280
> [  246.752290]  dma_fence_default_wait+0x1f4/0x280
> [  246.752294]  ? dma_fence_default_wait+0x280/0x280
> [  246.752297]  dma_fence_wait_timeout+0x2e/0x100
> [  246.752359]  amdgpu_ctx_wait_prev_fence+0x46/0x80 [amdgpu]
> [  246.752418]  amdgpu_cs_ioctl+0x1f2/0x1af0 [amdgpu]
> [  246.752478]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> [  246.752504]  drm_ioctl_kernel+0x59/0xb0 [drm]
> [  246.752524]  drm_ioctl+0x29f/0x340 [drm]
> [  246.752581]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
> [  246.752630]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> [  246.752635]  do_vfs_ioctl+0x8e/0x680
> [  246.752641]  ? SyS_futex+0x11d/0x150
> [  246.752644]  SyS_ioctl+0x74/0x80
> [  246.752647]  ? get_vtime_delta+0xe/0x40
> [  246.752650]  do_syscall_64+0x7b/0x1d0
> [  246.752654]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [  246.752658] RIP: 0033:0x3e292e57e7
> [  246.752660] RSP: 002b:7f17a2924b88 EFLAGS: 0246 ORIG_RAX:
> 0010
> [  246.752663] RAX: ffda RBX: 7f17a2924c78 RCX:
> 003e292e57e7
> [  246.752664] RDX: 7f17a2924bf0 RSI: c0186444 RDI:
> 000d
> [  246.752666] RBP: 7f17a2924bf0 R08: 7f17a2924ca0 R09:
> 7f17a2924c78
> [  246.752667] R10: 7f17a2924ca0 R11: 0246 R12:
> c0186444
> [  246.752668] R13: 000d R14: 00d2c588 R15:
> 0002
> 
> 
> kmscube git HEAD have not stalled after 50 attempts without any flag in
> GALLIUM_DDEBUG or R600_DEBUG.
> 
> It might not be relevant, but my platform can only boot with BIOS (it is
> based on coreboot). When you tried this bug did you tried with UEFI or BIOS?
> 
> Thanks

I think my BIOS is set to UEFI but it can't have any relation to this issue.

Andrey

-- 
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] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[Rob Herring]

On Wed, Mar 14, 2018 at 12:21 PM, Emil Velikov  wrote:
> On 14 March 2018 at 16:47, John Stultz  wrote:
>> When building AOSP after updating libdrm project to the
>> freedesktop/master branch, I've seen the following build errors:
>>
>> external/libdrm/intel/Android.mk: error: libdrm_intel
>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>> (SHARED_LIBRARIES android-arm64) You can set
>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>> intentional, but that may defer real problems until later in the
>> build.
>>
>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>> things to function properly, but is not ideal.
>>
>> So basically, while I'm not including the libdrm_intel package
>> into the build, just the fact that the Android.mk file references
>> libpciaccess which isn't a repo included in AOSP causes the build
>> failure.
>>
>> So it seems we need some sort of conditional filter in the
>> Android.mk to skip over it if we're not building for intel.
>>
> Could swear I asked a few times already, but cannot see an answer.
> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?
>
> One way to avoid this kind of clutches like is to have meta drivers
> like "arm-all" or "x86-all".
>
> Some examples:
>  - the Mesa i965/anv drivers will not build for arm

They used to...

>  - the Mesa vc4 (even vc5?) driver has some perf. sensitive arm/thumb assembly
>  - building the following combinations is waste of resources -
> i915/i965/i915g on !x86, freedreno/etnaviv/imx on !arm

I disagree. To use the kernel as an example, it is very valuable to
have your driver code build for x86 allmodconfig even if it is
something that never runs on x86 because lots of people and bots build
that.

If you require having ARM cross compilers and environment setup to
build test "arm" drivers in mesa/libdrm, then you've really cut down
the number of people doing build testing. Just look at Android build
testing. I can count the number of people that do that on one hand.

> Without something like my earlier suggestion all of the above will
> need to be special cased. And more are to come with time :-\
>
> That is, unless I'm loosing my marbles. In which case don't be shy and
> let me know, please.

I think this has been beaten to death and will apply it. It's an easy
revert if someone has an itch to come up with something better.

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

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Christian König]

Am 16.03.2018 um 14:51 schrieb Chris Wilson:

Quoting Christian König (2018-03-16 13:20:45)

@@ -326,6 +338,29 @@ struct dma_buf_attachment {
 struct device *dev;
 struct list_head node;
 void *priv;
+
+   /**
+* @invalidate_mappings:
+*
+* Optional callback provided by the importer of the attachment which
+* must be set before mappings are created.
+*
+* If provided the exporter can avoid pinning the backing store while
+* mappings exists.

Hmm, no I don't think it avoids the pinning issue entirely. As it stands,
the importer doesn't have a page refcount and so they all rely on the
exporter keeping the dmabuf pages pinned while attached. What can happen
is that given the invalidate cb, the importers can revoke their
attachments, letting the exporter recover the pages/sg, and then start
again from scratch.


Yes, exactly. The wording is just not 100% precise and I haven't found 
something better so far.



That also neatly answers what happens if not all importers provide an
invalidate cb, or fail, the dmabuf remains pinned and the exporter must
retreat.


Yes, exactly as well. As soon as at least one importer says "I can't do 
this", we must fallback to the old behavior.



+*
+* The function is called with the lock of the reservation object
+* associated with the dma_buf held and the mapping function must be
+* called with this lock held as well. This makes sure that no mapping
+* is created concurrently with an ongoing invalidation.
+*
+* After the callback all existing mappings are still valid until all
+* fences in the dma_bufs reservation object are signaled, but should be
+* destroyed by the importer as soon as possible.
+*
+* New mappings can be created immediately, but can't be used before the
+* exclusive fence in the dma_bufs reservation object is signaled.
+*/
+   void (*invalidate_mappings)(struct dma_buf_attachment *attach);

The intent is that the invalidate is synchronous and immediate, while
locked? We are looking at recursing back into the dma_buf functions to
remove each attachment from the invalidate cb (as well as waiting for
dma), won't that cause some nasty issues?


No, with this idea invalidation is asynchronous. Already discussed that 
with Daniel as well and YES Daniel also already pointed out that I need 
to better document this.


When the exporter calls invalidate_mappings() it just means that all 
importers can no longer use their sg tables for new submissions, old 
ones stay active.


The existing sg tables are guaranteed to stay valid until all fences in 
the reservation object have signaled and the importer should also delay 
it's call to call dma_buf_unmap_attachment() until all the fences have 
signaled.


When the importer has new work to do, e.g. wants to attach a new fence 
to the reservation object, it must grab a new sg table for that. The 
importer also needs to make sure that all new work touching the dma-buf 
doesn't start before the exclusive fence in the reservation object signals.


This allows for full grown pipelining, e.g. the exporter can say I need 
to move the buffer for some operation. Then let the move operation wait 
for all existing fences in the reservation object and install the fence 
of the move operation as exclusive fence.


The importer can then immediately grab a new sg table for the new 
location of the buffer and use it to prepare the next operation.


Regards,
Christian.


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

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

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

--- Comment #8 from tom34  ---
I see that Bohemia mentioned about this bug here:
https://community.bistudio.com/wiki/Arma_3_Experimental_Ports#Known_Issues


"AMD Mesa drivers can cause graphical glitches, such as white blinking
vegetation LODs."

"ATOC might cause rendering issues with AMD cards using MESA drivers."

-- 
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: [Intel-gfx] [PATCH 4/6] drm: Introduce drm_color_lut_size()

[Ville Syrjälä]

On Tue, Mar 06, 2018 at 08:54:21AM +0100, Daniel Vetter wrote:
> On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Provide a small helper to convert the blob length in bytes
> > to the number of LUT entries.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  include/drm/drm_color_mgmt.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > index 03a59cbce621..7ddf4457f3c1 100644
> > --- a/include/drm/drm_color_mgmt.h
> > +++ b/include/drm/drm_color_mgmt.h
> > @@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
> >  int gamma_size);
> >  
> 
> Add a bit of kerneldoc and you get my
> 
> Reviewed-by: Daniel Vetter 
> 
> for this and all remaining patches.

Entire series pushed to drm-misc-next. Thanks for the reviews.

> -Daniel
> 
> > +static inline int drm_color_lut_size(const struct drm_property_blob *blob)
> > +{
> > +   return blob->length / sizeof(struct drm_color_lut);
> > +}
> > +
> >  #endif
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

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

--- Comment #7 from tom34  ---
I using mesa3d (17.3.6) from stable padoka repo and i see white bushes in game,
here is the example:

(Headphone warning, mic volume too high)
https://www.twitch.tv/videos/239136303?t=01m10s

-- 
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/5] dma-buf: add optional invalidate_mappings callback v2

[Chris Wilson]

Quoting Christian König (2018-03-16 13:20:45)
> @@ -326,6 +338,29 @@ struct dma_buf_attachment {
> struct device *dev;
> struct list_head node;
> void *priv;
> +
> +   /**
> +* @invalidate_mappings:
> +*
> +* Optional callback provided by the importer of the attachment which
> +* must be set before mappings are created.
> +*
> +* If provided the exporter can avoid pinning the backing store while
> +* mappings exists.

Hmm, no I don't think it avoids the pinning issue entirely. As it stands,
the importer doesn't have a page refcount and so they all rely on the
exporter keeping the dmabuf pages pinned while attached. What can happen
is that given the invalidate cb, the importers can revoke their
attachments, letting the exporter recover the pages/sg, and then start
again from scratch.

That also neatly answers what happens if not all importers provide an
invalidate cb, or fail, the dmabuf remains pinned and the exporter must
retreat.

> +*
> +* The function is called with the lock of the reservation object
> +* associated with the dma_buf held and the mapping function must be
> +* called with this lock held as well. This makes sure that no mapping
> +* is created concurrently with an ongoing invalidation.
> +*
> +* After the callback all existing mappings are still valid until all
> +* fences in the dma_bufs reservation object are signaled, but should 
> be
> +* destroyed by the importer as soon as possible.
> +*
> +* New mappings can be created immediately, but can't be used before 
> the
> +* exclusive fence in the dma_bufs reservation object is signaled.
> +*/
> +   void (*invalidate_mappings)(struct dma_buf_attachment *attach);

The intent is that the invalidate is synchronous and immediate, while
locked? We are looking at recursing back into the dma_buf functions to
remove each attachment from the invalidate cb (as well as waiting for
dma), won't that cause some nasty issues?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #4 from philipmor...@gmail.com ---
Thanks for replies. My monitor is DVI DL only.

My old Haswell i5 4670 with HD4600 graphics was also single link DVI only
(https://communities.intel.com/thread/44135), and it worked at 60Hz. Could
somebody please explain why haswell can do it but raven can't ?

Otherwise I find myself assuming that the hardware is capable of DL DVI, just
that the manufacturers aren't validating for it, ergo fixable in software.

I understand if AMD object to coding for something that hasn't been validated
(I'd do the same myself).  Would it be possible alternatively to provide hints
in log output or code comments or on a wiki somewhere, such that people in my
position can hack the source themselves ?

Secondly, even accepting the single link limitation, shouldn't it be possible
to run at 33 refresh rate ?  I tried at 30 and got nothing.

Thirdly, why does amdgpu refer to the connection as HDMI-A-3 ?  There's no HDMI
in the setup at all.

-- 
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/5] drm/amdgpu: add independent DMA-buf import v2

[Christian König]

Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.

v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 44 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 32 ++
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 7b9edbc938eb..cb6ec9b7844a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -291,10 +291,26 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
return buf;
 }
 
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+   struct ttm_operation_ctx ctx = { false, false };
+   struct drm_gem_object *obj = attach->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct ttm_placement placement = {};
+   int r;
+
+   r = ttm_bo_validate(>tbo, , );
+   if (r)
+   DRM_ERROR("Failed to unmap DMA-buf import (%d))\n", r);
+}
+
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
 {
+   struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
+   int ret;
 
if (dma_buf->ops == _dmabuf_ops) {
obj = dma_buf->priv;
@@ -308,5 +324,31 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
}
}
 
-   return drm_gem_prime_import(dev, dma_buf);
+   if (!dma_buf->ops->supports_mapping_invalidation)
+   return drm_gem_prime_import(dev, dma_buf);
+
+   attach = dma_buf_attach(dma_buf, dev->dev);
+   if (IS_ERR(attach))
+   return ERR_CAST(attach);
+
+   get_dma_buf(dma_buf);
+
+   obj = amdgpu_gem_prime_import_sg_table(dev, attach, NULL);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto fail_detach;
+   }
+
+   obj->import_attach = attach;
+   attach->priv = obj;
+
+   dma_buf_set_invalidate_callback(attach,
+   amdgpu_gem_prime_invalidate_mappings);
+   return obj;
+
+fail_detach:
+   dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
+   return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 291dd3d600cd..aeead0281e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_object.h"
 #include "amdgpu_trace.h"
@@ -685,6 +686,7 @@ struct amdgpu_ttm_gup_task_list {
 
 struct amdgpu_ttm_tt {
struct ttm_dma_tt   ttm;
+   struct amdgpu_bo*bo;
u64 offset;
uint64_tuserptr;
struct mm_struct*usermm;
@@ -993,6 +995,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_buffer_object *bo,
return NULL;
}
gtt->ttm.ttm.func = _backend_func;
+   gtt->bo = ttm_to_amdgpu_bo(bo);
if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
kfree(gtt);
return NULL;
@@ -1005,7 +1008,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (gtt && gtt->userptr) {
ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
@@ -1017,7 +1019,19 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
return 0;
}
 
-   if (slave && ttm->sg) {
+   if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+   if (!ttm->sg) {
+   struct dma_buf_attachment *attach;
+   struct sg_table *sgt;
+
+   attach = gtt->bo->gem_base.import_attach;
+   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+   if (IS_ERR(sgt))
+   return PTR_ERR(sgt);
+
+   ttm->sg = sgt;
+   }
+
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address,
 ttm->num_pages);
@@ -1036,9 +1050,8 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
 
 static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 {
-   struct amdgpu_device *adev;
struct amdgpu_ttm_tt *gtt = (void 

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

[Christian König]

Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.

v2: fix unintended recursion, remove debugging leftovers

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   5 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  | 110 ++---
 4 files changed, 73 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 96bcdb97e7e2..909dc9764a22 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -371,7 +371,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
 void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
 unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
 amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e6709362994a..e32dcdf8d3db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -886,7 +886,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
-   .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 48e0115d4f76..18483a79dcdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -931,6 +932,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
 
amdgpu_bo_kunmap(abo);
 
+   if (abo->gem_base.dma_buf && !abo->gem_base.import_attach &&
+   bo->mem.mem_type != TTM_PL_SYSTEM)
+   dma_buf_invalidate_mappings(abo->gem_base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c9991738477..7b9edbc938eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -32,14 +32,6 @@
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-   int npages = bo->tbo.num_pages;
-
-   return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
 void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -126,22 +118,21 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct device *target_dev,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+  enum dma_data_direction dir)
 {
+   struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct sg_table *sgt;
long r;
 
-   r = drm_gem_map_attach(dma_buf, target_dev, attach);
-   if (r)
-   return r;
-
-   r = amdgpu_bo_reserve(bo, false);
-   if (unlikely(r != 0))
-   goto error_detach;
-
+   if (!attach->invalidate_mappings) {
+   r = amdgpu_bo_reserve(bo, false);
+   if (unlikely(r != 0))
+   return ERR_PTR(r);
+   }
 
if (dma_buf->ops != _dmabuf_ops) {
/*
@@ -157,41 +148,77 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
}
}
 
-   /* pin buffer into GTT */
-   r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
-   if (r)
+   if (!attach->invalidate_mappings) {
+   /* pin buffer into GTT */
+   r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
+   if (r)
+   goto error_unreserve;
+
+   } else {
+   /* move buffer into GTT */
+   struct ttm_operation_ctx ctx = { false, false };

[PATCH 2/5] drm/ttm: keep a reference to transfer pipelined BOs

[Christian König]

Make sure the transfered BO is never destroy before the transfer BO.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1f730b3f18e5..1ee20558ee31 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -39,6 +39,11 @@
 #include 
 #include 
 
+struct ttm_transfer_obj {
+   struct ttm_buffer_object base;
+   struct ttm_buffer_object *bo;
+};
+
 void ttm_bo_free_old_node(struct ttm_buffer_object *bo)
 {
ttm_bo_mem_put(bo, >mem);
@@ -435,7 +440,11 @@ EXPORT_SYMBOL(ttm_bo_move_memcpy);
 
 static void ttm_transfered_destroy(struct ttm_buffer_object *bo)
 {
-   kfree(bo);
+   struct ttm_transfer_obj *fbo;
+
+   fbo = container_of(bo, struct ttm_transfer_obj, base);
+   ttm_bo_unref(>bo);
+   kfree(fbo);
 }
 
 /**
@@ -456,14 +465,15 @@ static void ttm_transfered_destroy(struct 
ttm_buffer_object *bo)
 static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
  struct ttm_buffer_object **new_obj)
 {
-   struct ttm_buffer_object *fbo;
+   struct ttm_transfer_obj *fbo;
int ret;
 
fbo = kmalloc(sizeof(*fbo), GFP_KERNEL);
if (!fbo)
return -ENOMEM;
 
-   *fbo = *bo;
+   fbo->base = *bo;
+   fbo->bo = ttm_bo_reference(bo);
 
/**
 * Fix up members that we shouldn't copy directly:
@@ -471,25 +481,25 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
 */
 
atomic_inc(>bdev->glob->bo_count);
-   INIT_LIST_HEAD(>ddestroy);
-   INIT_LIST_HEAD(>lru);
-   INIT_LIST_HEAD(>swap);
-   INIT_LIST_HEAD(>io_reserve_lru);
-   mutex_init(>wu_mutex);
-   fbo->moving = NULL;
-   drm_vma_node_reset(>vma_node);
-   atomic_set(>cpu_writers, 0);
-
-   kref_init(>list_kref);
-   kref_init(>kref);
-   fbo->destroy = _transfered_destroy;
-   fbo->acc_size = 0;
-   fbo->resv = >ttm_resv;
-   reservation_object_init(fbo->resv);
-   ret = reservation_object_trylock(fbo->resv);
+   INIT_LIST_HEAD(>base.ddestroy);
+   INIT_LIST_HEAD(>base.lru);
+   INIT_LIST_HEAD(>base.swap);
+   INIT_LIST_HEAD(>base.io_reserve_lru);
+   mutex_init(>base.wu_mutex);
+   fbo->base.moving = NULL;
+   drm_vma_node_reset(>base.vma_node);
+   atomic_set(>base.cpu_writers, 0);
+
+   kref_init(>base.list_kref);
+   kref_init(>base.kref);
+   fbo->base.destroy = _transfered_destroy;
+   fbo->base.acc_size = 0;
+   fbo->base.resv = >base.ttm_resv;
+   reservation_object_init(fbo->base.resv);
+   ret = reservation_object_trylock(fbo->base.resv);
WARN_ON(!ret);
 
-   *new_obj = fbo;
+   *new_obj = >base;
return 0;
 }
 
-- 
2.14.1

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

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

[Christian König]

Pipeline removal of the BOs backing store when the placement is given
during validation.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 98e06f8bf23b..17e821f01d0a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1078,6 +1078,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
 
reservation_object_assert_held(bo->resv);
+
+   /*
+* Remove the backing store if no placement is given.
+*/
+   if (!placement->num_placement && !placement->num_busy_placement) {
+   ret = ttm_bo_pipeline_gutting(bo);
+   if (ret)
+   return ret;
+
+   return ttm_tt_create(bo, false);
+   }
+
/*
 * Check whether we need to move buffer.
 */
-- 
2.14.1

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

[PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

[Christian König]

Each importer can now provide an invalidate_mappings callback.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c | 60 +++
 include/linux/dma-buf.h   | 38 ++
 2 files changed, 98 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173dc..ed2b3559ba25 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -572,7 +572,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
if (ret)
goto err_attach;
}
+   reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+   reservation_object_unlock(dmabuf->resv);
 
mutex_unlock(>lock);
return attach;
@@ -598,7 +600,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attach)
return;
 
mutex_lock(>lock);
+   reservation_object_lock(dmabuf->resv, NULL);
list_del(>node);
+   reservation_object_unlock(dmabuf->resv);
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
 
@@ -632,10 +636,23 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
 
+   /*
+* Mapping a DMA-buf can trigger its invalidation, prevent sending this
+* event to the caller by temporary removing this attachment from the
+* list.
+*/
+   if (attach->invalidate_mappings) {
+   reservation_object_assert_held(attach->dmabuf->resv);
+   list_del(>node);
+   }
+
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
 
+   if (attach->invalidate_mappings)
+   list_add(>node, >dmabuf->attachments);
+
return sg_table;
 }
 EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
@@ -656,6 +673,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 {
might_sleep();
 
+   if (attach->invalidate_mappings)
+   reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
 
@@ -664,6 +684,44 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+/**
+ * dma_buf_set_invalidate_callback - set the invalidate_mappings callback
+ *
+ * @attach:[in]attachment where to set the callback
+ * @cb:[in]the callback to set
+ *
+ * Makes sure to take the appropriate locks when updating the invalidate
+ * mappings callback.
+ */
+void dma_buf_set_invalidate_callback(struct dma_buf_attachment *attach,
+void (*cb)(struct dma_buf_attachment *))
+{
+   reservation_object_lock(attach->dmabuf->resv, NULL);
+   attach->invalidate_mappings = cb;
+   reservation_object_unlock(attach->dmabuf->resv);
+}
+EXPORT_SYMBOL_GPL(dma_buf_set_invalidate_callback);
+
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
+{
+   struct dma_buf_attachment *attach;
+
+   reservation_object_assert_held(dmabuf->resv);
+
+   list_for_each_entry(attach, >attachments, node)
+   if (attach->invalidate_mappings)
+   attach->invalidate_mappings(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
+
 /**
  * DOC: cpu access
  *
@@ -1121,10 +1179,12 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
seq_puts(s, "\tAttached Devices:\n");
attach_count = 0;
 
+   reservation_object_lock(buf_obj->resv, NULL);
list_for_each_entry(attach_obj, _obj->attachments, node) {
seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
attach_count++;
}
+   reservation_object_unlock(buf_obj->resv);
 
seq_printf(s, "Total %d devices attached\n\n",
attach_count);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 085db2fee2d7..70c65fcfe1e3 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -91,6 +91,18 @@ struct dma_buf_ops {
 */
void (*detach)(struct dma_buf *, struct 

RFC: unpinned DMA-buf exporting v2

[Christian König]

Hi everybody,

since I've got positive feedback from Daniel I continued working on this 
approach.

A few issues are still open:
1. Daniel suggested that I make the invalidate_mappings callback a parameter of 
dma_buf_attach().

This approach unfortunately won't work because when the attachment is created 
the importer is not necessarily ready to handle invalidation events.

E.g. in the amdgpu example we first need to setup the imported GEM/TMM objects 
and install that in the attachment.

My solution is to introduce a separate function to grab the locks and set the 
callback, this function could then be used to pin the buffer later on if that 
turns out to be necessary after all.

2. With my example setup this currently results in a ping/pong situation 
because the exporter prefers a VRAM placement while the importer prefers a GTT 
placement.

This results in quite a performance drop, but can be fixed by a simple mesa 
patch which allows shred BOs to be placed in both VRAM and GTT.

Question is what should we do in the meantime? Accept the performance drop or 
only allow unpinned sharing with new Mesa?

Please review and comment,
Christian.

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

Re: [PATCH v2] Add udmabuf misc device

[Christian König]

Am 16.03.2018 um 08:46 schrieb Gerd Hoffmann:

A driver to let userspace turn iovecs into dma-bufs.

Use case:  Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources.  Then they can be passed around to display
those guest things on the host.  To spice client for classic full
framebuffer display, and hopefully some day to wayland server for
seamless guest window display.

Those dma-bufs are accounted against user's shm mlock bucket as the
pages are effectively locked in memory.


Sorry to disappoint you, but we have investigated the same idea for 
userptr use quite extensively and found that whole approach doesn't work.


The pages backing a DMA-buf are not allowed to move (at least not 
without a patch set I'm currently working on), but for certain MM 
operations to work correctly you must be able to modify the page tables 
entries and move the pages backing them around.


For example try to use fork() with some copy on write pages with this 
approach. You will find that you have only two options to correctly 
handle this.


Either you access memory which could no longer belong to your process, 
which in turn is major security no-go.


Or you use a MM notifier, but without being able to unmap DMA-bufs that 
won't work and you will certainly create a deadlock.


Even with the patch set I'm currently working on the MM notifier 
approach is a real beast to get right.


Regards,
Christian.



Cc: David Airlie 
Cc: Tomeu Vizoso 
Cc: Daniel Vetter 
Signed-off-by: Gerd Hoffmann 
---
  include/uapi/linux/udmabuf.h  |  23 ++
  drivers/dma-buf/udmabuf.c | 261 ++
  tools/testing/selftests/drivers/dma-buf/udmabuf.c |  69 ++
  drivers/dma-buf/Kconfig   |   7 +
  drivers/dma-buf/Makefile  |   1 +
  tools/testing/selftests/drivers/dma-buf/Makefile  |   5 +
  6 files changed, 366 insertions(+)
  create mode 100644 include/uapi/linux/udmabuf.h
  create mode 100644 drivers/dma-buf/udmabuf.c
  create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
  create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile

diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..54ceba203a
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include 
+#include 
+
+struct udmabuf_iovec {
+   __u64 base;
+   __u64 len;
+};
+
+#define UDMABUF_FLAGS_CLOEXEC  0x01
+
+struct udmabuf_create {
+   __u32 flags;
+   __u32 niov;
+   struct udmabuf_iovec iovs[];
+};
+
+#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..664ab4ee4e
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,261 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct udmabuf {
+   u32 pagecount;
+   struct page **pages;
+   struct user_struct *owner;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+   struct vm_area_struct *vma = vmf->vma;
+   struct udmabuf *ubuf = vma->vm_private_data;
+
+   if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+   return VM_FAULT_SIGBUS;
+
+   vmf->page = ubuf->pages[vmf->pgoff];
+   get_page(vmf->page);
+   return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+   .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+   struct udmabuf *ubuf = buf->priv;
+
+   if ((vma->vm_flags & VM_SHARED) == 0)
+   return -EINVAL;
+
+   vma->vm_ops = _vm_ops;
+   vma->vm_private_data = ubuf;
+   return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+   enum dma_data_direction direction)
+{
+   struct udmabuf *ubuf = at->dmabuf->priv;
+   struct sg_table *sg;
+
+   sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+   if (!sg)
+   goto err1;
+   if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+   goto err2;
+   if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+   goto err3;
+
+   return sg;
+
+err3:
+   sg_free_table(sg);
+err2:
+   kfree(sg);
+err1:
+  

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Joe Perches]

On Fri, 2018-03-16 at 08:41 +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> > arguments that can be removed by creating separate functins.
> > 
> > Create specific functions for these calls to reduce x86/64 defconfig
> > size by ~20k.
> > 
> > Modify the existing macros to use the specific calls.
> > 
> > new:
> > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > 1876562   44542 995 1922099  1d5433 (TOTALS)
> > 
> > old:
> > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > 1897565   44542 995 1943102  1da63e (TOTALS)
> > 
> > Miscellanea:
> > 
> > o intel_display requires a change to use the specific calls.
> > 
> > Signed-off-by: Joe Perches 
> 
> Impressed with the size of the bikeshed piled on top of this I decided to
> cut this all short by merging it.

Thanks.

There was a similar patch for the DRM_DEV_ macros
awhile ago that also reduced object code.

https://lkml.org/lkml/2017/9/25/247

Never applied.

Want a remerge resend?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[kbuild test robot]

Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/matthew-s-atwood-intel-com/drm-dp-Correctly-mask-DP_TRAINING_AUX_RD_INTERVAL-values-for-DP-1-4/20180316-185136
config: i386-randconfig-x003-201810 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from drivers/gpu/drm/drm_dp_helper.c:23:
   drivers/gpu/drm/drm_dp_helper.c: In function 
'drm_dp_link_train_clock_recovery_delay':
   drivers/gpu/drm/drm_dp_helper.c:127:48: error: 'DP_REV_14' undeclared (first 
use in this function); did you mean 'DPCD_REV_14'?
 if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
   ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/drm_dp_helper.c:127:2: note: in expansion of macro 'if'
 if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
 ^~
   drivers/gpu/drm/drm_dp_helper.c:127:48: note: each undeclared identifier is 
reported only once for each function it appears in
 if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
   ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/drm_dp_helper.c:127:2: note: in expansion of macro 'if'
 if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
 ^~

vim +/if +127 drivers/gpu/drm/drm_dp_helper.c

  > 23  #include 
24  #include 
25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  
34  #include "drm_crtc_helper_internal.h"
35  
36  /**
37   * DOC: dp helpers
38   *
39   * These functions contain some common logic and helpers at various 
abstraction
40   * levels to deal with Display Port sink devices and related things 
like DP aux
41   * channel transfers, EDID reading over DP aux channels, decoding 
certain DPCD
42   * blocks, ...
43   */
44  
45  /* Helpers for DP link training */
46  static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int 
r)
47  {
48  return link_status[r - DP_LANE0_1_STATUS];
49  }
50  
51  static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
52   int lane)
53  {
54  int i = DP_LANE0_1_STATUS + (lane >> 1);
55  int s = (lane & 1) * 4;
56  u8 l = dp_link_status(link_status, i);
57  return (l >> s) & 0xf;
58  }
59  
60  bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
61int lane_count)
62  {
63  u8 lane_align;
64  u8 lane_status;
65  int lane;
66  
67  lane_align = dp_link_status(link_status,
68  DP_LANE_ALIGN_STATUS_UPDATED);
69  if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
70  return false;
71  for (lane = 0; lane < lane_count; lane++) {
72  lane_status = dp_get_lane_status(link_status, lane);
73  if ((lane_status & DP_CHANNEL_EQ_BITS) != 
DP_CHANNEL_EQ_BITS)
74  return false;
75  }
76  return true;
77  }
78  EXPORT_SYMBOL(drm_dp_channel_eq_ok);
79  
80  bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
81int lane_count)
82  {
83  int lane;
84  u8 lane_status;
85  
86  for (lane = 0; lane < lane_count; lane++) {
87  lane_status = dp_get_lane_status(link_status, lane);
88  if ((lane_status & DP_LANE_CR_DONE) == 0)
89  return false;
90  }
91  return true;
92  }
93  EXPORT_SYMBOL(drm_dp_clock_recovery_ok);
94  
95  u8 drm_dp_get_adjust_request_voltage(const u8 
link_status[DP_LINK_STATUS_SIZE],
96   int lane)
97  {
98  int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
99  int s = ((lane & 1) ?
   100   DP_ADJU

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #59 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey

Testing with llvm7 setup:


R600_DEBUG=notiling,norbplus xinit

does not avoid the hang :(

[   31.200134] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=7, last emitted seq=8
[   31.200147] [drm] IP block:gfx_v8_0 is hung!
[   31.200152] [drm] GPU recovery disabled.



GALLIUM_DDEBUG=flush xinit

Seems to have a (good) impact. Hang happened after around 20 boots.

[   13.389894] NET: Registered protocol family 39
[   28.640142] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=652, last emitted seq=654
[   28.640154] [drm] IP block:gfx_v8_0 is hung!
[   28.640160] [drm] GPU recovery disabled.
[  246.752083] INFO: task amdgpu_cs:0:636 blocked for more than 120 seconds.
[  246.752092]   Not tainted 4.16.0-rc4-qtec-standard #1
[  246.752095] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[  246.752099] amdgpu_cs:0 D0   636543 0x0008
[  246.752099] amdgpu_cs:0 D0   636543 0x0008
[  246.752103] Call Trace:
[  246.752115]  ? __schedule+0x25c/0x860
[  246.752122]  ? dma_fence_default_wait+0x10c/0x280
[  246.752124]  ? dma_fence_default_wait+0x1c8/0x280
[  246.752127]  schedule+0x2f/0x90
[  246.752130]  schedule_timeout+0x1f1/0x440
[  246.752220]  ? amdgpu_cs_bo_validate+0x7f/0x120 [amdgpu]
[  246.752276]  ? amdgpu_ttm_alloc_gart+0x5d/0x270 [amdgpu]
[  246.752284]  ? dma_fence_default_wait+0x10c/0x280
[  246.752287]  ? dma_fence_default_wait+0x1c8/0x280
[  246.752290]  dma_fence_default_wait+0x1f4/0x280
[  246.752294]  ? dma_fence_default_wait+0x280/0x280
[  246.752297]  dma_fence_wait_timeout+0x2e/0x100
[  246.752359]  amdgpu_ctx_wait_prev_fence+0x46/0x80 [amdgpu]
[  246.752418]  amdgpu_cs_ioctl+0x1f2/0x1af0 [amdgpu]
[  246.752478]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
[  246.752504]  drm_ioctl_kernel+0x59/0xb0 [drm]
[  246.752524]  drm_ioctl+0x29f/0x340 [drm]
[  246.752581]  ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
[  246.752630]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[  246.752635]  do_vfs_ioctl+0x8e/0x680
[  246.752641]  ? SyS_futex+0x11d/0x150
[  246.752644]  SyS_ioctl+0x74/0x80
[  246.752647]  ? get_vtime_delta+0xe/0x40
[  246.752650]  do_syscall_64+0x7b/0x1d0
[  246.752654]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  246.752658] RIP: 0033:0x3e292e57e7
[  246.752660] RSP: 002b:7f17a2924b88 EFLAGS: 0246 ORIG_RAX:
0010
[  246.752663] RAX: ffda RBX: 7f17a2924c78 RCX:
003e292e57e7
[  246.752664] RDX: 7f17a2924bf0 RSI: c0186444 RDI:
000d
[  246.752666] RBP: 7f17a2924bf0 R08: 7f17a2924ca0 R09:
7f17a2924c78
[  246.752667] R10: 7f17a2924ca0 R11: 0246 R12:
c0186444
[  246.752668] R13: 000d R14: 00d2c588 R15:
0002


kmscube git HEAD have not stalled after 50 attempts without any flag in
GALLIUM_DDEBUG or R600_DEBUG.

It might not be relevant, but my platform can only boot with BIOS (it is based
on coreboot). When you tried this bug did you tried with UEFI or BIOS?

Thanks

-- 
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 RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

Hi, Daniel!
Sorry, if I strip the patch too much below.

On 03/16/2018 10:23 AM, Daniel Vetter wrote:


S-o-b line went missing here :-)

will restore it back ;)


I've read through it, 2 actual review comments (around hot-unplug and
around the error recovery for failed flips), a few bikesheds, but looks
all reasonable to me. And much easier to read as one big patch (it's just
3k).

One more thing I'd do as a follow-up (don't rewrite everything, this is
close to merge, better to get it in first): You have a lot of indirections
and function calls across sources files. That's kinda ok if you have a
huge driver with 100+k lines of code where you have to split things up.
But for a small driver like yours here it's a bit overkill.

will review and try to rework after the driver is in


Personally I'd merge at least the xen backend stuff into the corresponding
kms code, but that's up to you.

I prefer to have it in smaller chunks and all related code at
one place, so it is easier to maintain. That is why I didn't
plumb frontend <-> backend code right into the KMS code.

And as mentioned, if you decide to do
that, a follow-up patch (once this has merged) is perfectly fine.

Ok, after the merge

-Daniel


+int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct sg_table *sgt)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, NULL, sgt);
+}
+
+int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct page **pages)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, pages, NULL);
+}

The above two wrappers seem a bit much, just to set sgt = NULL or pages =
NULL in one of them. I'd drop them, but that's a bikeshed so feel free to
ignore.

I had that the way you say in some of the previous implementations,
but finally decided to have these dummy wrappers: seems
to be cleaner this way

+static void displback_disconnect(struct xen_drm_front_info *front_info)
+{
+   bool removed = true;
+
+   if (front_info->drm_pdev) {
+   if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
+   DRM_WARN("DRM driver still in use, deferring 
removal\n");
+   removed = false;
+   } else
+   xen_drv_remove_internal(front_info);

Ok this logic here is fishy, since you're open-coding the drm unplug
infrastructure, but slightly differently and slightyl racy. If you have a
driver where your underlying "hw" (well it's virtual here, but same idea)
can disappear any time while userspace is still using the drm driver, you
need to use the drm_dev_unplug() function and related code.
drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
case.

Then you also have to guard all the driver entry points where you do
access the backchannel using drm_dev_is_unplugged() (I've seen a few of
those already). Then you can rip out all the logic here and the 
xen_drm_front_drv_is_used() helper.

Will rework it with drm_dev_unplug, thank you

I thought there's some patches from Noralf in-flight that improved the
docs on this, I need to check


+#define XEN_DRM_NUM_VIDEO_MODES1
+#define XEN_DRM_CRTC_VREFRESH_HZ   60
+
+static int connector_get_modes(struct drm_connector *connector)
+{
+   struct xen_drm_front_drm_pipeline *pipeline =
+   to_xen_drm_pipeline(connector);
+   struct drm_display_mode *mode;
+   struct videomode videomode;
+   int width, height;
+
+   mode = drm_mode_create(connector->dev);
+   if (!mode)
+   return 0;
+
+   memset(, 0, sizeof(videomode));
+   videomode.hactive = pipeline->width;
+   videomode.vactive = pipeline->height;
+   width = videomode.hactive + videomode.hfront_porch +
+   videomode.hback_porch + videomode.hsync_len;
+   height = videomode.vactive + videomode.vfront_porch +
+   videomode.vback_porch + videomode.vsync_len;
+   videomode.pixelclock = width * height * XEN_DRM_CRTC_VREFRESH_HZ;
+   mode->type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER;
+
+   drm_display_mode_from_videomode(, mode);
+   drm_mode_probed_add(connector, mode);
+   return XEN_DRM_NUM_VIDEO_MODES;

Bikeshed: just hardcode this to 1, the #define is imo more confusing.

ok, will remove #define



+
+   }
+   /*
+* Send page flip request to the backend *after* we have event cached
+* above, so on page flip done event from the backend we can
+* deliver it and there is no race condition between this code and
+* event from the backend.
+* If 

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #3 from Christian König  ---
(In reply to philipmorant from comment #2)
> Will this work with an HDMI to DVI-D cable then ?

No, DVI only supports up to 1920×1200 @ 60Hz with a single link.

It doesn't matter if the output is HDMI or DVI as long as your monitor only
supports DVI input.

What you can use is either an active DP to dual DVI converter (probably rather
expensive if such a thing even exists) or native DP/HDMI (if the monitor has
connectors for that).

-- 
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 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #2 from philipmor...@gmail.com ---
Will this work with an HDMI to DVI-D cable then ?

-- 
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 105530] Stuttering on Raven Ridge when TearFree is on

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-t...@lists.x.org   |
Version|git |unspecified
  Component|Driver/AMDgpu   |DRM/AMDgpu

--- Comment #4 from Michel Dänzer  ---
(In reply to txtsd from comment #0)
> The stuttering is caused by enabling TearFree via xrandr.
> When on `auto`, there is no stuttering, but when enabled by setting it to
> `on`, there is intense stuttering noticeable when dragging windows around,
> but it's also very noticeable when just moving the mouse around on the
> desktop with no windows open.

Since HW cursor updates are always supposed to work without delay, and there is
no sign of an issue in the attached userspace information, this seems like a
kernel (DC?) issue.

In the amd-gfx mailing list thread, you said that this started on 2018-03-07.
Is that just when you enabled TearFree for the first time, or did this actually
not happen with older kernels?

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

Re: [PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[jacopo mondi]

Hi Niklas,
   thanks for review,

On Fri, Mar 16, 2018 at 01:00:04AM +0100, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970:
> enable HDMI output' or something similar not yet in renesas-drivers
> repository correct?

Yes, I have listed dependencies of this series in my v1 cover letter:

---
The series is based on Laurent's drm/next/du branch with patches on top for:
- Sergei: Enable PFC, I2c, GPIOs for r8a77970
- Sergei: Add support for r8a77970 in DU and add display device nodes in
  r8a77970 DTSI
- Niklas: Connect DU LVDS output to HDMI bridge adv7511w in Eagle DTS
- Sergei: fix video output on R8A77970

A base branch with these patches applied is available at
git://jmondi.org/linux v3m/v4.16-rc3/base
---

My bad I have not reported this in all cover letters (and I have not
reported the full name of the series)

PFC, GPIO and I2c support I have listed as dependencies seems to have
landed in renesas-drivers, while I don't see yet:

Sergei:
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

whose patches for r8a77970 dtsi are included in yours:
[PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output

On top I also have Sergei's/Laurent's:
[PATCH v4] v4l: vsp1: Fix video output on R8A77970

>
> In the next version would you care to include the LVDS commit from the
> dependency  series and squash this change into that one or in some other
> good manger stack to two? Laurent told me he did not like 5/5 in that
> patch-set as it did not yet have the LVDS decoder node due to no driver
> existed at that time when I posted that even if it's not strictly needed
> to get the display working :-)


I'll let Simon suggest how he preferes to handle this, if he wants me
to re-submit your series with this patch squashed on top or he prefers
to deal with this himself.
>
> I also think you should split this last patch out to a separate series
> as it should go in Simon's tree while the driver and documentation is
> going in earlier in a different tree right?

I assume bindings and driver go through DRM and Simon is to pick up
the Eagle changes.

>
> On a side note, do you plan to update the Gen2 boards DTS files which
> also have a decoder which are not yet described in DT?

Actually I'm not aware of Gen2 boards with this chip and similar
display pipelines. Can you point me to which one needs to have its
DTS brushed?

Thanks
   j

>
> On 2018-03-15 17:11:56 +0100, Jacopo Mondi wrote:
> > The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> > decoder, connected to the on-chip LVDS encoder output on one side
> > and to HDMI encoder ADV7511w on the other one.
> >
> > As the decoder does not need any configuration it has been so-far
> > omitted from DTS. Now that a driver is available, describe it in DT
> > as well.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 
> > +++---
> >  1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
> > b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > index c0fd144..69f43b8 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > @@ -42,6 +42,33 @@
> > };
> > };
> > };
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +
> > +   thc63lvd1024_in_0: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +
> > +   port@2{
> > +   reg = <2>;
> > +
> > +   thc63lvd1024_out_2: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +
> > +   };
> > +
> > +   };
> > +   };
> >  };
> >
> >   {
> > @@ -98,7 +125,7 @@
> > port@0 {
> > reg = <0>;
> > adv7511_in: endpoint {
> > -   remote-endpoint = <_out>;
> > +   remote-endpoint = <_out_2>;
> > };
> > };
> >
> > @@ -152,8 +179,8 @@
> >
> > ports {
> > port@1 {
> > -   endpoint {
> > -   remote-endpoint = <_in>;
> > +   

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

[bugzilla-daemon]

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

Michel Dänzer (mic...@daenzer.net) changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #40 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to shibe from comment #39)
> Otherwise, it may be a race with GPU.

Yeah, things are pointing to something like that.

Harry, does anything jump out in dce5_crtc_load_lut, or can you think of
anything else that might affect this, possibly specific to DCE5 or Turks?

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