[PATCHv14 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V12:
Wrap comments and fix commit message
V11:
No change
V10:
No change
V9:
Remove Display port node
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 63
1 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..89a3b9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,63 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<_encoder_input>;
+ };
+ };
+ };
+};
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv14 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the Sodt IP FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the Framebuffer 2 Soft IP and displayed on the Display Port Monitor. Ong Hean Loong (1): ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite Ong, Hean Loong (2): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 63 MAINTAINERS|9 + arch/arm/configs/socfpga_defconfig |8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 + drivers/gpu/drm/ivip/Makefile |6 + drivers/gpu/drm/ivip/intel_vip_conn.c | 93 ++ drivers/gpu/drm/ivip/intel_vip_drv.c | 335 drivers/gpu/drm/ivip/intel_vip_drv.h | 73 + 10 files changed, 604 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv14 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4..4727a96 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,14 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y +CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv14 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong, Hean Loong
---
MAINTAINERS |9 +
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/ivip/Kconfig | 14 ++
drivers/gpu/drm/ivip/Makefile |6 +
drivers/gpu/drm/ivip/intel_vip_conn.c | 93 +
drivers/gpu/drm/ivip/intel_vip_drv.c | 335 +
drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +++
8 files changed, 533 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e7e81fa..0fdec52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5229,6 +5229,15 @@ L: dri-devel@lists.freedesktop.org
F: include/drm/ttm/
F: drivers/gpu/drm/ttm/
+DRM INTEL IVIP
+M: Hean Loong, Ong
+L: dri-devel@lists.freedesktop.org
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: intel_vip_conn.c
+F: intel_vip_drv.c
+F: intel_vip_drv.h
+
DSBR100 USB FM RADIO DRIVER
M: Alexey Klimov
L: linux-me...@vger.kernel.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bd943a7..3db01e9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -231,6 +231,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1ac55c6..e8ac4e3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_V3D) += v3d/
obj-$(CONFIG_DRM_VC4) += vc4/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..8c54e11
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_drv.o intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..041b7a5
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * Authors:
+ * Walter Goossens
+ * Thomas Chou
+ * Chris Rauer
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs
[Bug 202555] nouveau: KMS is broken on last kernels (9700M GT)
https://bugzilla.kernel.org/show_bug.cgi?id=202555 --- Comment #1 from Evgeny Kurnevsky (kurnev...@gmail.com) --- Bisected to exact commit that breaks it: 800efb4c2857ec543fdc33585bbcb1fd5ef28337 -- 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 4/4] drm/sun4i: rgb: Change the pixel clock validation check
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on ]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-rgb-Relax-the-pixel-clock-check/20190227-012757
base:
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> drivers/gpu//drm/sun4i/sun4i_rgb.c:62:1: error: unknown type name 'DEFINE';
>> did you mean 'EPIPE'?
DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE 5
^~
EPIPE
>> drivers/gpu//drm/sun4i/sun4i_rgb.c:62:37: error: expected '=', ',', ';',
>> 'asm' or '__attribute__' before numeric constant
DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE 5
^
>> drivers/gpu//drm/sun4i/sun4i_rgb.c:191:16: error: 'sun4i_rgb_mode_valid'
>> undeclared here (not in a function); did you mean 'sun4i_rgb_con_funcs'?
.mode_valid = sun4i_rgb_mode_valid,
^~~~
sun4i_rgb_con_funcs
vim +191 drivers/gpu//drm/sun4i/sun4i_rgb.c
29e57fab9 Maxime Ripard 2015-10-29 55
3c3671edd Maxime Ripard 2019-02-26 56 /*
3c3671edd Maxime Ripard 2019-02-26 57 * VESA DMT defines a tolerance of
0.5% on the pixel clock, while the
3c3671edd Maxime Ripard 2019-02-26 58 * CVT spec reuses that tolerance in
its examples, so it looks to be a
3c3671edd Maxime Ripard 2019-02-26 59 * good default tolerance for the
EDID-based modes. Define it to 5 per
3c3671edd Maxime Ripard 2019-02-26 60 * mille to avoid floating point
operations.
3c3671edd Maxime Ripard 2019-02-26 61 */
3c3671edd Maxime Ripard 2019-02-26 @62 DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE
5
3c3671edd Maxime Ripard 2019-02-26 63
cde8b7548 Giulio Benetti 2018-03-13 64 static enum drm_mode_status
sun4i_rgb_mode_valid(struct drm_encoder *crtc,
cde8b7548 Giulio Benetti 2018-03-13 65
const struct drm_display_mode *mode)
29e57fab9 Maxime Ripard 2015-10-29 66 {
cde8b7548 Giulio Benetti 2018-03-13 67struct sun4i_rgb *rgb =
drm_encoder_to_sun4i_rgb(crtc);
b9c8506cb Chen-Yu Tsai 2017-02-23 68struct sun4i_tcon *tcon =
rgb->tcon;
29e57fab9 Maxime Ripard 2015-10-29 69u32 hsync = mode->hsync_end -
mode->hsync_start;
29e57fab9 Maxime Ripard 2015-10-29 70u32 vsync = mode->vsync_end -
mode->vsync_start;
7659a82a3 Maxime Ripard 2019-02-26 71unsigned long long rate =
mode->clock * 1000;
3c3671edd Maxime Ripard 2019-02-26 72unsigned long long lowest,
highest;
7659a82a3 Maxime Ripard 2019-02-26 73unsigned long long rounded_rate;
29e57fab9 Maxime Ripard 2015-10-29 74
29e57fab9 Maxime Ripard 2015-10-29 75DRM_DEBUG_DRIVER("Validating
modes...\n");
29e57fab9 Maxime Ripard 2015-10-29 76
29e57fab9 Maxime Ripard 2015-10-29 77if (hsync < 1)
29e57fab9 Maxime Ripard 2015-10-29 78return
MODE_HSYNC_NARROW;
29e57fab9 Maxime Ripard 2015-10-29 79
29e57fab9 Maxime Ripard 2015-10-29 80if (hsync > 0x3ff)
29e57fab9 Maxime Ripard 2015-10-29 81return MODE_HSYNC_WIDE;
29e57fab9 Maxime Ripard 2015-10-29 82
29e57fab9 Maxime Ripard 2015-10-29 83if ((mode->hdisplay < 1) ||
(mode->htotal < 1))
29e57fab9 Maxime Ripard 2015-10-29 84return MODE_H_ILLEGAL;
29e57fab9 Maxime Ripard 2015-10-29 85
29e57fab9 Maxime Ripard 2015-10-29 86if ((mode->hdisplay > 0x7ff) ||
(mode->htotal > 0xfff))
29e57fab9 Maxime Ripard 2015-10-29 87return MODE_BAD_HVALUE;
29e57fab9 Maxime Ripard 2015-10-29 88
29e57fab9 Maxime Ripard 2015-10-29 89DRM_DEBUG_DRIVER("Horizontal
parameters OK\n");
29e57fab9 Maxime Ripard 2015-10-29 90
29e57fab9 Maxime Ripard 2015-10-29 91if (vsync < 1)
29e57fab9 Maxime Ripard 2015-10-29 92return
MODE_VSYNC_NARROW;
29e57fab9 Maxime Ripard 2015-10-29 93
29e57fab9 Maxime Ripard 2015-10-29 94if (vsync > 0x3ff)
29e57fab9 Maxime Ripard 2015-10-29 95return MODE_VSYNC_WIDE;
29e57fab9 Maxime Ripard 2015-10-29 96
29e57fab9 Maxime Ripard 2015-10-29 97if ((mode->vdisplay < 1) ||
(mode->vtotal < 1))
29e57fab9 Maxime Ripard 2015-10-29 98return MODE_V_ILLEGAL;
29e57fab9 Maxime Ripard 2015-10-29 99
29e57fab9 Maxime Ripard 2015-10-29 100if ((mode->vdisplay > 0x7ff) ||
(mode->vtotal > 0xfff))
29e57fab9 Maxime Ripard 2015-10-29 101return MODE_BAD_VVALUE;
29e57fab9 Maxime Ripard 2015-10-29 102
29e57fab9 Maxime Ripard 2015-10-29 103DRM_DEBUG_DRIVER("Vertical
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #15 from mikhail.v.gavri...@gmail.com --- Created attachment 143485 --> https://bugs.freedesktop.org/attachment.cgi?id=143485=edit "suspicious RCU usage" the commits 3741540 and 222b5f0 is reverted -- 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 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #14 from mikhail.v.gavri...@gmail.com --- Removing commits 3741540 and 222b5f0 not fix "suspicious RCU usage" -- 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 109790] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=109790 --- Comment #3 from Alex Deucher --- (In reply to baopeng from comment #0) > Created attachment 143482 [details] > error_dmesg > > We enabled the Radeon OLAND series of graphics cards on ARM, very old > graphics cards, > The kernel is a 4.14 kernel and there is a problem with GPU acceleration not > being enabled: > The kernel initialization log is as follows, there are 2 errors, one is > radeon :43:00.0: failed VCE resume (-110). This one is harmless. > One is [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed > (scratch(0x850C)=0xCAFEDEAD), this error causes the GPU acceleration > function to be turned off. > Can you ask me what it is, or how to position it next? For this one, make sure you have this patch: https://cgit.freedesktop.org/drm/drm/commit/?id=e02f5c1bb2283cfcee68f2f0feddcc06150f13aa and also make sure your ARM platform supports cache coherence as required by the PCI spec. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/sun4i: rgb: Change the pixel clock validation check
Hi Maxime, I love your patch! Yet something to improve: [auto build test ERROR on ] url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-rgb-Relax-the-pixel-clock-check/20190227-012757 base: config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> drivers/gpu//drm/sun4i/sun4i_rgb.c:62:1: error: unknown type name 'DEFINE'; >> did you mean 'EMFILE'? DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE 5 ^~ EMFILE drivers/gpu//drm/sun4i/sun4i_rgb.c:62:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before numeric constant DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE 5 ^ drivers/gpu//drm/sun4i/sun4i_rgb.c:191:16: error: 'sun4i_rgb_mode_valid' undeclared here (not in a function); did you mean 'sun4i_rgb_con_funcs'? .mode_valid = sun4i_rgb_mode_valid, ^~~~ sun4i_rgb_con_funcs vim +62 drivers/gpu//drm/sun4i/sun4i_rgb.c 55 56 /* 57 * VESA DMT defines a tolerance of 0.5% on the pixel clock, while the 58 * CVT spec reuses that tolerance in its examples, so it looks to be a 59 * good default tolerance for the EDID-based modes. Define it to 5 per 60 * mille to avoid floating point operations. 61 */ > 62 DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE 5 63 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109790] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=109790 --- Comment #2 from baopeng --- Created attachment 143484 --> https://bugs.freedesktop.org/attachment.cgi?id=143484=edit uname_msg -- 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 109790] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=109790 --- Comment #1 from baopeng --- Created attachment 143483 --> https://bugs.freedesktop.org/attachment.cgi?id=143483=edit lspci_msg -- 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 109790] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=109790 Bug ID: 109790 Summary: [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) Product: DRI Version: DRI git Hardware: ARM OS: All Status: NEW Severity: critical Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: baopeng88_...@163.com Created attachment 143482 --> https://bugs.freedesktop.org/attachment.cgi?id=143482=edit error_dmesg We enabled the Radeon OLAND series of graphics cards on ARM, very old graphics cards, The kernel is a 4.14 kernel and there is a problem with GPU acceleration not being enabled: The kernel initialization log is as follows, there are 2 errors, one is radeon :43:00.0: failed VCE resume (-110). One is [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD), this error causes the GPU acceleration function to be turned off. Can you ask me what it is, or how to position it next? 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
[Bug 109789] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=109789 Bug ID: 109789 Summary: [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) Product: DRI Version: unspecified Hardware: ARM OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: baopeng88_...@163.com Created attachment 143481 --> https://bugs.freedesktop.org/attachment.cgi?id=143481=edit error_dmesg error msg: 1.[ 11.151435] radeon :43:00.0: failed VCE resume (-110); 2.[ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD); 3.radeon :43:00.0: disabling GPU acceleration -- 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 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #30 from Michael A. Leonetti (mikealeone...@gmail.com) --- Can confirm, disabling CONFIG_X86_VSMP corrects the issue. -- 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: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote: > > On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote: > > On 2/26/19 12:20 AM, John Stultz wrote: > > > It boots w/ AOSP, and allocations seem to work, but there's something > > > wrong with the dmabuf mmaping which casues the homescreen to crash > > > over and over. > > > (userland patches updated here: > > > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436) > > > > > > > Interesting, I wonder if the caching stuff is not right here, I'll see > > if I can get this working on my side (AOSP on Beagle x15). > > > > Let me know if you figure anything out, I'll also be looking at this today. > Ok. Figured out the issue. There was a missing: len = PAGE_ALIGN(len) assignment that the core used to do before calling the heap alloc op. Adding that into the heap alloc op got it booting ok w/ AOSP. I've updated the patches here: kernel: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap userland: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > I also realized some of Benajmin's error path improvements are going > to be hard to fix w/ my current code, specifically having the allocate > op do the allocation of the dma_heap_buffer (since we don't have a > free op, if something fails creating the dmabuf fd in the core, we > don't have a hook to release the dma_heap_buffer and heap private > data). I also realized doing my development and testing against my hikey960-mainline-WIP branch, I accidentally folded in an ion hack I was using to reduce cache operations, so I'll need to undo that in the heap-helpers.c. But at least we have a rough validation point for the design. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "dma-contiguous: do not allocate a single page from CMA area"
On 2019-02-26 8:23 pm, Nicolin Chen wrote:
This reverts commit d222e42e88168fd67e6d131984b86477af1fc256.
The original change breaks omap dss:
omapdss_dispc 58001000.dispc:
dispc_errata_i734_wa_init: dma_alloc_writecombine failed
Let's revert it first and then find a safer solution instead.
Ah, I think I see the problem - once arch/arm's __dma_alloc() has
decided to use CMA (because dev_get_cma_area(dev) returns the global
area), it then won't fall back to trying a regular page allocation if
dma_alloc_from_contiguous() returns NULL. Thus anything on 32-bit Arm
trying to allocate a single-page buffer in blockable context with a
CMA-enabled config is just going to fail. Similarly, it looks like none
of the DMA_ATTR_FORCE_CONTIGUOUS cases are prepared to handle this
change either (amd_iommu appears technically affected, but is already
using dma_alloc_from_contiguous() backwards compared to everyone else, hmm).
I guess the question is whether to add alloc_page()/free_page()
fallbacks to those call sites, or stuff them directly into the CMA
helpers here.
Robin.
Reported-by: Tony Lindgren
Signed-off-by: Nicolin Chen
---
Tony,
Would you please test and verify? Thanks!
kernel/dma/contiguous.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 09074bd04793..b2a87905846d 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -186,32 +186,16 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
*
* This function allocates memory buffer for specified device. It uses
* device specific contiguous memory area if available or the default
- * global one.
- *
- * However, it skips one-page size of allocations from the global area.
- * As the addresses within one page are always contiguous, so there is
- * no need to waste CMA pages for that kind; it also helps reduce the
- * fragmentations in the CMA area. So a caller should be the rebounder
- * in such case to allocate a normal page upon NULL return value.
- *
- * Requires architecture specific dev_get_cma_area() helper function.
+ * global one. Requires architecture specific dev_get_cma_area() helper
+ * function.
*/
struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
unsigned int align, bool no_warn)
{
- struct cma *cma;
-
if (align > CONFIG_CMA_ALIGNMENT)
align = CONFIG_CMA_ALIGNMENT;
- if (dev && dev->cma_area)
- cma = dev->cma_area;
- else if (count > 1)
- cma = dma_contiguous_default_area;
- else
- return NULL;
-
- return cma_alloc(cma, count, align, no_warn);
+ return cma_alloc(dev_get_cma_area(dev), count, align, no_warn);
}
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
> > At the end of the day, I don't really care that much. I get it, we > > all have large projects with scarce resources. I just think a few > > years down the road we'll all regret it as a community. > > AMD and others have also spent years tuning TTM for both UMA and VRAM, > but especially VRAM. It comes across a bit daft to complain about the > effort to move to TTM, but say nothing about the effort to tune GEM > for optimal VRAM performance. Effort that has already been expended > that you could take advantage of. I'm with Alex here, the patches you have now are just the start, I realise you think they are all you'll need, but I expect once Chris gets going with real VRAM hardware he'll generate reams for stuff. People have been tuning and making TTM run on VRAM using GPUs for longer than you've been making VRAM using GPUs, there had better be good and well thought out reasons for avoiding using it, and so far you haven't made that argument to me all. In fact your scheduler arguments works against you. If we should have abstracted i915 scheduler out and used it because it had more features and pre-existed, then i915 should be using TTM since it's already abstracted out and has more features. Like we've pulled other stuff out of TTM like reservation objects, I don't think i915 uses those yet either when it clearly could be. Maybe if we started by fixing that, moving to TTM would be less of a problem. Anyways, I expect moving to TTM is a big change for i915, and probably more than you are able to bite off at present, but I'm going to be watching closely what stuff you add on top of this sort of thing, and if it starts getting large and messier as you tune it, I'll have to start reconsidering how big a NO I have to use. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls
Hi Daniel,
Thanks for the comment.
On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote:
> On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
> wrote:
> >
> > On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > > Add the dmabuf map / unmap interfaces. This allows the user driver
> > > to be able to import the external dmabuf and use it from user space.
> > >
> > > Signed-off-by: Hyun Kwon
> > > ---
> > > drivers/uio/Makefile | 2 +-
> > > drivers/uio/uio.c| 43 +
> > > drivers/uio/uio_dmabuf.c | 210
> > > +++
> > > drivers/uio/uio_dmabuf.h | 26 ++
> > > include/uapi/linux/uio/uio.h | 33 +++
> > > 5 files changed, 313 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/uio/uio_dmabuf.c
> > > create mode 100644 drivers/uio/uio_dmabuf.h
> > > create mode 100644 include/uapi/linux/uio/uio.h
> > >
> > > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > > index c285dd2..5da16c7 100644
> > > --- a/drivers/uio/Makefile
> > > +++ b/drivers/uio/Makefile
> > > @@ -1,5 +1,5 @@
> > > # SPDX-License-Identifier: GPL-2.0
> > > -obj-$(CONFIG_UIO)+= uio.o
> > > +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> > > obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> > > obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> > > obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > > index 1313422..6841f98 100644
> > > --- a/drivers/uio/uio.c
> > > +++ b/drivers/uio/uio.c
> > > @@ -24,6 +24,12 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "uio_dmabuf.h"
> > >
> > > #define UIO_MAX_DEVICES (1U << MINORBITS)
> > >
> > > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void
> > > *dev_id)
> > > struct uio_listener {
> > > struct uio_device *dev;
> > > s32 event_count;
> > > + struct list_head dbufs;
> > > + struct mutex dbufs_lock; /* protect @dbufs */
> > > };
> > >
> > > static int uio_open(struct inode *inode, struct file *filep)
> > > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct file
> > > *filep)
> > > if (ret)
> > > goto err_infoopen;
> > >
> > > + INIT_LIST_HEAD(>dbufs);
> > > + mutex_init(>dbufs_lock);
> > > +
> > > return 0;
> > >
> > > err_infoopen:
> > > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, struct
> > > file *filep)
> > > struct uio_listener *listener = filep->private_data;
> > > struct uio_device *idev = listener->dev;
> > >
> > > + ret = uio_dmabuf_cleanup(idev, >dbufs,
> > > >dbufs_lock);
> > > + if (ret)
> > > + dev_err(>dev, "failed to clean up the dma bufs\n");
> > > +
> > > mutex_lock(>info_lock);
> > > if (idev->info && idev->info->release)
> > > ret = idev->info->release(idev->info, inode);
> > > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, const
> > > char __user *buf,
> > > return retval ? retval : sizeof(s32);
> > > }
> > >
> > > +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned
> > > long arg)
> >
> > We have resisted adding a uio ioctl for a long time, can't you do this
> > through sysfs somehow?
> >
> > A meta-comment about your ioctl structure:
> >
> > > +#define UIO_DMABUF_DIR_BIDIR 1
> > > +#define UIO_DMABUF_DIR_TO_DEV2
> > > +#define UIO_DMABUF_DIR_FROM_DEV 3
> > > +#define UIO_DMABUF_DIR_NONE 4
> >
> > enumerated type?
> >
> > > +
> > > +struct uio_dmabuf_args {
> > > + __s32 dbuf_fd;
> > > + __u64 dma_addr;
> > > + __u64 size;
> > > + __u32 dir;
> >
> > Why the odd alignment? Are you sure this is the best packing for such a
> > structure?
> >
> > Why is dbuf_fd __s32? dir can be __u8, right?
> >
> > I don't know that dma layer very well, it would be good to get some
> > review from others to see if this really is even a viable thing to do.
> > The fd handling seems a bit "odd" here, but maybe I just do not
> > understand it.
>
> Frankly looks like a ploy to sidestep review by graphics folks. We'd
> ask for the userspace first :-)
Please refer to pull request [1].
For any interest in more details, the libmetal is the abstraction layer
which provides platform independent APIs. The backend implementation
can be selected per different platforms: ex, rtos, linux,
standalone (xilinx),,,. For Linux, it supports UIO / vfio as of now.
The actual user space drivers sit on top of libmetal. Such drivers can be
found in [2]. This is why I try to avoid any device specific code in
Linux kernel.
>
> Also, exporting dma_addr to userspace is considered a very bad idea.
I agree, hence the RFC to pick some brains. :-) Would it make sense
if this call doesn't export the physicall address, but instead takes
only the dmabuf fd and register
Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls
Hi Greg,
Thanks for the comments.
On Tue, 2019-02-26 at 03:53:11 -0800, Greg Kroah-Hartman wrote:
> On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > Add the dmabuf map / unmap interfaces. This allows the user driver
> > to be able to import the external dmabuf and use it from user space.
> >
> > Signed-off-by: Hyun Kwon
> > ---
> > drivers/uio/Makefile | 2 +-
> > drivers/uio/uio.c| 43 +
> > drivers/uio/uio_dmabuf.c | 210
> > +++
> > drivers/uio/uio_dmabuf.h | 26 ++
> > include/uapi/linux/uio/uio.h | 33 +++
> > 5 files changed, 313 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/uio/uio_dmabuf.c
> > create mode 100644 drivers/uio/uio_dmabuf.h
> > create mode 100644 include/uapi/linux/uio/uio.h
> >
> > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > index c285dd2..5da16c7 100644
> > --- a/drivers/uio/Makefile
> > +++ b/drivers/uio/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_UIO) += uio.o
> > +obj-$(CONFIG_UIO) += uio.o uio_dmabuf.o
> > obj-$(CONFIG_UIO_CIF) += uio_cif.o
> > obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
> > obj-$(CONFIG_UIO_DMEM_GENIRQ) += uio_dmem_genirq.o
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 1313422..6841f98 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -24,6 +24,12 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "uio_dmabuf.h"
> >
> > #define UIO_MAX_DEVICES(1U << MINORBITS)
> >
> > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void *dev_id)
> > struct uio_listener {
> > struct uio_device *dev;
> > s32 event_count;
> > + struct list_head dbufs;
> > + struct mutex dbufs_lock; /* protect @dbufs */
> > };
> >
> > static int uio_open(struct inode *inode, struct file *filep)
> > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct file
> > *filep)
> > if (ret)
> > goto err_infoopen;
> >
> > + INIT_LIST_HEAD(>dbufs);
> > + mutex_init(>dbufs_lock);
> > +
> > return 0;
> >
> > err_infoopen:
> > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, struct
> > file *filep)
> > struct uio_listener *listener = filep->private_data;
> > struct uio_device *idev = listener->dev;
> >
> > + ret = uio_dmabuf_cleanup(idev, >dbufs, >dbufs_lock);
> > + if (ret)
> > + dev_err(>dev, "failed to clean up the dma bufs\n");
> > +
> > mutex_lock(>info_lock);
> > if (idev->info && idev->info->release)
> > ret = idev->info->release(idev->info, inode);
> > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, const
> > char __user *buf,
> > return retval ? retval : sizeof(s32);
> > }
> >
> > +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned long
> > arg)
>
> We have resisted adding a uio ioctl for a long time, can't you do this
> through sysfs somehow?
>
The dmabuf is managed as per process resource, so it's hard to do it through
sysfs.
> A meta-comment about your ioctl structure:
>
> > +#define UIO_DMABUF_DIR_BIDIR 1
> > +#define UIO_DMABUF_DIR_TO_DEV 2
> > +#define UIO_DMABUF_DIR_FROM_DEV3
> > +#define UIO_DMABUF_DIR_NONE4
>
> enumerated type?
>
> > +
> > +struct uio_dmabuf_args {
> > + __s32 dbuf_fd;
> > + __u64 dma_addr;
> > + __u64 size;
> > + __u32 dir;
>
> Why the odd alignment? Are you sure this is the best packing for such a
> structure?
>
> Why is dbuf_fd __s32? dir can be __u8, right?
The dmabuf fd is defined as int, so __s32 seems correct. Please let me know
otherwise. The dir can be __u8. Will fix if there is v2 at all.
>
> I don't know that dma layer very well, it would be good to get some
> review from others to see if this really is even a viable thing to do.
> The fd handling seems a bit "odd" here, but maybe I just do not
> understand it.
Agreed. So I'm looking forward to feedback or if there's more sensible
alternative.
Thanks,
-hyun
>
> thanks,
>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails
Quoting Eric Biggers (2019-02-26 22:08:58)
> From: Eric Biggers
>
> If drm_gem_handle_create() fails in vkms_gem_create(), then the
> vkms_gem_object is freed twice: once when the reference is dropped by
> drm_gem_object_put_unlocked(), and again by the extra calls to
> drm_gem_object_release() and kfree().
>
> Fix it by skipping the second release and free.
>
> This bug was originally found in the vgem driver by syzkaller using
> fault injection, but I noticed it's also present in the vkms driver.
>
> Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails
From: Eric Biggers
If drm_gem_handle_create() fails in vkms_gem_create(), then the
vkms_gem_object is freed twice: once when the reference is dropped by
drm_gem_object_put_unlocked(), and again by the extra calls to
drm_gem_object_release() and kfree().
Fix it by skipping the second release and free.
This bug was originally found in the vgem driver by syzkaller using
fault injection, but I noticed it's also present in the vkms driver.
Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
drivers/gpu/drm/vkms/vkms_gem.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 138b0bb325cf9..69048e73377dc 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
*dev,
ret = drm_gem_handle_create(file, >gem, handle);
drm_gem_object_put_unlocked(>gem);
- if (ret) {
- drm_gem_object_release(>gem);
- kfree(obj);
+ if (ret)
return ERR_PTR(ret);
- }
return >gem;
}
--
2.21.0.rc2.261.ga7da99ff1b-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vgem: fix use-after-free when drm_gem_handle_create() fails
From: Eric Biggers
If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
This was hit by syzkaller using fault injection.
Fix it by skipping the second free.
Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Reviewed-by: Chris Wilson
Cc: Laura Abbott
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
drivers/gpu/drm/vgem/vgem_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 5930facd6d2d8..11a8f99ba18c5 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -191,13 +191,9 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
ret = drm_gem_handle_create(file, >base, handle);
drm_gem_object_put_unlocked(>base);
if (ret)
- goto err;
+ return ERR_PTR(ret);
return >base;
-
-err:
- __vgem_gem_destroy(obj);
- return ERR_PTR(ret);
}
static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
--
2.21.0.rc2.261.ga7da99ff1b-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109749] FreeSync stutters if framerate is less than refresh rate and vsync/flipping is on
https://bugs.freedesktop.org/show_bug.cgi?id=109749 --- Comment #1 from bmil...@gmail.com --- Created attachment 143480 --> https://bugs.freedesktop.org/attachment.cgi?id=143480=edit backported for 5.0 patch Here's a backported patch for 5.0 Please consider this, anything that doesnt run at maximum vsync fps is a stuttery mess, making Freesync useless (with the fix something like 45-58fps is smooth, tearless and stutter free which is what VRR is supposed to do). -- 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/vgem: fix use-after-free when drm_gem_handle_create() fails
On Tue, Feb 26, 2019 at 09:01:29PM +, Chris Wilson wrote:
> Quoting Eric Biggers (2019-02-26 20:47:26)
> > From: Eric Biggers
> >
> > If drm_gem_handle_create() fails in vgem_gem_create(), then the
> > drm_vgem_gem_object is freed twice: once when the reference is dropped
> > by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
> >
> > This was hit by syzkaller using fault injection.
> >
> > Fix it by skipping the second free.
> >
> > Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
> > Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping")
>
> That's the wrong fixes line, it's
> Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> Cc: Chris Wilson
> Cc: Laura Abbott
> Cc: Daniel Vetter
>
> Sadly I reviewed it so I'm still culpable, but the fix is correct as the
> put purposely frees it on error.
>
You're right; I misread the code at that commit.
I'll resend with the correct tags.
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eric Biggers
>
> > ---
> > drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > index 5930facd6d2d8..70646d9da1596 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -189,15 +189,13 @@ static struct drm_gem_object *vgem_gem_create(struct
> > drm_device *dev,
> > return ERR_CAST(obj);
> >
> > ret = drm_gem_handle_create(file, >base, handle);
> > +
> > drm_gem_object_put_unlocked(>base);
> > +
>
> The pattern in the other GEM drivers is not to have these extra
> newlines.
>
> Reviewed-by: Chris Wilson
>
> > if (ret)
> > - goto err;
> > + return ERR_PTR(ret);
> >
> > return >base;
> > -
> > -err:
> > - __vgem_gem_destroy(obj);
> > - return ERR_PTR(ret);
> > }
> >
> > static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device
> > *dev,
> > --
> > 2.21.0.rc2.261.ga7da99ff1b-goog
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/mei-hdcp for char-misc-next
Hi Greg topic/mei-hdcp-2019-02-26: mei-hdcp driver mei driver for the me hdcp client, for use by drm/i915. Including the following prep work: - whitelist hdcp client in mei bus - merge to include char-misc-next because of another mei bus prep patch to export a helper macro to drivers - drm/i915 side of the mei_hdcp/i915 component interface (already pulled into drm-intel for 5.2 as a topic branch) - component prep work (including one patch touching i915), already pulled by you into drivers-base-next for 5.1 mei-hdcp patches all reviewed and acked by Tomas Winkler. All other bits and pieces acked by relevant subsystem people. Took a bit longer than planned, but so does the 5.0 release. Up to you whether you still want to pull for 5.1 merge window or delay for 5.2, either totally fine for us. The drm/i915 of this will only land in 5.2 completely. Cheers, Daniel Note: diffstat below generated against Linus' tree. Which is wrong, but since this both contains drivers-base-next, char-misc-next and stuff queued for drm-i915 (but which isn't in linux-next yet because that's aimed for 5.2) it's a bit a mess. Given that shrugged and just went with this. I can regenerate some other diffstat if you want something else, just didn't know what's really the right thing here. The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-26 for you to fetch changes up to fa301ad9fa8f6f738b9c22da3ede7824e3286693: misc/mei/hdcp: Component framework for I915 Interface (2019-02-25 17:03:01 +0100) mei-hdcp driver mei driver for the me hdcp client, for use by drm/i915. Including the following prep work: - whitelist hdcp client in mei bus - merge to include char-misc-next - drm/i915 side of the mei_hdcp/i915 component interface - component prep work (including one patch touching i915) Aditya Pakki (1): misc/ics932s401: Add a missing check to i2c_smbus_read_word_data Alan Tull (1): fpga: altera_freeze_bridge: remove restriction to socfpga Alban Bedel (7): nvmem: core: Set the provider read-only when no write callback is given nvmem: core: Fix of_nvmem_cell_get() for optional cells nvmem: core: Fix cell lookup when no cell is found nvmem: core: Properly handle connection ID in of_nvmem_device_get() nvmem: core: Always reference the device returned by nvmem_device_get() nvmem: core: Fix device reference leak nvmem: core: Avoid useless iterations in nvmem_cell_get_from_lookup() Alexander Kapshuk (1): ver_linux: Assign constant RE to variable name for clarity Alexander Usyskin (1): mei: squash single_recv_buf into one bit in client properties Anson Huang (2): dt-bindings: nvmem: imx-ocotp: add compatible string for i.MX7ULP nvmem: imx-ocotp: add i.MX7ULP support Buland Singh (1): hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable Chengguang Xu (2): uio: fix potential memory leak in error case uio: remove redundant check Christophe Leroy (2): lkdtm: Print real addresses lkdtm: Add tests for NULL pointer dereference Colin Ian King (2): drivers: misc: ad525x_dpot: clean indentation issue, remove tabs fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size Daniel Vetter (4): component: Add documentation components: multiple components for a device i915/snd_hdac: I915 subcomponent for the snd_hdac Pull in char-misc-next from Greg David Dai (2): interconnect: qcom: Add sdm845 interconnect provider driver arm64: dts: sdm845: Add interconnect provider DT nodes Finn Thain (22): scsi/atari_scsi: Don't select CONFIG_NVRAM m68k/atari: Move Atari-specific code out of drivers/char/nvram.c char/nvram: Re-order functions to remove forward declarations and #ifdefs nvram: Replace nvram_* function exports with static functions m68k/atari: Implement arch_nvram_ops struct powerpc: Replace nvram_* extern declarations with standard header char/nvram: Adopt arch_nvram_ops char/nvram: Allow the set_checksum and initialize ioctls to be omitted char/nvram: Implement NVRAM read/write methods m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS m68k/mac: Adopt naming and calling conventions for PRAM routines m68k/mac: Use macros for RTC accesses not magic numbers m68k/mac: Fix PRAM accessors macintosh/via-cuda: Don't rely on Cuda to end a transfer m68k: Dispatch nvram_ops calls to Atari or Mac functions char/nvram: Add "devname:nvram" module alias powerpc: Define missing ppc_md.nvram_size for CHRP and PowerMac
Re: [PATCH] drm/vgem: fix use-after-free when drm_gem_handle_create() fails
Quoting Eric Biggers (2019-02-26 20:47:26)
> From: Eric Biggers
>
> If drm_gem_handle_create() fails in vgem_gem_create(), then the
> drm_vgem_gem_object is freed twice: once when the reference is dropped
> by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
>
> This was hit by syzkaller using fault injection.
>
> Fix it by skipping the second free.
>
> Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
> Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping")
That's the wrong fixes line, it's
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Cc: Chris Wilson
Cc: Laura Abbott
Cc: Daniel Vetter
Sadly I reviewed it so I'm still culpable, but the fix is correct as the
put purposely frees it on error.
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 5930facd6d2d8..70646d9da1596 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -189,15 +189,13 @@ static struct drm_gem_object *vgem_gem_create(struct
> drm_device *dev,
> return ERR_CAST(obj);
>
> ret = drm_gem_handle_create(file, >base, handle);
> +
> drm_gem_object_put_unlocked(>base);
> +
The pattern in the other GEM drivers is not to have these extra
newlines.
Reviewed-by: Chris Wilson
> if (ret)
> - goto err;
> + return ERR_PTR(ret);
>
> return >base;
> -
> -err:
> - __vgem_gem_destroy(obj);
> - return ERR_PTR(ret);
> }
>
> static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device
> *dev,
> --
> 2.21.0.rc2.261.ga7da99ff1b-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vgem: fix use-after-free when drm_gem_handle_create() fails
From: Eric Biggers
If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
This was hit by syzkaller using fault injection.
Fix it by skipping the second free.
Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 5930facd6d2d8..70646d9da1596 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -189,15 +189,13 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
return ERR_CAST(obj);
ret = drm_gem_handle_create(file, >base, handle);
+
drm_gem_object_put_unlocked(>base);
+
if (ret)
- goto err;
+ return ERR_PTR(ret);
return >base;
-
-err:
- __vgem_gem_destroy(obj);
- return ERR_PTR(ret);
}
static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
--
2.21.0.rc2.261.ga7da99ff1b-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 08/17] kunit: test: add support for test abort
Quoting Brendan Higgins (2019-02-14 13:37:20)
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.
Can you add some more text here with the motivating reasons for
implementing assertions and bailing out of test cases?
For example, I wonder why unit tests can't just return with a failure
when they need to abort and then the test runner would detect that error
via the return value from the 'run test' function. That would be a more
direct approach, but also more verbose than a single KUNIT_ASSERT()
line. It would be more kernel idiomatic too because the control flow
isn't hidden inside a macro and it isn't intimately connected with
kthreads and completions.
>
> Signed-off-by: Brendan Higgins
[...]
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> new file mode 100644
> index 0..a936c041f1c8f
Could this whole file be another patch? It seems to be a test for the
try catch mechanism.
> diff --git a/kunit/test.c b/kunit/test.c
> index d18c50d5ed671..6e5244642ab07 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[...]
> +
> +static void kunit_generic_throw(struct kunit_try_catch *try_catch)
> +{
> + try_catch->context.try_result = -EFAULT;
> + complete_and_exit(try_catch->context.try_completion, -EFAULT);
> +}
> +
> +static int kunit_generic_run_threadfn_adapter(void *data)
> +{
> + struct kunit_try_catch *try_catch = data;
>
> + try_catch->try(_catch->context);
> +
> + complete_and_exit(try_catch->context.try_completion, 0);
The exit code doesn't matter, right? If so, it might be clearer to just
return 0 from this function because kthreads exit themselves as far as I
recall.
> +}
> +
> +static void kunit_generic_run_try_catch(struct kunit_try_catch *try_catch)
> +{
> + struct task_struct *task_struct;
> + struct kunit *test = try_catch->context.test;
> + int exit_code, wake_result;
> + DECLARE_COMPLETION(test_case_completion);
DECLARE_COMPLETION_ONSTACK()?
> +
> + try_catch->context.try_completion = _case_completion;
> + try_catch->context.try_result = 0;
> + task_struct = kthread_create(kunit_generic_run_threadfn_adapter,
> +try_catch,
> +"kunit_try_catch_thread");
> + if (IS_ERR_OR_NULL(task_struct)) {
It looks like NULL is never returned from kthread_create(), so don't
check for it here.
> + try_catch->catch(_catch->context);
> + return;
> + }
> +
> + wake_result = wake_up_process(task_struct);
> + if (wake_result != 0 && wake_result != 1) {
These are the only two possible return values of wake_up_process(), so
why not just use kthread_run() and check for an error on the process
creation?
> + kunit_err(test, "task was not woken properly: %d",
> wake_result);
> + try_catch->catch(_catch->context);
> + }
> +
> + /*
> +* TODO(brendanhigg...@google.com): We should probably have some type
> of
> +* timeout here. The only question is what that timeout value should
> be.
> +*
> +* The intention has always been, at some point, to be able to label
> +* tests with some type of size bucket (unit/small,
> integration/medium,
> +* large/system/end-to-end, etc), where each size bucket would get a
> +* default timeout value kind of like what Bazel does:
> +*
> https://docs.bazel.build/versions/master/be/common-definitions.html#test.size
> +* There is still some debate to be had on exactly how we do this.
> (For
> +* one, we probably want to have some sort of test runner level
> +* timeout.)
> +*
> +* For more background on this topic, see:
> +* https://mike-bland.com/2011/11/01/small-medium-large.html
> +*/
> + wait_for_completion(_case_completion);
It doesn't seem like a bad idea to make this have some arbitrarily large
timeout value to start with. Just to make sure the whole thing doesn't
get wedged. It's a timeout, so in theory it should never trigger if it's
large enough.
> +
> + exit_code = try_catch->context.try_result;
> + if (exit_code == -EFAULT)
> + try_catch->catch(_catch->context);
> + else if (exit_code == -EINTR)
> + kunit_err(test, "wake_up_process() was never called.");
Does kunit_err() add newlines? It would be good to stick to the rest of
kernel style (printk, tracing, etc.) and rely on the callers to have the
newlines they want. Also, remove the full-stop because it isn't really
necessary to have those in error logs.
> + else if (exit_code)
> + kunit_err(test, "Unknown error: %d", exit_code);
> +}
> +
> +void kunit_generic_try_catch_init(struct kunit_try_catch *try_catch)
> +{
> + try_catch->run = kunit_generic_run_try_catch;
Is the idea that 'run' would be anything besides
[Bug 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #20 from Michael Eagle --- Obviously you're used to nvidia/windows way on doing things. You are on linux now. Opensource is the whole philosophy. So yes, please just use the free/opensource drivers that come bundled with your favorite distro. This is the preferred way to go with AMD hardware. Here's the Radeon 7 with opensource amd drivers: https://www.phoronix.com/scan.php?page=article=radeon-vii-linux=1 Benchmarks between different mesa versions, so using an ubuntu ppa such as oibaf or pandoka does matter to get the newest stack and best performance: https://www.phoronix.com/scan.php?page=article=mesa182-4-july=1 And.. the icing on a cake, the comparison between opensource radeonsi and closed source (amdgpu-pro/radeon software aka the one you've downloaded): https://www.phoronix.com/scan.php?page=article=radeon-software-1820=1 As you can see, apart from the fact that the closed source one is kind of behind in performance, it also has some issues running some of the benchmarks (aka it crashes), hence your experience. So, in conclusion, yes. For polaris, on linux, use opensource drivers. If you've messed up the distro with alot of experiments and closed source driver installations, perhaps it would be better a fresh install and just use mesa/llvm packages from pandoka ppa stable with a recent ubuntu mainline kernel. Goodluck, Cheers! --- Sent from mobile, apologies for typos. -- 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: [Bug 109758] AMD GPU for Ubuntu Linux Broken
Obviously you're used to nvidia/windows way on doing things. You are on linux now. Opensource is the whole philosophy. So yes, please just use the free/opensource drivers that come bundled with your favorite distro. This is the preferred way to go with AMD hardware. Here's the Radeon 7 with opensource amd drivers: https://www.phoronix.com/scan.php?page=article=radeon-vii-linux=1 Benchmarks between different mesa versions, so using an ubuntu ppa such as oibaf or pandoka does matter to get the newest stack and best performance: https://www.phoronix.com/scan.php?page=article=mesa182-4-july=1 And.. the icing on a cake, the comparison between opensource radeonsi and closed source (amdgpu-pro/radeon software aka the one you've downloaded): https://www.phoronix.com/scan.php?page=article=radeon-software-1820=1 As you can see, apart from the fact that the closed source one is kind of behind in performance, it also has some issues running some of the benchmarks (aka it crashes), hence your experience. So, in conclusion, yes. For polaris, on linux, use opensource drivers. If you've messed up the distro with alot of experiments and closed source driver installations, perhaps it would be better a fresh install and just use mesa/llvm packages from pandoka ppa stable with a recent ubuntu mainline kernel. Goodluck, Cheers! --- Sent from mobile, apologies for typos. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote: > On 2/26/19 12:20 AM, John Stultz wrote: > > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote: > >> It all needs a bit more work, and I'm sure I'll find missing parts when > >> I add some more heaps, but hopefully this framework is simple enough that > >> it does not impede the implementation of all functionality once provided > >> by ION (shrinker, delayed free), nor any new functionality needed for > >> future heap exporting devices. > > > > I took your patch here, made some small reworks as I mentioned > > earlier, and tried to add some generic helpers and the system and cma > > heaps integrated. > > > > You can find the changes added on top of your patch here: > > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > > > I propose we should squish down the first three changes down into the > > core patch if you agree. > > > > All looks good to me. One thing I'm still unsure of is moving struct > dma_heap out into the public interface header. That struct contains > framework internal only info (device nodes, stats, etc.) that should not > be exposed to the outside world. I think of them as private members of > our class (too much C++ work lately), if we need to expose any members > of that struct then we can add accessors as needed. Hrm. The trouble is that the heaps need some way to index back to their own per-heap data (similar to how the heaps also need their own per-buffer data) like the cma struct for the specific cma region, for instance. Maybe this doesn't address your concern, but one way I've dealt with "subsystem internal" structures is to have local .h files, so only the heap implementations can see it. I may be missing a different approach that your thinking of, so please let me know. :) > > The helper functions need some work and cleanup, right now I'm only > > exposing the dmabuf ops and realistically folks will probably want to > > fill part of the ops with custom things. > > > > Yes, the current set of helper dma-buf-ops work well for pre-allocated > page-struct-backed memory buffers (basically sg list). For buffers > allocated outside of normal RAM, secure (unmapped) heaps, and attach > time allocated heaps all kinda break down with the current helpers. But > that's the best part of helpers, you don't need to use them if you don't > want :) > > > It boots w/ AOSP, and allocations seem to work, but there's something > > wrong with the dmabuf mmaping which casues the homescreen to crash > > over and over. > > (userland patches updated here: > > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436) > > > > Interesting, I wonder if the caching stuff is not right here, I'll see > if I can get this working on my side (AOSP on Beagle x15). > Let me know if you figure anything out, I'll also be looking at this today. I also realized some of Benajmin's error path improvements are going to be hard to fix w/ my current code, specifically having the allocate op do the allocation of the dma_heap_buffer (since we don't have a free op, if something fails creating the dmabuf fd in the core, we don't have a hook to release the dma_heap_buffer and heap private data). thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
On Tue, Feb 26, 2019 at 12:20 PM Alex Deucher wrote: > > On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen > wrote: > > > > Quoting Alex Deucher (2019-02-25 21:31:43) > > > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > > > wrote: > > > > > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > > > wrote: > > > > > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > > > wrote: > > > > > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > > > introduce the > > > > > > > > concept of different memory regions, and a simple buddy > > > > > > > > allocator to manage > > > > > > > > them. > > > > > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > > > have examples off in tree, but before you do that it would be > > > > > > > good to > > > > > > > have a why we can't use TTM discussion in public. > > > > > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > > > the cover letter. I anticipated the question, but was travelling > > > > > > for a couple of days at the time this was sent. I didn't want > > > > > > to write a hasty explanation and then disappear, leaving others to > > > > > > take the heat. > > > > > > > > > > > > So here goes the less-hasty version: > > > > > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > > > TTM when this was started initially. The conclusion was that we > > > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > > > locking. But it's more a trait of rewriting the memory handling with > > > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > > > > > And further, we've been getting rid of struct_mutex at a steady > > > > > > phase > > > > > > in the past years, so we have a clear path to the fine-grained > > > > > > locking > > > > > > already in the not-so-distant future. With all this we did not see > > > > > > much gained from converting over, as the code sharing is already > > > > > > substantial. > > > > > > > > > > > > We also wanted to have the buddy allocator instead of a for loop > > > > > > making > > > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > > > at bay. The intent is to move the buddy allocator to core DRM, to > > > > > > the > > > > > > benefit of all the drivers, if there is interest from community. It > > > > > > has > > > > > > been written as a strictly separate component with that in mind. > > > > > > > > > > > > And if you take the buddy allocator out of the patch set, the rest > > > > > > is > > > > > > mostly just vfuncing things up to be able to have different backing > > > > > > storages for objects. We took the opportunity to move over to the > > > > > > more > > > > > > valgrind friendly mmap while touching things, but it's something we > > > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > > > It would have just to made things look like TTM, when we already > > > > > > have the important parts of the code shared with TTM drivers > > > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > > > useful in the core DRM get out there and try and see if anyone else > > > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > > > use that yet? :-) > > > > > > > > Well, the buddy allocator should be useful for anybody wishing to have > > > > as continuous physical allocations as possible. I have naively assumed > > > > that would be almost everyone. So it would be only a question if others > > > > see the amount of work required to convert over is justified for them. > > > > > > > > For the common DRM scheduler, I think a solid move from the beginning > > > > would have been to factor out the i915 scheduler as it was most advanced > > > > in features :) Now there is a way more trivial common scheduler core > > > > with > > > > no easy path to transition
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Am 26.02.19 um 18:20 schrieb Alex Deucher: On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen wrote: Quoting Alex Deucher (2019-02-25 21:31:43) On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen wrote: Quoting Dave Airlie (2019-02-25 12:24:48) On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen wrote: + dri-devel mailing list, especially for the buddy allocator part Quoting Dave Airlie (2019-02-15 02:47:07) On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote: In preparation for upcoming devices with device local memory, introduce the concept of different memory regions, and a simple buddy allocator to manage them. This is missing the information on why it's not TTM. Nothing against extending i915 gem off into doing stuff we already have examples off in tree, but before you do that it would be good to have a why we can't use TTM discussion in public. Glad that you asked. It's my fault that it was not included in the cover letter. I anticipated the question, but was travelling for a couple of days at the time this was sent. I didn't want to write a hasty explanation and then disappear, leaving others to take the heat. So here goes the less-hasty version: We did an analysis on the effort needed vs benefit gained of using TTM when this was started initially. The conclusion was that we already share the interesting bits of code through core DRM, really. Re-writing the memory handling to TTM would buy us more fine-grained locking. But it's more a trait of rewriting the memory handling with the information we have learned, than rewriting it to use TTM :) And further, we've been getting rid of struct_mutex at a steady phase in the past years, so we have a clear path to the fine-grained locking already in the not-so-distant future. With all this we did not see much gained from converting over, as the code sharing is already substantial. We also wanted to have the buddy allocator instead of a for loop making drm_mm allocations to make sure we can keep the memory fragmentation at bay. The intent is to move the buddy allocator to core DRM, to the benefit of all the drivers, if there is interest from community. It has been written as a strictly separate component with that in mind. And if you take the buddy allocator out of the patch set, the rest is mostly just vfuncing things up to be able to have different backing storages for objects. We took the opportunity to move over to the more valgrind friendly mmap while touching things, but it's something we have been contemplating anyway. And yeah, loads of selftests. That's really all that needed adding, and most of it is internal to i915 and not to do with uAPI. This means porting over an userspace driver doesn't require a substantial rewrite, but adding new a few new IOCTLs to set the preferred backing storage placements. All the previous GEM abstractions keep applying, so we did not see a justification to rewrite the kernel driver and userspace drivers. It would have just to made things look like TTM, when we already have the important parts of the code shared with TTM drivers behind the GEM interfaces which all our drivers sit on top of. a) you guys should be the community as well, if the buddy allocator is useful in the core DRM get out there and try and see if anyone else has a use case for it, like the GPU scheduler we have now (can i915 use that yet? :-) Well, the buddy allocator should be useful for anybody wishing to have as continuous physical allocations as possible. I have naively assumed that would be almost everyone. So it would be only a question if others see the amount of work required to convert over is justified for them. For the common DRM scheduler, I think a solid move from the beginning would have been to factor out the i915 scheduler as it was most advanced in features :) Now there is a way more trivial common scheduler core with no easy path to transition without a feature regression. Can you elaborate? What features are missing from the drm gpu scheduler? Priority based pre-emption is the big thing coming to mind. But maybe we should not derail the discussion in this thread. The discussion should be in the archives, or we can start a new thread. Probably not worth continuing here, but I think there are probably features that the drm scheduler has that the i915 scheduler does not. For example, engine load balancing. So i wouldn't necessarily say it's more advanced, just different feature sets. We could all be enjoying all of these features if we all worked on the same infrastructure. Actually it is worth continuing. To be honest the DRM scheduler came first and the i915 scheduler should have been pushed back a bit more. Additional to that it does support priority based pre-emption from the very beginning, you guys just didn't cared to take a look :( Regards, Christian. We'd have to rewrite many of the more advanced features for that codebase before we could transition over. It's hard to justify such work, for that
[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #29 from Barret Rhoden (b...@google.com) --- Ah, nice find. That other bug (201339) looks like the root cause of this one. -- 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 v5 14/19] drm: writeback: Add job prepare and cleanup operations
Hi Laurent,
On Thu, Feb 21, 2019 at 12:32:07PM +0200, Laurent Pinchart wrote:
> As writeback jobs contain a framebuffer, drivers may need to prepare and
> cleanup them the same way they can prepare and cleanup framebuffers for
> planes. Add two new optional connector helper operations,
> .prepare_writeback_job() and .cleanup_writeback_job() to support this.
I'm having a bit of a hard time parsing the above paragraph. I think that
what you are saying is that you need to prepare and cleanup the framebuffers
that
writeback jobs have, but it also can be read that you need to prepare/cleanup
the actual jobs. If the latter, then I'm curious to know what is special
about the jobs that you need preparing/cleaning up.
>
> The job prepare operation is called from
> drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper
> that would need to be called by all drivers not using
> drm_atomic_helper_commit(). The job cleanup operation is called from the
> existing drm_writeback_cleanup_job() function, invoked both when
> destroying the job as part of a aborted commit, or when the job
> completes.
>
> The drm_writeback_job structure is extended with a priv field to let
> drivers store per-job data, such as mappings related to the writeback
> framebuffer.
Could the driver store in this priv field a structure that contains the
connector, whereby removing the need for a back-pointer?
>
> For internal plumbing reasons the drm_writeback_job structure needs to
> store a back-pointer to the drm_writeback_connector. To avoid pushing
> too much writeback-specific knowledge to drm_atomic_uapi.c, create a
> drm_writeback_set_fb() function, move the writeback job setup code
> there, and set the connector backpointer. The prepare_signaling()
> function doesn't need to allocate writeback jobs and can ignore
> connectors without a job, as it is called after the writeback jobs are
> allocated to store framebuffers, and a writeback fence with a
> framebuffer is an invalid configuration that gets rejected by the commit
> check.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 11 ++
> drivers/gpu/drm/drm_atomic_uapi.c| 31 +
> drivers/gpu/drm/drm_writeback.c | 43
> include/drm/drm_modeset_helper_vtables.h | 7
> include/drm/drm_writeback.h | 28 ++-
> 5 files changed, 96 insertions(+), 24 deletions(-)
>
> This patch is currently missing documentation for the
> .prepare_writeback_job() and .cleanup_writeback_job() operations. I plan
> to fix this, but first wanted feedback on the direction taken. I'm not
> entirely happy with the priv pointer in the drm_writeback_job structure,
> but adding a full state duplicate/destroy machinery for that structure
> was equally unappealing to me.
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6fe2303fccd9..70a4886c6e65 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2245,10 +2245,21 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
> int drm_atomic_helper_prepare_planes(struct drm_device *dev,
>struct drm_atomic_state *state)
> {
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
> struct drm_plane *plane;
> struct drm_plane_state *new_plane_state;
> int ret, i, j;
>
> + for_each_new_connector_in_state(state, connector, new_conn_state, i) {
> + if (!new_conn_state->writeback_job)
> + continue;
> +
> + ret = drm_writeback_prepare_job(new_conn_state->writeback_job);
> + if (ret < 0)
> + return ret;
> + }
> +
> for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c40889888a16..e802152a01ad 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -647,28 +647,15 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> return 0;
> }
>
> -static struct drm_writeback_job *
> -drm_atomic_get_writeback_job(struct drm_connector_state *conn_state)
> -{
> - WARN_ON(conn_state->connector->connector_type !=
> DRM_MODE_CONNECTOR_WRITEBACK);
> -
> - if (!conn_state->writeback_job)
> - conn_state->writeback_job =
> - kzalloc(sizeof(*conn_state->writeback_job), GFP_KERNEL);
> -
> - return conn_state->writeback_job;
> -}
> -
> static int drm_atomic_set_writeback_fb_for_connector(
> struct drm_connector_state *conn_state,
> struct drm_framebuffer *fb)
> {
> - struct drm_writeback_job *job =
> - drm_atomic_get_writeback_job(conn_state);
> - if (!job)
> -
Re: [PATCH v5 13/19] drm: writeback: Fix leak of writeback job
On Thu, Feb 21, 2019 at 12:32:06PM +0200, Laurent Pinchart wrote:
> Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
> deleted when the jobs complete. This results in both a memory leak of
> the job and a leak of the framebuffer if the atomic commit returns
> before the job is queued for processing, for instance if the atomic
> check fails or if the commit runs in test-only mode.
>
> Fix this by implementing the drm_writeback_cleanup_job() function and
> calling it from __drm_atomic_helper_connector_destroy_state(). As
> writeback jobs are removed from the state when they're queued for
> processing, any job left in the state when the state gets destroyed
> needs to be cleaned up.
>
> The existing declaration of the drm_writeback_cleanup_job() function
> without an implementation hints that this problem was considered, but
> never addressed.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 4
> drivers/gpu/drm/drm_writeback.c | 13 ++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 4985384e51f6..59ffb6b9c745 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -412,6 +413,9 @@ __drm_atomic_helper_connector_destroy_state(struct
> drm_connector_state *state)
>
> if (state->commit)
> drm_crtc_commit_put(state->commit);
> +
> + if (state->writeback_job)
> + drm_writeback_cleanup_job(state->writeback_job);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index 338b993d7c9f..afb1ae6e0ecb 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -273,6 +273,14 @@ void drm_writeback_queue_job(struct
> drm_writeback_connector *wb_connector,
> }
> EXPORT_SYMBOL(drm_writeback_queue_job);
>
> +void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> +{
> + if (job->fb)
> + drm_framebuffer_put(job->fb);
> +
> + kfree(job);
> +}
> +
> /*
> * @cleanup_work: deferred cleanup of a writeback job
> *
> @@ -285,10 +293,9 @@ static void cleanup_work(struct work_struct *work)
> struct drm_writeback_job *job = container_of(work,
>struct drm_writeback_job,
>cleanup_work);
> - drm_framebuffer_put(job->fb);
> - kfree(job);
> -}
>
> + drm_writeback_cleanup_job(job);
> +}
>
> /**
> * drm_writeback_signal_completion - Signal the completion of a writeback job
> --
> Regards,
>
> Laurent Pinchart
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 12/19] drm: writeback: Cleanup job ownership handling when queuing job
On Thu, Feb 21, 2019 at 12:32:05PM +0200, Laurent Pinchart wrote:
> The drm_writeback_queue_job() function takes ownership of the passed job
> and requires the caller to manually set the connector state
> writeback_job pointer to NULL. To simplify drivers and avoid errors
> (such as the missing NULL set in the vc4 driver), pass the connector
> state pointer to the function instead of the job pointer, and set the
> writeback_job pointer to NULL internally.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 3 +--
> drivers/gpu/drm/drm_writeback.c | 15 ++-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> include/drm/drm_writeback.h | 2 +-
> 4 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 041a64dc7167..87627219ce3b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -252,8 +252,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
>_state->addrs[0],
>mw_state->format);
>
> - drm_writeback_queue_job(mw_conn, conn_state->writeback_job);
> - conn_state->writeback_job = NULL;
> + drm_writeback_queue_job(mw_conn, conn_state);
> hwdev->hw->enable_memwrite(hwdev, mw_state->addrs,
> mw_state->pitches,
> mw_state->n_planes,
> fb->width, fb->height,
> mw_state->format,
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index c20e6fe00cb3..338b993d7c9f 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -242,11 +242,12 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
> /**
> * drm_writeback_queue_job - Queue a writeback job for later signalling
> * @wb_connector: The writeback connector to queue a job on
> - * @job: The job to queue
> + * @conn_state: The connector state containing the job to queue
> *
> - * This function adds a job to the job_queue for a writeback connector. It
> - * should be considered to take ownership of the writeback job, and so any
> other
> - * references to the job must be cleared after calling this function.
> + * This function adds the job contained in @conn_state to the job_queue for a
> + * writeback connector. It takes ownership of the writeback job and sets the
> + * @conn_state->writeback_job to NULL, and so no access to the job may be
> + * performed by the caller after this function returns.
> *
> * Drivers must ensure that for a given writeback connector, jobs are queued
> in
> * exactly the same order as they will be completed by the hardware (and
> @@ -258,10 +259,14 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
> * See also: drm_writeback_signal_completion()
> */
> void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> - struct drm_writeback_job *job)
> + struct drm_connector_state *conn_state)
> {
> + struct drm_writeback_job *job;
> unsigned long flags;
>
> + job = conn_state->writeback_job;
> + conn_state->writeback_job = NULL;
> +
> spin_lock_irqsave(_connector->job_lock, flags);
> list_add_tail(>list_entry, _connector->job_queue);
> spin_unlock_irqrestore(_connector->job_lock, flags);
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index aa279b5b0de7..5dabd91f2d7e 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -327,7 +327,7 @@ static void vc4_txp_connector_atomic_commit(struct
> drm_connector *conn,
>
> TXP_WRITE(TXP_DST_CTRL, ctrl);
>
> - drm_writeback_queue_job(>connector, conn_state->writeback_job);
> + drm_writeback_queue_job(>connector, conn_state);
> }
>
> static const struct drm_connector_helper_funcs
> vc4_txp_connector_helper_funcs = {
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 23df9d463003..47662c362743 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -123,7 +123,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>const u32 *formats, int n_formats);
>
> void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
> - struct drm_writeback_job *job);
> + struct drm_connector_state *conn_state);
>
> void drm_writeback_cleanup_job(struct drm_writeback_job *job);
>
> --
> Regards,
>
> Laurent Pinchart
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[Bug 109329] Luxmark freezes the system
https://bugs.freedesktop.org/show_bug.cgi?id=109329 --- Comment #1 from Jan Vesely --- (In reply to Fabian Maurer from comment #0) > Created attachment 143077 [details] > journalctl log > > Running luxmark (OpenCL) freezes the system. > Only help is to reboot with REISUB command. > > dmesg log (from journalctl) attached. > > System: > -Arch Linux > -AMD Radeon 285 > -AMD Radeon R9 200 Series (TONGA, DRM 3.27.0, 4.20.1-arch1-1-ARCH, LLVM > 7.0.0) > -Mesa 18.3.1 which scene are you trying to run? -- 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 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 vladimir gerasimov (v...@ggpi.org) changed: What|Removed |Added CC||v...@ggpi.org --- Comment #28 from vladimir gerasimov (v...@ggpi.org) --- Comment on attachment 281269 --> https://bugzilla.kernel.org/attachment.cgi?id=281269 Acutal 4.17.19 config There is a workaround, resolving this bug (for me at least) - disabling CONFIG_X86_VSMP parameter. Hint to this solution was here: https://bugzilla.kernel.org/show_bug.cgi?id=201339 -- 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: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
On Tue, Feb 26, 2019 at 7:17 AM Joonas Lahtinen wrote: > > Quoting Alex Deucher (2019-02-25 21:31:43) > > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > > wrote: > > > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > > wrote: > > > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > > wrote: > > > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > > introduce the > > > > > > > concept of different memory regions, and a simple buddy allocator > > > > > > > to manage > > > > > > > them. > > > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > > have examples off in tree, but before you do that it would be good > > > > > > to > > > > > > have a why we can't use TTM discussion in public. > > > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > > the cover letter. I anticipated the question, but was travelling > > > > > for a couple of days at the time this was sent. I didn't want > > > > > to write a hasty explanation and then disappear, leaving others to > > > > > take the heat. > > > > > > > > > > So here goes the less-hasty version: > > > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > > TTM when this was started initially. The conclusion was that we > > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > > locking. But it's more a trait of rewriting the memory handling with > > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > > > And further, we've been getting rid of struct_mutex at a steady phase > > > > > in the past years, so we have a clear path to the fine-grained locking > > > > > already in the not-so-distant future. With all this we did not see > > > > > much gained from converting over, as the code sharing is already > > > > > substantial. > > > > > > > > > > We also wanted to have the buddy allocator instead of a for loop > > > > > making > > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > > at bay. The intent is to move the buddy allocator to core DRM, to the > > > > > benefit of all the drivers, if there is interest from community. It > > > > > has > > > > > been written as a strictly separate component with that in mind. > > > > > > > > > > And if you take the buddy allocator out of the patch set, the rest is > > > > > mostly just vfuncing things up to be able to have different backing > > > > > storages for objects. We took the opportunity to move over to the more > > > > > valgrind friendly mmap while touching things, but it's something we > > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > > It would have just to made things look like TTM, when we already > > > > > have the important parts of the code shared with TTM drivers > > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > > useful in the core DRM get out there and try and see if anyone else > > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > > use that yet? :-) > > > > > > Well, the buddy allocator should be useful for anybody wishing to have > > > as continuous physical allocations as possible. I have naively assumed > > > that would be almost everyone. So it would be only a question if others > > > see the amount of work required to convert over is justified for them. > > > > > > For the common DRM scheduler, I think a solid move from the beginning > > > would have been to factor out the i915 scheduler as it was most advanced > > > in features :) Now there is a way more trivial common scheduler core with > > > no easy path to transition without a feature regression. > > > > Can you elaborate? What features are missing from the drm gpu scheduler? > > Priority based pre-emption is the big thing coming to mind. But maybe we > should not derail the discussion in this thread. The discussion should > be in the archives, or we can start a new thread.
Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 26, 2019 at 10:45 AM Russell King - ARM Linux admin
> wrote:
> >
> >
> > I can't see how you'd extend a single I2S setup to support multi-
> > channel audio without either adding more I2S data lines or adding
> > additional WS signals (so making it e.g., a binary number).
> >
>
> That's a very good point too. In light of this, I struggle to understand how
> the ssl_ssi can specify this:
>
> static struct snd_soc_dai_driver fsl_ssi_dai_template = {
> .playback = {
> .stream_name = "CPU-Playback",
> .channels_min = 1,
> .channels_max = 32,
> },
>
> There is talk in the manual about "network mode", which could work by changing
> the LRCLK only at the first slot - thereby allowing clients to receive all
> slots just by counting, as long as they know the slot size?
>
> LRCLK _/-\_/-
> DATASLOT1|SLOT2|SLOT3|SLOT4|SLOT1
From what I gather, these are described using SND_SOC_DAIFMT_DSP_A
and SND_SOC_DAIFMT_DSP_B dai formats, and the parameters are
controlled not through snd_soc_dai_set_bclk_ratio() but via
snd_soc_dai_set_tdm_slot().
So, IMHO, the TDM formats should be disregarded from consideration
here. Mark, ack?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: ti-sn65dsi86: make const array static
From: Colin Ian King
Don't populate the const array ti_sn_bridge_supply_names on the
stack but instead make it static.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f72ee137e5f1..4c2ca4e39be5 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -211,7 +211,7 @@ static struct ti_sn_bridge *bridge_to_ti_sn_bridge(struct
drm_bridge *bridge)
static int ti_sn_bridge_parse_regulators(struct ti_sn_bridge *pdata)
{
unsigned int i;
- const char * const ti_sn_bridge_supply_names[] = {
+ static const char * const ti_sn_bridge_supply_names[] = {
"vcca", "vcc", "vccio", "vpll",
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #27 from Michael A. Leonetti (mikealeone...@gmail.com) --- (In reply to Michel Dänzer from comment #26) > When the amdgpu driver is built into the kernel, so must be all the > microcode files under /lib/firmware/amdgpu/ that it needs with your GPU. Thanks for that! I had to include the raven* firmware files. I had only included the vega* firmware files. -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #26 from Alex van Kaam (alexvk...@gmail.com) --- hi on request of the people over at SUSE I tested my Tumbleweed install with the Kernel of the Day. first did: BOOT_IMAGE=/boot/vmlinuz-5.0.0-rc8-1.g4ddf057-default root=UUID=fce8b6dd-98d6-4b86-a5d9-2812f3c1e242 splash=silent resume=/dev/disk/by-uuid/c9f35ed5-bdbe-413a-801b-7df1c8a64145 quiet and it booted with a screen then did: BOOT_IMAGE=/boot/vmlinuz-5.0.0-rc8-1.g4ddf057-default root=UUID=fce8b6dd-98d6-4b86-a5d9-2812f3c1e242 splash=silent resume=/dev/disk/by-uuid/c9f35ed5-bdbe-413a-801b-7df1c8a64145 quiet amdgpu.dc=1 and it also booted with a screen so on this specifik hardware HP Notebook - 17-ca0710nd, Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] it seems to be fixed -- 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: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> That's a very good point too. In light of this, I struggle to understand how
> the ssl_ssi can specify this:
> static struct snd_soc_dai_driver fsl_ssi_dai_template = {
> .playback = {
> .stream_name = "CPU-Playback",
> .channels_min = 1,
> .channels_max = 32,
> },
> There is talk in the manual about "network mode", which could work by changing
> the LRCLK only at the first slot - thereby allowing clients to receive all
> slots just by counting, as long as they know the slot size?
That's basically what the FSL controllers want to support - they're
generic programmable serial ports, their most native formats are the DSP
modes which only pay attention to one edge of LRCLK and then just have
however many samples one after another. Several other devices like the
PXA SSP ports are similar. They can generate I2S style LRCLKs but many
implementations struggle to interpret incoming I2S properly, they often
have issues with triggering on both rising and falling edges so get
confused if there's any unused clock cycles.
For a DSP mode it's more:
LRCLK /\__/\
DATA|SLOT1|SLOT2|SLOT3|SLOT4|SLOT1
I2S style it'd end up as more like:
LRCLK /-\_/--
DATA|SLOTL1|SLOTL2|SLOTR1|SLOTR2|SLOTL1
This sort of stuff is why ASoC has a preference for exact clocking - it
improves interoperability with hardware that's generic serial ports as
it means that you only need to pay attention to one edge of the LRCLK
even if it's doing something more than just a simple pulse.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #26 from Michel Dänzer (mic...@daenzer.net) --- When the amdgpu driver is built into the kernel, so must be all the microcode files under /lib/firmware/amdgpu/ that it needs with your GPU. -- 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 0/2] Lima DRM driver
Am 26.02.19 um 16:58 schrieb Daniel Vetter: On Wed, Feb 13, 2019 at 9:35 AM Christian König wrote: Am 13.02.19 um 08:59 schrieb Daniel Vetter: On Wed, Feb 13, 2019 at 2:44 AM Rob Herring wrote: On Tue, Feb 12, 2019 at 7:00 PM Eric Anholt wrote: Rob Herring writes: On Thu, Feb 7, 2019 at 9:51 AM Daniel Vetter wrote: On Thu, Feb 07, 2019 at 11:21:52PM +0800, Qiang Yu wrote: On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote: On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote: Kernel DRM driver for ARM Mali 400/450 GPUs. Since last RFC, all feedback has been addressed. Most Mali DTS changes are already upstreamed by SoC maintainers. The kernel driver and user-kernel interface are quite stable for several months, so I think it's ready to be upstreamed. This implementation mainly take amdgpu DRM driver as reference. - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for OpenGL vertex shader processing and PP is for fragment shader processing. Each processor has its own MMU so prcessors work in virtual address space. - There's only one GP but multiple PP (max 4 for mali 400 and 8 for mali 450) in the same mali 4xx GPU. All PPs are grouped togather to handle a single fragment shader task divided by FB output tiled pixels. Mali 400 user space driver is responsible for assign target tiled pixels to each PP, but mali 450 has a HW module called DLBU to dynamically balance each PP's load. - User space driver allocate buffer object and map into GPU virtual address space, upload command stream and draw data with CPU mmap of the buffer object, then submit task to GP/PP with a register frame indicating where is the command stream and misc settings. - There's no command stream validation/relocation due to each user process has its own GPU virtual address space. GP/PP's MMU switch virtual address space before running two tasks from different user process. Error or evil user space code just get MMU fault or GP/PP error IRQ, then the HW/SW will be recovered. - Use TTM as MM. TTM_PL_TT type memory is used as the content of lima buffer object which is allocated from TTM page pool. all lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when allocation, so there's no buffer eviction and swap for now. All other render gpu drivers that have unified memory (aka is on the SoC) use GEM directly, with some of the helpers we have. So msm, etnaviv, vc4 (and i915 is kinda the same too really). TTM makes sense if you have some discrete memory to manage, but imo not in any other place really. What's the design choice behind this? To be honest, it's just because TTM offers more helpers. I did implement a GEM way with cma alloc at the beginning. But when implement paged mem, I found TTM has mem pool alloc, sync and mmap related helpers which covers much of my existing code. It's totally possible with GEM, but not as easy as TTM to me. And virtio-gpu seems an example to use TTM without discrete mem. Shouldn't TTM a super set of both unified mem and discrete mem? virtio does have fake vram and migration afaiui. And sure, you can use TTM without the vram migration, it's just that most of the complexity of TTM is due to buffer placement and migration and all that stuff. If you never need to move buffers, then you don't need that ever. Wrt lack of helpers, what exactly are you looking for? A big part of these for TTM is that TTM is a bid a midlayer, so reinvents a bunch of things provided by e.g. dma-api. It's cleaner to use the dma-api directly. Basing the lima kernel driver on vc4, freedreno or etnaviv (last one is probably closest, since it doesn't have a display block either) would be better I think. FWIW, I'm working on the panfrost driver and am using the shmem helpers from Noralf. It's the early stages though. I started a patch for etnaviv to use it too, but found I need to rework it to sub-class the shmem GEM object. Did you just convert the shmem helpers over to doing alloc_coherent? If so, I'd be interested in picking them up for v3d, and that might help get another patch out of your stack. I haven't really fully addressed that yet, but yeah, my plan is just to switch to WC alloc and mappings. I was going to try to make it configurable, but there is a comment in the ARM dma mapping code which makes me wonder if tinydrm using streaming DMA for SPI is fundamentally broken (and maybe CMA is less broken?). If not broken, not guaranteed to work. /* * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems * that the intention is to allow exporting memory allocated via the * coherent DMA APIs through the dma_buf API, which only accepts a * scattertable. This presents a couple of problems: * 1. Not all memory allocated via the coherent DMA APIs is backed by *a struct page * 2. Passing coherent DMA memory into the streaming APIs is not allowed *as we will try to flush
Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
On Tue, Feb 26, 2019 at 03:45:19PM +, Russell King - ARM Linux admin wrote: > Adding more WS signals makes the bus deviate from the I2S standard, > thereby making it impossible to connect a set of standard DACs to > such a source, whereas adding more I2S data lines, you just connect > each DAC to each I2S data line and common up the bit clock and WS > signals across all. > In other words, the TDA998x approach is really the only sane way > forward. Right. You do also see some things doing this by stuffing all the left samples together in the left clock cycle and all the right samples together in the right clock cycle but that's usually more programmable hardware that also supports DSP modes and it's just falling out of the implementation with little effort rather than someone sitting down and thinking this is a good idea AFAICT. > Now, as far as transmitter support, I believe TI Davinci SoCs use > this - my Onkyo TX-NR609 AV receiver uses a DA830 SoC as a DSP to > do the surround decode, which feeds multi-channel audio out to a > set of DACs over a parallel I2S bus. The "mcasp" audio driver > has multiple serialisers to cope with this - see > Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt. Samsung LSI have multi-channel I2S with multiple data lines in their v5 and later controllers as well. I can't think of any other examples upstream off the top of my head. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
From: Ayan Kumar Halder
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 3dc8a6f..044bf7f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -531,8 +531,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
From: Ayan Kumar Halder
We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.
Also we have added support for XYUV 444 8 and 10 bit formats
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 64c2ca3..b4a0e11 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
From: Ayan Kumar Halder
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 31 ---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4106f5d..21725c9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -391,6 +391,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = _mode_config_funcs;
drm->mode_config.helper_private = _mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 044bf7f..d42e0ea 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -939,7 +939,26 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
- int ret, i, j, n;
+ int ret, i = 0, j = 0, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
+* of supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -964,9 +983,15 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ _de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers, plane_type,
+ NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
From: Ayan Kumar Halder
We need to define a common list of format modifiers supported by each of
the Mali display processors.
The following are the constraints with AFBC:-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.
10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.
11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.
Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 32 ++---
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 96 +--
drivers/gpu/drm/arm/malidp_hw.h | 24 +--
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 126 +++-
6 files changed, 246 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad0..c697664 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,37 +264,17 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +299,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
+bool malidp_hw_format_is_linear_only(u32 format);
+bool malidp_hw_format_is_afbc_only(u32 format);
+
+bool
[PATCH 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
From: Ayan Kumar Halder
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0ac2762..8df12e9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -380,14 +380,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -665,9 +690,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -693,19 +718,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+ bytes_per_column = 8;
+ else
+ return -EINVAL;
+ break;
+
[PATCH 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
From: Ayan Kumar Halder
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c697664..4106f5d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -298,6 +298,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -314,15 +315,19 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
+ / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
+ mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #25 from Michael A. Leonetti (mikealeone...@gmail.com) --- Created attachment 281359 --> https://bugzilla.kernel.org/attachment.cgi?id=281359=edit fb: switching to amdgpudrmfb from EFI VGA freeze 4.19.23 Barret, I will apply the patch and post the output for the commits as you asked. I have tried a couple of times to compile AMDGPU and DRM into the kernel and it freezes after "fb: switching to amdgpudrmfb from EFI VGA" and doesn't give any errors for me to see. I've also attached the output from kernel 4.19.23. -- 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 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
From: Ayan Kumar Halder
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 28cd351..2865f7a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
From: Ayan Kumar Halder
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.
Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/arm/malidp_hw.c | 30 ++
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 107
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 136 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..64c2ca3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,14 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG1_AD_CTRL },
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG2_AD_CTRL },
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +109,16 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +128,18 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
MALIDP550_DE_LS_R1_STRIDE, 0, MALIDP650_DE_LS_MMU_CTRL,
[PATCH 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010
From: Ayan Kumar Halder
This new format is supported by DP550 and DP650
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0a3efa5..8681f01 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b4fb674..5fed518 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/10] Add support for Arm Framebuffer Compression(AFBC) in mali display driver
This patchset aims to add support for AFBC in mali display driver with the help of format modifiers. AFBC modifiers add some constraints to framebuffer size, alignment, pitch, formats, etc In the initial patchset ie https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html I had illustrated how to add support for one format (ie BGR888) with one valid combination of AFBC modifiers ie AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE Changes from v1:- Enabled the support for all AFBC modifiers (which are supported on DP500, DP550 and DP650) with all the pixel formats. Also, we have introduced some new pixel formats which are supported with AFBC modifiers only as well some other pixel formats which are supported with LINEAR only. Changes from v2 (ie https://patchwork.freedesktop.org/patch/265212/):- - Addressed the review comments on the previous patchset. - Rebased on top of the drm-misc-next Ayan Kumar Halder (9): drm: Added a new format DRM_FORMAT_XVYU2101010 drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650 drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats drm/arm/malidp:- Writeback framebuffer does not support any modifiers drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer. drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART Brian Starkey (1): drm/fourcc: Add AFBC yuv fourccs for Mali drivers/gpu/drm/arm/malidp_drv.c| 48 +++ drivers/gpu/drm/arm/malidp_drv.h| 6 + drivers/gpu/drm/arm/malidp_hw.c | 249 + drivers/gpu/drm/arm/malidp_hw.h | 31 - drivers/gpu/drm/arm/malidp_mw.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 271 +--- drivers/gpu/drm/arm/malidp_regs.h | 20 +++ drivers/gpu/drm/drm_fourcc.c| 17 +++ include/uapi/drm/drm_fourcc.h | 23 ++- 9 files changed, 586 insertions(+), 86 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] drm: Add CRTC background color property (v5)
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote: > Hey, > > Op 21-02-2019 om 01:28 schreef Matt Roper: > > Some display controllers can be programmed to present non-black colors > > for pixels not covered by any plane (or pixels covered by the > > transparent regions of higher planes). Compositors that want a UI with > > a solid color background can potentially save memory bandwidth by > > setting the CRTC background property and using smaller planes to display > > the rest of the content. > > > > To avoid confusion between different ways of encoding RGB data, we > > define a standard 64-bit format that should be used for this property's > > value. Helper functions and macros are provided to generate and dissect > > values in this standard format with varying component precision values. > > > > v2: > > - Swap internal representation's blue and red bits to make it easier > >to read if printed out. (Ville) > > - Document bgcolor property in drm_blend.c. (Sean Paul) > > - s/background_color/bgcolor/ for consistency between property name and > >value storage field. (Sean Paul) > > - Add a convenience function to attach property to a given crtc. > > > > v3: > > - Restructure ARGB component extraction macros to be easier to > >understand and enclose the parameters in () to avoid calculations > >if expressions are passed. (Sean Paul) > > - s/rgba/argb/ in helper function/macro names. Even though the idea is > >to not worry about the internal representation of the u64, it can > >still be confusing to look at code that uses 'rgba' terminology, but > >stores values with argb ordering. (Ville) > > > > v4: > > - Drop the bgcolor_changed flag. (Ville, Brian Starkey) > > - Clarify in kerneldoc that background color is expected to undergo the > >same pipe-level degamma/csc/gamma transformations that planes do. > >(Brian Starkey) > > - Update kerneldoc to indicate non-opaque colors are allowed, but are > >generally only useful in special cases such as when writeback > >connectors are used (Brian Starkey / Eric Anholt) > > > > v5: > > - Set crtc->state->bgcolor to solid black inside > >drm_crtc_add_bgcolor_property() in case drivers don't do this > >themselves. (Ville) > > - Add kerneldoc to drm_crtc_add_bgcolor_property() function. > > > > Cc: dri-devel@lists.freedesktop.org > > Cc: wei.c...@intel.com > > Cc: harish.krupo@intel.com > > Cc: Ville Syrjälä > > Cc: Sean Paul > > Cc: Brian Starkey > > Cc: Eric Anholt > > Cc: Stéphane Marchesin > > Cc: Daniel Vetter > > Signed-off-by: Matt Roper > > Reviewed-by(v2): Sean Paul > > Reviewed-by: Brian Starkey > > I like how bgcolor is a u64 now, but there is an issue with setting > crtc->state->bgcolor in attaching the property. > > We should do it in atomic core init instead, like we already do for > connector/plane properties.. > > See for example https://patchwork.freedesktop.org/series/52363/ > > This was specificallly for the background color proposal, but we > probalby have to split out the non-trivial conversions of > __drm_atomic_helper_crtc_reset. Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190226]
[cannot apply to v5.0-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/Propagate-DP-over-Type-C-hotplug-events-from-Type-C-subsys-to-drm-drivers/20190226-005334
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s1-02261802 (attached as .config)
compiler: gcc-6 (Debian 6.5.0-2) 6.5.0 20181026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
ld: drivers/usb/typec/altmodes/displayport.o: in function
`dp_altmode_remove':
>> drivers/usb/typec/altmodes/displayport.c:570: undefined reference to
>> `drm_kms_call_oob_hotplug_notifier_chain'
ld: drivers/usb/typec/altmodes/displayport.o: in function
`dp_altmode_notify':
drivers/usb/typec/altmodes/displayport.c:79: undefined reference to
`drm_kms_call_oob_hotplug_notifier_chain'
vim +570 drivers/usb/typec/altmodes/displayport.c
562
563 static void dp_altmode_remove(struct typec_altmode *alt)
564 {
565 struct dp_altmode *dp = typec_altmode_get_drvdata(alt);
566
567 sysfs_remove_group(>dev.kobj, _altmode_group);
568 cancel_work_sync(>work);
569
> 570
> drm_kms_call_oob_hotplug_notifier_chain(DRM_OOB_HOTPLUG_TYPE_C_DP);
571 }
572
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Lima DRM driver
On Wed, Feb 13, 2019 at 9:35 AM Christian König wrote: > > Am 13.02.19 um 08:59 schrieb Daniel Vetter: > > On Wed, Feb 13, 2019 at 2:44 AM Rob Herring wrote: > >> On Tue, Feb 12, 2019 at 7:00 PM Eric Anholt wrote: > >>> Rob Herring writes: > >>> > On Thu, Feb 7, 2019 at 9:51 AM Daniel Vetter wrote: > > On Thu, Feb 07, 2019 at 11:21:52PM +0800, Qiang Yu wrote: > >> On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote: > >>> On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote: > Kernel DRM driver for ARM Mali 400/450 GPUs. > > Since last RFC, all feedback has been addressed. Most Mali DTS > changes are already upstreamed by SoC maintainers. The kernel > driver and user-kernel interface are quite stable for several > months, so I think it's ready to be upstreamed. > > This implementation mainly take amdgpu DRM driver as reference. > > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for > OpenGL vertex shader processing and PP is for fragment shader > processing. Each processor has its own MMU so prcessors work in > virtual address space. > - There's only one GP but multiple PP (max 4 for mali 400 and 8 > for mali 450) in the same mali 4xx GPU. All PPs are grouped > togather to handle a single fragment shader task divided by > FB output tiled pixels. Mali 400 user space driver is > responsible for assign target tiled pixels to each PP, but mali > 450 has a HW module called DLBU to dynamically balance each > PP's load. > - User space driver allocate buffer object and map into GPU > virtual address space, upload command stream and draw data with > CPU mmap of the buffer object, then submit task to GP/PP with > a register frame indicating where is the command stream and misc > settings. > - There's no command stream validation/relocation due to each user > process has its own GPU virtual address space. GP/PP's MMU switch > virtual address space before running two tasks from different > user process. Error or evil user space code just get MMU fault > or GP/PP error IRQ, then the HW/SW will be recovered. > - Use TTM as MM. TTM_PL_TT type memory is used as the content of > lima buffer object which is allocated from TTM page pool. all > lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when > allocation, so there's no buffer eviction and swap for now. > >>> All other render gpu drivers that have unified memory (aka is on the > >>> SoC) > >>> use GEM directly, with some of the helpers we have. So msm, etnaviv, > >>> vc4 > >>> (and i915 is kinda the same too really). TTM makes sense if you have > >>> some > >>> discrete memory to manage, but imo not in any other place really. > >>> > >>> What's the design choice behind this? > >> To be honest, it's just because TTM offers more helpers. I did > >> implement > >> a GEM way with cma alloc at the beginning. But when implement paged > >> mem, > >> I found TTM has mem pool alloc, sync and mmap related helpers which > >> covers > >> much of my existing code. It's totally possible with GEM, but not as > >> easy as > >> TTM to me. And virtio-gpu seems an example to use TTM without discrete > >> mem. Shouldn't TTM a super set of both unified mem and discrete mem? > > virtio does have fake vram and migration afaiui. And sure, you can use > > TTM > > without the vram migration, it's just that most of the complexity of TTM > > is due to buffer placement and migration and all that stuff. If you > > never > > need to move buffers, then you don't need that ever. > > > > Wrt lack of helpers, what exactly are you looking for? A big part of > > these > > for TTM is that TTM is a bid a midlayer, so reinvents a bunch of things > > provided by e.g. dma-api. It's cleaner to use the dma-api directly. > > Basing > > the lima kernel driver on vc4, freedreno or etnaviv (last one is > > probably > > closest, since it doesn't have a display block either) would be better I > > think. > FWIW, I'm working on the panfrost driver and am using the shmem > helpers from Noralf. It's the early stages though. I started a patch > for etnaviv to use it too, but found I need to rework it to sub-class > the shmem GEM object. > >>> Did you just convert the shmem helpers over to doing alloc_coherent? If > >>> so, I'd be interested in picking them up for v3d, and that might help > >>> get another patch out of your stack. > >> I haven't really fully addressed that yet, but yeah, my plan is just > >> to switch to WC alloc and mappings. I
Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote: > On Tue, Feb 26, 2019 at 4:11 AM Russell King - ARM Linux admin > > If the signal continues toggling, what does it do for the inactive > > channel - is that just one BCLK period long or does it assume there > > is still the second channel? If the former, it means we could end > > up with bclk_ratios of 17, 25, 33 which imho is unlikely, and > > would mess up TDA998x's CTS measurement. > Good point. i2s with a single channel makes no sense. As with every bad idea you can think of that never stopped anyone making such hardware. Mono is usually implemented by either leaving the right channel idle or playing the same signal on both channels. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] drm/panel: Add Ronbo RB070D30
On Wed, Feb 20, 2019 at 09:21:53AM +0100, Maxime Ripard wrote: > Hi, > > Here is a series adding a driver for the Ronbo RB070D30 panel. This was > previously integrated in the DSI burst series, but those parts have been > merged since. > > It's been tested on an Allwinner A33 board. > > Let me know what you think, > Maxime Applied with the order fixup suggested by Paul on patch 1. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio
On Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote: > I notice that hdmi-codec.c supports up to 8 channels in hdmi multi-channel > playback mode. If we had a _theoretical_ hdmi xmitter with 8chan support, > would the bclk_ratio not be 8 x slot_size - or 8 x 32 if using an fsl_ssi > in master mode? > > This will of course never happen with the tda998x, because > .max_i2s_channels = 2, > but we are thinking about a generic solution here. The way TDA998x supports multichannel audio with I2S is as follows: "The TDA9983B supports the NXP I2S-bus format. There are four I2S-bus stereo input channels (AP1 to AP4), which enable 8 uncompressed audio channels to be carried." There is only one WS input and one SCK (bclk) input, which are common to each of the I2S buses. The TDA19988 reduces this down to two I2S buses, which means it supports only up to 4 uncompressed channels. hdmi-codec doesn't take account of these restrictions, and just assumes the maximal number of channels are always available. So, given this parallel bus architecture, it means that whether we have 2, 4, 6, or 8 channels is irrelevant to the number of bitclocks per sample - the number of bitclocks would be the same. I can't see how you'd extend a single I2S setup to support multi- channel audio without either adding more I2S data lines or adding additional WS signals (so making it e.g., a binary number). Adding more WS signals makes the bus deviate from the I2S standard, thereby making it impossible to connect a set of standard DACs to such a source, whereas adding more I2S data lines, you just connect each DAC to each I2S data line and common up the bit clock and WS signals across all. In other words, the TDA998x approach is really the only sane way forward. Now, as far as transmitter support, I believe TI Davinci SoCs use this - my Onkyo TX-NR609 AV receiver uses a DA830 SoC as a DSP to do the surround decode, which feeds multi-channel audio out to a set of DACs over a parallel I2S bus. The "mcasp" audio driver has multiple serialisers to cope with this - see Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On Tue, Feb 26, 2019 at 3:12 PM Benjamin Gaignard wrote: > Overall I like the idea but I think "dma_heap" will be confusing like > dma_buf is because it isn't > related to DMA engine. It wouldn't be the only place, in Device Tree we use "dma-ranges" in the PCI bus host bindings to define how the PCI devices see the memory on the host system, and it is called like that since the PCI devices indeed perform direct memory access. And this is even system agnostic and cannot be changed. In the kernel we use dma_alloc_coherent() for allocating framebuffers though what we want is physically contiguous. I think it's a lost cause, we just have to remind everyone once a week that DMA means "some device or component accessing the memory directly without involvement of the CPU. Such as a display scan-out, not to be confused with DMA engines". FWIW it might be easier to rename DMA engines to "memmove and stream" or "blitters". :/ Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #13 from Andrey Grodzovsky --- Also, in the meanwhile try reverting this 2 patches and see if it helps - 3741540 Andrey Grodzovsky 5 weeks agodrm/sched: Rework HW fence processing. 222b5f0 Andrey Grodzovsky 5 weeks agodrm/sched: Refactor ring mirror list handling. They are causing this deadlock. -- 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 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #12 from Andrey Grodzovsky --- Thanks for more info. Please be patient on this deadlock bug since the fix is not trivial and also I am currently working on other pressing issues - so this might take a bit. -- 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: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/26/19 8:12 AM, Benjamin Gaignard wrote: > Le lun. 25 févr. 2019 à 15:36, Andrew F. Davis a écrit : >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> >> Thanks, >> Andrew > > Overall I like the idea but I think "dma_heap" will be confusing like > dma_buf is because it isn't > related to DMA engine. The intention was to keep things consistent within dma_buf and dma_fence names, originally this was dmabuf_heap, right before I posted I did a mass rename, so if there is push back here then it can always be mass renamed again. > I would like to see how this could be used with exiting allocator like > CMA or genalloc. > > Benjamin > >> >> drivers/dma-buf/Kconfig | 12 ++ >> drivers/dma-buf/Makefile | 1 + >> drivers/dma-buf/dma-heap.c| 268 ++ >> include/linux/dma-heap.h | 57 >> include/uapi/linux/dma-heap.h | 54 +++ >> 5 files changed, 392 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> >> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig >> index 2e5a0faa2cb1..30b0d7c83945 100644 >> --- a/drivers/dma-buf/Kconfig >> +++ b/drivers/dma-buf/Kconfig >> @@ -39,4 +39,16 @@ config UDMABUF >> A driver to let userspace turn memfd regions into dma-bufs. >> Qemu can use this to create host dmabufs for guest framebuffers. >> >> +menuconfig DMABUF_HEAPS >> + bool "DMA-BUF Userland Memory Heaps" >> + depends on HAS_DMA && MMU > > Why do you put MMU dependency ? > >> + select GENERIC_ALLOCATOR > > Maybe I have miss it but I don't see the need to select GENERIC_ALLOCATOR > For the two above they are leftover from ION when the heaps where more tightly coupled with the core, these can now be moved out to the individual heaps that use them. >> + select DMA_SHARED_BUFFER >> + help >> + Choose this option to enable the DMA-BUF userland memory heaps, >> + this allows userspace to allocate dma-bufs that can be shared >> between >> + drivers. >> + >> +source "drivers/dma-buf/heaps/Kconfig" >> + >> endmenu >> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile >> index 0913a6ccab5a..b0332f143413 100644 >> --- a/drivers/dma-buf/Makefile >> +++ b/drivers/dma-buf/Makefile >> @@ -1,4 +1,5 @@ >> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o >> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o >> obj-$(CONFIG_SYNC_FILE)+= sync_file.o >> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o >> obj-$(CONFIG_UDMABUF) += udmabuf.o >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >> new file mode
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/26/19 12:20 AM, John Stultz wrote: > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. > > I took your patch here, made some small reworks as I mentioned > earlier, and tried to add some generic helpers and the system and cma > heaps integrated. > > You can find the changes added on top of your patch here: > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > I propose we should squish down the first three changes down into the > core patch if you agree. > All looks good to me. One thing I'm still unsure of is moving struct dma_heap out into the public interface header. That struct contains framework internal only info (device nodes, stats, etc.) that should not be exposed to the outside world. I think of them as private members of our class (too much C++ work lately), if we need to expose any members of that struct then we can add accessors as needed. > The helper functions need some work and cleanup, right now I'm only > exposing the dmabuf ops and realistically folks will probably want to > fill part of the ops with custom things. > Yes, the current set of helper dma-buf-ops work well for pre-allocated page-struct-backed memory buffers (basically sg list). For buffers allocated outside of normal RAM, secure (unmapped) heaps, and attach time allocated heaps all kinda break down with the current helpers. But that's the best part of helpers, you don't need to use them if you don't want :) > It boots w/ AOSP, and allocations seem to work, but there's something > wrong with the dmabuf mmaping which casues the homescreen to crash > over and over. > (userland patches updated here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436) > Interesting, I wonder if the caching stuff is not right here, I'll see if I can get this working on my side (AOSP on Beagle x15). Thanks, Andrew > But that's about as far as I can do tonight, so I'm crashing and will > see what you think tomorrow. :) > > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] dt-bindings: panel: Add YAML schemas for the Ronbo RB070D30 panel
Hi, On Wed, 2019-02-20 at 09:21 +0100, Maxime Ripard wrote: > The Ronbo RB070D30 panel is a 1024x600 MIPI-DSI panel. > > Signed-off-by: Maxime Ripard Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 52 > > 1 file changed, 52 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml > > diff --git > a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml > b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml > new file mode 100644 > index ..a0e6fa1559cf > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml > @@ -0,0 +1,52 @@ > +# SPDX-License-Identifier: (GPL-2.0+ OR X11) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/ronbo,rb070d30.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Ronbo RB070D30 DSI Display Panel > + > +maintainers: > + - Maxime Ripard > + > +properties: > + compatible: > +const: ronbo,rb070d30 > + > + reg: > +description: MIPI-DSI virtual channel > + > + power-gpios: > +description: GPIO used for the power pin > +maxItems: 1 > + > + reset-gpios: > +description: GPIO used for the reset pin > +maxItems: 1 > + > + shlr-gpios: > +description: GPIO used for the shlr pin (horizontal flip) > +maxItems: 1 > + > + updn-gpios: > +description: GPIO used for the updn pin (vertical flip) > +maxItems: 1 > + > + vcc-lcd-supply: > +description: Power regulator > + > + backlight: > +description: Backlight used by the panel > +$ref: "/schemas/types.yaml#/definitions/phandle" > + > +required: > + - compatible > + - power-gpios > + - reg > + - reset-gpios > + - shlr-gpios > + - updn-gpios > + - vcc-lcd-supply > + > +additionalProperties: false > + -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] dt-bindings: Add vendor prefix for Ronbo Electronics
On Tue, 2019-02-26 at 15:30 +0100, Paul Kocialkowski wrote: > Hi, > > On Wed, 2019-02-20 at 09:21 +0100, Maxime Ripard wrote: > > From: Konstantin Sudakov > > > > Ronbo Electronics manufactures display panels. > > > > Signed-off-by: Konstantin Sudakov > > Signed-off-by: Maxime Ripard Ah actually, I went too fast on this one: the vendor is not added following alphabetical order. With that fixed: > Reviewed-by: Paul Kocialkowski Cheers, Paul > > --- > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > > b/Documentation/devicetree/bindings/vendor-prefixes.txt > > index 4f225ce815d8..b64d8316dfae 100644 > > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > > @@ -337,6 +337,7 @@ riscv RISC-V Foundation > > rockchip Fuzhou Rockchip Electronics Co., Ltd > > rohm ROHM Semiconductor Co., Ltd > > roofullShenzhen Roofull Technology Co, Ltd > > +ronbo Ronbo Electronics > > samsungSamsung Semiconductor > > samtec Samtec/Softing company > > sancloud Sancloud Ltd -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] dt-bindings: Add vendor prefix for Ronbo Electronics
Hi, On Wed, 2019-02-20 at 09:21 +0100, Maxime Ripard wrote: > From: Konstantin Sudakov > > Ronbo Electronics manufactures display panels. > > Signed-off-by: Konstantin Sudakov > Signed-off-by: Maxime Ripard Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 4f225ce815d8..b64d8316dfae 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -337,6 +337,7 @@ riscv RISC-V Foundation > rockchip Fuzhou Rockchip Electronics Co., Ltd > rohm ROHM Semiconductor Co., Ltd > roofull Shenzhen Roofull Technology Co, Ltd > +ronbo Ronbo Electronics > samsung Samsung Semiconductor > samtec Samtec/Softing company > sancloud Sancloud Ltd -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 9:53 PM, Sumit Semwal wrote: > On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. > > As an idea, I really like the direction for this. It gives a good > amount of flexibilty for exporters. So definitely thanks to John and > you for taking the plunge there :) > >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> > Other than current heaps, the secure heaps have been talked about > quite a bit in the past, so I will check with Linaro's security group > on them trying out the next version as well. As I also moonlight as a Linaro member engineer as part of SWG (andrew.da...@linaro.org) I've talked with Joakim and Etienne about the secure (unmapped) heaps, adding those are already baked into my plans here :) Andrew > We also would need to do a performance comparison, so that's another > activity to be added. >> Thanks, >> Andrew > Best, > Sumit. >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/sun4i: rgb: Store the bridge pointer
We'll need the bridge pointer, if any, in the mode_valid callback in
addition to the init function. Store the pointer to the bridge in the
rgb private structure.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index d181ee399b03..8a43ed46af82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -28,6 +28,7 @@ struct sun4i_rgb {
struct sun4i_tcon *tcon;
struct drm_panel*panel;
+ struct drm_bridge *bridge;
};
static inline struct sun4i_rgb *
@@ -169,7 +170,6 @@ static struct drm_encoder_funcs sun4i_rgb_enc_funcs = {
int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
{
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
struct sun4i_rgb *rgb;
int ret;
@@ -180,7 +180,7 @@ int sun4i_rgb_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
encoder = >encoder;
ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
- >panel, );
+ >panel, >bridge);
if (ret) {
dev_info(drm->dev, "No panel or bridge found... RGB output
disabled\n");
return 0;
@@ -222,8 +222,8 @@ int sun4i_rgb_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
}
}
- if (bridge) {
- ret = drm_bridge_attach(encoder, bridge, NULL);
+ if (rgb->bridge) {
+ ret = drm_bridge_attach(encoder, rgb->bridge, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't attach our bridge\n");
goto err_cleanup_connector;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/sun4i: rgb: Relax the pixel clock check
Hi, This implements roughly what we discussed as part of the ANX6345 series to relax the pixel clock validation while still filtering out the modes we can't reach using the bridges. Let me know what you think, Maxime Maxime Ripard (4): drm/sun4i: Move the panel pointer from the TCON to the encoders drm/sun4i: rgb: Store the bridge pointer drm/sun4i: Move rate variables to long long drm/sun4i: rgb: Change the pixel clock validation check drivers/gpu/drm/sun4i/sun4i_lvds.c | 29 drivers/gpu/drm/sun4i/sun4i_rgb.c | 74 +-- drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 +- 3 files changed, 64 insertions(+), 41 deletions(-) base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/sun4i: Move rate variables to long long
Our clock rate variables are getting pretty close to the LONG_MAX / ULONG_MAX
limit, especially since we will start doing arithmetic on it. Move those
types to unsigned long long to be sure we don't overflow their type.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 8a43ed46af82..893b6e6d4d85 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -60,8 +60,8 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct
drm_encoder *crtc,
struct sun4i_tcon *tcon = rgb->tcon;
u32 hsync = mode->hsync_end - mode->hsync_start;
u32 vsync = mode->vsync_end - mode->vsync_start;
- unsigned long rate = mode->clock * 1000;
- long rounded_rate;
+ unsigned long long rate = mode->clock * 1000;
+ unsigned long long rounded_rate;
DRM_DEBUG_DRIVER("Validating modes...\n");
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/sun4i: rgb: Change the pixel clock validation check
The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.
However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.
This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.
We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.
On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.
Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.
We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.
Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 37 ++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 893b6e6d4d85..05beefe93989 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -53,6 +53,14 @@ static int sun4i_rgb_get_modes(struct drm_connector
*connector)
return drm_panel_get_modes(rgb->panel);
}
+/*
+ * VESA DMT defines a tolerance of 0.5% on the pixel clock, while the
+ * CVT spec reuses that tolerance in its examples, so it looks to be a
+ * good default tolerance for the EDID-based modes. Define it to 5 per
+ * mille to avoid floating point operations.
+ */
+DEFINE SUN4I_RGB_DOTCLOCK_TOLERANCE5
+
static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode
*mode)
{
@@ -61,6 +69,7 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct
drm_encoder *crtc,
u32 hsync = mode->hsync_end - mode->hsync_start;
u32 vsync = mode->vsync_end - mode->vsync_start;
unsigned long long rate = mode->clock * 1000;
+ unsigned long long lowest, highest;
unsigned long long rounded_rate;
DRM_DEBUG_DRIVER("Validating modes...\n");
@@ -93,15 +102,39 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct
drm_encoder *crtc,
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+ /*
+* TODO: We should use the struct display_timing if available
+* and / or trying to stretch the timings within that
+* tolerancy to take care of panels that we wouldn't be able
+* to have a exact match for.
+*/
+ if (rgb->panel) {
+ DRM_DEBUG_DRIVER("RGB panel used, skipping clock rate checks");
+ goto out;
+ }
+
+ /*
+* That shouldn't ever happen unless something is really wrong, but it
+* doesn't harm to check.
+*/
+ if (!rgb->bridge)
+ goto out;
+
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
+
+ lowest = rate * (1000 - SUN4I_RGB_DOTCLOCK_TOLERANCE);
+ do_div(lowest, 1000);
+ if (rounded_rate < lowest)
return MODE_CLOCK_LOW;
- if (rounded_rate > rate)
+ highest = rate * (1000 + SUN4I_RGB_DOTCLOCK_TOLERANCE);
+ do_div(highest, 1000);
+ if (rounded_rate > highest)
return MODE_CLOCK_HIGH;
+out:
DRM_DEBUG_DRIVER("Clock rate OK\n");
return MODE_OK;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/sun4i: Move the panel pointer from the TCON to the encoders
The TCON driver used to need the panel pointer in order to configure the
tcon according to the various parameters of the panel. However, this has
evolved over time (especially to support bridges), and therefore the panel
pointer isn't needed anymore by the TCON driver.
Move that pointer to the LVDS and RGB encoders drivers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_lvds.c | 29 -
drivers/gpu/drm/sun4i/sun4i_rgb.c | 27 ---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 --
3 files changed, 24 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index e7eb0d1e17be..5696f55db5cd 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -20,7 +20,7 @@ struct sun4i_lvds {
struct drm_connectorconnector;
struct drm_encoder encoder;
- struct sun4i_tcon *tcon;
+ struct drm_panel*panel;
};
static inline struct sun4i_lvds *
@@ -41,9 +41,8 @@ static int sun4i_lvds_get_modes(struct drm_connector
*connector)
{
struct sun4i_lvds *lvds =
drm_connector_to_sun4i_lvds(connector);
- struct sun4i_tcon *tcon = lvds->tcon;
- return drm_panel_get_modes(tcon->panel);
+ return drm_panel_get_modes(lvds->panel);
}
static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
@@ -54,9 +53,8 @@ static void
sun4i_lvds_connector_destroy(struct drm_connector *connector)
{
struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
- struct sun4i_tcon *tcon = lvds->tcon;
- drm_panel_detach(tcon->panel);
+ drm_panel_detach(lvds->panel);
drm_connector_cleanup(connector);
}
@@ -71,26 +69,24 @@ static const struct drm_connector_funcs
sun4i_lvds_con_funcs = {
static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
{
struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
- struct sun4i_tcon *tcon = lvds->tcon;
DRM_DEBUG_DRIVER("Enabling LVDS output\n");
- if (tcon->panel) {
- drm_panel_prepare(tcon->panel);
- drm_panel_enable(tcon->panel);
+ if (lvds->panel) {
+ drm_panel_prepare(lvds->panel);
+ drm_panel_enable(lvds->panel);
}
}
static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
{
struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
- struct sun4i_tcon *tcon = lvds->tcon;
DRM_DEBUG_DRIVER("Disabling LVDS output\n");
- if (tcon->panel) {
- drm_panel_disable(tcon->panel);
- drm_panel_unprepare(tcon->panel);
+ if (lvds->panel) {
+ drm_panel_disable(lvds->panel);
+ drm_panel_unprepare(lvds->panel);
}
}
@@ -113,11 +109,10 @@ int sun4i_lvds_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
lvds = devm_kzalloc(drm->dev, sizeof(*lvds), GFP_KERNEL);
if (!lvds)
return -ENOMEM;
- lvds->tcon = tcon;
encoder = >encoder;
ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
- >panel, );
+ >panel, );
if (ret) {
dev_info(drm->dev, "No panel or bridge found... LVDS output
disabled\n");
return 0;
@@ -138,7 +133,7 @@ int sun4i_lvds_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
/* The LVDS encoder can only work with the TCON channel 0 */
lvds->encoder.possible_crtcs = drm_crtc_mask(>crtc->crtc);
- if (tcon->panel) {
+ if (lvds->panel) {
drm_connector_helper_add(>connector,
_lvds_con_helper_funcs);
ret = drm_connector_init(drm, >connector,
@@ -152,7 +147,7 @@ int sun4i_lvds_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
drm_connector_attach_encoder(>connector,
>encoder);
- ret = drm_panel_attach(tcon->panel, >connector);
+ ret = drm_panel_attach(lvds->panel, >connector);
if (ret) {
dev_err(drm->dev, "Couldn't attach our panel\n");
goto err_cleanup_connector;
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f4a22689eb54..d181ee399b03 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -27,6 +27,7 @@ struct sun4i_rgb {
struct drm_encoder encoder;
struct sun4i_tcon *tcon;
+ struct drm_panel*panel;
};
static inline struct sun4i_rgb *
@@ -47,9 +48,8 @@ static int sun4i_rgb_get_modes(struct drm_connector
*connector)
{
struct sun4i_rgb *rgb =
drm_connector_to_sun4i_rgb(connector);
AFBC versions modifiers
Hi Ayan, Could you help distinguish which are the AFBC modifiers for each version of AFBC ? The Amlogic SoCs embeds an AFBC 1.0 compatible decoder, then the newer SoCs embeds an AFBC 1.2 decoder, I assume the modifiers before the patch "drm/fourcc: Add modifier defininitions for AFBC 1.3" are valid for AFBC 1.2, but what is the subset for 1.0 and 1.1 ? Thanks, Neil -- Neil Armstrong Embedded Linux Software Engineer BayLibre - At the Heart of Embedded Linux www.baylibre.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
Le lun. 25 févr. 2019 à 15:36, Andrew F. Davis a écrit : > > This framework allows a unified userspace interface for dma-buf > exporters, allowing userland to allocate specific types of memory > for use in dma-buf sharing. > > Each heap is given its own device node, which a user can allocate > a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. > > Signed-off-by: Andrew F. Davis > --- > > Hello all, > > I had a little less time over the weekend than I thought I would to > clean this up more and finish the first set of user heaps, but wanted > to get this out anyway. > > ION in its current form assumes a lot about the memory it exports and > these assumptions lead to restrictions on the full range of operations > dma-buf's can produce. Due to this if we are to add this as an extension > of the core dma-buf then it should only be the user-space advertisement > and allocation front-end. All dma-buf exporting and operation need to be > placed in the control of the exporting heap. The core becomes rather > small, just a few hundred lines you see here. This is not to say we > should not provide helpers to make the heap exporters more simple, but > they should only be helpers and not enforced by the core framework. > > Basic use model here is an exporter (dedicated heap memory driver, CMA, > System, etc.) registers with the framework by providing a struct > dma_heap_info which gives us the needed info to export this heap to > userspace as a device node. Next a user will request an allocation, > the IOCTL is parsed and the request made to a heap provided alloc() op. > The heap should return the filled out struct dma_heap_buffer, including > exporting the buffer as a dma-buf. This dma-buf we then return to the > user as a fd. Buffer free is still a bit open as we need to update some > stats and free some memory, but the release operation is controlled by > the heap exporter, so some hook will have to be created. > > It all needs a bit more work, and I'm sure I'll find missing parts when > I add some more heaps, but hopefully this framework is simple enough that > it does not impede the implementation of all functionality once provided > by ION (shrinker, delayed free), nor any new functionality needed for > future heap exporting devices. > > Thanks, > Andrew Overall I like the idea but I think "dma_heap" will be confusing like dma_buf is because it isn't related to DMA engine. I would like to see how this could be used with exiting allocator like CMA or genalloc. Benjamin > > drivers/dma-buf/Kconfig | 12 ++ > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-heap.c| 268 ++ > include/linux/dma-heap.h | 57 > include/uapi/linux/dma-heap.h | 54 +++ > 5 files changed, 392 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index 2e5a0faa2cb1..30b0d7c83945 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -39,4 +39,16 @@ config UDMABUF > A driver to let userspace turn memfd regions into dma-bufs. > Qemu can use this to create host dmabufs for guest framebuffers. > > +menuconfig DMABUF_HEAPS > + bool "DMA-BUF Userland Memory Heaps" > + depends on HAS_DMA && MMU Why do you put MMU dependency ? > + select GENERIC_ALLOCATOR Maybe I have miss it but I don't see the need to select GENERIC_ALLOCATOR > + select DMA_SHARED_BUFFER > + help > + Choose this option to enable the DMA-BUF userland memory heaps, > + this allows userspace to allocate dma-bufs that can be shared > between > + drivers. > + > +source "drivers/dma-buf/heaps/Kconfig" > + > endmenu > diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile > index 0913a6ccab5a..b0332f143413 100644 > --- a/drivers/dma-buf/Makefile > +++ b/drivers/dma-buf/Makefile > @@ -1,4 +1,5 @@ > obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o > +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o > obj-$(CONFIG_SYNC_FILE)+= sync_file.o > obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o > obj-$(CONFIG_UDMABUF) += udmabuf.o > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > new file mode 100644 > index ..72ed225fa892 > --- /dev/null > +++ b/drivers/dma-buf/dma-heap.c > @@ -0,0 +1,268 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Framework for userspace DMA-BUF allocations > + * > + * Copyright (C) 2011 Google, Inc. > + * Copyright (C) 2019 Linaro Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#define DEVNAME "dma_heap" > + > +#define NUM_HEAP_MINORS 128 > +static DEFINE_IDR(dma_heap_idr); > +static
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 6:55 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> unsigned int flags)
>> +{
>> + struct dma_heap_buffer *buffer;
>> + int fd, ret;
>> +
>> + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
>> + if (!buffer)
>> + return -ENOMEM;
>> +
>> + buffer->heap = heap;
>> + ret = heap->ops->allocate(heap, buffer, len, flags);
>> + if (ret) {
>> + kfree(buffer);
>> + return ret;
>> + }
>
> Similarly, I think the struct dma_heap_buffer, should be allocated and
> returned by the heap's allocate function.
>
That sound good, we could also then remove the free in buffer_free(),
just wasn't sure about object lifetimes causing issues if it was freed
early and the framework still needed something from it.
Andrew
> That way it can allocate its own larger structure (with the
> dma_heap_buffer as part of it) with private fields, and use
> container_of() to traverse from the buffer to the private data.
>
> Once I get things building, I'll share my changes.
>
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
On 2/25/19 6:20 PM, John Stultz wrote: > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote: >> >> This framework allows a unified userspace interface for dma-buf >> exporters, allowing userland to allocate specific types of memory >> for use in dma-buf sharing. >> >> Each heap is given its own device node, which a user can allocate >> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. >> >> Signed-off-by: Andrew F. Davis >> --- >> >> Hello all, >> >> I had a little less time over the weekend than I thought I would to >> clean this up more and finish the first set of user heaps, but wanted >> to get this out anyway. >> >> ION in its current form assumes a lot about the memory it exports and >> these assumptions lead to restrictions on the full range of operations >> dma-buf's can produce. Due to this if we are to add this as an extension >> of the core dma-buf then it should only be the user-space advertisement >> and allocation front-end. All dma-buf exporting and operation need to be >> placed in the control of the exporting heap. The core becomes rather >> small, just a few hundred lines you see here. This is not to say we >> should not provide helpers to make the heap exporters more simple, but >> they should only be helpers and not enforced by the core framework. >> >> Basic use model here is an exporter (dedicated heap memory driver, CMA, >> System, etc.) registers with the framework by providing a struct >> dma_heap_info which gives us the needed info to export this heap to >> userspace as a device node. Next a user will request an allocation, >> the IOCTL is parsed and the request made to a heap provided alloc() op. >> The heap should return the filled out struct dma_heap_buffer, including >> exporting the buffer as a dma-buf. This dma-buf we then return to the >> user as a fd. Buffer free is still a bit open as we need to update some >> stats and free some memory, but the release operation is controlled by >> the heap exporter, so some hook will have to be created. >> >> It all needs a bit more work, and I'm sure I'll find missing parts when >> I add some more heaps, but hopefully this framework is simple enough that >> it does not impede the implementation of all functionality once provided >> by ION (shrinker, delayed free), nor any new functionality needed for >> future heap exporting devices. >> >> Thanks, >> Andrew >> >> drivers/dma-buf/Kconfig | 12 ++ >> drivers/dma-buf/Makefile | 1 + >> drivers/dma-buf/dma-heap.c| 268 ++ >> include/linux/dma-heap.h | 57 >> include/uapi/linux/dma-heap.h | 54 +++ >> 5 files changed, 392 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> >> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig >> index 2e5a0faa2cb1..30b0d7c83945 100644 >> --- a/drivers/dma-buf/Kconfig >> +++ b/drivers/dma-buf/Kconfig >> @@ -39,4 +39,16 @@ config UDMABUF >> A driver to let userspace turn memfd regions into dma-bufs. >> Qemu can use this to create host dmabufs for guest framebuffers. >> >> +menuconfig DMABUF_HEAPS >> + bool "DMA-BUF Userland Memory Heaps" >> + depends on HAS_DMA && MMU >> + select GENERIC_ALLOCATOR >> + select DMA_SHARED_BUFFER >> + help >> + Choose this option to enable the DMA-BUF userland memory heaps, >> + this allows userspace to allocate dma-bufs that can be shared >> between >> + drivers. >> + >> +source "drivers/dma-buf/heaps/Kconfig" >> + >> endmenu >> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile >> index 0913a6ccab5a..b0332f143413 100644 >> --- a/drivers/dma-buf/Makefile >> +++ b/drivers/dma-buf/Makefile >> @@ -1,4 +1,5 @@ >> obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o >> +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o >> obj-$(CONFIG_SYNC_FILE)+= sync_file.o >> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o >> obj-$(CONFIG_UDMABUF) += udmabuf.o >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c >> new file mode 100644 >> index ..72ed225fa892 >> --- /dev/null >> +++ b/drivers/dma-buf/dma-heap.c >> @@ -0,0 +1,268 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Framework for userspace DMA-BUF allocations >> + * >> + * Copyright (C) 2011 Google, Inc. >> + * Copyright (C) 2019 Linaro Ltd. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> +#define DEVNAME "dma_heap" >> + >> +#define NUM_HEAP_MINORS 128 >> +static DEFINE_IDR(dma_heap_idr); >> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */ >> + >> +dev_t dma_heap_devt; >> +struct class *dma_heap_class; >> +struct list_head dma_heap_list; >> +struct dentry
Re: [PATCH 0/5] Clean up TTM mmap offsets
Am 07.02.19 um 10:45 schrieb Thomas Zimmermann: Am 07.02.19 um 10:36 schrieb Koenig, Christian: Am 07.02.19 um 09:59 schrieb Thomas Zimmermann: Almost all TTM-based drivers use the same values for the mmap-able range of BO addresses. Each driver therefore duplicates the DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not configurable by drivers. This patch set replaces driver-specific configuration with a single setup. All code is located within TTM. TTM and GEM share the same range for mmap-able BOs. Thomas Zimmermann (5): staging/vboxvideo: Use same BO mmap offset as other drivers drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() drm/ttm: Quick-test mmap offset in ttm_bo_mmap() drm: Use the same mmap-range offset and size for GEM and TTM Reviewed-by: Christian König for the whole series. That was quick! Thank you. FYI I just pushed this series into our internal branch for upstreaming. Regards, Christian. Nice cleanup! Thanks, Christian. drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 12 ++-- drivers/gpu/drm/ast/ast_drv.h | 2 -- drivers/gpu/drm/ast/ast_ttm.c | 10 ++ drivers/gpu/drm/bochs/bochs.h | 2 -- drivers/gpu/drm/bochs/bochs_mm.c| 10 ++ drivers/gpu/drm/cirrus/cirrus_drv.h | 1 - drivers/gpu/drm/cirrus/cirrus_ttm.c | 10 ++ drivers/gpu/drm/drm_gem.c | 17 - drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 12 ++-- drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - drivers/gpu/drm/mgag200/mgag200_ttm.c | 10 ++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 -- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 drivers/gpu/drm/qxl/qxl_drv.h | 3 --- drivers/gpu/drm/qxl/qxl_ttm.c | 11 +++ drivers/gpu/drm/radeon/radeon_ttm.c | 13 ++--- drivers/gpu/drm/ttm/ttm_bo.c| 6 +++--- drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 +++ drivers/gpu/drm/virtio/virtgpu_ttm.c| 4 +--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 11 ++- drivers/staging/vboxvideo/vbox_drv.h| 2 -- drivers/staging/vboxvideo/vbox_ttm.c| 12 +++- include/drm/drm_vma_manager.h | 12 include/drm/ttm/ttm_bo_driver.h | 2 +- 26 files changed, 42 insertions(+), 132 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #19 from Christian König --- I think that we can all agree on that this bug can be closed because it doesn't contain any valuable information. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #18 from Daniel Stone --- The user has been permanently banned for harrassment. -- 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 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #17 from Daniel Stone --- The content of attachment 143467 has been deleted for the following reason: 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
[Bug 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #16 from Daniel Stone --- The content of attachment 143475 has been deleted for the following reason: harrassment -- 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 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #14 from Daniel Stone --- The content of attachment 143468 has been deleted for the following reason: harrassment -- 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 109758] AMD GPU for Ubuntu Linux Broken
https://bugs.freedesktop.org/show_bug.cgi?id=109758 --- Comment #15 from Daniel Stone --- The content of attachment 143474 has been deleted for the following reason: harrassment -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
Quoting Alex Deucher (2019-02-25 21:31:43) > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > wrote: > > > > Quoting Dave Airlie (2019-02-25 12:24:48) > > > On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen > > > wrote: > > > > > > > > + dri-devel mailing list, especially for the buddy allocator part > > > > > > > > Quoting Dave Airlie (2019-02-15 02:47:07) > > > > > On Fri, 15 Feb 2019 at 00:57, Matthew Auld > > > > > wrote: > > > > > > > > > > > > In preparation for upcoming devices with device local memory, > > > > > > introduce the > > > > > > concept of different memory regions, and a simple buddy allocator > > > > > > to manage > > > > > > them. > > > > > > > > > > This is missing the information on why it's not TTM. > > > > > > > > > > Nothing against extending i915 gem off into doing stuff we already > > > > > have examples off in tree, but before you do that it would be good to > > > > > have a why we can't use TTM discussion in public. > > > > > > > > Glad that you asked. It's my fault that it was not included in > > > > the cover letter. I anticipated the question, but was travelling > > > > for a couple of days at the time this was sent. I didn't want > > > > to write a hasty explanation and then disappear, leaving others to > > > > take the heat. > > > > > > > > So here goes the less-hasty version: > > > > > > > > We did an analysis on the effort needed vs benefit gained of using > > > > TTM when this was started initially. The conclusion was that we > > > > already share the interesting bits of code through core DRM, really. > > > > > > > > Re-writing the memory handling to TTM would buy us more fine-grained > > > > locking. But it's more a trait of rewriting the memory handling with > > > > the information we have learned, than rewriting it to use TTM :) > > > > > > > > And further, we've been getting rid of struct_mutex at a steady phase > > > > in the past years, so we have a clear path to the fine-grained locking > > > > already in the not-so-distant future. With all this we did not see > > > > much gained from converting over, as the code sharing is already > > > > substantial. > > > > > > > > We also wanted to have the buddy allocator instead of a for loop making > > > > drm_mm allocations to make sure we can keep the memory fragmentation > > > > at bay. The intent is to move the buddy allocator to core DRM, to the > > > > benefit of all the drivers, if there is interest from community. It has > > > > been written as a strictly separate component with that in mind. > > > > > > > > And if you take the buddy allocator out of the patch set, the rest is > > > > mostly just vfuncing things up to be able to have different backing > > > > storages for objects. We took the opportunity to move over to the more > > > > valgrind friendly mmap while touching things, but it's something we > > > > have been contemplating anyway. And yeah, loads of selftests. > > > > > > > > That's really all that needed adding, and most of it is internal to > > > > i915 and not to do with uAPI. This means porting over an userspace > > > > driver doesn't require a substantial rewrite, but adding new a few > > > > new IOCTLs to set the preferred backing storage placements. > > > > > > > > All the previous GEM abstractions keep applying, so we did not see > > > > a justification to rewrite the kernel driver and userspace drivers. > > > > It would have just to made things look like TTM, when we already > > > > have the important parts of the code shared with TTM drivers > > > > behind the GEM interfaces which all our drivers sit on top of. > > > > > > a) you guys should be the community as well, if the buddy allocator is > > > useful in the core DRM get out there and try and see if anyone else > > > has a use case for it, like the GPU scheduler we have now (can i915 > > > use that yet? :-) > > > > Well, the buddy allocator should be useful for anybody wishing to have > > as continuous physical allocations as possible. I have naively assumed > > that would be almost everyone. So it would be only a question if others > > see the amount of work required to convert over is justified for them. > > > > For the common DRM scheduler, I think a solid move from the beginning > > would have been to factor out the i915 scheduler as it was most advanced > > in features :) Now there is a way more trivial common scheduler core with > > no easy path to transition without a feature regression. > > Can you elaborate? What features are missing from the drm gpu scheduler? Priority based pre-emption is the big thing coming to mind. But maybe we should not derail the discussion in this thread. The discussion should be in the archives, or we can start a new thread. > > We'd have to rewrite many of the more advanced features for that codebase > > before we could transition over. It's hard to justify such work, for > > that it would buy us very little compared to amount of work. > > > > Situation would be different if there was something
Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls
On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
wrote:
>
> On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > Add the dmabuf map / unmap interfaces. This allows the user driver
> > to be able to import the external dmabuf and use it from user space.
> >
> > Signed-off-by: Hyun Kwon
> > ---
> > drivers/uio/Makefile | 2 +-
> > drivers/uio/uio.c| 43 +
> > drivers/uio/uio_dmabuf.c | 210
> > +++
> > drivers/uio/uio_dmabuf.h | 26 ++
> > include/uapi/linux/uio/uio.h | 33 +++
> > 5 files changed, 313 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/uio/uio_dmabuf.c
> > create mode 100644 drivers/uio/uio_dmabuf.h
> > create mode 100644 include/uapi/linux/uio/uio.h
> >
> > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > index c285dd2..5da16c7 100644
> > --- a/drivers/uio/Makefile
> > +++ b/drivers/uio/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_UIO)+= uio.o
> > +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> > obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> > obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> > obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 1313422..6841f98 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -24,6 +24,12 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "uio_dmabuf.h"
> >
> > #define UIO_MAX_DEVICES (1U << MINORBITS)
> >
> > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void *dev_id)
> > struct uio_listener {
> > struct uio_device *dev;
> > s32 event_count;
> > + struct list_head dbufs;
> > + struct mutex dbufs_lock; /* protect @dbufs */
> > };
> >
> > static int uio_open(struct inode *inode, struct file *filep)
> > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct file
> > *filep)
> > if (ret)
> > goto err_infoopen;
> >
> > + INIT_LIST_HEAD(>dbufs);
> > + mutex_init(>dbufs_lock);
> > +
> > return 0;
> >
> > err_infoopen:
> > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, struct
> > file *filep)
> > struct uio_listener *listener = filep->private_data;
> > struct uio_device *idev = listener->dev;
> >
> > + ret = uio_dmabuf_cleanup(idev, >dbufs,
> > >dbufs_lock);
> > + if (ret)
> > + dev_err(>dev, "failed to clean up the dma bufs\n");
> > +
> > mutex_lock(>info_lock);
> > if (idev->info && idev->info->release)
> > ret = idev->info->release(idev->info, inode);
> > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, const
> > char __user *buf,
> > return retval ? retval : sizeof(s32);
> > }
> >
> > +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned long
> > arg)
>
> We have resisted adding a uio ioctl for a long time, can't you do this
> through sysfs somehow?
>
> A meta-comment about your ioctl structure:
>
> > +#define UIO_DMABUF_DIR_BIDIR 1
> > +#define UIO_DMABUF_DIR_TO_DEV2
> > +#define UIO_DMABUF_DIR_FROM_DEV 3
> > +#define UIO_DMABUF_DIR_NONE 4
>
> enumerated type?
>
> > +
> > +struct uio_dmabuf_args {
> > + __s32 dbuf_fd;
> > + __u64 dma_addr;
> > + __u64 size;
> > + __u32 dir;
>
> Why the odd alignment? Are you sure this is the best packing for such a
> structure?
>
> Why is dbuf_fd __s32? dir can be __u8, right?
>
> I don't know that dma layer very well, it would be good to get some
> review from others to see if this really is even a viable thing to do.
> The fd handling seems a bit "odd" here, but maybe I just do not
> understand it.
Frankly looks like a ploy to sidestep review by graphics folks. We'd
ask for the userspace first :-)
Also, exporting dma_addr to userspace is considered a very bad idea.
If you want to do this properly, you need a minimal in-kernel memory
manager, and those tend to be based on top of drm_gem.c and merged
through the gpu tree. The last place where we accidentally leaked a
dma addr for gpu buffers was in the fbdev code, and we plugged that
one with
commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a (tag:
drm-misc-next-fixes-2018-10-03)
Author: Neil Armstrong
Date: Fri Sep 28 14:05:55 2018 +0200
drm/fb_helper: Allow leaking fbdev smem_start
Together with cuse the above patch should be enough to implement a drm
driver entirely in userspace at least.
Cheers, 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
Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls
On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> Add the dmabuf map / unmap interfaces. This allows the user driver
> to be able to import the external dmabuf and use it from user space.
>
> Signed-off-by: Hyun Kwon
> ---
> drivers/uio/Makefile | 2 +-
> drivers/uio/uio.c| 43 +
> drivers/uio/uio_dmabuf.c | 210
> +++
> drivers/uio/uio_dmabuf.h | 26 ++
> include/uapi/linux/uio/uio.h | 33 +++
> 5 files changed, 313 insertions(+), 1 deletion(-)
> create mode 100644 drivers/uio/uio_dmabuf.c
> create mode 100644 drivers/uio/uio_dmabuf.h
> create mode 100644 include/uapi/linux/uio/uio.h
>
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2..5da16c7 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_UIO)+= uio.o
> +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 1313422..6841f98 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -24,6 +24,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +#include
> +
> +#include "uio_dmabuf.h"
>
> #define UIO_MAX_DEVICES (1U << MINORBITS)
>
> @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void *dev_id)
> struct uio_listener {
> struct uio_device *dev;
> s32 event_count;
> + struct list_head dbufs;
> + struct mutex dbufs_lock; /* protect @dbufs */
> };
>
> static int uio_open(struct inode *inode, struct file *filep)
> @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct file
> *filep)
> if (ret)
> goto err_infoopen;
>
> + INIT_LIST_HEAD(>dbufs);
> + mutex_init(>dbufs_lock);
> +
> return 0;
>
> err_infoopen:
> @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, struct file
> *filep)
> struct uio_listener *listener = filep->private_data;
> struct uio_device *idev = listener->dev;
>
> + ret = uio_dmabuf_cleanup(idev, >dbufs, >dbufs_lock);
> + if (ret)
> + dev_err(>dev, "failed to clean up the dma bufs\n");
> +
> mutex_lock(>info_lock);
> if (idev->info && idev->info->release)
> ret = idev->info->release(idev->info, inode);
> @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, const char
> __user *buf,
> return retval ? retval : sizeof(s32);
> }
>
> +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned long
> arg)
We have resisted adding a uio ioctl for a long time, can't you do this
through sysfs somehow?
A meta-comment about your ioctl structure:
> +#define UIO_DMABUF_DIR_BIDIR 1
> +#define UIO_DMABUF_DIR_TO_DEV2
> +#define UIO_DMABUF_DIR_FROM_DEV 3
> +#define UIO_DMABUF_DIR_NONE 4
enumerated type?
> +
> +struct uio_dmabuf_args {
> + __s32 dbuf_fd;
> + __u64 dma_addr;
> + __u64 size;
> + __u32 dir;
Why the odd alignment? Are you sure this is the best packing for such a
structure?
Why is dbuf_fd __s32? dir can be __u8, right?
I don't know that dma layer very well, it would be good to get some
review from others to see if this really is even a viable thing to do.
The fd handling seems a bit "odd" here, but maybe I just do not
understand it.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #11 from mikhail.v.gavri...@gmail.com --- Created attachment 143476 --> https://bugs.freedesktop.org/attachment.cgi?id=143476=edit [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* - kernel log -- 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 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #10 from mikhail.v.gavri...@gmail.com ---
Even without reproducing GPU hang in kernel log I found "suspicious RCU usage"
and some errors.
[drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 2caf7aed is still
alive
[drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 2caf7aed is still alive
=
WARNING: suspicious RCU usage
5.0.0-rc1-drm-next-kernel+ #1 Tainted: G C
-
include/linux/rcupdate.h:280 Illegal context switch in RCU read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by CrashBandicootN/26312:
#0: eb680bad (>f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
#1: b3a3c406 (>lock){+.+.}, at: seq_read+0x38/0x410
#2: 7c893f05 (rcu_read_lock){}, at: dev_seq_start+0x5/0x100
stack backtrace:
CPU: 8 PID: 26312 Comm: CrashBandicootN Tainted: G C
5.0.0-rc1-drm-next-kernel+ #1
Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING,
BIOS 1103 11/16/2018
Call Trace:
dump_stack+0x85/0xc0
___might_sleep+0x100/0x180
__mutex_lock+0x61/0x930
? igb_get_stats64+0x29/0x80 [igb]
? seq_vprintf+0x33/0x50
? igb_get_stats64+0x29/0x80 [igb]
igb_get_stats64+0x29/0x80 [igb]
dev_get_stats+0x5c/0xc0
dev_seq_printf_stats+0x33/0xe0
dev_seq_show+0x10/0x30
seq_read+0x2fa/0x410
proc_reg_read+0x3c/0x60
__vfs_read+0x37/0x1b0
vfs_read+0xb2/0x170
ksys_read+0x52/0xc0
do_syscall_64+0x5c/0xa0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f2188d8934c
Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 79 c9 01 00 48 8b 54
24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 30
44 89 c7 48 89 44 24 08 e8 af c9 01 00 48
RSP: 002b:0023f010 EFLAGS: 0246 ORIG_RAX:
RAX: ffda RBX: 7d11b6d0 RCX: 7f2188d8934c
RDX: 0400 RSI: 7d0dd4f0 RDI: 007b
RBP: 0d68 R08: R09:
R10: 7f2188621c40 R11: 0246 R12: 7f2188e59740
R13: 7f2188e5a340 R14: 01ff R15: 7d11b6d0
This only occures when I use "amd-staging-drm-next".
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)
So I'm not going to go into technical detail here, which I'll happily leave to Joonas et al, but I think a couple of general points deserve to be addressed. On Tue, 26 Feb 2019, Alex Deucher wrote: > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > wrote: >> Adding the suggested smaller amount of code vs. doing a much bigger >> rewrite is something of a straightforward choice with the amount of >> platforms and features in flight, especially when the end result is >> the same. > > Because you will probably never do it. It's almost always easier to > just incrementally add on to existing code. One could argue that GEM > evolved into more or less the exact same thing as TTM anyway so why > not bite the bullet and switch at some point? TTM works fine even for > UMA hardware. Surely we have lots of faults, but being averse to refactoring, reworking, and continuously rewriting parts of the driver is not among them by any stretch. Sometimes it's just for the general maintainability, sometimes to remodel stuff to neatly plug in support for that new piece of hardware, and everything in between. > There is a common misconception in big companies that if you utilize > shared infrastructure it will slow you down or you'll lose control of > your code which is I think what you are referring to. Ultimately, it > does sometimes raise the bar, but in the long term it benefits > everyone and usually it doesn't really add that much overhead. It > sounds like you are just feeding that misconception; you can't > contribute to or take advantage of any shared infrastructure because > that might slow you down. If that is the case, then why does upstream > first even matter? It seems like the only common code you want to > support is common code that you wrote in the first place. Again, on a general note, without actually checking the stats, I like to think we're pretty good citizens wrt actively using and contributing to shared infrastructure, and shared uapi. Especially so for KMS, and even when it really has slowed us down. So while you may have fair points about a specific case, and again I'll let Joonas address the specific case, I'll have to ask you to please not generalize that to the whole driver. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH libdrm] configure.ac fix build error for config.h in autotools
On Tuesday, 2019-02-26 10:00:56 +0900, Seung-Woo Kim wrote:
> After the commit 0926f0af54d6 ("meson,configure: include config.h
> automatically"), there is build error for autotools because
> config.h is not included. Fix the error by adding "-include
> config.h" to CPPFLAGS instead of CFLAGS from configure.ac.
Thanks!
Reviewed-by: Eric Engestrom
Fixes: 0926f0af54d654b1a958 "meson,configure: include config.h automatically"
I'll push it in moment.
>
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=106561
> Signed-off-by: Seung-Woo Kim
> ---
> It looks like missed from mailing list, so I resend.
> ---
> configure.ac |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 7e7c8d3..d72e84a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -541,7 +541,7 @@ else
> AC_DEFINE(HAVE_VISIBILITY, 0)
> fi
>
> -CFLAGS="$CFLAGS -include config.h"
> +CPPFLAGS="$CPPFLAGS -include config.h"
>
> AC_SUBST(WARN_CFLAGS)
> AC_CONFIG_FILES([
> --
> 1.7.4.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [TWO BUGs] etnaviv crashes overnight
Hi Russell,
Am Dienstag, den 26.02.2019, 09:24 + schrieb Russell King - ARM Linux admin:
> I'm not sure when this happened, only that it happened sometime
> overnight. It was left running an Xfce desktop having only logged in,
> but with the monitor disconnected. Fedora 23 plus xf86-video-armada.
>
> I don't have any more information than that and the kernel messages
> below.
Thanks for the report! Both of those issues are caused by the GPU
scheduler failing to put the scheduler fence callback execution into a
work item, like it normally does, in the dying sched_entity cleanup.
This causes multiple code paths which expect to be called from a clean
process context to be called from the same IRQ context with a number of
locks potentially already held.
It will take me some time to work through the corners of this code, but
I should have a patch fixing this later today.
Regards,
Lucas
> [51328.909729]
> [51328.915044] WARNING: possible recursive locking detected
> [51328.920361] 4.20.0+ #307 Not tainted
> [51328.923939]
> [51328.929254] Xorg/5379 is trying to acquire lock:
> [51328.933874] cd12d5e4 (&(>lock)->rlock){-.-.}, at:
> dma_fence_signal+0x9c/0x1d4
> [51328.941638]
> [51328.941638] but task is already holding lock:
> [51328.947474] cd12d6a4 (&(>lock)->rlock){-.-.}, at:
> dma_fence_signal+0x9c/0x1d4
> [51328.955226]
> [51328.955226] other info that might help us debug this:
> [51328.961756] Possible unsafe locking scenario:
> [51328.961756]
> [51328.967678]CPU0
> [51328.970127]
> [51328.976761] lock(&(>lock)->rlock);
> [51328.980948]
> [51328.980948] *** DEADLOCK ***
> [51328.980948]
> [51328.986871] May be due to missing lock nesting notation
> [51328.986871]
> [51328.993663] 4 locks held by Xorg/5379:
> [51328.997414] #0: d8c6bdd0 (reservation_ww_class_acquire){+.+.}, at:
> drm_ioctl_kernel+0x90/0xc8
> [51329.006040] #1: d879e2ac (>lock){+.+.}, at:
> etnaviv_cmdbuf_init+0x5c/0x16c [etnaviv]
> [51329.014784] #2: d900dd88 (&(>fence_spinlock)->rlock){-.-.}, at:
> dma_fence_signal+0x9c/0x1d4
> [51329.023668] #3: cd12d6a4 (&(>lock)->rlock){-.-.}, at:
> dma_fence_signal+0x9c/0x1d4
> [51329.031854]
> [51329.031854] stack backtrace:
> [51329.036218] CPU: 0 PID: 5379 Comm: Xorg Not tainted 4.20.0+ #307
> [51329.042227] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [51329.048772] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [51329.056527] [] (show_stack) from []
> (dump_stack+0x9c/0xd4)
> [51329.063763] [] (dump_stack) from []
> (__lock_acquire+0x1270/0x19b8)
> [51329.071689] [] (__lock_acquire) from []
> (lock_acquire+0xc4/0x1dc)
> [51329.079529] [] (lock_acquire) from []
> (_raw_spin_lock_irqsave+0x44/0x58)
> [51329.087975] [] (_raw_spin_lock_irqsave) from []
> (dma_fence_signal+0x9c/0x1d4)
> [51329.096872] [] (dma_fence_signal) from []
> (drm_sched_entity_kill_jobs_cb+0x14/0x78 [gpu_sched])
> [51329.107327] [] (drm_sched_entity_kill_jobs_cb [gpu_sched]) from
> [] (dma_fence_signal+0xe0/0x1d4)
> [51329.117866] [] (dma_fence_signal) from []
> (drm_sched_process_job+0x60/0x1a4 [gpu_sched])
> [51329.127710] [] (drm_sched_process_job [gpu_sched]) from
> [] (dma_fence_signal+0xe0/0x1d4)
> [51329.137569] [] (dma_fence_signal) from []
> (irq_handler+0xc8/0x1d8 [etnaviv])
> [51329.146389] [] (irq_handler [etnaviv]) from []
> (__handle_irq_event_percpu+0x98/0x378)
> [51329.155966] [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x1c/0x58)
> [51329.165629] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x38/0x5c)
> [51329.174511] [] (handle_irq_event) from []
> (handle_fasteoi_irq+0x94/0x124)
> [51329.183044] [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x18/0x28)
> [51329.191665] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x54/0xb0)
> [51329.200374] [] (__handle_domain_irq) from []
> (gic_handle_irq+0x48/0x98)
> [51329.208735] [] (gic_handle_irq) from []
> (__irq_svc+0x70/0x98)
> [51329.216221] Exception stack(0xd8c6bc28 to 0xd8c6bc70)
> [51329.221279] bc20: 0001 0011 d8c6bc78 c2005940
> d879e2ac
> [51329.229462] bc40: c0c2c580 600b0013 c0b98568
> c13bb508 d8c6bc78
> [51329.237643] bc60: c0085804 c0087860 800b0013
> [51329.242704] [] (__irq_svc) from []
> (lock_acquire+0xdc/0x1dc)
> [51329.250111] [] (lock_acquire) from []
> (__mutex_lock+0x50/0x8b8)
> [51329.25] [] (__mutex_lock) from []
> (mutex_lock_nested+0x1c/0x24)
> [51329.265812] [] (mutex_lock_nested) from []
> (etnaviv_cmdbuf_init+0x5c/0x16c [etnaviv])
> [51329.275424] [] (etnaviv_cmdbuf_init [etnaviv]) from []
> (etnaviv_ioctl_gem_submit+0x61c/0x1210 [etnaviv])
> [51329.286668] [] (etnaviv_ioctl_gem_submit [etnaviv]) from
> [] (drm_ioctl_kernel+0x90/0xc8)
> [51329.296503] [] (drm_ioctl_kernel) from []
> (drm_ioctl+0x1e0/0x3b0)
> [51329.304344] []
