[Bug 200809] lightdm/Xorg freezes on startup everytime with amdgpu driver enabled on 4.18.0-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=200809 --- Comment #4 from Jaya Balan Aaron (bucket.s...@gmail.com) --- Unable to reproduce any error with HDMI display unplugged, primary display is being selected as VGA device. Kernel used: Problem is with kernel 4.18.0 build from a 3rd party => https://github.com/M-Bab/linux-kernel-amdgpu-binaries. Still see a lot of error traces and [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2! type 0 expected 3 Setting priority as low. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200809] lightdm/Xorg freezes on startup everytime with amdgpu driver enabled on 4.18.0-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=200809 --- Comment #5 from Jaya Balan Aaron (bucket.s...@gmail.com) --- Created attachment 277921 --> https://bugzilla.kernel.org/attachment.cgi?id=277921=edit dmesg of 4.18.0 kernel with drm.debug=4 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200809] lightdm/Xorg freezes on startup everytime with amdgpu driver enabled on 4.18.0-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=200809 Jaya Balan Aaron (bucket.s...@gmail.com) changed: What|Removed |Added Severity|blocking|low -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200809] lightdm/Xorg freezes on startup everytime with amdgpu driver enabled on 4.18.0-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=200809 --- Comment #3 from Jaya Balan Aaron (bucket.s...@gmail.com) --- Might have committed a blunder while testing. I have a "DELL ST2220L" connected on analog VGA and "Panasonic Tv" connected on HDMI. All the while primary might have been selected as the TV and the extended desktop presented on VGA line, which I mistook as a hung lightdm/Xorg. But also upgraded the kernel to latest from git. Will revert back to 4.18.1 and test further. Sorry if this lead to any waste of your time. -- 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 v6 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
From: "abhin...@codeaurora.org"
Add the device tree bindings for Truly NT35597 panel driver.
This panel driver supports both single DSI and dual DSI.
However, this patch series supports only dual DSI.
Changes in v6:
- Change the compatible string to indicate the
reference board and the panel
- Remove the display timing node
Signed-off-by: Abhinav Kumar
---
.../devicetree/bindings/display/truly,nt35597.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/truly,nt35597.txt
diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
b/Documentation/devicetree/bindings/display/truly,nt35597.txt
new file mode 100644
index 000..68960a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
@@ -0,0 +1,55 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "qcom,sdm845-mtp-2K-display"
+- vdda-supply: phandle of the regulator that provides the supply voltage
+ Power IC supply
+- vdispp-supply: phandle of the regulator that provides the supply voltage
+ for positive LCD bias
+- vdispn-supply: phandle of the regulator that provides the supply voltage
+ for negative LCD bias
+- reset-gpios: phandle of gpio for reset line
+ This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+ for single DSI or Dual DSI
+ This should be low for dual DSI and high for single DSI mode
+- ports: This device has two video ports driven by two DSIs. Their connections
+ are modelled using the OF graph bindings specified in
+ Documentation/devicetree/bindings/graph.txt.
+ - port@0: DSI input port driven by master DSI
+ - port@1: DSI input port driven by secondary DSI
+
+Example:
+
+ dsi@ae94000 {
+ panel@0 {
+ compatible = "qcom,sdm845-mtp-2K-display";
+ reg = <0>;
+ vdda-supply = <_l14>;
+ vdispp-supply = <_regulator>;
+ vdispn-supply = <_regulator>;
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <_dsi_active>;
+ pinctrl-1 = <_dsi_suspend>;
+
+ reset-gpios = < 6 0>;
+ mode-gpios = < 52 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel1_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the 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
[PATCH v6 1/2] drm/panel: Add support for Truly NT35597 panel driver
From: "abhin...@codeaurora.org"
Add support for Truly NT35597 panel driver used
in MSM reference platforms.
This panel driver supports both single DSI and dual DSI
modes.
However, this patch series adds support only for
dual DSI mode.
Changes in v6:
- Introduce panel config to store panel specific
details
- Bring back the size member for the panel command
structure to make the design more scalable
- Move the display mode from the DT to driver
- Change the compatible string to indicate which
which board and panel it will be used for
- Rename the functions to match the panel driver
- Have a data member for each compatible string
- Remove the panel commands split as its not
required for the panel init functionality
Signed-off-by: Archit Taneja
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-truly-nt35597.c | 705
3 files changed, 714 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..7ae74c2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,12 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TRULY_NT35597_WQXGA
+ tristate "Truly WQXGA"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
+ Video Mode panel
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..80fd19f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
new file mode 100644
index 000..691be03
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -0,0 +1,705 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const char * const regulator_names[] = {
+ "vdda",
+ "vdispp",
+ "vdispn",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10,
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100,
+};
+
+struct nt35597_config {
+ u32 width_mm;
+ u32 height_mm;
+ char panel_name[256];
+ void *panel_on_cmds;
+ u32 num_on_cmds;
+ struct drm_display_mode *dm;
+};
+
+struct truly_nt35597 {
+ struct device *dev;
+ struct drm_panel panel;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *mode_gpio;
+
+ struct backlight_device *backlight;
+
+ struct mipi_dsi_device *dsi[2];
+
+ const struct nt35597_config *config;
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
+{
+ return container_of(panel, struct truly_nt35597, panel);
+}
+
+#define MAX_LEN5
+#define SHORT_PACKET 2
+#define LONG_PACKET 4
+
+struct cmd_set {
+ u8 commands[MAX_LEN];
+ int size;
+};
+
+static struct cmd_set qcom_2k_panel_magic_cmds[] = {
+ /* CMD2_P0 */
+ { { 0xff, 0x20 }, 2 },
+ { { 0xfb, 0x01 }, 2 },
+ { { 0x00, 0x01 }, 2 },
+ { { 0x01, 0x55 }, 2 },
+ { { 0x02, 0x45 }, 2 },
+ { { 0x05, 0x40 }, 2 },
+ { { 0x06, 0x19 }, 2 },
+ { { 0x07, 0x1e }, 2 },
+ { { 0x0b, 0x73 }, 2 },
+ { { 0x0c, 0x73 }, 2 },
+ { { 0x0e, 0xb0 }, 2 },
+ { { 0x0f, 0xae }, 2 },
+ { { 0x11, 0xb8 }, 2 },
+ { { 0x13, 0x00 }, 2 },
+ { { 0x58, 0x80 }, 2 },
+ { { 0x59, 0x01 }, 2 },
+ { { 0x5a, 0x00 }, 2 },
+ { { 0x5b, 0x01 }, 2 },
+ { { 0x5c, 0x80 }, 2 },
+ { { 0x5d, 0x81 }, 2 },
+ { { 0x5e, 0x00 }, 2 },
+ { { 0x5f, 0x01 }, 2 },
+ { { 0x72, 0x11 }, 2 },
+ { { 0x68, 0x03 }, 2 },
+ /* CMD2_P4 */
+ { { 0xFF, 0x24 }, 2 },
+ { { 0xFB, 0x01 }, 2 },
+ { { 0x00, 0x1C }, 2 },
+ { { 0x01, 0x0B }, 2 },
+ { { 0x02, 0x0C }, 2 },
+ { { 0x03,
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #47 from Andrey Grodzovsky --- Created attachment 141174 --> https://bugs.freedesktop.org/attachment.cgi?id=141174=edit add_debug_info.patch A am attaching a basic debug patch, please try to apply it. It should give a bit more info in dmesg whe VM fault happens. I wasn't able to test it on my system so it might be buggy or crash. Reproduce again like before with the cmd-trace like before and once the fault happens if possible try quickly run sudo umr -O halt_waves -wa and only if you still have running system after that do the sudo umr -O verbose -R gfx[.] The driver should be loaded amdgpu.vm_fault_stop=2 from grub Also check if adding amdgpu.vm_debug=1 makes the issue reproduce more quickly -- 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] mach64: detect the dot clock divider correctly on sparc
From: Mikulas Patocka Date: Fri, 17 Aug 2018 15:19:37 -0400 (EDT) > On Sun Ultra 5, it happens that the dot clock is not set up properly for > some videomodes. For example, if we set the videomode "r1024x768x60" in > the firmware, Linux would incorrectly set a videomode with refresh rate > 180Hz when booting (suprisingly, my LCD monitor can display it, although > display quality is very low). > > The reason is this: Older mach64 cards set the divider in the register > VCLK_POST_DIV. The register has four 2-bit fields (the field that is > actually used is specified in the lowest two bits of the register > CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards, > there's another bit added - the top four bits of PLL_EXT_CNTL extend the > divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12". > The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets > them, so it can work regardless if the card supports them. However, the > sparc64 firmware may set these extended dividers during boot - and the > mach64 driver detects incorrect dot clock in this case. > > This patch makes the driver read the additional divider bit from > PLL_EXT_CNTL and calculate the initial refresh rate properly. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org Acked-by: David S. Miller ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
This patch needs to now incorporate the newly added slice_row_per_frame
parameter in PPS_16.
Anusha
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 31, 2018 2:07 PM
>To: intel-...@lists.freedesktop.org
>Cc: Navare, Manasi D ; Singh, Gaurav K
>; dri-devel@lists.freedesktop.org; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; Harry Wentland
>
>Subject: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS
>infoframe
>
>This patch defines a new header file for all the DSC 1.2 structures and
>creates a
>structure for PPS infoframe which will be used to send picture parameter set
>secondary data packet for display stream compression.
>All the PPS infoframe syntax elements are taken from DSC 1.2 specification from
>VESA.
>
>Cc: Gaurav K Singh
>Cc: dri-devel@lists.freedesktop.org
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Cc: Harry Wentland
>Signed-off-by: Manasi Navare
>---
> include/drm/drm_dsc.h | 365
>++
> 1 file changed, 365 insertions(+)
> create mode 100644 include/drm/drm_dsc.h
>
>diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h new file mode
>100644 index 000..678e8e6
>--- /dev/null
>+++ b/include/drm/drm_dsc.h
>@@ -0,0 +1,365 @@
>+/*
>+ * Copyright (C) 2018 Intel Corp.
>+ *
>+ * Permission is hereby granted, free of charge, to any person
>+obtaining a
>+ * copy of this software and associated documentation files (the
>+"Software"),
>+ * to deal in the Software without restriction, including without
>+limitation
>+ * the rights to use, copy, modify, merge, publish, distribute,
>+sublicense,
>+ * and/or sell copies of the Software, and to permit persons to whom
>+the
>+ * Software is furnished to do so, subject to the following conditions:
>+ *
>+ * The above copyright notice and this permission notice shall be
>+included in
>+ * all copies or substantial portions of the Software.
>+ *
>+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>+EXPRESS OR
>+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>+MERCHANTABILITY,
>+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>EVENT
>+SHALL
>+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
>+ *
>+ * Authors:
>+ * Manasi Navare */
>+
>+#ifndef DRM_DSC_H_
>+#define DRM_DSC_H_
>+
>+#include
>+
>+/* VESA Display Stream Compression DSC 1.2 constants */
>+#define DSC_NUM_BUF_RANGES15
>+
>+/**
>+ * struct picture_parameter_set - Represents 128 bytes of Picture
>+Parameter Set
>+ *
>+ * The VESA DSC standard defines picture parameter set (PPS) which
>+display
>+ * stream compression encoders must communicate to decoders.
>+ * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
>+fields in
>+ * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
>+ * The PPS fields that span over more than a byte should be stored in
>+Big Endian
>+ * format.
>+ */
>+struct picture_parameter_set {
>+ /**
>+ * @dsc_version:
>+ * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
>+ * PPS0[7:4] - dsc_version_major: Contains major version of DSC
>+ */
>+ u8 dsc_version;
>+ /**
>+ * @pps_identifier:
>+ * PPS1[7:0] - Application specific identifier that can be
>+ * used to differentiate between different PPS tables.
>+ */
>+ u8 pps_identifier;
>+ /**
>+ * @pps_reserved:
>+ * PPS2[7:0]- RESERVED Byte
>+ */
>+ u8 pps_reserved;
>+ /**
>+ * @pps_3:
>+ * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
>+ * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
>+ * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
>+ * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
>+ * PPS3[7:4] - bits_per_component: Bits per component for the original
>+ * pixels of the encoded picture.
>+ * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
>+ * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
>+ * allowed only when dsc_minor_version = 0x2)
>+ */
>+ u8 pps_3;
>+ /**
>+ * @pps_4:
>+ * PPS4[1:0] -These are the most significant 2 bits of
>+ * compressed BPP bits_per_pixel[9:0] syntax element.
>+ * PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
>+ * PPS4[3] - simple_422: Indicates if decoder drops samples to
>+ * reconstruct the 4:2:2 picture.
>+ * PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
>+ * active.
>+ * PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
>+ * groups in picture
>+ * PPS4[7:6] - Reseved bits
>+ */
>+ u8 pps_4;
>+
[PATCH] atyfb: fix debugging printks
This patch fixes the debugging printks. Use pr_cont, so that the lines are
not broken up. Use printk when starting a new line (a long string of
pr_cont's without any printks causes missing characters in the console
output on sparc).
Signed-off-by: Mikulas Patocka
---
drivers/video/fbdev/aty/atyfb_base.c | 36 +++
1 file changed, 20 insertions(+), 16 deletions(-)
Index: linux-stable/drivers/video/fbdev/aty/atyfb_base.c
===
--- linux-stable.orig/drivers/video/fbdev/aty/atyfb_base.c 2018-08-15
19:45:56.0 +0200
+++ linux-stable/drivers/video/fbdev/aty/atyfb_base.c 2018-08-15
20:46:52.0 +0200
@@ -1480,24 +1480,28 @@ static int atyfb_set_par(struct fb_info
base = 0x2000;
printk("debug atyfb: Mach64 non-shadow register values:");
for (i = 0; i < 256; i = i+4) {
- if (i % 16 == 0)
- printk("\ndebug atyfb: 0x%04X: ", base + i);
- printk(" %08X", aty_ld_le32(i, par));
+ if (i % 16 == 0) {
+ pr_cont("\n");
+ printk("debug atyfb: 0x%04X: ", base + i);
+ }
+ pr_cont(" %08X", aty_ld_le32(i, par));
}
- printk("\n\n");
+ pr_cont("\n\n");
#ifdef CONFIG_FB_ATY_CT
/* PLL registers */
base = 0x00;
printk("debug atyfb: Mach64 PLL register values:");
for (i = 0; i < 64; i++) {
- if (i % 16 == 0)
- printk("\ndebug atyfb: 0x%02X: ", base + i);
+ if (i % 16 == 0) {
+ pr_cont("\n");
+ printk("debug atyfb: 0x%02X: ", base + i);
+ }
if (i % 4 == 0)
- printk(" ");
- printk("%02X", aty_ld_pll_ct(i, par));
+ pr_cont(" ");
+ pr_cont("%02X", aty_ld_pll_ct(i, par));
}
- printk("\n\n");
+ pr_cont("\n\n");
#endif /* CONFIG_FB_ATY_CT */
#ifdef CONFIG_FB_ATY_GENERIC_LCD
@@ -1509,19 +1513,19 @@ static int atyfb_set_par(struct fb_info
for (i = 0; i <= POWER_MANAGEMENT; i++) {
if (i == EXT_VERT_STRETCH)
continue;
- printk("\ndebug atyfb: 0x%04X: ",
+ pr_cont("\ndebug atyfb: 0x%04X: ",
lt_lcd_regs[i]);
- printk(" %08X", aty_ld_lcd(i, par));
+ pr_cont(" %08X", aty_ld_lcd(i, par));
}
} else {
for (i = 0; i < 64; i++) {
if (i % 4 == 0)
- printk("\ndebug atyfb: 0x%02X: ",
+ pr_cont("\ndebug atyfb: 0x%02X: ",
base + i);
- printk(" %08X", aty_ld_lcd(i, par));
+ pr_cont(" %08X", aty_ld_lcd(i, par));
}
}
- printk("\n\n");
+ pr_cont("\n\n");
}
#endif /* CONFIG_FB_ATY_GENERIC_LCD */
}
@@ -2597,8 +2601,8 @@ static int aty_init(struct fb_info *info
aty_ld_le32(DSP_ON_OFF, par),
aty_ld_le32(CLOCK_CNTL, par));
for (i = 0; i < 40; i++)
- printk(" %02x", aty_ld_pll_ct(i, par));
- printk("\n");
+ pr_cont(" %02x", aty_ld_pll_ct(i, par));
+ pr_cont("\n");
}
#endif
if (par->pll_ops->init_pll)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] mach64: detect the dot clock divider correctly on sparc
On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display quality is very low).
The reason is this: Older mach64 cards set the divider in the register
VCLK_POST_DIV. The register has four 2-bit fields (the field that is
actually used is specified in the lowest two bits of the register
CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
there's another bit added - the top four bits of PLL_EXT_CNTL extend the
divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
them, so it can work regardless if the card supports them. However, the
sparc64 firmware may set these extended dividers during boot - and the
mach64 driver detects incorrect dot clock in this case.
This patch makes the driver read the additional divider bit from
PLL_EXT_CNTL and calculate the initial refresh rate properly.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/aty/atyfb.h |3 ++-
drivers/video/fbdev/aty/atyfb_base.c |7 ---
drivers/video/fbdev/aty/mach64_ct.c | 10 +-
3 files changed, 11 insertions(+), 9 deletions(-)
Index: linux-stable/drivers/video/fbdev/aty/atyfb.h
===
--- linux-stable.orig/drivers/video/fbdev/aty/atyfb.h 2018-08-13
21:12:11.0 +0200
+++ linux-stable/drivers/video/fbdev/aty/atyfb.h2018-08-13
21:17:14.0 +0200
@@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_
extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll
*pll);
extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
+extern const u8 aty_postdividers[8];
+
/*
* Hardware cursor support
@@ -359,7 +361,6 @@ static inline void wait_for_idle(struct
extern void aty_reset_engine(const struct atyfb_par *par);
extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
-extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
Index: linux-stable/drivers/video/fbdev/aty/atyfb_base.c
===
--- linux-stable.orig/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
21:12:11.0 +0200
+++ linux-stable/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
21:22:23.0 +0200
@@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_
/*
* PLL Reference Divider M:
*/
- M = pll_regs[2];
+ M = pll_regs[PLL_REF_DIV];
/*
* PLL Feedback Divider N (Dependent on CLOCK_CNTL):
*/
- N = pll_regs[7 + (clock_cntl & 3)];
+ N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
/*
* PLL Post Divider P (Dependent on CLOCK_CNTL):
*/
- P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
+ P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl
& 3) << 1)) & 3) |
+((pll_regs[PLL_EXT_CNTL] >> (2 +
(clock_cntl & 3))) & 4)];
/*
* PLL Divider Q:
Index: linux-stable/drivers/video/fbdev/aty/mach64_ct.c
===
--- linux-stable.orig/drivers/video/fbdev/aty/mach64_ct.c 2018-08-13
21:12:11.0 +0200
+++ linux-stable/drivers/video/fbdev/aty/mach64_ct.c2018-08-13
21:35:32.0 +0200
@@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8
*/
#define Maximum_DSP_PRECISION 7
-static u8 postdividers[] = {1,2,4,8,3};
+const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
static int aty_dsp_gt(const struct fb_info *info, u32 bpp, struct pll_ct *pll)
{
@@ -222,7 +222,7 @@ static int aty_valid_pll_ct(const struct
pll->vclk_post_div += (q < 64*8);
pll->vclk_post_div += (q < 32*8);
}
- pll->vclk_post_div_real = postdividers[pll->vclk_post_div];
+ pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];
//pll->vclk_post_div <<= 6;
pll->vclk_fb_div = q * pll->vclk_post_div_real / 8;
pllvclk = (100 * 2 * pll->vclk_fb_div) /
@@ -513,7 +513,7 @@ static int aty_init_pll_ct(const struct
u8 mclk_fb_div, pll_ext_cntl;
pll->ct.pll_ref_div = aty_ld_pll_ct(PLL_REF_DIV, par);
pll_ext_cntl = aty_ld_pll_ct(PLL_EXT_CNTL, par);
- pll->ct.xclk_post_div_real =
[PATCH] mach64: fix console corruption in 24bpp mode
There's console font corruption when using the mach64 driver in 24bpp
mode.
In 24bpp mode, the mach64 accelerator is set up for 8-bpp mode (with
horizontal width and stride multiplied by 3). In this mode, the
accelerator can't even possibly support color expansion. Consquently, we
have to use an unaccelerated function cfb_imageblit for color expansion.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/video/fbdev/aty/mach64_accel.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-stable/drivers/video/fbdev/aty/mach64_accel.c
===
--- linux-stable.orig/drivers/video/fbdev/aty/mach64_accel.c2018-04-20
18:11:01.0 +0200
+++ linux-stable/drivers/video/fbdev/aty/mach64_accel.c 2018-08-13
17:37:04.0 +0200
@@ -291,7 +291,8 @@ void atyfb_imageblit(struct fb_info *inf
if (!image->width || !image->height)
return;
if (!par->accel_flags ||
- (image->depth != 1 && info->var.bits_per_pixel != image->depth)) {
+ (image->depth != 1 && info->var.bits_per_pixel != image->depth) ||
+ (image->depth == 1 && info->var.bits_per_pixel == 24)) {
cfb_imageblit(info, image);
return;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: fix a compile warning
On 08/16/2018 08:09 PM, Wen Yang wrote:
> Fix comile warning like,
> CC [M] drivers/gpu/drm/i915/gvt/execlist.o
> CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
> CC [M] drivers/gpu/drm/radeon/btc_dpm.o
> CC [M] drivers/isdn/hisax/avm_a1p.o
> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.o
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
> function ‘dcn10_update_mpcc’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
> warning: missing braces around initializer [-Wmissing-braces]
> struct mpcc_blnd_cfg blnd_cfg = {0};
> ^
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
> warning: (near initialization for ‘blnd_cfg.black_color’) [-Wmissing-braces]
>
> Signed-off-by: Wen Yang
> Reviewed-by: Jiang Biao
works for me. Thanks.
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index cfcc54f..a06a035 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -1900,7 +1900,7 @@ static void update_dpp(struct dpp *dpp, struct
> dc_plane_state *plane_state)
> static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
> {
> struct hubp *hubp = pipe_ctx->plane_res.hubp;
> - struct mpcc_blnd_cfg blnd_cfg = {0};
> + struct mpcc_blnd_cfg blnd_cfg = {{0}};
> bool per_pixel_alpha = pipe_ctx->plane_state->per_pixel_alpha &&
> pipe_ctx->bottom_pipe;
> int mpcc_id;
> struct mpcc *new_mpcc;
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/disp/dpu: Use proper define for drm_encoder_init() 'encoder_type'
On 8/17/2018 5:06 AM, Stephen Boyd wrote:
We got a bug report that this function oopses when trying to do a kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27: ffd8 x26:
x25: ff8008c216c8 x24:
x23: x22: ff80095fb720
x21: x20: ff80095fb720
x19: ff80095fb6f0 x18: 000a
x17: b42ba473 x16: ff800805bbe8
x15: 000a157d x14: 000c
x13: x12: 000f
x11: 0003 x10: 0001
x9 : 0040 x8 : 001c
x7 : x6 :
x5 : 0228 x4 :
x3 : 0a00ff04 x2 : 7961
x1 : x0 :
Process kworker/3:1 (pid: 61, stack limit = 0xff80095f8000)
Call trace:
Exception stack(0xff80095fb400 to 0xff80095fb540)
b400: 7961 0a00ff04
b420: 0228
b440: 001c 0040 0001 0003
b460: 000f 000c 000a157d
b480: ff800805bbe8 b42ba473 000a ff80095fb6f0
b4a0: ff80095fb720 ff80095fb720
b4c0: ff8008c216c8 ffd8
b4e0: ff8008ad42bc ff80095fb540 ff80088d5fc4 ff80095fb540
b500: ff80088d35d8 a0c00049 ff80095fb550 ff80080d06a4
b520: ff80088d5e0c ff80095fb540 ff80088d35d8
[] string+0x2c/0x60
[] vsnprintf+0x28c/0x4ec
[] kvasprintf+0x68/0x100
[] kasprintf+0x60/0x80
[] drm_encoder_init+0x134/0x164
[] dpu_encoder_init+0x60/0x94
[] _dpu_kms_drm_obj_init+0xa0/0x424
[] dpu_kms_hw_init+0x61c/0x6bc
[] msm_drm_bind+0x380/0x67c
[] try_to_bring_up_master+0x228/0x264
[] component_master_add_with_match+0x90/0xc0
[] msm_pdev_probe+0x260/0x2c8
[] platform_drv_probe+0x58/0xa8
[] driver_probe_device+0x2d8/0x40c
[] __device_attach_driver+0xd4/0x10c
[] bus_for_each_drv+0xb4/0xd0
[] __device_attach+0xd0/0x160
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x38/0x98
[] deferred_probe_work_func+0x144/0x148
[] process_one_work+0x218/0x3bc
[] process_scheduled_works+0x44/0x48
[] worker_thread+0x288/0x32c
[] kthread+0x134/0x13c
[] ret_from_fork+0x10/0x18
Code: 910003fd 2a0403e6 eb0400ff 5460 (38646845)
Looking at the code I see that drm_encoder_init() is called from the DPU
code with 'DRM_MODE_CONNECTOR_DSI' passed in as the 'encoder_type'
argument (follow from _dpu_kms_initialize_dsi()). That corresponds to
the integer 16. That is then indexed into drm_encoder_enum_list in
drm_encoder_init() to look up the name of the encoder. If you're still
following along, that's an encoder not a connector! We really want to
use DRM_MODE_ENCODER_DSI (integer 6) instead of DRM_MODE_CONNECTOR_DSI
here, or we'll go out of bounds of the encoder array. Pass the right
thing and everything is fine.
Cc: Jeykumar Sankaran
Cc: Jordan Crouse
Cc: Sean Paul
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7dd6bd2d6d37..74cc204b07e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -450,7 +450,7 @@ static void _dpu_kms_initialize_dsi(struct drm_device *dev,
int i, rc;
/*TODO: Support two independent DSI connectors */
- encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
if (IS_ERR_OR_NULL(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
return;
I have tested this on sdm845 mtp and it does fix the issue.
Tested-by: Sai Prakash Ranjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200809] lightdm/Xorg freezes on startup everytime with amdgpu driver enabled on 4.18.0-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=200809 --- Comment #2 from Jaya Balan Aaron (bucket.s...@gmail.com) --- Problem is with kernel 4.18.0-rc8 build from a 3rd party => https://github.com/M-Bab/linux-kernel-amdgpu-binaries. Not sure if the amd-staging-drm-next is in it. It only says: "Kernel source code of amd-staging with DAL and latest security patches". So I doubt it has "amd-staging-drm-next". Seems like 4.18.1 is latest stable, will compile that myself tonight and check if i'm able to reproduce. Will get back with more details. -- 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: Use horizontal and vertical chroma subsampling factor while calculating offsets in the physical address of framebuffer
For multi-planar formats, while calculating offsets in planes with index
greater than 0
(ie second plane, third plane, etc), one needs to divide (src_x * cpp) with
horizontal
chroma subsampling factor and (src_y * pitch) with vertical chroma subsampling
factor.
The reason being that the planes contain subsampled (ie reduced) data (by a
factor of 2) and thus the
while calculating the byte position coresponding to the x and y co-ordinates,
one needs to be
divide it with the sampling factor.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/drm_fb_cma_helper.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index b127061..47e0e2f 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -86,14 +86,21 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
{
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
+ u8 h_div = 1, v_div = 1;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
return 0;
paddr = obj->paddr + fb->offsets[plane];
- paddr += fb->format->cpp[plane] * (state->src_x >> 16);
- paddr += fb->pitches[plane] * (state->src_y >> 16);
+
+ if (plane > 0) {
+ h_div = fb->format->hsub;
+ v_div = fb->format->vsub;
+ }
+
+ paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
+ paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
return paddr;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/disp/dpu: Use proper define for drm_encoder_init() 'encoder_type'
On 2018-08-16 16:36, Stephen Boyd wrote:
We got a bug report that this function oopses when trying to do a
kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27: ffd8 x26:
x25: ff8008c216c8 x24:
x23: x22: ff80095fb720
x21: x20: ff80095fb720
x19: ff80095fb6f0 x18: 000a
x17: b42ba473 x16: ff800805bbe8
x15: 000a157d x14: 000c
x13: x12: 000f
x11: 0003 x10: 0001
x9 : 0040 x8 : 001c
x7 : x6 :
x5 : 0228 x4 :
x3 : 0a00ff04 x2 : 7961
x1 : x0 :
Process kworker/3:1 (pid: 61, stack limit = 0xff80095f8000)
Call trace:
Exception stack(0xff80095fb400 to 0xff80095fb540)
b400: 7961
0a00ff04
b420: 0228
b440: 001c 0040 0001
0003
b460: 000f 000c
000a157d
b480: ff800805bbe8 b42ba473 000a
ff80095fb6f0
b4a0: ff80095fb720 ff80095fb720
b4c0: ff8008c216c8
ffd8
b4e0: ff8008ad42bc ff80095fb540 ff80088d5fc4
ff80095fb540
b500: ff80088d35d8 a0c00049 ff80095fb550
ff80080d06a4
b520: ff80088d5e0c ff80095fb540
ff80088d35d8
[] string+0x2c/0x60
[] vsnprintf+0x28c/0x4ec
[] kvasprintf+0x68/0x100
[] kasprintf+0x60/0x80
[] drm_encoder_init+0x134/0x164
[] dpu_encoder_init+0x60/0x94
[] _dpu_kms_drm_obj_init+0xa0/0x424
[] dpu_kms_hw_init+0x61c/0x6bc
[] msm_drm_bind+0x380/0x67c
[] try_to_bring_up_master+0x228/0x264
[] component_master_add_with_match+0x90/0xc0
[] msm_pdev_probe+0x260/0x2c8
[] platform_drv_probe+0x58/0xa8
[] driver_probe_device+0x2d8/0x40c
[] __device_attach_driver+0xd4/0x10c
[] bus_for_each_drv+0xb4/0xd0
[] __device_attach+0xd0/0x160
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x38/0x98
[] deferred_probe_work_func+0x144/0x148
[] process_one_work+0x218/0x3bc
[] process_scheduled_works+0x44/0x48
[] worker_thread+0x288/0x32c
[] kthread+0x134/0x13c
[] ret_from_fork+0x10/0x18
Code: 910003fd 2a0403e6 eb0400ff 5460 (38646845)
Looking at the code I see that drm_encoder_init() is called from the
DPU
code with 'DRM_MODE_CONNECTOR_DSI' passed in as the 'encoder_type'
argument (follow from _dpu_kms_initialize_dsi()). That corresponds to
the integer 16. That is then indexed into drm_encoder_enum_list in
drm_encoder_init() to look up the name of the encoder. If you're still
following along, that's an encoder not a connector! We really want to
use DRM_MODE_ENCODER_DSI (integer 6) instead of DRM_MODE_CONNECTOR_DSI
here, or we'll go out of bounds of the encoder array. Pass the right
thing and everything is fine.
Cc: Jeykumar Sankaran
Cc: Jordan Crouse
Cc: Sean Paul
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Stephen Boyd
---
Reviewed-by: Jeykumar Sankaran
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7dd6bd2d6d37..74cc204b07e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -450,7 +450,7 @@ static void _dpu_kms_initialize_dsi(struct
drm_device
*dev,
int i, rc;
/*TODO: Support two independent DSI connectors */
- encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
if (IS_ERR_OR_NULL(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
return;
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107607] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - enc1_stream_encoder_dp_blank line:804
https://bugs.freedesktop.org/show_bug.cgi?id=107607 Bug ID: 107607 Summary: [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - enc1_stream_encoder_dp_blank line:804 Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: pmenzel+bugs.freedesk...@molgen.mpg.de Created attachment 141169 --> https://bugs.freedesktop.org/attachment.cgi?id=141169=edit Linux 4.18+ messages Using the tiled/MST monitor Dell UP3214Q connected over DisplayPort with the MSI B350M MORTAR (MS-7A37) with the Raven device Ryzen 3 2200G causes problems when switching the inputs of the monitor (two systems are connected). I believe the monitor firmware is buggy, but the problems do not happen with Microsoft Windows. [ 2366.214057] [drm] DM_MST: stopping TM on aconnector: 9b429054 [id: 51] [ 2366.214456] [drm] Cannot find any crtc or sizes [ 2366.214461] [drm] DM_MST: Disabling connector: 8d721c89 [id: 56] [master: 9b429054] [ 2366.214594] [drm] DM_MST: Disabling connector: 0f6ee0cf [id: 60] [master: 9b429054] [ 2366.214730] [drm] Cannot find any crtc or sizes [ 2366.282730] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - enc1_stream_encoder_dp_blank line:804 [ 2366.282785] WARNING: CPU: 0 PID: 13 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [ 2366.282787] Modules linked in: fuse snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep amdgpu snd_pcm snd_timer r8169 snd crct10dif_pclmul soundcore crc32_pclmul k10temp ghash_clmulni_intel chash gpu_sched i2c_piix4 wmi video crc32c_intel xhci_pci xhci_hcd [ 2366.282801] CPU: 0 PID: 13 Comm: kworker/0:1 Tainted: GW 4.18.0-08135-g7cfc03071f97 #85 [ 2366.282802] Hardware name: MSI MS-7A37/B350M MORTAR (MS-7A37), BIOS 1.G1 05/17/2018 [ 2366.282807] Workqueue: events drm_mode_rmfb_work_fn [ 2366.282844] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [ 2366.282846] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 f8 27 5b c0 e8 c4 37 05 db 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [ 2366.282848] RSP: 0018:b5e201923a28 EFLAGS: 00010297 [ 2366.282849] RAX: RBX: 000a RCX: [ 2366.282851] RDX: RSI: 92509e815508 RDI: 92509e815508 [ 2366.282852] RBP: 92508d225600 R08: 9b516e40 R09: 00010200 [ 2366.282853] R10: 92509ee28658 R11: 9c9303cd R12: 0bb9 [ 2366.282854] R13: 58cc R14: 0001 R15: [ 2366.282856] FS: () GS:92509e80() knlGS: [ 2366.282857] CS: 0010 DS: ES: CR0: 80050033 [ 2366.282858] CR2: 559c01161ef0 CR3: 0003d62df000 CR4: 003406f0 [ 2366.282859] Call Trace: [ 2366.282901] enc1_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [ 2366.282940] core_link_disable_stream+0x54/0x220 [amdgpu] [ 2366.282981] reset_hw_ctx_wrap+0x241/0x250 [amdgpu] [ 2366.283020] dce110_apply_ctx_to_hw+0x45/0x650 [amdgpu] [ 2366.283061] ? dcn10_verify_allow_pstate_change_high+0x1d/0x240 [amdgpu] [ 2366.283098] dc_commit_state+0x2dc/0x550 [amdgpu] [ 2366.283140] amdgpu_dm_atomic_commit_tail+0x37a/0xd80 [amdgpu] [ 2366.283144] ? create_object+0x23e/0x290 [ 2366.283147] ? _cond_resched+0x15/0x30 [ 2366.283148] ? wait_for_completion_timeout+0x3a/0x180 [ 2366.283150] ? wait_for_completion_interruptible+0x35/0x1b0 [ 2366.283153] commit_tail+0x3d/0x70 [ 2366.283155] drm_atomic_helper_commit+0x103/0x110 [ 2366.283157] drm_framebuffer_remove+0x347/0x3c0 [ 2366.283160] drm_mode_rmfb_work_fn+0x4f/0x60 [ 2366.283163] process_one_work+0x19b/0x350 [ 2366.283165] worker_thread+0x30/0x370 [ 2366.283167] ? rescuer_thread+0x320/0x320 [ 2366.283169] kthread+0x112/0x130 [ 2366.283170] ? kthread_create_worker_on_cpu+0x70/0x70 [ 2366.283173] ret_from_fork+0x22/0x40 [ 2366.283174] ---[ end trace 71abef89afed8778 ]--- -- 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 107604] tes dhfhdghgdfgdshgfhs
https://bugs.freedesktop.org/show_bug.cgi?id=107604 Daniel Stone changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Group||spam -- 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/scheduler: Add stopped flag to drm_sched_entity
The flag will prevent another thread from same process to
reinsert the entity queue into scheduler's rq after it was already
removed from there by another thread during drm_sched_entity_flush.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 +-
include/drm/gpu_scheduler.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 1416edb..07cfe63 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -177,8 +177,12 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
/* For killed process disable any more IBs enqueue right now */
last_user = cmpxchg(>last_user, current->group_leader, NULL);
if ((!last_user || last_user == current->group_leader) &&
- (current->flags & PF_EXITING) && (current->exit_code == SIGKILL))
+ (current->flags & PF_EXITING) && (current->exit_code == SIGKILL)) {
+ spin_lock(>rq_lock);
+ entity->stopped = true;
drm_sched_rq_remove_entity(entity->rq, entity);
+ spin_unlock(>rq_lock);
+ }
return ret;
}
@@ -504,6 +508,10 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job,
if (first) {
/* Add the entity to the run queue */
spin_lock(>rq_lock);
+ if (entity->stopped) {
+ spin_unlock(>rq_lock);
+ return;
+ }
drm_sched_rq_add_entity(entity->rq, entity);
spin_unlock(>rq_lock);
drm_sched_wakeup(entity->rq->sched);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 919ae57..daec50f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -70,6 +70,7 @@ enum drm_sched_priority {
* @fini_status: contains the exit status in case the process was signalled.
* @last_scheduled: points to the finished fence of the last scheduled job.
* @last_user: last group leader pushing a job into the entity.
+ * @stopped: Marks the enity as removed from rq and destined for termination.
*
* Entities will emit jobs in order to their corresponding hardware
* ring, and the scheduler will alternate between entities based on
@@ -92,6 +93,7 @@ struct drm_sched_entity {
atomic_t*guilty;
struct dma_fence*last_scheduled;
struct task_struct *last_user;
+ boolstopped;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 34f34823bab5..77898c95bef6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
aconnector->dc_sink = sink;
if (sink->dc_edid.length == 0) {
aconnector->edid = NULL;
+ drm_dp_cec_unset_edid(>dm_dp_aux.aux);
} else {
aconnector->edid =
(struct edid *) sink->dc_edid.raw_edid;
@@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
drm_connector_update_edid_property(connector,
aconnector->edid);
+ drm_dp_cec_set_edid(>dm_dp_aux.aux,
+ aconnector->edid);
}
amdgpu_dm_add_sink_to_freesync_module(connector,
aconnector->edid);
} else {
+ drm_dp_cec_unset_edid(>dm_dp_aux.aux);
amdgpu_dm_remove_sink_from_freesync_module(connector);
drm_connector_update_edid_property(connector, NULL);
aconnector->num_modes = 0;
@@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
drm_kms_helper_hotplug_event(dev);
}
}
+
if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
- (dc_link->type == dc_connection_mst_branch))
+ (dc_link->type == dc_connection_mst_branch)) {
dm_handle_hpd_rx_irq(aconnector);
+ }
- if (dc_link->type != dc_connection_mst_branch)
+ if (dc_link->type != dc_connection_mst_branch) {
+ drm_dp_cec_irq(>dm_dp_aux.aux);
mutex_unlock(>hpd_lock);
+ }
}
static void register_hpd_handlers(struct amdgpu_device *adev)
@@ -2732,6 +2740,7 @@ static void amdgpu_dm_connector_destroy(struct
drm_connector *connector)
dm->backlight_dev = NULL;
}
#endif
+ drm_dp_cec_unregister_connector(>dm_dp_aux.aux);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9a300732ba37..18a3a6e5ffa0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -496,6 +496,8 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
drm_dp_aux_register(>dm_dp_aux.aux);
+ drm_dp_cec_register_connector(>dm_dp_aux.aux,
+ aconnector->base.name, dm->adev->dev);
aconnector->mst_mgr.cbs = _mst_cbs;
drm_dp_mst_topology_mgr_init(
>mst_mgr,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 3/5] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()
From: Hans Verkuil When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the result is wrong due to a missing idx increment. This was never noticed since DP_REMOTE_DPCD_READ is currently not used, but if you enable it, then it is all wrong. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 7780567aa669..5ff1d79b86c4 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -439,6 +439,7 @@ static bool drm_dp_sideband_parse_remote_dpcd_read(struct drm_dp_sideband_msg_rx if (idx > raw->curlen) goto fail_len; repmsg->u.remote_dpcd_read_ack.num_bytes = raw->msg[idx]; + idx++; if (idx > raw->curlen) goto fail_len; -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 2/5] drm_dp_cec: add note about good MegaChips 2900 CEC support
From: Hans Verkuil A big problem with DP CEC-Tunneling-over-AUX is that it is tricky to find adapters with a chipset that supports this AND where the manufacturer actually connected the HDMI CEC line to the chipset. Add a mention of the MegaChips 2900 chipset which seems to support this feature well. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/drm_dp_cec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c index 1407b13a8d5d..8a718f85079a 100644 --- a/drivers/gpu/drm/drm_dp_cec.c +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -16,7 +16,9 @@ * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters * have a converter chip that supports CEC-Tunneling-over-AUX (usually the * Parade PS176), but they do not wire up the CEC pin, thus making CEC - * useless. + * useless. Note that MegaChips 2900-based adapters appear to have good + * support for CEC tunneling. Those adapters that I have tested using + * this chipset all have the CEC line connected. * * Sadly there is no way for this driver to know this. What happens is * that a /dev/cecX device is created that is isolated and unable to see -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 0/5] drm/nouveau+amdgpu: add DP CEC-Tunneling-over-AUX (repost)
From: Hans Verkuil Repost because I wasn't a member of the nouveau mailinglist the first time around and this series was blocked. I also updated this cover letter for the part about the amdgpu patch after receiving feedback from Alex Deucher. The patches are unchanged (except for adding Alex' Acked-by to the amdgpu patch). Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support has been merged in the mainline kernel it is time to roll this out to nouveau and amdgpu as well. The first patch is required for this: it adds checks that the drm_dp_cec functions are called with a working aux implementation. These checks weren't necessary for the i915, but nouveau and amdgpu require them. The next two patches update a comment in drm_dp_cec.c and fix a bug in sideband AUX handling that I found while researching CEC Tunneling over an MST hub. It's there to prevent others from stumbling over the same bug in the future. The fourth patch adds support for CEC to the nouveau driver. The last patch adds support for CEC to the amdgpu driver. CEC is only supported for the new DC modesetting code (thanks to Alex Deucher for explaining this to me). I have no plans to add CEC support to the old modesetting code (amd/amdgpu/dce*.c). If someone wants to, then please contact me. I can't test this myself, but I can assist. Two notes on CEC-Tunneling-over-AUX: 1) You need to be very careful about which USB-C/DP/mini-DP to HDMI adapters you buy. Only a few support this feature correctly today. Known chipsets that support this are Parade PS175 & PS176 and MegaChips 2900. Unfortunately almost all Parade-based adapters do not hook up the HDMI CEC pin to the chip, making them useless for this. The Parade reference design was only recently changed to hook up this pin, so perhaps this situation will change for new Parade-based adapters. Adapters based on the new MegaChips 2900 fare much better: it appears that their reference design *does* hook up the CEC pin. Club3D has adapters using this device for USB-C, DP and mini-DP to HDMI, and they all work fine. If anyone finds other adapters that work besides those I list in https://hverkuil.home.xs4all.nl/cec-status.txt, please let me know and I'll add them to the list. Linux is the first OS that supports this feature, so I am not surprised that HW support for this has been poor. Hopefully this will change going forward. BTW, note the irony that CEC is now supported for DP-to-HDMI adapters, but not for the native HDMI ports on NVIDIA/AMD/Intel GPUs. 2) CEC-Tunneling does not work (yet?) if there is an MST hub in between. I'm still researching this but this might be a limitation of MST. Regards, Hans Hans Verkuil (5): drm_dp_cec: check that aux has a transfer function drm_dp_cec: add note about good MegaChips 2900 CEC support drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read() drm/nouveau: add DisplayPort CEC-Tunneling-over-AUX support drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++-- .../display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 ++ drivers/gpu/drm/drm_dp_cec.c | 18 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/nouveau/nouveau_connector.c| 17 +++-- 5 files changed, 46 insertions(+), 5 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 1/5] drm_dp_cec: check that aux has a transfer function
From: Hans Verkuil
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in those drivers before
every drm_dp_cec call, but it makes sense to check it in the
drm_dp_cec functions to prevent a kernel oops.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/drm_dp_cec.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 988513346e9c..1407b13a8d5d 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -238,6 +238,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
u8 cec_irq;
int ret;
+ /* No transfer function was set, so not a DP connector */
+ if (!aux->transfer)
+ return;
+
mutex_lock(>cec.lock);
if (!aux->cec.adap)
goto unlock;
@@ -293,6 +297,10 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
unsigned int num_las = 1;
u8 cap;
+ /* No transfer function was set, so not a DP connector */
+ if (!aux->transfer)
+ return;
+
#ifndef CONFIG_MEDIA_CEC_RC
/*
* CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
@@ -361,6 +369,10 @@ EXPORT_SYMBOL(drm_dp_cec_set_edid);
*/
void drm_dp_cec_unset_edid(struct drm_dp_aux *aux)
{
+ /* No transfer function was set, so not a DP connector */
+ if (!aux->transfer)
+ return;
+
cancel_delayed_work_sync(>cec.unregister_work);
mutex_lock(>cec.lock);
@@ -404,6 +416,8 @@ void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
const char *name,
struct device *parent)
{
WARN_ON(aux->cec.adap);
+ if (WARN_ON(!aux->transfer))
+ return;
aux->cec.name = name;
aux->cec.parent = parent;
INIT_DELAYED_WORK(>cec.unregister_work,
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH (repost) 4/5] drm/nouveau: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to nouveau.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 51932c72334e..eb4f766b5958 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -400,8 +400,10 @@ nouveau_connector_destroy(struct drm_connector *connector)
kfree(nv_connector->edid);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
- if (nv_connector->aux.transfer)
+ if (nv_connector->aux.transfer) {
+ drm_dp_cec_unregister_connector(_connector->aux);
drm_dp_aux_unregister(_connector->aux);
+ }
kfree(connector);
}
@@ -608,6 +610,7 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
nouveau_connector_set_encoder(connector, nv_encoder);
conn_status = connector_status_connected;
+ drm_dp_cec_set_edid(_connector->aux, nv_connector->edid);
goto out;
}
@@ -1108,11 +,14 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
NV_DEBUG(drm, "service %s\n", name);
+ drm_dp_cec_irq(_connector->aux);
if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP)))
nv50_mstm_service(nv_encoder->dp.mstm);
} else {
bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
+ if (!plugged)
+ drm_dp_cec_unset_edid(_connector->aux);
NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP))) {
if (!plugged)
@@ -1302,7 +1308,6 @@ nouveau_connector_create(struct drm_device *dev, int
index)
kfree(nv_connector);
return ERR_PTR(ret);
}
-
funcs = _connector_funcs;
break;
default:
@@ -1356,6 +1361,14 @@ nouveau_connector_create(struct drm_device *dev, int
index)
break;
}
+ switch (type) {
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ drm_dp_cec_register_connector(_connector->aux,
+ connector->name, dev->dev);
+ break;
+ }
+
ret = nvif_notify_init(>disp.object, nouveau_connector_hotplug,
true, NV04_DISP_NTFY_CONN,
&(struct nvif_notify_conn_req_v0) {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 5/8] drm: Define helper function for plane color enabling
Define helper function to enable Plane color features
to attach plane color properties to plane structure.
v2: Rebase
v3: Modiefied the function to use updated property names.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 42 ++
include/drm/drm_color_mgmt.h | 5 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d0bf10b..d1b4ac1 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
}
/**
+ * drm_plane_enable_color_mgmt - enable color management properties
+ * @plane: DRM Plane
+ * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
+ * @plane_has_ctm: whether to attach ctm_property for CSC matrix
+ * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a plane. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+ uint plane_degamma_lut_size,
+ bool plane_has_ctm,
+ uint plane_gamma_lut_size)
+{
+ if (plane_degamma_lut_size) {
+ drm_object_attach_property(>base,
+ plane->degamma_lut_property, 0);
+ drm_object_attach_property(>base,
+ plane->degamma_lut_size_property,
+ plane_degamma_lut_size);
+ }
+
+ if (plane_has_ctm)
+ drm_object_attach_property(>base,
+ plane->ctm_property, 0);
+
+ if (plane_gamma_lut_size) {
+ drm_object_attach_property(>base,
+ plane->gamma_lut_property, 0);
+ drm_object_attach_property(>base,
+ plane->gamma_lut_size_property,
+ plane_gamma_lut_size);
+ }
+}
+EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
+
+/**
* drm_universal_plane_init - Initialize a new universal plane object
* @dev: DRM device
* @plane: plane object to init
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 44f04233..9b8e566 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -68,4 +68,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
u32 supported_ranges,
enum drm_color_encoding default_encoding,
enum drm_color_range default_range);
+
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+uint plane_degamma_lut_size,
+bool plane_has_ctm,
+uint plane_gamma_lut_size);
#endif
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 8/8] drm/i915: Load plane color luts from atomic flip
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4
drivers/gpu/drm/i915/intel_color.c| 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645..abc9051 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -224,6 +224,10 @@ static void intel_plane_atomic_update(struct drm_plane
*plane,
intel_atomic_get_new_plane_state(state, intel_plane);
struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc;
+ if (new_plane_state->base.color_mgmt_changed) {
+ intel_color_load_plane_luts(_plane_state->base);
+ }
+
if (new_plane_state->base.visible) {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state,
to_intel_crtc(crtc));
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 2b5c0cd..de28d6b 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -666,6 +666,14 @@ void intel_color_load_luts(struct drm_crtc_state
*crtc_state)
dev_priv->display.load_luts(crtc_state);
}
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+ struct drm_device *dev = plane_state->plane->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->display.load_plane_luts(plane_state);
+}
+
int intel_color_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3850a5b..fea772b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2179,6 +2179,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
void intel_color_set_csc(struct drm_crtc_state *crtc_state);
void intel_color_load_luts(struct drm_crtc_state *crtc_state);
void intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
/* intel_lspcon.c */
bool lspcon_init(struct intel_digital_port *intel_dig_port);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 6/8] drm/i915: Enable plane color features
Enable and initialize plane color features.
v2: Rebase and some cleanup
v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_color.c | 14 ++
drivers/gpu/drm/i915/intel_device_info.h | 5 +
drivers/gpu/drm/i915/intel_drv.h | 9 +
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fa1388..dddb1c3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -455,6 +455,11 @@ struct drm_i915_display_funcs {
void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
void (*load_luts)(struct drm_crtc_state *crtc_state);
+ /* Add Plane Color callbacks */
+ void (*load_plane_csc_matrix)(const struct drm_plane_state
+ *plane_state);
+ void (*load_plane_luts)(const struct drm_plane_state
+ *plane_state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c6a7bea..fb8402f 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -642,6 +642,20 @@ int intel_color_check(struct drm_crtc *crtc,
return -EINVAL;
}
+void intel_plane_color_init(struct drm_plane *plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+ drm_plane_color_create_prop(plane->dev, plane);
+
+ /* Enable color management support when we have degamma & gamma LUTs. */
+ if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 &&
+ INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0)
+ drm_plane_enable_color_mgmt(plane,
+ INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size,
+ true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size);
+}
+
void intel_color_init(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 6eecd64..71132ad 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -182,6 +182,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+ struct plane_color_luts {
+ u16 plane_degamma_lut_size;
+ u16 plane_gamma_lut_size;
+ } plane_color;
};
struct intel_driver_caps {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b984ae..3850a5b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -535,6 +535,14 @@ struct intel_plane_state {
*/
int scaler_id;
+ /*
+* Use reduced/limited/broadcast rbg range, compressing from the full
+* range fed into the crtcs.
+*/
+ bool limited_color_range;
+ /* Gamma mode programmed on the plane */
+ uint32_t gamma_mode;
+
struct drm_intel_sprite_colorkey ckey;
};
@@ -2170,6 +2178,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
void intel_color_set_csc(struct drm_crtc_state *crtc_state);
void intel_color_load_luts(struct drm_crtc_state *crtc_state);
+void intel_plane_color_init(struct drm_plane *plane);
/* intel_lspcon.c */
bool lspcon_init(struct intel_digital_port *intel_dig_port);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 4/8] drm: Add Plane Gamma properties
Add plane gamma as blob property and size as a
range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
v4: Rebase
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic.c| 9 +
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
drivers/gpu/drm/drm_plane.c | 23 +++
include/drm/drm_plane.h | 22 ++
5 files changed, 63 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 16d6d8d..bcf9a86 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -563,6 +563,12 @@ Plane Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: ctm_property
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: gamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: gamma_lut_size_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ddda935..8b0bf14 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -925,6 +925,13 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->gamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >gamma_lut,
+ val, -1, sizeof(struct drm_color_lut),
+ );
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -998,6 +1005,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+ } else if (property == plane->gamma_lut_property) {
+ *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 866181f..f524255 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3618,6 +3618,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+ if (state->gamma_lut)
+ drm_property_blob_put(state->gamma_lut);
state->color_mgmt_changed = false;
}
@@ -3667,6 +3669,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+ drm_property_blob_put(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 97520b1..d0bf10b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -494,6 +494,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
* Blob property which allows a userspace to provide CTM coefficients
* to do color space conversion or any other enhancement by doing a
* matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma/tone-mapping curve using the h/w plane gamma
+ * processing engine, thereby making the content as non-linear
+ * or to perform any tone mapping operation for HDR usecases.
+ *
+ * gamma_lut_size_property:
+ * Range Property to indicate size of the plane gamma LUT.
*/
int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -521,6 +530,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->ctm_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB,
+ "PLANE_GAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+ plane->gamma_lut_property = prop;
+
+ prop = drm_property_create_range(dev,
+
[RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Implement Plane Gamma feature for BDW and Gen9 platforms.
v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.
v3: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 25
drivers/gpu/drm/i915/intel_color.c | 58
drivers/gpu/drm/i915/intel_display.c | 4 +++
drivers/gpu/drm/i915/intel_sprite.c | 4 +++
5 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e931b48..40de78c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,7 +54,10 @@
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
IVB_CURSOR_C_OFFSET }
#define BDW_COLORS \
- .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+ .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
+ .plane_color = { .plane_degamma_lut_size = 0, \
+.plane_gamma_lut_size = 16 }
+
#define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
#define GLK_COLORS \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c9f03d..2db6a84 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -172,6 +172,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
+/* Plane Gamma Registers */
+#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+#define _MMIO_PLANE_GAMC16(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
#define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
#define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
@@ -9713,6 +9717,27 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Plane Gamma in Gen9+ */
+#define _PLANE_GAMC_1_A0x701d0
+#define _PLANE_GAMC_1_B0x711d0
+#define _PLANE_GAMC_2_A0x702d0
+#define _PLANE_GAMC_2_B0x712d0
+#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
+#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
+#define PLANE_GAMC(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
+
+#define _PLANE_GAMC16_1_A 0x70210
+#define _PLANE_GAMC16_1_B 0x71210
+#define _PLANE_GAMC16_2_A 0x70310
+#define _PLANE_GAMC16_2_B 0x71310
+#define _PLANE_GAMC16_1(pipe) _PIPE(pipe, _PLANE_GAMC16_1_A, \
+_PLANE_GAMC16_1_B)
+#define _PLANE_GAMC16_2(pipe) _PIPE(pipe, _PLANE_GAMC16_2_A, \
+_PLANE_GAMC16_2_B)
+#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
+ _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index fb8402f..2b5c0cd 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -492,6 +492,59 @@ static void broadwell_load_luts(struct drm_crtc_state
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
+static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
+u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ uint32_t i, lut_size =
+ INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
+
+ if (state->gamma_lut) {
+ struct drm_color_lut_ext *lut =
+ (struct drm_color_lut_ext *) state->gamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ uint32_t word =
+ (drm_color_lut_extract(lut[i].red, 10) << 20) |
+ (drm_color_lut_extract(lut[i].green, 10) << 10) |
+ drm_color_lut_extract(lut[i].blue, 10);
+
+ I915_WRITE(PLANE_GAMC(pipe, plane, i), word);
+ }
+
+ /* Program the max register to clamp values > 1.0. */
+ i = lut_size - 1;
+ I915_WRITE(PLANE_GAMC16(pipe, plane, 0),
+ drm_color_lut_extract(lut[i].red, 16));
+
[RFC v4 0/8] Add Plane Color Properties
This patch series adds properties for plane color features. It adds properties for degamma used to linearize data, CSC used for gamut conversion, and gamma used to again non-linearize data as per panel supported color space. These can be utilize by user space to convert planes from one format to another, one color space to another etc. Usersapce can take smart blending decisions and utilize these hardware supported plane color features to get accurate color profile. The same can help in consistent color quality from source to panel taking advantage of advanced color features in hardware. These patches just add the property interfaces and enable helper functions. This series adds Intel Gen9 specific plane gamma feature. We can build up and add other platform/hardware specific implementation on top of this series Note: This is just to get a design feedback whether these interfaces look ok. Based on community feedback on interfaces, we will implement IGT tests to validate plane color features. This is un-tested currently. Userspace implementation using these properties have been done in drm hwcomposer by "Alexandru-Cosmin Gheorghe alexandru-cosmin.gheor...@arm.com" from ARM. A merge request has been opened by Alexandru for drm_hwcomposer, implementing the property changes for the same. Please review that as well: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25 v2: Dropped legacy gamma table for plane as suggested by Maarten. Added Gen9/BDW plane gamma feature and rebase on tot. v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul comments and moved plane color properties to drm_plane instead of mode_config. Added property documentation as suggested by Daniel, Vetter. Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. v4: Rebase Uma Shankar (8): drm: Add Enhanced Gamma LUT precision structure drm: Add Plane Degamma properties drm: Add Plane CTM property drm: Add Plane Gamma properties drm: Define helper function for plane color enabling drm/i915: Enable plane color features drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms drm/i915: Load plane color luts from atomic flip Documentation/gpu/drm-kms.rst | 18 drivers/gpu/drm/drm_atomic.c | 32 drivers/gpu/drm/drm_atomic_helper.c | 13 +++ drivers/gpu/drm/drm_plane.c | 131 ++ drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_pci.c | 5 +- drivers/gpu/drm/i915/i915_reg.h | 25 ++ drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + drivers/gpu/drm/i915/intel_color.c| 80 ++ drivers/gpu/drm/i915/intel_device_info.h | 5 ++ drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_drv.h | 10 +++ drivers/gpu/drm/i915/intel_sprite.c | 4 + include/drm/drm_color_mgmt.h | 5 ++ include/drm/drm_plane.h | 61 ++ include/uapi/drm/drm_mode.h | 15 16 files changed, 416 insertions(+), 1 deletion(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 2/8] drm: Add Plane Degamma properties
Add Plane Degamma as a blob property and plane degamma size as
a range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
v4: Rebase
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 9 +
drivers/gpu/drm/drm_atomic.c| 13 +
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
drivers/gpu/drm/drm_plane.c | 35 +++
include/drm/drm_plane.h | 24
5 files changed, 87 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 5dee6b8..8b10b12 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -551,6 +551,15 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
+Plane Color Management Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: degamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: degamma_lut_size_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e..f8cad9b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
@@ -908,6 +910,13 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+ } else if (property == plane->degamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >degamma_lut,
+ val, -1, sizeof(struct drm_color_lut),
+ );
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -976,6 +985,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+ } else if (property == plane->degamma_lut_property) {
+ *val = (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
@@ -1116,6 +1128,7 @@ static void drm_atomic_plane_print_state(struct
drm_printer *p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+ drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 38ce9a3..67c5b51 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3613,6 +3613,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
state->fence = NULL;
state->commit = NULL;
+
+ if (state->degamma_lut)
+ drm_property_blob_get(state->degamma_lut);
+ state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3657,6 +3661,8 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+ drm_property_blob_put(state->degamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index cd71fd0..03e0560 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -478,6 +478,41 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
}
EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
+/**
+ * DOC: degamma_lut_property
+ *
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w
[RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 19 +++
include/uapi/drm/drm_mode.h | 15 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 6153cbd..cd71fd0 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -430,6 +430,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_force_disable);
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (32 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract_ext);
+
/**
* drm_mode_plane_set_obj_prop - set the value of a property
* @plane: drm plane object to set property value for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8d67243..874407b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -629,6 +629,21 @@ struct drm_color_lut {
__u16 reserved;
};
+/*
+ * Creating 32 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+* Data is U0.32 fixed point format.
+*/
+ __u32 red;
+ __u32 green;
+ __u32 blue;
+ __u32 reserved;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4 3/8] drm: Add Plane CTM property
Add a blob property for plane CSC usage.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
v4: Rebase
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 3 +++
drivers/gpu/drm/drm_atomic.c| 10 ++
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_plane.c | 12
include/drm/drm_plane.h | 15 +++
5 files changed, 44 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 8b10b12..16d6d8d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -560,6 +560,9 @@ Plane Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: degamma_lut_size_property
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: ctm_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f8cad9b..ddda935 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->ctm_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >ctm,
+ val,
+ sizeof(struct drm_color_ctm), -1,
+ );
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+ } else if (property == plane->ctm_property) {
+ *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 67c5b51..866181f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3616,6 +3616,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+ if (state->ctm)
+ drm_property_blob_get(state->ctm);
+
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3663,6 +3666,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
drm_property_blob_put(state->degamma_lut);
+ drm_property_blob_put(state->ctm);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 03e0560..97520b1 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
*
* degamma_lut_size_property:
* Range Property to indicate size of the plane degamma LUT.
+ *
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
*/
int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->degamma_lut_size_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB,
+ "PLANE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ plane->ctm_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_color_create_prop);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 28357ac..5143277 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -183,6 +183,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;
/**
+* @ctm:
+*
+* Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+* blob
[Bug 107604] tes dhfhdghgdfgdshgfhs
https://bugs.freedesktop.org/show_bug.cgi?id=107604 Bug ID: 107604 Summary: tes dhfhdghgdfgdshgfhs Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: pradee...@qspiders.com gjhfjkhgkjfdkghfdkjhgkjfdkghkjdfhgjkhdfjkghkjdfhgkjdfkghkjdf -- 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
[radeon-alex:vega20_psp_smu 28/44] include/asm-generic/div64.h:239:22: error: passing argument 1 of '__div64_32' from incompatible pointer type
tree: git://people.freedesktop.org/~agd5f/linux.git vega20_psp_smu
head: 9b9ef18df4349dd2d2b8941e76c032ed8acf2529
commit: 27480799ed68e17e8228372a4afac7d5dcfbf01a [28/44] drm/amd/powerplay: new
interfaces for overdrive vega20 sclk and mclk
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 27480799ed68e17e8228372a4afac7d5dcfbf01a
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from arch/arm/include/asm/div64.h:127:0,
from include/linux/kernel.h:174,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c: In function
'vega20_set_sclk_od':
include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note:
in expansion of macro 'do_div'
do_div(od_sclk, 100);
^~
In file included from include/linux/kernel.h:10:0,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
include/asm-generic/div64.h:235:25: warning: right shift count >= width of
type [-Wshift-count-overflow]
} else if (likely(((n) >> 32) == 0)) { \
^
include/linux/compiler.h:76:40: note: in definition of macro 'likely'
# define likely(x) __builtin_expect(!!(x), 1)
^
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note:
in expansion of macro 'do_div'
do_div(od_sclk, 100);
^~
In file included from arch/arm/include/asm/div64.h:127:0,
from include/linux/kernel.h:174,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
>> include/asm-generic/div64.h:239:22: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
__rem = __div64_32(&(n), __base); \
^
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note:
in expansion of macro 'do_div'
do_div(od_sclk, 100);
^~
In file included from include/linux/kernel.h:174:0,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
arch/arm/include/asm/div64.h:33:24: note: expected 'uint64_t * {aka long
long unsigned int *}' but argument is of type 'uint32_t * {aka unsigned int *}'
static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
^~
In file included from arch/arm/include/asm/div64.h:127:0,
from include/linux/kernel.h:174,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c: In function
'vega20_set_mclk_od':
include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1247:2: note:
in expansion of macro 'do_div'
do_div(od_mclk, 100);
^~
In file included from include/linux/kernel.h:10:0,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
include/asm-generic/div64.h:235:25: warning: right shift count >= width of
type [-Wshift-count-overflow]
} else if (likely(((n) >> 32) == 0)) { \
^
include/linux/compiler.h:76:40: note: in definition of macro 'likely'
# define likely(x) __builtin_expect(!!(x), 1)
^
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1247:2: note:
in expansion of macro 'do_div'
do_div(od_mclk, 100);
^~
In file included from arch/arm/include/asm/div64.h:127:0,
from include/linux/kernel.h:174,
from include/linux/delay.h:22,
from
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24:
>> include/asm-generic/div64.h:239:22: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
[Bug 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)
https://bugzilla.kernel.org/show_bug.cgi?id=199653 Marcus Husar (marcus.hu...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Marcus Husar (marcus.hu...@gmail.com) --- See comment #9 and #10. Kernel parameter idle=nomwait fixed this bug for me. It seems to be a CPU related problem. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours
https://bugs.freedesktop.org/show_bug.cgi?id=104817 Marcus Husar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #10 from Marcus Husar --- See comment #8. Kernel parameter idle=nomwait fixed this bug for me. It seems to be a CPU related problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v4)
Am 17.08.2018 um 12:08 schrieb Huang Rui:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
"drm/amdgpu: band aid validating VM PTs"
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--+-+---+---+
| |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
|
| |Principle(Vulkan)| |
|
++
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308
ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
|
++
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
|
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204
ms(16K)|
|PT BOs on LRU)| | |
|
++
| Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213
ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K)
|
+--+-+---+---+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
3 files changed, 75 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 502b94f..9fbdf02 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1260,6 +1260,16 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
return 0;
}
+static void amdgpu_cs_vm_move_on_lru(struct amdgpu_device *adev,
+struct amdgpu_cs_parser *p)
+{
+ struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
+ struct amdgpu_vm *vm = >vm;
+
+ if (vm->validated)
That check belongs inside amdgpu_vm_move_to_lru_tail().
+ amdgpu_vm_move_to_lru_tail(adev, vm);
+}
+
int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
{
struct amdgpu_device *adev = dev->dev_private;
@@ -1310,6 +1320,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
r = amdgpu_cs_submit(, cs);
+ amdgpu_cs_vm_move_on_lru(adev, );
out:
amdgpu_cs_parser_fini(, r, reserved_buffers);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9c84770..037cfbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -268,6 +268,53 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
}
/**
+ * amdgpu_vm_move_to_lru_tail_by_list - move one list of BOs to end of LRU
+ *
+ * @vm: vm providing the BOs
+ * @list: the list that stored BOs
+ *
+ * Move one list of BOs to the end of LRU and update the positions.
+ */
+static void
+amdgpu_vm_move_to_lru_tail_by_list(struct amdgpu_vm *vm, struct list_head
*list)
I don't see much of a point having a separate function for this any more.
+{
+ struct
[Bug 107454] BLENDER 2.8 principled BSDF shader and shadow are broken in EEVEE on mesa gallium r600g gpu
https://bugs.freedesktop.org/show_bug.cgi?id=107454 --- Comment #3 from amonpaike --- today the repository padoka ppa has updated the drivers so I could test blender 2.8 ... all the problems are now solved! (Except the shadow ESMs that probably depend on blender, I will present to the blender developers of the problem) Great job Thank you !! -- 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: RFC for a render API to support adaptive sync and VRR
It would be really nice to have support for the automatic extension-less fullscreen game scenario. Maybe you don't have to solve everything in the first implementation... So a friendly ping here! Regards //Ernst Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter : > > On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland > wrote: > > > > > > On 2018-04-24 08:09 AM, Daniel Vetter wrote: > >> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote: > >>> On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote: > On 2018-04-20 04:32 PM, Manasi Navare wrote: > > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard > >> wrote: > >>> Michel Dänzer writes: > Time-based presentation seems to be the right approach for preventing > micro-stutter in games as well, Croteam developers have been > researching > this. > >>> > >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present > >>> extension offer the ability to specify the desired display time in > >>> seconds. > >>> > >>> Similarly, I'd suggest that the min/max display refresh rate values be > >>> advertised as time between frames rather than frames per second. > > > > So there is a global min and max refresh rate as advertised by the > > monitor > > range descriptor. That I guess can be exposed as a global range in > > terms of > > min and max time between frames as a global property of the connector. > > > > We dont need the per mode min and max refresh rate to be exposed right? > > If I understand VRR right, with CinemaVRR acceptable refresh rates might > fall outside the range advertised by the monitor. Would we > 1) advertise 24/1.001 as a lower bound, > 2) expect media apps to use the lower bound simply for informational > purposes, > 3) or simply not support CinemaVRR? > > (1) has the added caveat that not all reported rates would be supported. > > Alternatively a bit could indicate that CinemaVRR is support, but I'm > not sure if user mode would need all these details. > > Harry > >>> > >>> Are there special CinemaVRR suported monitors? In that case we need to > >>> understand how those monitors > >>> advertise the monitor range and if they have a bit in EDID that indicate > >>> they are CinemaVRR capable > >>> as opposed to just the Adaptive Sync/VRR. > >>> Harry, if you have one of those monitors, could you send the EDID dump > >>> for that? > >> > >> As long as the any multiple of the 24/1.001 refresh rate is within the > >> officially supported refresh range rate this should work out. Maybe we'll > >> end up uploading 2x (to run at ~48Hz), maybe the kernel only uploads at > >> 24Hz. But should all be fine. > >> > > > > Would kernel driver upload 48Hz when UMD asks for 24Hz or would UMD be > > expected to submit double frames? > > > > If kernel driver supports frame doubling (like our DC driver) we would > > probably report half of monitor-reported min-refresh (or rather double of > > monitor-reported max frame time). > > Your driver (amdgpu) already supports frame doubling, except only for > vblank seqno instead of timestamps. Whether VRR can get down to 24Hz > or not is totally irrelevant from userspace's point of view. By > default the kernel is expected to keep display the current frame for > as long as userspace gives it a new one. There's no expectation that > userspace provides a new buffer for every vblank (whether that's a > fixed or variable refresh rate doesn't matter). > -Daniel > > > > > Harry > > > >> Ofc if we have CinemaVRR screens which don't fit this, then maybe we need > >> to figure out something ... > >> -Daniel > >> > >>> > >>> Manasi > >>> > > > > >>> > >>> I'd also encourage using a single unit for all of these values, > >>> preferably nanoseconds. Absolute times should all be referenced to > >>> CLOCK_MONOTONIC. > >> > >> +1 on everything Keith said. I got somehow dragged in khr vk > >> discussions around preventing micro-stuttering, and consensus seems to > >> be that timestamps for scheduling frames is the way to go, most likely > >> absolute ones (not everything is running Linux unfortunately, so can't > >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC). > >> -Daniel > > > > And yes I also got consensus from Mesa and media folks about using the > > absolute timestamp for scheduling the frames and then the driver will > > modify the vblank logic to "present no earlier than the timestamp" > > > > Manasi > > > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > >> ___ > >> dri-devel mailing list > >>
[PATCH v4 5/5] drm/amdgpu: move PD/PT bos on LRU again
The new bulk moving functionality is ready, the overhead of moving PD/PT bos to LRU is fixed. So move them on LRU again. Signed-off-by: Huang Rui Tested-by: Mike Lothian Tested-by: Dieter N??tzel Acked-by: Chunming Zhou Reviewed-by: Junwei Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 037cfbc..f498b7c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -1121,7 +1121,7 @@ int amdgpu_vm_update_directories(struct amdgpu_device *adev, struct amdgpu_vm_bo_base, vm_status); bo_base->moved = false; - list_del_init(_base->vm_status); + list_move(_base->vm_status, >idle); bo = bo_base->bo->parent; if (!bo) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/ttm: add bulk move function on LRU
This function allow us to bulk move a group of BOs to the tail of their LRU.
The positions of group of BOs are stored on the (first, last) bulk_move_pos
structure.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/ttm/ttm_bo.c | 52
include/drm/ttm/ttm_bo_api.h | 10 +
2 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7117b6b..39d9d55 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -247,6 +247,58 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
+static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
+ struct list_head *lru, bool is_swap)
+{
+ struct list_head entries, before;
+ struct list_head *list1, *list2;
+
+ list1 = is_swap ? >last->swap : >last->lru;
+ list2 = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
+
+ list_cut_position(, lru, list1);
+ list_cut_position(, , list2);
+ list_splice(, lru);
+ list_splice_tail(, lru);
+}
+
+void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
+{
+ unsigned i;
+
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ struct ttm_mem_type_manager *man;
+
+ if (!bulk->tt[i].first)
+ continue;
+
+ man = >tt[i].first->bdev->man[TTM_PL_TT];
+ ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
+ }
+
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ struct ttm_mem_type_manager *man;
+
+ if (!bulk->vram[i].first)
+ continue;
+
+ man = >vram[i].first->bdev->man[TTM_PL_VRAM];
+ ttm_bo_bulk_move_helper(>vram[i], >lru[i], false);
+ }
+
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ struct ttm_lru_bulk_move_pos *pos = >swap[i];
+ struct list_head *lru;
+
+ if (!pos->first)
+ continue;
+
+ lru = >first->bdev->glob->swap_lru[i];
+ ttm_bo_bulk_move_helper(>swap[i], lru, true);
+ }
+}
+EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
+
static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
struct ttm_mem_reg *mem, bool evict,
struct ttm_operation_ctx *ctx)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 0d4eb81..8c19470 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -417,6 +417,16 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
struct ttm_lru_bulk_move *bulk);
/**
+ * ttm_bo_bulk_move_lru_tail
+ *
+ * @bulk: bulk move structure
+ *
+ * Bulk move BOs to the LRU tail, only valid to use when driver makes sure that
+ * BO order never changes. Should be called with ttm_bo_global::lru_lock held.
+ */
+void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk);
+
+/**
* ttm_bo_lock_delayed_workqueue
*
* Prevent the delayed workqueue from running.
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v4)
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
"drm/amdgpu: band aid validating VM PTs"
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--+-+---+---+
| |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
|
| |Principle(Vulkan)| |
|
++
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308
ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
|
++
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
|
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204
ms(16K)|
|PT BOs on LRU)| | |
|
++
| Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213
ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K)
|
+--+-+---+---+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
3 files changed, 75 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 502b94f..9fbdf02 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1260,6 +1260,16 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
return 0;
}
+static void amdgpu_cs_vm_move_on_lru(struct amdgpu_device *adev,
+struct amdgpu_cs_parser *p)
+{
+ struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
+ struct amdgpu_vm *vm = >vm;
+
+ if (vm->validated)
+ amdgpu_vm_move_to_lru_tail(adev, vm);
+}
+
int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
{
struct amdgpu_device *adev = dev->dev_private;
@@ -1310,6 +1320,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
r = amdgpu_cs_submit(, cs);
+ amdgpu_cs_vm_move_on_lru(adev, );
out:
amdgpu_cs_parser_fini(, r, reserved_buffers);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9c84770..037cfbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -268,6 +268,53 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
}
/**
+ * amdgpu_vm_move_to_lru_tail_by_list - move one list of BOs to end of LRU
+ *
+ * @vm: vm providing the BOs
+ * @list: the list that stored BOs
+ *
+ * Move one list of BOs to the end of LRU and update the positions.
+ */
+static void
+amdgpu_vm_move_to_lru_tail_by_list(struct amdgpu_vm *vm, struct list_head
*list)
+{
+ struct amdgpu_vm_bo_base *bo_base;
+
+ list_for_each_entry(bo_base, list, vm_status) {
+ struct amdgpu_bo *bo = bo_base->bo;
+
+ if (!bo->parent)
+
[PATCH v4 2/5] drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves
From: Christian König
When move a BO to the end of LRU, it need remember the BO positions.
Make sure all moved bo in between "first" and "last". And they will be bulk
moving together.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c | 26 +-
include/drm/ttm/ttm_bo_api.h | 6 +-
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 015613b..9c84770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -297,9 +297,9 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
break;
spin_lock(>lru_lock);
- ttm_bo_move_to_lru_tail(>tbo);
+ ttm_bo_move_to_lru_tail(>tbo, NULL);
if (bo->shadow)
- ttm_bo_move_to_lru_tail(>shadow->tbo);
+ ttm_bo_move_to_lru_tail(>shadow->tbo, NULL);
spin_unlock(>lru_lock);
}
@@ -319,9 +319,9 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
if (!bo->parent)
continue;
- ttm_bo_move_to_lru_tail(>tbo);
+ ttm_bo_move_to_lru_tail(>tbo, NULL);
if (bo->shadow)
- ttm_bo_move_to_lru_tail(>shadow->tbo);
+ ttm_bo_move_to_lru_tail(>shadow->tbo, NULL);
}
spin_unlock(>lru_lock);
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c48472..7117b6b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -214,12 +214,36 @@ void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
}
EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);
-void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
+static void ttm_bo_bulk_move_set_pos(struct ttm_lru_bulk_move_pos *pos,
+struct ttm_buffer_object *bo)
+{
+ if (!pos->first)
+ pos->first = bo;
+ pos->last = bo;
+}
+
+void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
+struct ttm_lru_bulk_move *bulk)
{
reservation_object_assert_held(bo->resv);
ttm_bo_del_from_lru(bo);
ttm_bo_add_to_lru(bo);
+
+ if (bulk && !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
+ switch (bo->mem.mem_type) {
+ case TTM_PL_TT:
+ ttm_bo_bulk_move_set_pos(>tt[bo->priority], bo);
+ break;
+
+ case TTM_PL_VRAM:
+ ttm_bo_bulk_move_set_pos(>vram[bo->priority], bo);
+ break;
+ }
+ if (bo->ttm && !(bo->ttm->page_flags &
+(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED)))
+ ttm_bo_bulk_move_set_pos(>swap[bo->priority], bo);
+ }
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index a01ba20..0d4eb81 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -51,6 +51,8 @@ struct ttm_placement;
struct ttm_place;
+struct ttm_lru_bulk_move;
+
/**
* struct ttm_bus_placement
*
@@ -405,12 +407,14 @@ void ttm_bo_del_from_lru(struct ttm_buffer_object *bo);
* ttm_bo_move_to_lru_tail
*
* @bo: The buffer object.
+ * @bulk: optional bulk move structure to remember BO positions
*
* Move this BO to the tail of all lru lists used to lookup and reserve an
* object. This function must be called with struct ttm_bo_global::lru_lock
* held, and is used to make a BO less likely to be considered for eviction.
*/
-void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo);
+void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
+struct ttm_lru_bulk_move *bulk);
/**
* ttm_bo_lock_delayed_workqueue
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] drm/ttm,amdgpu: Introduce LRU bulk move functionality
The idea and proposal is originally from Christian, and I continue to work to deliver it. Background: amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of them on the end of LRU list one by one. Thus, that cause so many BOs moved to the end of the LRU, and impact performance seriously. Then Christian provided a workaround to not move PD/PT BOs on LRU with below patch: "drm/amdgpu: band aid validating VM PTs" Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU instead of one by one. Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be validated we move all BOs together to the end of the LRU without dropping the lock for the LRU. While doing so we note the beginning and end of this block in the LRU list. Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do, we don't move every BO one by one, but instead cut the LRU list into pieces so that we bulk move everything to the end in just one operation. Test data: +--+-+---+---+ | |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL) | | |Principle(Vulkan)| | | ++ | | | |0.319 ms(1k) 0.314 ms(2K) 0.308 ms(4K) | | Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K) | ++ | Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K) | |(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204 ms(16K)| |PT BOs on LRU)| | | | ++ | Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213 ms(4K) | | | | |0.214 ms(8K) 0.225 ms(16K) | +--+-+---+---+ After test them with above three benchmarks include vulkan and opencl. We can see the visible improvement than original, and even better than original with workaround. Changes from V1 -> V2: - Fix to missed the BOs in relocated/moved that should be also moved to the end of LRU. Changes from V2 -> V3: - Remove unused parameter and use list_for_each_entry instead of the one with save entry. Changes from V3 -> V4: - Move the amdgpu_vm_move_to_lru_tail after command submission, at that time, all bo will be back on idle list. Thanks, Rui Christian König (2): drm/ttm: add helper structures for bulk moves on lru list drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves Huang Rui (3): drm/ttm: add bulk move function on LRU drm/amdgpu: use bulk moves for efficient VM LRU handling (v4) drm/amdgpu: move PD/PT bos on LRU again drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 73 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 - drivers/gpu/drm/ttm/ttm_bo.c | 78 +- include/drm/ttm/ttm_bo_api.h | 16 ++- include/drm/ttm/ttm_bo_driver.h| 28 6 files changed, 196 insertions(+), 21 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/ttm: add helper structures for bulk moves on lru list
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
Reviewed-by: Junwei Zhang
---
include/drm/ttm/ttm_bo_driver.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 3234cc3..e4fee8e 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -491,6 +491,34 @@ struct ttm_bo_device {
};
/**
+ * struct ttm_lru_bulk_move_pos
+ *
+ * @first: first BO in the bulk move range
+ * @last: last BO in the bulk move range
+ *
+ * Positions for a lru bulk move.
+ */
+struct ttm_lru_bulk_move_pos {
+ struct ttm_buffer_object *first;
+ struct ttm_buffer_object *last;
+};
+
+/**
+ * struct ttm_lru_bulk_move
+ *
+ * @tt: first/last lru entry for BOs in the TT domain
+ * @vram: first/last lru entry for BOs in the VRAM domain
+ * @swap: first/last lru entry for BOs on the swap list
+ *
+ * Helper structure for bulk moves on the LRU list.
+ */
+struct ttm_lru_bulk_move {
+ struct ttm_lru_bulk_move_pos tt[TTM_MAX_BO_PRIORITY];
+ struct ttm_lru_bulk_move_pos vram[TTM_MAX_BO_PRIORITY];
+ struct ttm_lru_bulk_move_pos swap[TTM_MAX_BO_PRIORITY];
+};
+
+/**
* ttm_flag_masked
*
* @old: Pointer to the result and original value.
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] drm/ttm,amdgpu: Introduce LRU bulk move functionality
On Thu, Aug 16, 2018 at 08:41:44AM +0800, Dieter Nützel wrote: > For the series > > Tested-by: Dieter Nützel > > on RX580, > amd-staging-drm-next > #5024f8dfe478 > Thank you so much, will add tested-by in next version. Thanks, Ray > Dieter > > Am 13.08.2018 11:58, schrieb Huang Rui: > > The idea and proposal is originally from Christian, and I continue to > > work to > > deliver it. > > > > Background: > > amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then > > move all of > > them on the end of LRU list one by one. Thus, that cause so many BOs > > moved to > > the end of the LRU, and impact performance seriously. > > > > Then Christian provided a workaround to not move PD/PT BOs on LRU with > > below > > patch: > > "drm/amdgpu: band aid validating VM PTs" > > Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae > > > > However, the final solution should bulk move all PD/PT and PerVM BOs on > > the LRU > > instead of one by one. > > > > Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which > > need to be > > validated we move all BOs together to the end of the LRU without > > dropping the > > lock for the LRU. > > > > While doing so we note the beginning and end of this block in the LRU > > list. > > > > Now when amdgpu_vm_validate_pt_bos() is called and we don't have > > anything to do, > > we don't move every BO one by one, but instead cut the LRU list into > > pieces so > > that we bulk move everything to the end in just one operation. > > > > Test data: > > +--+-+---+---+ > > | |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL) > > | > > | |Principle(Vulkan)| | > > | > > ++ > > | | | |0.319 ms(1k) 0.314 > > ms(2K) 0.308 ms(4K) | > > | Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 > > ms(16K) | > > ++ > > | Orignial + WA| | |0.254 ms(1K) 0.241 > > ms(2K) | > > |(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 > > ms(8K) 0.204 ms(16K)| > > |PT BOs on LRU)| | | > > | > > ++ > > | Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 > > ms(2K) 0.213 ms(4K) | > > | | | |0.214 ms(8K) 0.225 > > ms(16K) | > > +--+-+---+---+ > > > > After test them with above three benchmarks include vulkan and opencl. > > We can > > see the visible improvement than original, and even better than > > original with > > workaround. > > > > Changes from V1 -> V2: > > - Fix to missed the BOs in relocated/moved that should be also moved to > > the end > > of LRU. > > > > Changes from V2 -> V3: > > - Remove unused parameter and use list_for_each_entry instead of the > > one with > > save entry. > > > > Thanks, > > Rui > > > > Christian König (2): > > drm/ttm: add helper structures for bulk moves on lru list > > drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves > > > > Huang Rui (3): > > drm/ttm: add bulk move function on LRU > > drm/amdgpu: use bulk moves for efficient VM LRU handling (v3) > > drm/amdgpu: move PD/PT bos on LRU again > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 75 > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 4 ++ > > drivers/gpu/drm/ttm/ttm_bo.c | 78 > > +- > > include/drm/ttm/ttm_bo_api.h | 16 ++- > > include/drm/ttm/ttm_bo_driver.h| 28 > > 5 files changed, 182 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107482] Images gamma rendering issue
https://bugs.freedesktop.org/show_bug.cgi?id=107482 --- Comment #7 from Sebastian Luncan --- (In reply to Michel Dänzer from comment #6) > Can you try if current upstream xf86-video-amdgpu Git master works better > with DC? It's the same. I've also tried videos with gamma 3. All hardware decoded videos (h264) look fine, software decoded have this issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107559] no color format choice in amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=107559 --- Comment #4 from zamundaa...@gmail.com --- With amdgpu.dc=0 it seems to work just fine. I've booted up with my normal setup, switched the cables so I am connected by HDMI directly and I get good colors -- 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 107559] no color format choice in amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=107559 --- Comment #3 from zamundaa...@gmail.com --- Created attachment 141165 --> https://bugs.freedesktop.org/attachment.cgi?id=141165=edit dmesg 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 107559] no color format choice in amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=107559 --- Comment #2 from zamundaa...@gmail.com --- Created attachment 141164 --> https://bugs.freedesktop.org/attachment.cgi?id=141164=edit dmesg with amdgpu.dc=0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Rationalize DRM_MIPI_DSI inclusion in Kconfig
On Thu, Aug 16, 2018 at 02:54:14PM -0400, Sean Paul wrote: > From: Sean Paul > > DRM_MIPI_DSI is included via both "select" and "depends on", this is > trouble waiting to happen since this will result in different behavior > depending on which is used. > > This patch resolves the problem by: > - Converting all inclusion to "select" since DRM_MIPI_DSI is not a menu > item. > - Remove "depends on DRM" since "select"ing DRM_MIPI_DSI won't include > DRM anyways, so this is misleading. The reason behind the decision to have both select and depends on for this was, if I recall correctly, so that a driver would select the symbol if it implemented (i.e. "provided") a DSI controller and panel drivers (or bridge drivers for that matter) would depend on the symbol to specify that they want to "consume" a DSI controller. That way the DSI panels and bridges can't be selected unless there is a driver that provides a DSI controller. If there's no driver that provides a DSI controller, there's no use in enabling any panels that need one. Granted, in retrospect this seems somewhat over-engineered, but the reason why it works is because thy symbol is not user-visible. That's one of the, I think even documented, use-cases where it is safe to use both select and depends. That said, I'm fine with simplifying this, but if we do, I would prefer going all the way and just removing the symbol entirely. It's not like it is a lot of extra infrastructure, at least compared to the rest of the helpers that we already pull in. There are also quite a few drivers that support DSI now, so I think there's more justification for unconditional inclusion than there used to be. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/panel: add Kingdisplay kd097d04 panel driver
From: Nickey Yang
Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
it is a MIPI dual-DSI panel.
v4:
- address Philipp's comments
- real range for usleep_range and
- poweroff ordering in kingdisplay_panel_prepare
- return value beautification in panel_probe
- update author naming for full name
v3:
- address Thierry's comments
- error handling for init dsi writes in init
- unconditionally remove the panel
- don't use drm_panel_detach
- a bit of variable signednes wiggling
- I did talk to ChromeOS people and the delays really should be as short
as possible, so dropped the 100ms from the delay comments
v2:
- update timing + cmds from chromeos kernel
- new backlight API including switch to devm_of_find_backlight
- fix most of Sean Paul's comments
enable/prepare tracking seems something all panels do
- document origins of the init sequence
- lanes per dsi interface to 4 (two interfaces). Matches how tegra
and pending rockchip dual-dsi handle (dual-)dsi lanes
- spdx header instead of license boilerplate
Signed-off-by: Nickey Yang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-kingdisplay-kd097d04.c| 473 ++
3 files changed, 485 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30a33b3..458253dc0842 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -77,6 +77,17 @@ config DRM_PANEL_JDI_LT070ME05000
The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
24 bit per pixel.
+config DRM_PANEL_KINGDISPLAY_KD097D04
+ tristate "Kingdisplay kd097d04 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Kingdisplay kd097d04
+ TFT-LCD modules. The panel has a 1536x2048 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9d13af..d59f75b84d48 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
new file mode 100644
index ..2a25a914d09e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct kingdisplay_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct backlight_device *backlight;
+ struct regulator *supply;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+struct kingdisplay_panel_cmd {
+ char cmd;
+ char data;
+};
+
+/*
+ * According to the discussion on
+ * https://review.coreboot.org/#/c/coreboot/+/22472/
+ * the panel init array is not part of the panels datasheet but instead
+ * just came in this form from the panel vendor.
+ */
+static const struct kingdisplay_panel_cmd init_code[] = {
+ /* voltage setting */
+ { 0xB0, 0x00 },
+ { 0xB2, 0x02 },
+ { 0xB3, 0x11 },
+ { 0xB4, 0x00 },
+ { 0xB6, 0x80 },
+ /* VCOM disable */
+ { 0xB7, 0x02 },
+ { 0xB8, 0x80 },
+ { 0xBA, 0x43 },
+ /* VCOM setting */
+ { 0xBB, 0x53 },
+ /* VSP setting */
+ { 0xBC, 0x0A },
+ /* VSN setting */
+ { 0xBD, 0x4A },
+ /* VGH setting */
+ { 0xBE, 0x2F },
+ /* VGL setting */
+ { 0xBF, 0x1A },
+ { 0xF0, 0x39 },
+ { 0xF1, 0x22 },
+ /* Gamma setting */
+ { 0xB0, 0x02 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x01 },
+ { 0xC2, 0x0B },
+ { 0xC3, 0x15 },
+ { 0xC4, 0x22 },
+ { 0xC5, 0x11 },
+ { 0xC6, 0x15 },
+ { 0xC7, 0x19 },
+ {
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 Daniel Vetter (dan...@ffwll.ch) changed: What|Removed |Added CC||dan...@ffwll.ch --- Comment #17 from Daniel Vetter (dan...@ffwll.ch) --- Can you pls attach a new kasan backtrace with my patch https://patchwork.freedesktop.org/patch/230355/ applied? Just want to double check nothing has moved, and also whether some other peculiarities of the stacktraces are invariant. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vgem: Remove unecessary dma_fence_ops
On Thu, Aug 09, 2018 at 01:48:42PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2018-08-09 13:45:44) > > dma_fence_default_wait is the default now, same for the trivial > > enable_signaling implementation. > > > > Also remove the ->signaled callback, vgem can't peek ahead with a > > fastpath, returning false is the default implementation. > > > > v2: Protect the meaningful space! (Chris) > > > > Signed-off-by: Daniel Vetter > > Cc: Kees Cook > > Cc: Cihangir Akturk > > Cc: Chris Wilson > > Cc: Sean Paul > > Cc: Daniel Vetter > > 1-4, > Reviewed-by: Chris Wilson Thanks for your reviews, all four pushed to drm-misc-next now. -Daniel -- 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
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #12 from Paju --- I'm using reference RX480 with default clocks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Do not include
On Fri, Aug 17, 2018 at 10:21:38AM +0200, Thomas Zimmermann wrote: > The gma500 driver has no dependencies on drm_global.h. Remove the include > statement. > > Signed-off-by: Thomas Zimmermann Applied, thanks for your patch. -Daniel > --- > drivers/gpu/drm/gma500/psb_drv.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/psb_drv.h > b/drivers/gpu/drm/gma500/psb_drv.h > index d067b262e454..b061764ef171 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.h > +++ b/drivers/gpu/drm/gma500/psb_drv.h > @@ -23,7 +23,6 @@ > #include > > #include > -#include > #include > #include "psb_reg.h" > #include "psb_intel_drv.h" > -- > 2.18.0 > > ___ > 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
[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #38 from Chí-Thanh Christopher Nguyễn --- Created attachment 141163 --> https://bugs.freedesktop.org/attachment.cgi?id=141163=edit patch against 4.18.1 I tried the latest patch too, and LVDS is now working (as expected, VGA does not work). I slightly adapted the patch so that it applies against linux 4.18.1, in case anyone is interested. -- 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/gma500: Do not include
The gma500 driver has no dependencies on drm_global.h. Remove the include statement. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/gma500/psb_drv.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h index d067b262e454..b061764ef171 100644 --- a/drivers/gpu/drm/gma500/psb_drv.h +++ b/drivers/gpu/drm/gma500/psb_drv.h @@ -23,7 +23,6 @@ #include #include -#include #include #include "psb_reg.h" #include "psb_intel_drv.h" -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107482] Images gamma rendering issue
https://bugs.freedesktop.org/show_bug.cgi?id=107482 Michel Dänzer changed: What|Removed |Added CC||sunpeng...@amd.com --- Comment #6 from Michel Dänzer --- (In reply to Sebastian Luncan from comment #5) > I've also took a picture (attached). On the left is amdgpu-dc on the right > amdgpu, gamma 3 (xgamma -gamma 3), kernel 4.17. See the trees and the grass > on the left. Why do they look different on the same gamma values? Can you try if current upstream xf86-video-amdgpu Git master works better with DC? -- 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 v1 3/7] mfd: add atmel-lcdc driver
On 15/08/2018 at 22:40, Sam Ravnborg wrote:
Hi Lee.
+
+static const struct mfd_cell lcdc_cells[] = {
+ {
+ .name = "atmel-lcdc-pwm",
+ .of_compatible = "atmel,lcdc-pwm",
+ },
+ {
+ .name = "atmel-lcdc-dc",
+ .of_compatible = "atmel,lcdc-display-controller",
+ },
+};
Will you be adding any more devices, or is this the entirety of the
device? If the latter, I suggest that this doesn't warrant being an
MFD.
Thats it. And others agree with you that this is not a good approach.
So in v2 there will be no MFD.
Thanks for confirming that the non-mfd way is the better approach.
MFD approach would have had the benefit of keeping this driver series
architecture close to the HLCD one. This would have been easier to
understand and use one SoC or another one from the AT91 product line
Anyway, I'd wait for Boris' feedback for making a decision.
Best regards,
--
Nicolas Ferre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: Fix potential Spectre v1
arg.version is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:4526 vmw_execbuf_ioctl() warn: potential spectre issue 'copy_offset' [w] Fix this by sanitizing arg.version before using it to index copy_offset Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel=152449131114778=2 Cc: sta...@vger.kernel.org Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c index 1f13457..ad91c6e 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -25,6 +25,7 @@ * **/ #include +#include #include "vmwgfx_drv.h" #include "vmwgfx_reg.h" @@ -4520,8 +4521,10 @@ int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data, return -EINVAL; } - if (arg.version > 1 && - copy_from_user(_handle, + if (arg.version >= ARRAY_SIZE(copy_offset)) + return -EFAULT; + arg.version = array_index_nospec(arg.version, ARRAY_SIZE(copy_offset)); + if (copy_from_user(_handle, (void __user *) (data + copy_offset[0]), copy_offset[arg.version - 1] - copy_offset[0]) != 0) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v5 2/3] dt-bindings: display: atmel: optional video-interface of endpoints
On 2018-08-03 10:51, jacopo mondi wrote:
> On Fri, Aug 03, 2018 at 10:40:02AM +0200, Peter Rosin wrote:
>> On 2018-08-03 10:11, jacopo mondi wrote:
>>> Hi Peter!
>>>
>>> On Fri, Aug 03, 2018 at 09:23:07AM +0200, Peter Rosin wrote:
With bus-type/bus-width properties in the endpoint nodes, the video-
interface of the connection can be specified for cases where the
heuristic fails to select the correct output mode. This can happen
e.g. if not all RGB pins are routed on the PCB; the driver has no
way of knowing this, and needs to be told explicitly.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/display/atmel/hlcdc-dc.txt | 26
++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
index 82f2acb3d374..9de434a8f523 100644
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
@@ -15,6 +15,14 @@ Required children nodes:
to external devices using the OF graph reprensentation (see
../graph.txt).
At least one port node is required.
+Optional properties in grandchild nodes:
+ Any endpoint grandchild node may specify a desired video interface
+ according to ../../media/video-interfaces.txt, specifically
+ - bus-type: must be <0>.
>>>
>>> Is there any value in specifying this, if it has a fixed value to
>>> "autodetect"? I understand it's optional, so if nobody else objects,
>>> feels free to keep it there.
>>
>> That's just how media/video-interfaces.txt works.
>>
>> bus-type 0 means that other properties describe the bus type. In this
>> case bus-width is specified, so that means a parallel bus. But bus-width
>> has no meaning (or may not have) if bus-type is non-zero. But checking
>> that bus-type for zero in the code seemed like overkill to me since the
>> driver already knows that it is a parallel bus...
>>
>
> Yeah, I felt like pointing that out since you're not cheking for its value,
> and that property is only used by v4l2-fwnode to handle some
> not-that-used-anymore bus as CCP2 is.
>
>> TL;DR I'd like to keep it.
>>
>
> Fine with me then.
>
>>>
+ - bus-width: recognized values are <12>, <16>, <18> and <24>, and
+ override any output mode selection heuristic, forcing "rgb444",
+ "rgb565", "rgb666" and "rgb888" respectively.
+
Example:
hlcdc: hlcdc@f003 {
@@ -50,3 +58,21 @@ Example:
#pwm-cells = <3>;
};
};
+
>>>
>>> Two blank lines here.
>>>
+
+Example 2: With a video interface override to force rgb565; as above
+but with these changes/additions:
+
+ {
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lcd_base _lcd_rgb565>;
+
+ port@0 {
>>>
>>> The node has a unit address specified, you're missing a reg = <0>
>>> property (no big deal, it's an example, but the other one has it)
>>>
+ hlcdc_panel_output: endpoint@0 {
>>>
>>> Missing reg here too.
>>
>> I'll fix those (I think they appeared for the original example after I
>> wrote the patch).
>>
>
> Ok, then please consider also describing the port@0 node cell sizes too
> since it has a child endpoint node.
Ok, I have now figured out why this was as it were, and I no longer agree
with adding the extra properties. The whole of example 2 is inside a
reference (using the notation) to the hlcdc node in example 1, and
therefore these "missing" properties are not missing. I think they are
just clutter that hides what is really needed/different between example 1
and 2, and apparently Boris and Rob agreed when they acked/reviewed. The
description of example 2 also clearly states that example 2 is changes
and additions on top of example 1. So, I plan to have this in the next
iteration:
{
hlcdc-display-controller {
pinctrl-names = "default";
pinctrl-0 = <_lcd_base _lcd_rgb565>;
port@0 {
hlcdc_panel_output: endpoint@0 {
bus-width = <16>;
};
};
};
};
Jacopo, please let me know if you want me to
[PATCH] drm/msm/disp/dpu: Use proper define for drm_encoder_init() 'encoder_type'
We got a bug report that this function oopses when trying to do a kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27: ffd8 x26:
x25: ff8008c216c8 x24:
x23: x22: ff80095fb720
x21: x20: ff80095fb720
x19: ff80095fb6f0 x18: 000a
x17: b42ba473 x16: ff800805bbe8
x15: 000a157d x14: 000c
x13: x12: 000f
x11: 0003 x10: 0001
x9 : 0040 x8 : 001c
x7 : x6 :
x5 : 0228 x4 :
x3 : 0a00ff04 x2 : 7961
x1 : x0 :
Process kworker/3:1 (pid: 61, stack limit = 0xff80095f8000)
Call trace:
Exception stack(0xff80095fb400 to 0xff80095fb540)
b400: 7961 0a00ff04
b420: 0228
b440: 001c 0040 0001 0003
b460: 000f 000c 000a157d
b480: ff800805bbe8 b42ba473 000a ff80095fb6f0
b4a0: ff80095fb720 ff80095fb720
b4c0: ff8008c216c8 ffd8
b4e0: ff8008ad42bc ff80095fb540 ff80088d5fc4 ff80095fb540
b500: ff80088d35d8 a0c00049 ff80095fb550 ff80080d06a4
b520: ff80088d5e0c ff80095fb540 ff80088d35d8
[] string+0x2c/0x60
[] vsnprintf+0x28c/0x4ec
[] kvasprintf+0x68/0x100
[] kasprintf+0x60/0x80
[] drm_encoder_init+0x134/0x164
[] dpu_encoder_init+0x60/0x94
[] _dpu_kms_drm_obj_init+0xa0/0x424
[] dpu_kms_hw_init+0x61c/0x6bc
[] msm_drm_bind+0x380/0x67c
[] try_to_bring_up_master+0x228/0x264
[] component_master_add_with_match+0x90/0xc0
[] msm_pdev_probe+0x260/0x2c8
[] platform_drv_probe+0x58/0xa8
[] driver_probe_device+0x2d8/0x40c
[] __device_attach_driver+0xd4/0x10c
[] bus_for_each_drv+0xb4/0xd0
[] __device_attach+0xd0/0x160
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x38/0x98
[] deferred_probe_work_func+0x144/0x148
[] process_one_work+0x218/0x3bc
[] process_scheduled_works+0x44/0x48
[] worker_thread+0x288/0x32c
[] kthread+0x134/0x13c
[] ret_from_fork+0x10/0x18
Code: 910003fd 2a0403e6 eb0400ff 5460 (38646845)
Looking at the code I see that drm_encoder_init() is called from the DPU
code with 'DRM_MODE_CONNECTOR_DSI' passed in as the 'encoder_type'
argument (follow from _dpu_kms_initialize_dsi()). That corresponds to
the integer 16. That is then indexed into drm_encoder_enum_list in
drm_encoder_init() to look up the name of the encoder. If you're still
following along, that's an encoder not a connector! We really want to
use DRM_MODE_ENCODER_DSI (integer 6) instead of DRM_MODE_CONNECTOR_DSI
here, or we'll go out of bounds of the encoder array. Pass the right
thing and everything is fine.
Cc: Jeykumar Sankaran
Cc: Jordan Crouse
Cc: Sean Paul
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7dd6bd2d6d37..74cc204b07e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -450,7 +450,7 @@ static void _dpu_kms_initialize_dsi(struct drm_device *dev,
int i, rc;
/*TODO: Support two independent DSI connectors */
- encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
if (IS_ERR_OR_NULL(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
return;
--
Sent by a computer through tubes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: host1x: Ignore clients initialization failure
On Monday, 13 August 2018 20:48:25 MSK Dmitry Osipenko wrote:
> On Friday, 10 August 2018 02:12:11 MSK Dmitry Osipenko wrote:
> > From time to time new bugs are popping up, causing some host1x client to
> > fail its initialization. Currently a single clients initialization failure
> > causes whole host1x device registration to fail, as a result a single DRM
> > sub-device initialization failure makes whole DRM initialization to fail.
> > Let's ignore clients initialization failure, as a result display panel
> > lights up even if some DRM clients (say GR2D or VIC) fail to initialize.
> > Actually VIC fails if initramfs misses the firmware file, so with this
> > change a serial console isn't needed anymore to figure out why display
> > isn't working.
> >
> > Signed-off-by: Dmitry Osipenko
> > ---
> >
> > Changelog:
> >
> > v2: Added WARN_ON() that should get more attention than just a error
> > message. Made clients_lock to lock around the lists modification, that is
> > in line with the rest of the code.
> >
> > drivers/gpu/host1x/bus.c | 20
> > 1 file changed, 8 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> > index 815bdb42e3f0..07bb6b6c1260 100644
> > --- a/drivers/gpu/host1x/bus.c
> > +++ b/drivers/gpu/host1x/bus.c
> > @@ -199,19 +199,23 @@ static void host1x_subdev_unregister(struct
> > host1x_device *device, */
> >
> > int host1x_device_init(struct host1x_device *device)
> > {
> >
> > - struct host1x_client *client;
> > + struct host1x_client *client, *cl;
> >
> > int err;
> >
> > mutex_lock(>clients_lock);
> >
> > - list_for_each_entry(client, >clients, list) {
> > + list_for_each_entry_safe(client, cl, >clients, list) {
> >
> > if (client->ops && client->ops->init) {
> >
> > err = client->ops->init(client);
> >
> > - if (err < 0) {
> > + if (WARN_ON(err < 0)) {
> >
> > dev_err(>dev,
> >
> > "failed to initialize %s: %d\n",
> > dev_name(client->dev), err);
> >
> > - goto teardown;
> > +
> > + /* add the client to the list of idle clients */
> > + mutex_lock(_lock);
> > + list_add_tail(>list, );
>
> This shall be list_move_tail(), v3 is coming.
>
> > + mutex_unlock(_lock);
I just realized that DRM won't load if any of host1x drivers fail to probe. I
think the behaviour should be consistent in a case of driver-probe and client-
init failures. It looks like changing drivers probe error handling will be a
much bigger change, hence let's keep the old behaviour at least for now.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: do not double put device node in zx_drm_probe
for_each_available_child_of_node will get and put the node properly,
the following of_node_put will lead to the double put. So just
remove it.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 6f4205e8..d7b9870 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -161,10 +161,8 @@ static int zx_drm_probe(struct platform_device *pdev)
if (ret)
return ret;
- for_each_available_child_of_node(parent, child) {
+ for_each_available_child_of_node(parent, child)
component_match_add(dev, , compare_of, child);
- of_node_put(child);
- }
return component_master_add_with_match(dev, _drm_master_ops, match);
}
--
1.7.12.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Documentation/fb/vesafb.txt: "inverse" option corrections
From: Randy Dunlap Spell the vesafb "inverse" option correctly and tell what it does. Signed-off-by: Randy Dunlap Cc: Bartlomiej Zolnierkiewicz Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Antonino A. Daplas --- Documentation/fb/vesafb.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- lnx-418.orig/Documentation/fb/vesafb.txt +++ lnx-418/Documentation/fb/vesafb.txt @@ -114,11 +114,11 @@ to turn it on. You can pass options to vesafb using "video=vesafb:option" on the kernel command line. Multiple options should be separated -by comma, like this: "video=vesafb:ypan,invers" +by comma, like this: "video=vesafb:ypan,inverse" Accepted options: -invers no comment... +inverseuse inverse color map ypan enable display panning using the VESA protected mode interface. The visible screen is just a window of the ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: fix a compile warning
Fix comile warning like,
CC [M] drivers/gpu/drm/i915/gvt/execlist.o
CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
CC [M] drivers/gpu/drm/radeon/btc_dpm.o
CC [M] drivers/isdn/hisax/avm_a1p.o
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.o
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_update_mpcc’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
warning: missing braces around initializer [-Wmissing-braces]
struct mpcc_blnd_cfg blnd_cfg = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:1903:9:
warning: (near initialization for ‘blnd_cfg.black_color’) [-Wmissing-braces]
Signed-off-by: Wen Yang
Reviewed-by: Jiang Biao
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index cfcc54f..a06a035 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1900,7 +1900,7 @@ static void update_dpp(struct dpp *dpp, struct
dc_plane_state *plane_state)
static void dcn10_update_mpcc(struct dc *dc, struct pipe_ctx *pipe_ctx)
{
struct hubp *hubp = pipe_ctx->plane_res.hubp;
- struct mpcc_blnd_cfg blnd_cfg = {0};
+ struct mpcc_blnd_cfg blnd_cfg = {{0}};
bool per_pixel_alpha = pipe_ctx->plane_state->per_pixel_alpha &&
pipe_ctx->bottom_pipe;
int mpcc_id;
struct mpcc *new_mpcc;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-sn65dsi86: Fix 0-day build error
On Thu, Aug 16, 2018 at 12:31 AM Daniel Vetter wrote: > > On Wed, Aug 15, 2018 at 03:49:14PM -0400, Sean Paul wrote: > > From: Guenter Roeck > > > > 0day reports: > > > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function > > `ti_sn_bridge_remove': > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:629: undefined reference to > > `mipi_dsi_detach' > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:630: undefined reference to > > `mipi_dsi_device_unregister' > >drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function > > `ti_sn_bridge_attach': > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:249: undefined reference to > > `of_find_mipi_dsi_host_by_node' > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:256: undefined reference to > > `mipi_dsi_device_register_full' > > >> drivers/gpu/drm/bridge/ti-sn65dsi86.c:276: undefined reference to > > `mipi_dsi_attach' > >drivers/gpu/drm/bridge/ti-sn65dsi86.c:289: undefined reference to > > `mipi_dsi_device_unregister' > > > > Quite obviously the driver depends on DRM_MIPI_DSI. > > We can not use "depends" since the driver configuration uses "select", > > so we'll have to select the missing dependency instead. > > > > Cc: Sean Paul > > Cc: Dylan Reid > > Signed-off-by: Guenter Roeck > > You can't mix depends and select for the same symbol, or all hell breaks > loose. So needs a depends on DRM_MIPI_DSI instead. With that changed: > Yes, that is why I used select, not depends, as explained. "depends" causes a circular dependency. Guenter > Reviewed-by: Daniel Vetter > > > --- > > > > Originally uploaded here: > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1176224 > > > > > > drivers/gpu/drm/bridge/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 9a455c5f24f0..9eeb8ef0b174 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -142,6 +142,7 @@ config DRM_TI_SN65DSI86 > > select DRM_KMS_HELPER > > select REGMAP_I2C > > select DRM_PANEL > > + select DRM_MIPI_DSI > > help > > Texas Instruments SN65DSI86 DSI to eDP Bridge driver > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS > > > > ___ > > 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
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #5 from Przemek --- Full valid git bisect log: git bisect log git bisect start # bad: [5024f8dfe478c1f56ef8812dabc55f2793024e93] drm/amdgpu:change VEGA booting with firmware loaded by PSP git bisect bad 5024f8dfe478c1f56ef8812dabc55f2793024e93 # good: [5c16f36f6f003b4415237acca59384a074cd8030] drm/amd/powerplay: Set higher SCLK frequency than dpm7 in OD (v2) git bisect good 5c16f36f6f003b4415237acca59384a074cd8030 # good: [c90fca951e90ba470a3dc6087667edffcf8db21b] Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux git bisect good c90fca951e90ba470a3dc6087667edffcf8db21b # good: [ab0b2e59323cd3972e5f011fbbf3868a4ec360dd] Merge tag 'upstream-4.18-rc1' of git://git.infradead.org/linux-ubifs git bisect good ab0b2e59323cd3972e5f011fbbf3868a4ec360dd # good: [19785cf93b6c4252981894394f2dbd35c5e5d1ec] Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal git bisect good 19785cf93b6c4252981894394f2dbd35c5e5d1ec # good: [3069290d9d6a9afa93661c299419089eea57164b] Merge tag 'drm-intel-next-2018-06-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next git bisect good 3069290d9d6a9afa93661c299419089eea57164b # bad: [c6d707136b4de409c7e74825e1f39e17e4b0797c] drm/amdgpu: Add support for logging process info in amdgpu_vm. git bisect bad c6d707136b4de409c7e74825e1f39e17e4b0797c # good: [565c17b5f02dacd8430da8d95bbba60587f339af] Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next git bisect good 565c17b5f02dacd8430da8d95bbba60587f339af # good: [adbf1d96771e898ea12b0c3f448a60c4bcf19979] drm/amd/display: Program vsc_infopacket in commit_planes_for_stream git bisect good adbf1d96771e898ea12b0c3f448a60c4bcf19979 # bad: [a7dd65771617773335fc289e8cb6b75346331799] drm/amdgpu/vce: simplify vce instance setup git bisect bad a7dd65771617773335fc289e8cb6b75346331799 # bad: [35e1371a89eb98069116dabfdfabdc6a9dbfda9e] drm/amd/powerplay: correct smc display config for multi monitor git bisect bad 35e1371a89eb98069116dabfdfabdc6a9dbfda9e # bad: [05d2638072d5b946623f96bac82673c2fa82c7e6] drm/amdgpu: Split set_pg_state into separate function git bisect bad 05d2638072d5b946623f96bac82673c2fa82c7e6 # good: [48c17e727376169a6165682fce9338393ee6b6da] drm/amdgpu: Rename set_mmhub_powergating_by_smu to powergate_mmhub git bisect good 48c17e727376169a6165682fce9338393ee6b6da # bad: [3d632bde5f010ff6f9d6baa0f24cd9e2c49bdb24] drm/amd/pp: Add gfx pg support in smu through set_powergating_by_smu git bisect bad 3d632bde5f010ff6f9d6baa0f24cd9e2c49bdb24 # bad: [561a5c83eadde747253924be2f7be9070841b7c0] drm/amd/pp: Unify powergate_uvd/vce/mmhub to set_powergating_by_smu git bisect bad 561a5c83eadde747253924be2f7be9070841b7c0 # good: [4a67b31524d6343fd153a1256b9652df5fcf29bc] drm/amd/pp: Rename enable_per_cu_power_gating to powergate_gfx git bisect good 4a67b31524d6343fd153a1256b9652df5fcf29bc # first bad commit: [561a5c83eadde747253924be2f7be9070841b7c0] drm/amd/pp: Unify powergate_uvd/vce/mmhub to set_powergating_by_smu -- 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: [RFC] etnaviv: missing dma_mask
On Tue, Aug 14, 2018 at 05:12:25PM +0300, Eugeniy Paltsev wrote: > Hi Lucas, Christoph, > > After switching ARC to generic dma_noncoherent cache ops > etnaviv driver start failing on dma maping functions because of > dma_mask lack. > > So I'm wondering is it valid case to have device which is > DMA capable and doesn't have dma_mask set? > > If not, then I guess something like that should work > (at least it works for ARC): This looks ok is a minimal fix: Reviewed-by: Christoph Hellwig But why doesn't this device have a dma-range property in DT? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 4.19-rc1
On Fri, Aug 17, 2018 at 12:22 AM, John Stultz wrote: > On Thu, Aug 16, 2018 at 3:16 PM, Daniel Vetter wrote: >> On Thu, Aug 16, 2018 at 11:21 PM, John Stultz wrote: >>> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter wrote: You happen to have set drm_fb_overalloc respectively CONFIG_DRM_FBDEV_OVERALLOC? Was added so that mali blob can pageflip, would explain what's going on at least. >>> >>> Yep. CONFIG_DRM_FBDEV_OVERALLOC is set to 200. >> >> So ->max_height is indeed the limit (or should be, minus driver bugs) >> for framebuffers. That's enforced in drm_framebuffer_create_internal >> for everything (both ioctl and should also for all internal callers), >> except the cma helpers never made sure this is correct. So I'd call >> this a bugfix. > > Sure. I'm really not sure where the max_height=2048 comes from (and > if its the real limitation or a vendor guessed value - the hikey960 > driver I have uses the same), but yea, the old code wasn't checking > it. So in a way the limit is not entirely correct, since it's enforced for drm_framebuffer, not for the underlying memory object. Assuming you keep alignment correct (which is not exposed to userspace) you can overallocate that and scan the drm_framebuffer over it. But the fbdev helpers don't do that. We also don't have separate limits for fb sizes and max scanout. Though the later is supposed to be filtered in the various mode_valid callbacks, not through max_*. >> Now the question is whether the fbdev page-flipping actually worked on >> older kernels for you or not ... > > It sure seems to work ok with the changes reverted. Any suggestion > on how to check this? No idea. I didn't type a testcase for it, wasn't my feature :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #11 from madc...@atlas.cz --- Just out of curiosity, do either of you have a card that is supposed to have some small overclocking done by the manufacturer? My RX570 is supposed to have this and I’m wondering if it could be responsible in any way. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Rationalize DRM_MIPI_DSI inclusion in Kconfig
On Thu, 16 Aug 2018, Daniel Vetter wrote: > On Thu, Aug 16, 2018 at 02:54:14PM -0400, Sean Paul wrote: >> From: Sean Paul >> >> DRM_MIPI_DSI is included via both "select" and "depends on", this is >> trouble waiting to happen since this will result in different behavior >> depending on which is used. >> >> This patch resolves the problem by: >> - Converting all inclusion to "select" since DRM_MIPI_DSI is not a menu >> item. >> - Remove "depends on DRM" since "select"ing DRM_MIPI_DSI won't include >> DRM anyways, so this is misleading. >> >> Cc: Jani Nikula >> Cc: Thierry Reding >> Suggested-by: Daniel Vetter >> Signed-off-by: Sean Paul >> --- >> drivers/gpu/drm/Kconfig | 1 - >> drivers/gpu/drm/panel/Kconfig | 22 +++--- >> 2 files changed, 11 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index cb88528e7b10..197691b10c6b 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -25,7 +25,6 @@ menuconfig DRM >> >> config DRM_MIPI_DSI >> bool >> -depends on DRM > > Since DRM_MIPI_DSI is a hidden symbol this should be ok. Personally I > think just throwing this out would be better, pretty much all other > helpers we have aren't optional (beyond the overall helper knob, maybe > also doesn't make sense - every driver needs it anyway). > > Reviewed-by: Daniel Vetter > > But Jani's ack here is worth more for sure on this topic :-) Haven't had my morning coffee yet, but looks good. Acked-by: Jani Nikula > -Daniel > > >> >> config DRM_DP_AUX_CHARDEV >> bool "DRM DP AUX Interface" >> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig >> index 6020c30a33b3..a1e00e9fa566 100644 >> --- a/drivers/gpu/drm/panel/Kconfig >> +++ b/drivers/gpu/drm/panel/Kconfig >> @@ -49,7 +49,7 @@ config DRM_PANEL_ILITEK_IL9322 >> config DRM_PANEL_ILITEK_ILI9881C >> tristate "Ilitek ILI9881C-based panels" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y if you want to enable support for panels based on the >> @@ -58,7 +58,7 @@ config DRM_PANEL_ILITEK_ILI9881C >> config DRM_PANEL_INNOLUX_P079ZCA >> tristate "Innolux P079ZCA panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y here if you want to enable support for Innolux P079ZCA >> @@ -69,7 +69,7 @@ config DRM_PANEL_INNOLUX_P079ZCA >> config DRM_PANEL_JDI_LT070ME05000 >> tristate "JDI LT070ME05000 WUXGA DSI panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y here if you want to enable support for JDI DSI video mode >> @@ -93,7 +93,7 @@ config DRM_PANEL_LG_LG4573 >> config DRM_PANEL_ORISETECH_OTM8009A >> tristate "Orise Technology otm8009a 480x800 dsi 2dl panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y here if you want to enable support for Orise Technology >> @@ -102,7 +102,7 @@ config DRM_PANEL_ORISETECH_OTM8009A >> config DRM_PANEL_PANASONIC_VVX10F034N00 >> tristate "Panasonic VVX10F034N00 1920x1200 video mode panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y here if you want to enable support for Panasonic VVX10F034N00 >> @@ -111,7 +111,7 @@ config DRM_PANEL_PANASONIC_VVX10F034N00 >> >> config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN >> tristate "Raspberry Pi 7-inch touchscreen panel" >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> help >>Say Y here if you want to enable support for the Raspberry >>Pi 7" Touchscreen. To compile this driver as a module, >> @@ -120,7 +120,7 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN >> config DRM_PANEL_RAYDIUM_RM68200 >> tristate "Raydium RM68200 720x1280 DSI video mode panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> help >>Say Y here if you want to enable support for Raydium RM68200 >> @@ -129,14 +129,14 @@ config DRM_PANEL_RAYDIUM_RM68200 >> config DRM_PANEL_SAMSUNG_S6E3HA2 >> tristate "Samsung S6E3HA2 DSI video mode panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> select VIDEOMODE_HELPERS >> >> config DRM_PANEL_SAMSUNG_S6E63J0X03 >> tristate "Samsung S6E63J0X03 DSI command mode panel" >> depends on OF >> -depends on DRM_MIPI_DSI >> +select DRM_MIPI_DSI >> depends on BACKLIGHT_CLASS_DEVICE >> select VIDEOMODE_HELPERS >> >> @@ -158,7 +158,7 @@ config
