[PATCH 4/6] drm/bridge: Add Analogix anx6345 support
From: Icenowy Zheng
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
---
drivers/gpu/drm/bridge/analogix/Kconfig| 11 +
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 808 +
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 2 +-
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 8 +
.../drm/bridge/analogix/analogix-i2c-txcommon.h| 3 +
6 files changed, 832 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index ed2d05c12546..3c6ec535d361 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ANALOGIX_ANX6345
+ tristate "Analogix ANX6345 bridge"
+ select DRM_ANALOGIX_DP_I2C
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX6345 is an ultra-low Full-HD DisplayPort/eDP
+ transmitter designed for portable devices. The
+ ANX6345 transforms the LVTTL RGB output of an
+ application processor to eDP or DisplayPort.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP_I2C
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index 2d523b67487d..12fed7b04e1e 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
analogix_dp_i2c-objs := analogix-i2c-dptx.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
new file mode 100644
index ..36f38a9f042a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -0,0 +1,810 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) Icenowy Zheng
+ * Based on analogix-anx6345.c, which is:
+ * Copyright(c) 2016, Analogix Semiconductor.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "analogix-i2c-dptx.h"
+#include "analogix-i2c-txcommon.h"
+
+#define I2C_NUM_ADDRESSES 2
+#define I2C_IDX_DPTX 0
+#define I2C_IDX_TXCOM 1
+
+#define POLL_DELAY 5 /* us */
+#define POLL_TIMEOUT 500 /* us */
+
+static const u8 anx6345_i2c_addresses[] = {
+ [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX,
+ [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
+};
+
+struct anx6345 {
+ struct drm_dp_aux aux;
+ struct drm_bridge bridge;
+ struct i2c_client *client;
+ struct edid *edid;
+ struct drm_connector connector;
+ struct drm_dp_link link;
+ struct drm_panel *panel;
+ struct regulator *dvdd12;
+ struct regulator *dvdd25;
+ struct gpio_desc *gpiod_reset;
+ struct mutex lock;
+
+ /*
+* I2C Slave addresses of ANX6345 are mapped as DPTX and SYS
+*/
+ struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
+ struct regmap *map[I2C_NUM_ADDRESSES];
+
+ u16 chipid;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
+
+ bool powered;
+};
+
+static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
+{
+ return container_of(c, struct anx6345, connector);
+}
+
+static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx6345, bridge);
+}
+
+static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, mask);
+}
+
+static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux);
+
+ return anx_aux_transfer(anx6345->map[I2C_IDX_DPTX], msg);
+}
+
+static int anx6345_dp_link_training(struct anx6345 *anx6345)
+{
+ unsigned int value;
+ u8 dp_bw;
+ int err;
+
+ err = anx6345_clear_
[PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
From: Icenowy Zheng
Some code can be shared within different DP bridges by Analogix.
Extract them to a new module.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
---
drivers/gpu/drm/bridge/analogix/Kconfig| 4 +
drivers/gpu/drm/bridge/analogix/Makefile | 2 +
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +-
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 169 +
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 2 +
5 files changed, 178 insertions(+), 145 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index c4d343a2f04d..ed2d05c12546 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
+ select DRM_ANALOGIX_DP_I2C
select DRM_KMS_HELPER
select REGMAP_I2C
help
@@ -11,3 +12,6 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_DP_I2C
+ tristate
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index ce1687e60975..2d523b67487d 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,4 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+analogix_dp_i2c-objs := analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
+obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index f8433c93f463..bf8291d0ddd0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -45,8 +45,6 @@
#define I2C_IDX_RX_P1 4
#define XTAL_CLK 270 /* 27M */
-#define AUX_CH_BUFFER_SIZE 16
-#define AUX_WAIT_TIMEOUT_MS15
static const u8 anx78xx_i2c_addresses[] = {
[I2C_IDX_TX_P0] = TX_P0,
@@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8
reg, u8 mask)
return regmap_update_bits(map, reg, mask, 0);
}
-static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx)
-{
- unsigned int value;
- int err;
-
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG,
- &value);
- if (err < 0)
- return false;
-
- return (value & SP_AUX_EN) == 0;
-}
-
-static int anx78xx_aux_wait(struct anx78xx *anx78xx)
-{
- unsigned long timeout;
- unsigned int status;
- int err;
-
- timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
-
- while (!anx78xx_aux_op_finished(anx78xx)) {
- if (time_after(jiffies, timeout)) {
- if (!anx78xx_aux_op_finished(anx78xx)) {
- DRM_ERROR("Timed out waiting AUX to finish\n");
- return -ETIMEDOUT;
- }
-
- break;
- }
-
- usleep_range(1000, 2000);
- }
-
- /* Read the AUX channel access status */
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG,
- &status);
- if (err < 0) {
- DRM_ERROR("Failed to read from AUX channel: %d\n", err);
- return err;
- }
-
- if (status & SP_AUX_STATUS) {
- DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
- status);
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr)
-{
- int err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG,
- addr & 0xff);
- if (err)
- return err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG,
- (addr & 0xff00) >> 8);
- if (err)
- return err;
-
- /*
-* DP AUX CH Address Register #2, only update bits[3:0]
-* [7:4] RESERVED
-* [3:0] AUX_ADDR[19:16], Register control AUX CH address.
-*/
- err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
-SP_AUX_ADDR_19_16_REG,
-SP_AUX_ADDR_19_16_MASK,
-(addr & 0xf) >> 16);
-
- if (err)
- return err;
-
- return 0;
-}
-
static ssize_t anx78xx_aux_transfer(struct drm_dp_aux *aux,
[PATCH 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
From: Icenowy Zheng
The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Rob Herring
Signed-off-by: Torsten Duwe
---
.../bindings/display/bridge/anx6345.txt | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt
b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
new file mode 100644
index ..e79a11348d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,56 @@
+Analogix ANX6345 eDP Transmitter
+
+
+The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
+portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx6345"
+ - reg : I2C address of the device
+ - reset-gpios : Which GPIO to use for reset
+ - dvdd12-supply : Regulator for 1.2V digital core power.
+ - dvdd25-supply : Regulator for 2.5V digital core power.
+
+Optional properties:
+
+ - Video ports for RGB input and eDP output using the DT bindings
+ defined in [1]
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_fldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+};
[PATCH 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
From: Icenowy Zheng
Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus. eDP output goes
to an Innolux N116BGE panel.
Enable it in the device tree.
Signed-off-by: Icenowy Zheng
Signed-off-by: Torsten Duwe
---
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 +--
1 file changed, 61 insertions(+), 4 deletions(-)
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -65,6 +65,21 @@
};
};
+ panel: panel {
+ compatible ="innolux,n116bge", "simple-panel";
+ status = "okay";
+ power-supply = <®_dcdc1>;
+ backlight = <&backlight>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out>;
+ };
+ };
+ };
+ };
+
reg_usb1_vbus: usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -81,20 +96,48 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
-/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
- * driver for this chip at the moment, the bootloader initializes it.
- * However it can be accessed with the i2c-dev driver from user space.
- */
&i2c0 {
clock-frequency = <10>;
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
+
+ anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ anx6345_in: endpoint {
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+ port@1 {
+ anx6345_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -279,6 +322,20 @@
vcc-hdmi-supply = <®_dldo1>;
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_anx6345: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&anx6345_in>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
[PATCH 1/6] drm/bridge: move ANA78xx driver to analogix subdirectory
From: Icenowy Zheng
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Laurent Pinchart
Signed-off-by: Torsten Duwe
---
drivers/gpu/drm/bridge/Kconfig | 10 --
drivers/gpu/drm/bridge/Makefile | 4 ++--
drivers/gpu/drm/bridge/analogix/Kconfig | 10 ++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h | 0
6 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..4922c1ceffef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,16 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_ANALOGIX_ANX78XX
- tristate "Analogix ANX78XX bridge"
- select DRM_KMS_HELPER
- select REGMAP_I2C
- ---help---
- ANX78XX is an ultra-low Full-HD SlimPort transmitter
- designed for portable devices. The ANX78XX transforms
- the HDMI output of an application processor to MyDP
- or DisplayPort.
-
config DRM_CDNS_DSI
tristate "Cadence DPI/DSI bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..a6c7dd7727ea 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
@@ -12,8 +11,9 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 80f286fa3a69..c4d343a2f04d 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ANALOGIX_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX78XX is an ultra-low Full-HD SlimPort transmitter
+ designed for portable devices. The ANX78XX transforms
+ the HDMI output of an application processor to MyDP
+ or DisplayPort.
+
config DRM_ANALOGIX_DP
tristate
depends on DRM
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index cd4010ba6890..ce1687e60975 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
--
2.16.4
[PATCH 2/6] drm/bridge: split some definitions of ANX78xx to dedicated headers
From: Icenowy Zheng Some definitions currently in analogix-anx78xx.h are not restricted to the ANX78xx series, but also applicable to other DisplayPort transmitters by Analogix. Split out them to dedicated headers, and make analogix-anx78xx.h include them. Signed-off-by: Icenowy Zheng Signed-off-by: Vasily Khoruzhick Signed-off-by: Torsten Duwe --- drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 464 + .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 248 +++ .../drm/bridge/analogix/analogix-i2c-txcommon.h| 237 +++ 3 files changed, 490 insertions(+), 459 deletions(-) create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h index 38753c870137..8aa1eca306d3 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h @@ -15,9 +15,12 @@ #ifndef __ANX78xx_H #define __ANX78xx_H -#define TX_P0 0x70 +#include "analogix-i2c-dptx.h" +#include "analogix-i2c-txcommon.h" + +#define TX_P0 ANALOGIX_I2C_DPTX #define TX_P1 0x7a -#define TX_P2 0x72 +#define TX_P2 ANALOGIX_I2C_TXCOMMON #define RX_P0 0x7e #define RX_P1 0x80 @@ -225,463 +228,6 @@ #define SP_CLEAR_AVMUTEBIT(4) #define SP_SET_AVMUTE BIT(0) -/***/ -/* Register definition of device address 0x70 */ -/***/ - -/* HDCP Status Register */ -#define SP_TX_HDCP_STATUS_REG 0x00 -#define SP_AUTH_FAIL BIT(5) -#define SP_AUTHEN_PASS BIT(1) - -/* HDCP Control Register 0 */ -#define SP_HDCP_CTRL0_REG 0x01 -#define SP_RX_REPEATER BIT(6) -#define SP_RE_AUTH BIT(5) -#define SP_SW_AUTH_OK BIT(4) -#define SP_HARD_AUTH_ENBIT(3) -#define SP_HDCP_ENC_EN BIT(2) -#define SP_BKSV_SRM_PASS BIT(1) -#define SP_KSVLIST_VLD BIT(0) -/* HDCP Function Enabled */ -#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3)) - -/* HDCP Receiver BSTATUS Register 0 */ -#defineSP_HDCP_RX_BSTATUS0_REG 0x1b -/* HDCP Receiver BSTATUS Register 1 */ -#defineSP_HDCP_RX_BSTATUS1_REG 0x1c - -/* HDCP Embedded "Blue Screen" Content Registers */ -#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c -#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d -#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e - -/* HDCP Wait R0 Timing Register */ -#define SP_HDCP_WAIT_R0_TIME_REG 0x40 - -/* HDCP Link Integrity Check Timer Register */ -#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41 - -/* HDCP Repeater Ready Wait Timer Register */ -#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42 - -/* HDCP Auto Timer Register */ -#define SP_HDCP_AUTO_TIMER_REG 0x51 - -/* HDCP Key Status Register */ -#define SP_HDCP_KEY_STATUS_REG 0x5e - -/* HDCP Key Command Register */ -#define SP_HDCP_KEY_COMMAND_REG0x5f -#define SP_DISABLE_SYNC_HDCP BIT(2) - -/* OTP Memory Key Protection Registers */ -#define SP_OTP_KEY_PROTECT1_REG0x60 -#define SP_OTP_KEY_PROTECT2_REG0x61 -#define SP_OTP_KEY_PROTECT3_REG0x62 -#define SP_OTP_PSW10xa2 -#define SP_OTP_PSW20x7e -#define SP_OTP_PSW30xc6 - -/* DP System Control Registers */ -#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1) -/* Bits for DP System Control Register 2 */ -#define SP_CHA_STA BIT(2) -/* Bits for DP System Control Register 3 */ -#define SP_HPD_STATUS BIT(6) -#define SP_STRM_VALID BIT(2) -/* Bits for DP System Control Register 4 */ -#define SP_ENHANCED_MODE BIT(3) - -/* DP Video Control Register */ -#define SP_DP_VIDEO_CTRL_REG 0x84 -#define SP_COLOR_F_MASK0x06 -#define SP_COLOR_F_SHIFT 1 -#define SP_BPC_MASK0xe0 -#define SP_BPC_SHIFT 5 -# define SP_BPC_6BITS 0x00 -# define SP_BPC_8BITS 0x01 -# define SP_BPC_10BITS0x02 -# define SP_BPC_12BITS0x03 - -/* DP Audio Control Register */ -#define SP_DP_AUDIO_CTRL_REG 0x87 -#define SP_AUD_EN BIT(0) - -/* 10us Pulse Generate Timer Registers */ -#define SP_I2C_GEN_10US_TIMER0_REG 0x88 -#define SP_I2C_GEN_10US_TIMER1_REG 0x89 - -/* Packet Send Control Register */
Re: [PATCH 2/5] drm/vmgfx: kill off unused init_mutex
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> According to the docs - prevents firstopen/lastclose races. Yet never
> used in practise.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
> 2 files changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index a38f06909fb6..d3f108f7e52d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -664,7 +664,6 @@ static int vmw_driver_load(struct drm_device
> *dev, unsigned long chipset)
> INIT_LIST_HEAD(&dev_priv->res_lru[i]);
> }
>
> - mutex_init(&dev_priv->init_mutex);
> init_waitqueue_head(&dev_priv->fence_queue);
> init_waitqueue_head(&dev_priv->fifo_queue);
> dev_priv->fence_queue_waiters = 0;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 96983c47fb40..9be2176cc260 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -484,11 +484,6 @@ struct vmw_private {
>
> spinlock_t resource_lock;
> struct idr res_idr[vmw_res_max];
> - /*
> - * Block lastclose from racing with firstopen.
> - */
> -
> - struct mutex init_mutex;
>
> /*
>* A resource manager for kernel-only surfaces and
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] vmwgfx: drop empty lastclose stub
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Core DRM is safe when the callback is NULL.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index be25ce9440ad..a38f06909fb6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1200,10 +1200,6 @@ static long vmw_compat_ioctl(struct file
> *filp, unsigned int cmd,
> }
> #endif
>
> -static void vmw_lastclose(struct drm_device *dev)
> -{
> -}
> -
> static void vmw_master_init(struct vmw_master *vmaster)
> {
> ttm_lock_init(&vmaster->lock);
> @@ -1568,7 +1564,6 @@ static struct drm_driver driver = {
> DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER | DRIVER_ATOMIC,
> .load = vmw_driver_load,
> .unload = vmw_driver_unload,
> - .lastclose = vmw_lastclose,
> .get_vblank_counter = vmw_get_vblank_counter,
> .enable_vblank = vmw_enable_vblank,
> .disable_vblank = vmw_disable_vblank,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
Hi, Emil,
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Drop the custom ioctl io encoding check - core drm does it for us.
I fail to see where the core does this, or do I miss something?
Thanks,
Thomas
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 2cb6ae219e43..f65542639b55 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1147,9 +1147,6 @@ static long vmw_generic_ioctl(struct file
> *filp, unsigned int cmd,
> return -EACCES;
> }
>
> - if (unlikely(ioctl->cmd != cmd))
> - goto out_io_encoding;
> -
> flags = ioctl->flags;
> } else if (!drm_ioctl_flags(nr, &flags))
> return -EINVAL;
> @@ -1169,12 +1166,6 @@ static long vmw_generic_ioctl(struct file
> *filp, unsigned int cmd,
> ttm_read_unlock(&vmaster->lock);
>
> return ret;
> -
> -out_io_encoding:
> - DRM_ERROR("Invalid command format, ioctl %d\n",
> - nr - DRM_COMMAND_BASE);
> -
> - return -EINVAL;
> }
>
> static long vmw_unlocked_ioctl(struct file *filp, unsigned int cmd,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: Fix warning about unhandled enum value
Hi, Sean:
On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Fixes the following build warning:
> drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> ‘HDMI_INFOFRAME_TYPE_DRM’ not handled in switch [-Wswitch]
>
> Introduced with the addition of HDMI_INFOFRAME_TYPE_DRM in the commit
> below, but the code really should have been future-proofed from the
> start.
Acked-by: CK Hu
>
> Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
I think "drm: Enable HDR infoframe support" exist only in drm-misc tree,
could you just merge this patch to "drm: Enable HDR infoframe support"?
Regards,
CK
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: "Ville Syrjälä"
> Cc: Hans Verkuil
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index e04e6c293d39..10cc9910f164 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -341,6 +341,9 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi
> *hdmi, u8 *buffer,
> ctrl_frame_en = VS_EN;
> ctrl_reg = GRL_ACP_ISRC_CTRL;
> break;
> + default:
> + dev_err(hdmi->dev, "Unknown infoframe type %d\n", frame_type);
> + return;
> }
> mtk_hdmi_clear_bits(hdmi, ctrl_reg, ctrl_frame_en);
> mtk_hdmi_write(hdmi, GRL_INFOFRM_TYPE, frame_type);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203627] [Regression] Boot fails with linux-firmware 20190514
https://bugzilla.kernel.org/show_bug.cgi?id=203627 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Can you narrow down which firmware file causes the regression? -- 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: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Sean,
On Tue, 21 May 2019 10:51:51 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> between commit:
>
> 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
>
> from Linus' tree and commits:
>
> b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> S9700RTWV43TR-01B")
> fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
>
> from the drm-misc tree.
>
> I fixed it up (I deleted the file and added the patch below) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> From: Stephen Rothwell
> Date: Tue, 21 May 2019 10:48:36 +1000
> Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion
>
> Signed-off-by: Stephen Rothwell
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 83ca4816a78b..749e3c3843d0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -287,6 +287,8 @@ patternProperties:
> description: Everest Semiconductor Co. Ltd.
>"^everspin,.*":
> description: Everspin Technologies, Inc.
> + "^evervision,.*":
> +description: Evervision Electronics Co. Ltd.
>"^exar,.*":
> description: Exar Corporation
>"^excito,.*":
> @@ -851,6 +853,8 @@ patternProperties:
> description: Shenzhen Techstar Electronics Co., Ltd.
>"^terasic,.*":
> description: Terasic Inc.
> + "^tfc,.*":
> +description: Three Five Corp
>"^thine,.*":
> description: THine Electronics, Inc.
>"^ti,.*":
> @@ -925,6 +929,8 @@ patternProperties:
> description: Voipac Technologies s.r.o.
>"^vot,.*":
> description: Vision Optical Technology Co., Ltd.
> + "^vxt,.*"
> +description: VXT Ltd
>"^wd,.*":
> description: Western Digital Corp.
>"^wetek,.*":
> --
> 2.20.1
In doing a back merge of Linus' tree into the drm-misc tree, you seem
to have missed the above merge fixup and so lost some of the changes
from the above commits.
--
Cheers,
Stephen Rothwell
pgpz8b3Dzr4Fa.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()
On Thu, 23 May 2019 at 01:03, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Cc: Ben Skeggs
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Emil Velikov
Thanks!
> ---
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 --
> drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> 3 files changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index c3fd5dd39ed9..0c585dc5f5c3 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -244,12 +244,6 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
> return 0;
> }
>
> -int
> -nouveau_abi16_ioctl_setparam(ABI16_IOCTL_ARGS)
> -{
> - return -EINVAL;
> -}
> -
> int
> nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
> {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
> b/drivers/gpu/drm/nouveau/nouveau_abi16.h
> index 36fde1ff3ad5..9275d529b947 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
> @@ -6,7 +6,6 @@
> struct drm_device *dev, void *data, struct drm_file *file_priv
>
> int nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS);
> -int nouveau_abi16_ioctl_setparam(ABI16_IOCTL_ARGS);
> int nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS);
> int nouveau_abi16_ioctl_channel_free(ABI16_IOCTL_ARGS);
> int nouveau_abi16_ioctl_grobj_alloc(ABI16_IOCTL_ARGS);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 22cd45845e07..ed45ad2b72f2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -1046,7 +1046,7 @@ nouveau_drm_postclose(struct drm_device *dev, struct
> drm_file *fpriv)
> static const struct drm_ioctl_desc
> nouveau_ioctls[] = {
> DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, drm_invalid_op,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC,
> nouveau_abi16_ioctl_channel_alloc, DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE,
> nouveau_abi16_ioctl_channel_free, DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC,
> nouveau_abi16_ioctl_grobj_alloc, DRM_AUTH|DRM_RENDER_ALLOW),
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
include/drm/drm_mode_config.h
between commit:
585b000de23b ("drm: move content protection property to mode_config")
from the drm-intel tree and commit:
fbb5d0353c62 ("drm: Add HDR source metadata property")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/drm/drm_mode_config.h
index 5764ee3c7453,c031b5a9d8d1..
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@@ -836,12 -836,13 +836,19 @@@ struct drm_mode_config
*/
struct drm_property *writeback_out_fence_ptr_property;
+ /**
+ * @content_protection_property: DRM ENUM property for content
+ * protection. See drm_connector_attach_content_protection_property().
+ */
+ struct drm_property *content_protection_property;
+
+ /**
+* hdr_output_metadata_property: Connector property containing hdr
+* metatda. This will be provided by userspace compositors based
+* on HDR content
+*/
+ struct drm_property *hdr_output_metadata_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
pgp0Rl7jxd7UG.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_atomic_uapi.c
between commit:
585b000de23b ("drm: move content protection property to mode_config")
from the drm-intel tree and commit:
fbb5d0353c62 ("drm: Add HDR source metadata property")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_atomic_uapi.c
index 4131e669785a,125605ff45af..
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@@ -814,7 -823,10 +823,10 @@@ drm_atomic_connector_get_property(struc
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdr_output_metadata_property) {
+ *val = state->hdr_output_metadata ?
+ state->hdr_output_metadata->base.id : 0;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
pgpCZ8_Jszw0A.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: dw_hdmi: add basic rk3228 support
Like the RK3328, RK322x SoCs offer a Synopsis DesignWare HDMI transmitter
and an Innosilicon HDMI PHY.
Add a new dw_hdmi_plat_data struct, rk3228_hdmi_drv_data.
Assign a set of mostly generic rk3228_hdmi_phy_ops functions.
Add dw_hdmi_rk3228_setup_hpd() to enable the HDMI HPD and DDC lines.
Signed-off-by: Justin Swartz
---
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 53 ++
2 files changed, 54 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 39143424a..703503103 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -12,6 +12,7 @@ following device-specific properties.
Required properties:
- compatible: should be one of the following:
+ "rockchip,rk3228-dw-hdmi"
"rockchip,rk3288-dw-hdmi"
"rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 4cdc9f86c..182a852af 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -23,6 +23,14 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
+#define RK3228_GRF_SOC_CON20x0408
+#define RK3228_HDMI_SDAIN_MSK BIT(14)
+#define RK3228_HDMI_SCLIN_MSK BIT(13)
+#define RK3228_GRF_SOC_CON60x0418
+#define RK3228_HDMI_HPD_VSEL BIT(6)
+#define RK3228_HDMI_SDA_VSEL BIT(5)
+#define RK3228_HDMI_SCL_VSEL BIT(4)
+
#define RK3288_GRF_SOC_CON60x025C
#define RK3288_HDMI_LCDC_SEL BIT(4)
#define RK3328_GRF_SOC_CON20x0408
@@ -325,6 +333,25 @@ static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi
*dw_hdmi, void *data)
phy_power_off(hdmi->phy);
}
+static void dw_hdmi_rk3228_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+ regmap_write(hdmi->regmap,
+ RK3228_GRF_SOC_CON6,
+ HIWORD_UPDATE(RK3228_HDMI_HPD_VSEL | RK3228_HDMI_SDA_VSEL |
+ RK3228_HDMI_SCL_VSEL,
+ RK3228_HDMI_HPD_VSEL | RK3228_HDMI_SDA_VSEL |
+ RK3228_HDMI_SCL_VSEL));
+
+ regmap_write(hdmi->regmap,
+ RK3228_GRF_SOC_CON2,
+ HIWORD_UPDATE(RK3228_HDMI_SDAIN_MSK | RK3228_HDMI_SCLIN_MSK,
+ RK3228_HDMI_SDAIN_MSK | RK3228_HDMI_SCLIN_MSK));
+}
+
static enum drm_connector_status
dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
{
@@ -370,6 +397,29 @@ static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi
*dw_hdmi, void *data)
RK3328_HDMI_HPD_IOE));
}
+static const struct dw_hdmi_phy_ops rk3228_hdmi_phy_ops = {
+ .init = dw_hdmi_rockchip_genphy_init,
+ .disable= dw_hdmi_rockchip_genphy_disable,
+ .read_hpd = dw_hdmi_phy_read_hpd,
+ .update_hpd = dw_hdmi_phy_update_hpd,
+ .setup_hpd = dw_hdmi_rk3228_setup_hpd,
+};
+
+static struct rockchip_hdmi_chip_data rk3228_chip_data = {
+ .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
+ .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mpll_cfg = rockchip_mpll_cfg,
+ .cur_ctr = rockchip_cur_ctr,
+ .phy_config = rockchip_phy_config,
+ .phy_data = &rk3228_chip_data,
+ .phy_ops = &rk3228_hdmi_phy_ops,
+ .phy_name = "inno_dw_hdmi_phy2",
+ .phy_force_vendor = true,
+};
+
static struct rockchip_hdmi_chip_data rk3288_chip_data = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_HDMI_LCDC_SEL),
@@ -422,6 +472,9 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data
= {
};
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
+ { .compatible = "rockchip,rk3228-dw-hdmi",
+ .data = &rk3228_hdmi_drv_data
+ },
{ .compatible = "rockchip,rk3288-dw-hdmi",
.data = &rk3288_hdmi_drv_data
},
--
2.11.0
[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another
https://bugs.freedesktop.org/show_bug.cgi?id=108824 --- Comment #14 from raffa...@zoho.com --- The patch fixes corruption caused by 78e35df52aa2f7d770f929a0866a0faa89c261a9 but not the one from 12bf7cfecf52083c484602f971738475edfe497e, which still persists in scroll bars of falkon and akregator. I'm using an RX 480. -- 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 110733] [Regression] Kernel 4.19.x + linux-firmware 20190514 + Vega 64: boot fails
https://bugs.freedesktop.org/show_bug.cgi?id=110733 Bug ID: 110733 Summary: [Regression] Kernel 4.19.x + linux-firmware 20190514 + Vega 64: boot fails Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mezin.alexan...@gmail.com Copying https://bugzilla.kernel.org/show_bug.cgi?id=203627 here, as I'm not sure where to report the issue (and got no response in kernel bugzilla so far) After linux-firmware upgrade from 4b6cf2bd1a9d53caa087403d943e7695009c1d0c to 711d3297bac870af42088a467459a0634c1970ca (20190514), 4.19 kernels (at least 4.19.40-4.19.45) don't boot anymore. Early during boot the monitor turns off, and, apparently, the system hangs. Can't connect over SSH, SysRq keys don't work. Also the failed boot attempt doesn't get recorded by journald. Kernels 5.0 and 5.1 still boot completely fine. Also, 4.19 kernels boot if I downgrade firmware back to 4b6cf2bd1a9d53caa087403d943e7695009c1d0c. Apparently, these problems are caused by https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=2579167548be33afb1fe2a9a5c141561ee5a8bbe GPU: RX Vega 64 (Sapphire Nitro+, vbios_version: 113-D0500110-O01) Distro: Arch Linux Archlinux bug: https://bugs.archlinux.org/task/62666 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
+Bjorn Helgaas On Wed, May 15, 2019 at 12:41 AM Daniel Vetter wrote: > > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote: > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote: > > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins > > > wrote: > > > > > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > > > > However, the reply is incorrect. Kselftest in-kernel tests (which > > > > > > > is the context here) can be configured as built in instead of as > > > > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > > > > running the in-kernel tests before UML attempts to invoke the > > > > > > > init process. > > > > > > > > > > > > Um, Citation needed? > > > > > > > > > > > > I don't see any evidence for this in the kselftest documentation, > > > > > > nor > > > > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > > > > > > > There exists test modules in the kernel that run before the init > > > > > > scripts run --- but that's not strictly speaking part of kselftests, > > > > > > and do not have any kind of infrastructure. As noted, the > > > > > > kselftests_harness header file fundamentally assumes that you are > > > > > > running test code in userspace. > > > > > > > > > > Yeah I really like the "no userspace required at all" design of kunit, > > > > > while still collecting results in a well-defined way (unless the > > > > > current > > > > > self-test that just run when you load the module, with maybe some > > > > > kselftest ad-hoc wrapper around to collect the results). > > > > > > > > > > What I want to do long-term is to run these kernel unit tests as part > > > > > of > > > > > the build-testing, most likely in gitlab (sooner or later, for drm.git > > > > > > > > Totally! This is part of the reason I have been insisting on a minimum > > > > of UML compatibility for all unit tests. If you can suffiently constrain > > > > the environment that is required for tests to run in, it makes it much > > > > easier not only for a human to run your tests, but it also makes it a > > > > lot easier for an automated service to be able to run your tests. > > > > > > > > I actually have a prototype presubmit already working on my > > > > "stable/non-upstream" branch. You can checkout what presubmit results > > > > look like here[1][2]. > > > > > > ug gerrit :-) > > > > Yeah, yeah, I know, but it is a lot easier for me to get a project set > > up here using Gerrit, when we already use that for a lot of other > > projects. > > > > Also, Gerrit has gotten a lot better over the last two years or so. Two > > years ago, I wouldn't touch it with a ten foot pole. It's not so bad > > anymore, at least if you are used to using a web UI to review code. > > I was somewhat joking, I'm just not used to gerrit ... And seems to indeed > be a lot more polished than last time I looked at it seriously. I mean, it is still not perfect, but I think it has finally gotten to the point where I prefer it over reviewing by email for high context patches where you don't expect a lot of deep discussion. Still not great for patches where you want to have a lot of discussion. > > > > > only ofc). So that people get their pull requests (and patch series, > > > > > we > > > > > have some ideas to tie this into patchwork) automatically tested for > > > > > this > > > > > > > > Might that be Snowpatch[3]? I talked to Russell, the creator of > > > > Snowpatch, > > > > and he seemed pretty open to collaboration. > > > > > > > > Before I heard about Snowpatch, I had an intern write a translation > > > > layer that made Prow (the presubmit service that I used in the prototype > > > > above) work with LKML[4]. > > > > > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have > > > a different one on freedesktop.org. It's a bit a mess :-/ I think Snowpatch is an ozlabs project; at least the maintainer works at IBM. Patchwork originally was a ozlabs project, right? Has any discussion taken place trying to consolidate some of the forks? Presubmit clearly seems like a feature that a number of people want. > > Oh, I didn't realize that. I found your patchwork instance here[5], but > > do you have a place where I can see the changes you have added to > > support presubmit? > > Ok here's a few links. Aside from the usual patch view we've also added a > series view: > > https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated > > This ties the patches + cover letter together, and it even (tries to at > least) track revisions. Here's an example which is currently at revision > 9: > > https://patchwork.freedesktop.org/series/57232/ Oooh, nice! That looks awesome! Looks like you have a number of presubmits too. > Below the patch list for each revision we als
[Bug 203679] Revert 8059add0478e29cb641936011a8fcc9ce9fd80be for stable 5.1.x
https://bugzilla.kernel.org/show_bug.cgi?id=203679 Dmitry (nrn...@gmail.com) changed: What|Removed |Added URL||https://git.kernel.org/pub/ ||scm/linux/kernel/git/torval ||ds/linux.git/commit/?id=dbb ||92471674a48892f5e50779425e0 ||3388073ab9 Regression|No |Yes -- 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 203679] New: Revert 8059add0478e29cb641936011a8fcc9ce9fd80be for stable 5.1.x
https://bugzilla.kernel.org/show_bug.cgi?id=203679 Bug ID: 203679 Summary: Revert 8059add0478e29cb641936011a8fcc9ce9fd80be for stable 5.1.x Product: Drivers Version: 2.5 Kernel Version: 5.1.x Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: nrn...@gmail.com Regression: No Original commit 8059add0478e29cb641936011a8fcc9ce9fd80be (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_ioctl.c?id=8059add0478e29cb641936011a8fcc9ce9fd80be) was added in 5.1 merge cycle and reverted by dbb92471674a48892f5e50779425e03388073ab9 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dbb92471674a48892f5e50779425e03388073ab9) in 5.2. So radv is still broken in 5.1. -- 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
[pull] amdgpu, amdkfd drm-fixes-5.2
Hi Dave, Daniel, Fixes for 5.2: - Fix for DMCU firmware issues for stable - Add missing polaris10 pci id to kfd - Screen corruption fix on picasso - Fix for driver reload on vega10 - SR-IOV fixes - Locking fix in new SMU code - Compute profile switching fix for KFD The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-5.2 for you to fetch changes up to 43d8107f0bdcaa4300e40231cc45ecbd1f77f73f: drm/amdkfd: Fix compute profile switching (2019-05-20 21:22:49 -0500) Alex Deucher (2): drm/amdgpu/soc15: skip reset on init drm/amdgpu/gmc9: set vram_width properly for SR-IOV Dan Carpenter (1): drm/amd/powerplay: fix locking in smu_feature_set_supported() Flora Cui (1): drm/amdgpu: keep stolen memory on picasso Harish Kasiviswanathan (1): drm/amdkfd: Fix compute profile switching Harry Wentland (2): drm/amd/display: Add ASICREV_IS_PICASSO drm/amd/display: Don't load DMCU for Raven 1 Kent Russell (1): drm/amdkfd: Add missing Polaris10 ID Yintian Tao (1): drm/amdgpu: skip fw pri bo alloc for SRIOV drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 17 ++--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 ++- drivers/gpu/drm/amd/amdgpu/soc15.c| 5 + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 17 + drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 ++- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 7 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++-- drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 2 +- 9 files changed, 70 insertions(+), 19 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On Wed, May 22, 2019 at 2:41 PM Clément Péron wrote: > > Hi Rob, > > On Wed, 22 May 2019 at 21:27, Rob Herring wrote: > > > > On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote: > > > > > > Hi, > > > > > > The Allwinner H6 has a Mali-T720 MP2 which should be supported by > > > the new panfrost driver. This series fix two issues and introduce the > > > dt-bindings but a simple benchmark show that it's still NOT WORKING. > > > > > > I'm pushing it in case someone want to continue the work. > > > > > > This has been tested with Mesa3D 19.1.0-RC2 and a GPU bitness patch[1]. > > > > > > One patch is from Icenowy Zheng where I changed the order as required > > > by Rob Herring[2]. > > > > > > Thanks, > > > Clement > > > > > > [1] https://gitlab.freedesktop.org/kszaq/mesa/tree/panfrost_64_32 > > > [2] https://patchwork.kernel.org/patch/10699829/ > > > > > > > > > [ 345.204813] panfrost 180.gpu: mmu irq status=1 > > > [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > 0x02400400 > > > [ 345.209617] Reason: TODO > > > [ 345.209617] raw fault status: 0x82C1 > > > [ 345.209617] decoded fault status: SLAVE FAULT > > > [ 345.209617] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 > > > [ 345.209617] access type 0x2: READ > > > [ 345.209617] source id 0x8000 > > > [ 345.729957] panfrost 180.gpu: gpu sched timeout, js=0, > > > status=0x8, head=0x2400400, tail=0x2400400, sched_job=9e204de9 > > > [ 346.055876] panfrost 180.gpu: mmu irq status=1 > > > [ 346.060680] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > 0x02C00A00 > > > [ 346.060680] Reason: TODO > > > [ 346.060680] raw fault status: 0x810002C1 > > > [ 346.060680] decoded fault status: SLAVE FAULT > > > [ 346.060680] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 > > > [ 346.060680] access type 0x2: READ > > > [ 346.060680] source id 0x8100 > > > [ 346.561955] panfrost 180.gpu: gpu sched timeout, js=1, > > > status=0x8, head=0x2c00a00, tail=0x2c00a00, sched_job=b55a9a85 > > > [ 346.573913] panfrost 180.gpu: mmu irq status=1 > > > [ 346.578707] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > 0x02C00B80 > > > > > > Change in v5: > > > - Remove fix indent > > > > > > Changes in v4: > > > - Add bus_clock probe > > > - Fix sanity check in io-pgtable > > > - Add vramp-delay > > > - Merge all boards into one patch > > > - Remove upstreamed Neil A. patch > > > > > > Change in v3 (Thanks to Maxime Ripard): > > > - Reauthor Icenowy for her path > > > > > > Changes in v2 (Thanks to Maxime Ripard): > > > - Drop GPU OPP Table > > > - Add clocks and clock-names in required > > > > > > Clément Péron (5): > > > drm: panfrost: add optional bus_clock > > > iommu: io-pgtable: fix sanity check for non 48-bit mali iommu > > > dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible > > > arm64: dts: allwinner: Add ARM Mali GPU node for H6 > > > arm64: dts: allwinner: Add mali GPU supply for H6 boards > > > > > > Icenowy Zheng (1): > > > dt-bindings: gpu: add bus clock for Mali Midgard GPUs > > > > I've applied patches 1 and 3 to drm-misc. I was going to do patch 4 > > too, but it doesn't apply. > > Thanks, > > I have tried to applied on drm-misc/for-linux-next but it doesn't apply too. > It looks like commit d5ff1adb3809e2f74a3b57cea2e57c8e37d693c4 is > missing on drm-misc ? > https://github.com/torvalds/linux/commit/d5ff1adb3809e2f74a3b57cea2e57c8e37d693c4#diff-c3172f5d421d492ff91d7bb44dd44917 5.2-rc1 is merged in now and I've applied patch 4. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
> The two hard requirements I have for supporting any new hardware feature
> in Linux are (1) a single kernel image binary continues to run on old
> hardware while making use of the new feature if available and (2) old
> user space continues to run on new hardware while new user space can
> take advantage of the new feature.
Agreed! And I think the series meets these requirements, yes?
> For MTE, we just can't enable it by default since there are applications
> who use the top byte of a pointer and expect it to be ignored rather
> than failing with a mismatched tag. Just think of a hwasan compiled
> binary where TBI is expected to work and you try to run it with MTE
> turned on.
Ah! Okay, here's the use-case I wasn't thinking of: the concern is TBI
conflicting with MTE. And anything that starts using TBI suddenly can't
run in the future because it's being interpreted as MTE bits? (Is that
the ABI concern? I feel like we got into the weeds about ioctl()s and
one-off bugs...)
So there needs to be some way to let the kernel know which of three
things it should be doing:
1- leaving userspace addresses as-is (present)
2- wiping the top bits before using (this series)
3- wiping the top bits for most things, but retaining them for MTE as
needed (the future)
I expect MTE to be the "default" in the future. Once a system's libc has
grown support for it, everything will be trying to use MTE. TBI will be
the special case (but TBI is effectively a prerequisite).
AFAICT, the only difference I see between 2 and 3 will be the tag handling
in usercopy (all other places will continue to ignore the top bits). Is
that accurate?
Is "1" a per-process state we want to keep? (I assume not, but rather it
is available via no TBI/MTE CONFIG or a boot-time option, if at all?)
To choose between "2" and "3", it seems we need a per-process flag to
opt into TBI (and out of MTE). For userspace, how would a future binary
choose TBI over MTE? If it's a library issue, we can't use an ELF bit,
since the choice may be "late" after ELF load (this implies the need
for a prctl().) If it's binary-only ("built with HWKASan") then an ELF
bit seems sufficient. And without the marking, I'd expect the kernel to
enforce MTE when there are high bits.
> I would also expect the C library or dynamic loader to check for the
> presence of a HWCAP_MTE bit before starting to tag memory allocations,
> otherwise it would get SIGILL on the first MTE instruction it tries to
> execute.
I've got the same question as Elliot: aren't MTE instructions just NOP
to older CPUs? I.e. if the CPU (or kernel) don't support it, it just
gets entirely ignored: checking is only needed to satisfy curiosity
or behavioral expectations.
To me, the conflict seems to be using TBI in the face of expecting MTE to
be the default state of the future. (But the internal changes needed
for TBI -- this series -- is a prereq for MTE.)
--
Kees Cook
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
On Thu, May 16, 2019 at 07:40:05PM +0530, Uma Shankar wrote: > This patch series enables HDR support in drm. It basically defines > HDR metadata structures, property to pass content (after blending) > metadata from user space compositors to driver. > > Dynamic Range and Mastering infoframe creation and sending. > > ToDo: > 1. We need to get the color framework in place for all planes >which support HDR content in hardware. This is already in progres >and patches are out for review in mailing list. > 2. UserSpace/Compositors: Blending policies and metadata blob >creation and passing to driver. Work is already in progress >by Intel's middleware teams on wayland and the patches for >the same are in review. > > A POC has already been developed by Ville based on wayland. Please refer > below link to see the component interactions and usage: > https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html > > v2: Updated Ville's POC changes to the patch series.Incorporated cleanups > and fixes from Ville. Rebase on latest drm-tip. > > v3: Fixed a warning causing builds to break on CI. No major change. > > v4: Addressed Shashank's review comments. > > v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset > case for HDR metadata update. Dropped a redundant patch. > > v6: Addressed Shashank's review comments and added RB's received. > > v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and > Shashank's review comments. > > v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the > series, > fixed a WARN_ON on BYT/CHT. > > v9: Addressed Ville and Jonas Karlman's review comments. Added the infoframe > state readout and metadata reference count. > > v10: Addressed review comments from Jonas and Ville. Dropped one patch related > to i915 fastset handling as per Ville's feedback. > > v11: Addressed Ville's review comments. > > Note: v9 version is already tested with Kodi and a confirmation from team > kodi has been > received. Branch details for the same as below: > https://github.com/xbmc/xbmc/tree/feature_drmprime-vaapi > > v9 of this series is: > Tested-by: Jonas Karlman > > Jonas Karlman (1): > drm: Add reference counting on HDR metadata blob > > Uma Shankar (9): > drm: Add HDR source metadata property > drm: Parse HDR metadata info from EDID > drm: Enable HDR infoframe support > drm/i915: Attach HDR metadata property to connector > drm/i915: Write HDR infoframe and send to panel > drm/i915:Enabled Modeset when HDR Infoframe changes > drm/i915: Added DRM Infoframe handling for BYT/CHT > video/hdmi: Add Unpack function for DRM infoframe > drm/i915: Add state readout for DRM infoframe > > Ville Syrjälä (2): > drm: Add HLG EOTF > drm/i915: Enable infoframes on GLK+ for HDR Pushed the core/etc. bits to drm-misc-next so that other drivers can base their work on that. We'll need a backmerge to get the i915 stuff in via dinq. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: Fix warning about unhandled enum value
From: Sean Paul
Fixes the following build warning:
drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
‘HDMI_INFOFRAME_TYPE_DRM’ not handled in switch [-Wswitch]
Introduced with the addition of HDMI_INFOFRAME_TYPE_DRM in the commit
below, but the code really should have been future-proofed from the
start.
Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Ville Syrjälä"
Cc: Hans Verkuil
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index e04e6c293d39..10cc9910f164 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -341,6 +341,9 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi
*hdmi, u8 *buffer,
ctrl_frame_en = VS_EN;
ctrl_reg = GRL_ACP_ISRC_CTRL;
break;
+ default:
+ dev_err(hdmi->dev, "Unknown infoframe type %d\n", frame_type);
+ return;
}
mtk_hdmi_clear_bits(hdmi, ctrl_reg, ctrl_frame_en);
mtk_hdmi_write(hdmi, GRL_INFOFRM_TYPE, frame_type);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Da.*, First -fixes pull, predictably light. The merge here was bringing over some sun4i patches that missed the last -misc-next-fixes pull. drm-misc-fixes-2019-05-22: - sun4i fixes to hdmi phy as well as u16 overflow in dsi (left from -next-fixes) - gma500 fix to make lvds detection more reliable - select devfreq for panfrost since it can't probe without it Cheers, Sean The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-05-22 for you to fetch changes up to f3617b449d0bcf3b5d80a97f51498dcf7463cf7e: drm/panfrost: Select devfreq (2019-05-22 13:05:13 -0500) - sun4i fixes to hdmi phy as well as u16 overflow in dsi (left from -next-fixes) - gma500 fix to make lvds detection more reliable - select devfreq for panfrost since it can't probe without it Ezequiel Garcia (1): drm/panfrost: Select devfreq Jagan Teki (1): drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow Jernej Skrabec (2): drm/sun4i: Fix sun8i HDMI PHY clock initialization drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz Patrik Jakobsson (1): drm/gma500/cdv: Check vbt config bits when detecting lvds panels Sean Paul (1): Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++ drivers/gpu/drm/gma500/intel_bios.c | 3 +++ drivers/gpu/drm/gma500/psb_drv.h| 1 + drivers/gpu/drm/panfrost/Kconfig| 1 + drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 ++--- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 5 +++-- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 29 - 7 files changed, 29 insertions(+), 26 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
Can you explain how this avoids OOM situations? When is it safe to leave
a reserved BO on the LRU list? Could we do the same thing in
amdgpu_amdkfd_gpuvm.c? And if we did, what would be the expected side
effects or consequences?
Thanks,
Felix
On 2019-05-22 8:59 a.m., Christian König wrote:
> [CAUTION: External Email]
>
> This avoids OOM situations when we have lots of threads
> submitting at the same time.
>
> v3: apply this to the whole driver, not just CS
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 20f2955d2a55..3e2da24cd17a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
> *p,
> }
>
> r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
> - &duplicates, true);
> + &duplicates, false);
> if (unlikely(r != 0)) {
> if (r != -ERESTARTSYS)
> DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> index 06f83cac0d3a..f660628e6af9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> @@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
> struct amdgpu_vm *vm,
> list_add(&csa_tv.head, &list);
> amdgpu_vm_get_pd_bo(vm, &list, &pd);
>
> - r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, true);
> + r = ttm_eu_reserve_buffers(&ticket, &list, true, NULL, false);
> if (r) {
> DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
> return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index d513a5ad03dd..ed25a4e14404 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
>
> amdgpu_vm_get_pd_bo(vm, &list, &vm_pd);
>
> - r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, true);
> + r = ttm_eu_reserve_buffers(&ticket, &list, false, &duplicates, false);
> if (r) {
> dev_err(adev->dev, "leaking bo va because "
> "we fail to reserve bo (%d)\n", r);
> @@ -608,7 +608,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> *data,
>
> amdgpu_vm_get_pd_bo(&fpriv->vm, &list, &vm_pd);
>
> - r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates, true);
> + r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates, false);
> if (r)
> goto error_unref;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index c430e8259038..d60593cc436e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -155,7 +155,7 @@ static inline int amdgpu_bo_reserve(struct amdgpu_bo *bo,
> bool no_intr)
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> int r;
>
> - r = ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
> + r = __ttm_bo_reserve(&bo->tbo, !no_intr, false, NULL);
> if (unlikely(r != 0)) {
> if (r != -ERESTARTSYS)
> dev_err(adev->dev, "%p reserve failed\n", bo);
> --
> 2.17.1
>
> ___
> 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
Re: [PATCH] drm/panfrost: Select devfreq
On Fri, May 17, 2019 at 10:33 AM Neil Armstrong wrote: > > On 17/05/2019 17:00, Ezequiel Garcia wrote: > > Currently, there is some logic for the driver to work without devfreq. > > However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. > > > > Fix this by selecting devfreq, and drop the additional checks > > for devfreq. > > > > Please add a Fixes tag. I applied this, but forgot the Fixes tag. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110575] [R9 380X] Artifacts in CSGO
https://bugs.freedesktop.org/show_bug.cgi?id=110575 --- Comment #5 from Danylo --- It helps, unfortunately it also reduces fps by around 15 - 20% -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 029/244] drm/nouveau/bar/nv50: ensure BAR is mapped
From: Jon Derrick [ Upstream commit f10b83de1fd49216a4c657816f48001437e4bdd5 ] If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by: Jon Derrick Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c index 157b076a12723..38c9c086754b6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c @@ -109,7 +109,7 @@ nv50_bar_oneinit(struct nvkm_bar *base) struct nvkm_device *device = bar->base.subdev.device; static struct lock_class_key bar1_lock; static struct lock_class_key bar2_lock; - u64 start, limit; + u64 start, limit, size; int ret; ret = nvkm_gpuobj_new(device, 0x2, 0, false, NULL, &bar->mem); @@ -127,7 +127,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR2 */ start = 0x01ULL; - limit = start + device->func->resource_size(device, 3); + size = device->func->resource_size(device, 3); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar2_lock, "bar2", &bar->bar2_vmm); @@ -164,7 +167,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR1 */ start = 0x00ULL; - limit = start + device->func->resource_size(device, 1); + size = device->func->resource_size(device, 1); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar1_lock, "bar1", &bar->bar1_vmm); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote: > > Hi, > > The Allwinner H6 has a Mali-T720 MP2 which should be supported by > the new panfrost driver. This series fix two issues and introduce the > dt-bindings but a simple benchmark show that it's still NOT WORKING. > > I'm pushing it in case someone want to continue the work. > > This has been tested with Mesa3D 19.1.0-RC2 and a GPU bitness patch[1]. > > One patch is from Icenowy Zheng where I changed the order as required > by Rob Herring[2]. > > Thanks, > Clement > > [1] https://gitlab.freedesktop.org/kszaq/mesa/tree/panfrost_64_32 > [2] https://patchwork.kernel.org/patch/10699829/ > > > [ 345.204813] panfrost 180.gpu: mmu irq status=1 > [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > 0x02400400 > [ 345.209617] Reason: TODO > [ 345.209617] raw fault status: 0x82C1 > [ 345.209617] decoded fault status: SLAVE FAULT > [ 345.209617] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 > [ 345.209617] access type 0x2: READ > [ 345.209617] source id 0x8000 > [ 345.729957] panfrost 180.gpu: gpu sched timeout, js=0, > status=0x8, head=0x2400400, tail=0x2400400, sched_job=9e204de9 > [ 346.055876] panfrost 180.gpu: mmu irq status=1 > [ 346.060680] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > 0x02C00A00 > [ 346.060680] Reason: TODO > [ 346.060680] raw fault status: 0x810002C1 > [ 346.060680] decoded fault status: SLAVE FAULT > [ 346.060680] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 > [ 346.060680] access type 0x2: READ > [ 346.060680] source id 0x8100 > [ 346.561955] panfrost 180.gpu: gpu sched timeout, js=1, > status=0x8, head=0x2c00a00, tail=0x2c00a00, sched_job=b55a9a85 > [ 346.573913] panfrost 180.gpu: mmu irq status=1 > [ 346.578707] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > 0x02C00B80 > > Change in v5: > - Remove fix indent > > Changes in v4: > - Add bus_clock probe > - Fix sanity check in io-pgtable > - Add vramp-delay > - Merge all boards into one patch > - Remove upstreamed Neil A. patch > > Change in v3 (Thanks to Maxime Ripard): > - Reauthor Icenowy for her path > > Changes in v2 (Thanks to Maxime Ripard): > - Drop GPU OPP Table > - Add clocks and clock-names in required > > Clément Péron (5): > drm: panfrost: add optional bus_clock > iommu: io-pgtable: fix sanity check for non 48-bit mali iommu > dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible > arm64: dts: allwinner: Add ARM Mali GPU node for H6 > arm64: dts: allwinner: Add mali GPU supply for H6 boards > > Icenowy Zheng (1): > dt-bindings: gpu: add bus clock for Mali Midgard GPUs I've applied patches 1 and 3 to drm-misc. I was going to do patch 4 too, but it doesn't apply. Patch 2 can go in via the iommu tree and the rest via the allwinner tree. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 037/317] drm/nouveau/bar/nv50: ensure BAR is mapped
From: Jon Derrick [ Upstream commit f10b83de1fd49216a4c657816f48001437e4bdd5 ] If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by: Jon Derrick Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c index 157b076a12723..38c9c086754b6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c @@ -109,7 +109,7 @@ nv50_bar_oneinit(struct nvkm_bar *base) struct nvkm_device *device = bar->base.subdev.device; static struct lock_class_key bar1_lock; static struct lock_class_key bar2_lock; - u64 start, limit; + u64 start, limit, size; int ret; ret = nvkm_gpuobj_new(device, 0x2, 0, false, NULL, &bar->mem); @@ -127,7 +127,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR2 */ start = 0x01ULL; - limit = start + device->func->resource_size(device, 3); + size = device->func->resource_size(device, 3); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar2_lock, "bar2", &bar->bar2_vmm); @@ -164,7 +167,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR1 */ start = 0x00ULL; - limit = start + device->func->resource_size(device, 1); + size = device->func->resource_size(device, 1); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar1_lock, "bar1", &bar->bar1_vmm); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.1 043/375] drm/nouveau/bar/nv50: ensure BAR is mapped
From: Jon Derrick [ Upstream commit f10b83de1fd49216a4c657816f48001437e4bdd5 ] If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by: Jon Derrick Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c index 157b076a12723..38c9c086754b6 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c @@ -109,7 +109,7 @@ nv50_bar_oneinit(struct nvkm_bar *base) struct nvkm_device *device = bar->base.subdev.device; static struct lock_class_key bar1_lock; static struct lock_class_key bar2_lock; - u64 start, limit; + u64 start, limit, size; int ret; ret = nvkm_gpuobj_new(device, 0x2, 0, false, NULL, &bar->mem); @@ -127,7 +127,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR2 */ start = 0x01ULL; - limit = start + device->func->resource_size(device, 3); + size = device->func->resource_size(device, 3); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar2_lock, "bar2", &bar->bar2_vmm); @@ -164,7 +167,10 @@ nv50_bar_oneinit(struct nvkm_bar *base) /* BAR1 */ start = 0x00ULL; - limit = start + device->func->resource_size(device, 1); + size = device->func->resource_size(device, 1); + if (!size) + return -ENOMEM; + limit = start + size; ret = nvkm_vmm_new(device, start, limit-- - start, NULL, 0, &bar1_lock, "bar1", &bar->bar1_vmm); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
On Wed, May 22, 2019 at 08:30:21AM -0700, enh wrote:
> On Wed, May 22, 2019 at 3:11 AM Catalin Marinas
> wrote:
> > On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > > I just want to make sure I fully understand your concern about this
> > > being an ABI break, and I work best with examples. The closest situation
> > > I can see would be:
> > >
> > > - some program has no idea about MTE
> >
> > Apart from some libraries like libc (and maybe those that handle
> > specific device ioctls), I think most programs should have no idea about
> > MTE. I wouldn't expect programmers to have to change their app just
> > because we have a new feature that colours heap allocations.
Right -- things should Just Work from the application perspective.
> obviously i'm biased as a libc maintainer, but...
>
> i don't think it helps to move this to libc --- now you just have an
> extra dependency where to have a guaranteed working system you need to
> update your kernel and libc together. (or at least update your libc to
> understand new ioctls etc _before_ you can update your kernel.)
I think (hope?) we've all agreed that we shouldn't pass this off to
userspace. At the very least, it reduces the utility of MTE, and at worst
it complicates userspace when this is clearly a kernel/architecture issue.
>
> > > - malloc() starts returning MTE-tagged addresses
> > > - program doesn't break from that change
> > > - program uses some syscall that is missing untagged_addr() and fails
> > > - kernel has now broken userspace that used to work
> >
> > That's one aspect though probably more of a case of plugging in a new
> > device (graphics card, network etc.) and the ioctl to the new device
> > doesn't work.
I think MTE will likely be rather like NX/PXN and SMAP/PAN: there will
be glitches, and we can disable stuff either via CONFIG or (as is more
common now) via a kernel commandline with untagged_addr() containing a
static branch, etc. But I actually don't think we need to go this route
(see below...)
> > The other is that, assuming we reach a point where the kernel entirely
> > supports this relaxed ABI, can we guarantee that it won't break in the
> > future. Let's say some subsequent kernel change (some refactoring)
> > misses out an untagged_addr(). This renders a previously TBI/MTE-capable
> > syscall unusable. Can we rely only on testing?
> >
> > > The trouble I see with this is that it is largely theoretical and
> > > requires part of userspace to collude to start using a new CPU feature
> > > that tickles a bug in the kernel. As I understand the golden rule,
> > > this is a bug in the kernel (a missed ioctl() or such) to be fixed,
> > > not a global breaking of some userspace behavior.
> >
> > Yes, we should follow the rule that it's a kernel bug but it doesn't
> > help the user that a newly installed kernel causes user space to no
> > longer reach a prompt. Hence the proposal of an opt-in via personality
> > (for MTE we would need an explicit opt-in by the user anyway since the
> > top byte is no longer ignored but checked against the allocation tag).
>
> but realistically would this actually get used in this way? or would
> any given system either be MTE or non-MTE. in which case a kernel
> configuration option would seem to make more sense. (because either
> way, the hypothetical user basically needs to recompile the kernel to
> get back on their feet. or all of userspace.)
Right: the point is to design things so that we do our best to not break
userspace that is using the new feature (which I think this series has
done well). But supporting MTE/TBI is just like supporting PAN: if someone
refactors a driver and swaps a copy_from_user() to a memcpy(), it's going
to break under PAN. There will be the same long tail of these bugs like
any other, but my sense is that they are small and rare. But I agree:
they're going to be pretty weird bugs to track down. The final result,
however, will be excellent annotation in the kernel for where userspace
addresses get used and people make assumptions about them.
The sooner we get the series landed and gain QEMU support (or real
hardware), the faster we can hammer out these missed corner-cases.
What's the timeline for either of those things, BTW?
> > > I feel like I'm missing something about this being seen as an ABI
> > > break. The kernel already fails on userspace addresses that have high
> > > bits set -- are there things that _depend_ on this failure to operate?
> >
> > It's about providing a relaxed ABI which allows non-zero top byte and
> > breaking it later inadvertently without having something better in place
> > to analyse the kernel changes.
It sounds like the question is how to switch a process in or out of this
ABI (but I don't think that's the real issue: I think it's just a matter
of whether or not a process uses tags at all). Doing it at the prctl()
level doesn't make sense to me, except maybe to detect MTE support or
something. ("Should I tag allo
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom wrote:
>
> Hi, Emil,
>
> On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently vmw_execbuf_ioctl() open-codes the permission checking,
> > size
> > extending and copying that is already done in core drm.
> >
> > Kill all the duplication, adding a few comments for clarity.
>
> Ah, there is core functionality for this now.
>
> What worries me though with the core approach is that the sizes are not
> capped by the size of the kernel argument definition, which makes
> mailicious user-space being able to force kmallocs() the size of the
> maximum ioctl size. Should probably be fixed before pushing this.
Hm I always worked under the assumption that kmalloc and friends
should be userspace hardened. Otherwise stuff like kmalloc_array
doesn't make any sense, everyone just feeds it unchecked input and
expects that helper to handle overflows.
If we assume kmalloc isn't hardened against that, then we have a much
bigger problem than just vmwgfx ioctls ...
-Daniel
>
>
> >
> > Cc: "VMware Graphics"
> > Cc: Thomas Hellstrom
> > Cc: Daniel Vetter
> > Signed-off-by: Emil Velikov
> > ---
> > Thomas, VMware team,
> >
> > Please give this some testing on your end. I've only tested it
> > against
> > mesa-master.
>
> I'll review tomorrow and do some testing. Need to see if I can dig up
> user-space apps with version 0...
>
> Thanks,
>
> Thomas
>
> >
> > Thanks
> > Emil
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
> >
> > 3 files changed, 23 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index d3f108f7e52d..2cb6ae219e43 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -186,7 +186,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] =
> > {
> > DRM_RENDER_ALLOW),
> > VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
> > DRM_AUTH | DRM_RENDER_ALLOW),
> > - VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
> > + VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
> > DRM_RENDER_ALLOW),
> > VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
> > DRM_RENDER_ALLOW),
> > @@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file
> > *filp, unsigned int cmd,
> > &vmw_ioctls[nr - DRM_COMMAND_BASE];
> >
> > if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
> > - ret = (long) drm_ioctl_permit(ioctl->flags,
> > file_priv);
> > - if (unlikely(ret != 0))
> > - return ret;
> > -
> > - if (unlikely((cmd & (IOC_IN | IOC_OUT)) !=
> > IOC_IN))
> > - goto out_io_encoding;
> > -
> > - return (long) vmw_execbuf_ioctl(dev, arg,
> > file_priv,
> > - _IOC_SIZE(cmd))
> > ;
> > + return ioctl_func(filp, cmd, arg);
> > } else if (nr == DRM_COMMAND_BASE +
> > DRM_VMW_UPDATE_LAYOUT) {
> > if (!drm_is_current_master(file_priv) &&
> > !capable(CAP_SYS_ADMIN))
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index 9be2176cc260..f5bfac85f793 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -910,8 +910,8 @@ static inline struct page *vmw_piter_page(struct
> > vmw_piter *viter)
> > * Command submission - vmwgfx_execbuf.c
> > */
> >
> > -extern int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long
> > data,
> > - struct drm_file *file_priv, size_t size);
> > +extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv);
> > extern int vmw_execbuf_process(struct drm_file *file_priv,
> > struct vmw_private *dev_priv,
> > void __user *user_commands,
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > index 2ff7ba04d8c8..767e2b99618d 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > @@ -3977,54 +3977,40 @@ void vmw_execbuf_release_pinned_bo(struct
> > vmw_private *dev_priv)
> > mutex_unlock(&dev_priv->cmdbuf_mutex);
> > }
> >
> > -int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
> > - struct drm_file *file_priv, size_t size)
> > +int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv)
> > {
> >
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 alvarex changed: What|Removed |Added Status|VERIFIED|REOPENED Resolution|FIXED |--- -- 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 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
Hi, Emil,
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently vmw_execbuf_ioctl() open-codes the permission checking,
> size
> extending and copying that is already done in core drm.
>
> Kill all the duplication, adding a few comments for clarity.
Ah, there is core functionality for this now.
What worries me though with the core approach is that the sizes are not
capped by the size of the kernel argument definition, which makes
mailicious user-space being able to force kmallocs() the size of the
maximum ioctl size. Should probably be fixed before pushing this.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> Thomas, VMware team,
>
> Please give this some testing on your end. I've only tested it
> against
> mesa-master.
I'll review tomorrow and do some testing. Need to see if I can dig up
user-space apps with version 0...
Thanks,
Thomas
>
> Thanks
> Emil
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
>
> 3 files changed, 23 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index d3f108f7e52d..2cb6ae219e43 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -186,7 +186,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] =
> {
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
> DRM_AUTH | DRM_RENDER_ALLOW),
> - VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
> + VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
> DRM_RENDER_ALLOW),
> @@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file
> *filp, unsigned int cmd,
> &vmw_ioctls[nr - DRM_COMMAND_BASE];
>
> if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
> - ret = (long) drm_ioctl_permit(ioctl->flags,
> file_priv);
> - if (unlikely(ret != 0))
> - return ret;
> -
> - if (unlikely((cmd & (IOC_IN | IOC_OUT)) !=
> IOC_IN))
> - goto out_io_encoding;
> -
> - return (long) vmw_execbuf_ioctl(dev, arg,
> file_priv,
> - _IOC_SIZE(cmd))
> ;
> + return ioctl_func(filp, cmd, arg);
> } else if (nr == DRM_COMMAND_BASE +
> DRM_VMW_UPDATE_LAYOUT) {
> if (!drm_is_current_master(file_priv) &&
> !capable(CAP_SYS_ADMIN))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 9be2176cc260..f5bfac85f793 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -910,8 +910,8 @@ static inline struct page *vmw_piter_page(struct
> vmw_piter *viter)
> * Command submission - vmwgfx_execbuf.c
> */
>
> -extern int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long
> data,
> - struct drm_file *file_priv, size_t size);
> +extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> extern int vmw_execbuf_process(struct drm_file *file_priv,
> struct vmw_private *dev_priv,
> void __user *user_commands,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 2ff7ba04d8c8..767e2b99618d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3977,54 +3977,40 @@ void vmw_execbuf_release_pinned_bo(struct
> vmw_private *dev_priv)
> mutex_unlock(&dev_priv->cmdbuf_mutex);
> }
>
> -int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
> - struct drm_file *file_priv, size_t size)
> +int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> {
> struct vmw_private *dev_priv = vmw_priv(dev);
> - struct drm_vmw_execbuf_arg arg;
> + struct drm_vmw_execbuf_arg *arg = data;
> int ret;
> - static const size_t copy_offset[] = {
> - offsetof(struct drm_vmw_execbuf_arg, context_handle),
> - sizeof(struct drm_vmw_execbuf_arg)};
> struct dma_fence *in_fence = NULL;
>
> - if (unlikely(size < copy_offset[0])) {
> - VMW_DEBUG_USER("Invalid command size, ioctl %d\n",
> -DRM_VMW_EXECBUF);
> - return -EINVAL;
> - }
> -
> - if (copy_from_user(&arg, (void __user *) data, copy_of
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 alvarex changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 alvarex changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from alvarex --- it is the same bug, it is fixed! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
On Wed, May 22, 2019 at 7:28 PM Christian König
wrote:
>
> Am 22.05.19 um 18:17 schrieb Sumit Semwal:
> > Hi Christian,
> >
> > On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
> >> On Tue, 16 Apr 2019, Christian König wrote:
> >>
> >>> To allow a smooth transition from pinning buffer objects to dynamic
> >>> invalidation we first start to cache the sg_table for an attachment
> >>> unless the driver explicitly says to not do so.
> >>>
> >>> ---
> >>> drivers/dma-buf/dma-buf.c | 24
> >>> include/linux/dma-buf.h | 11 +++
> >>> 2 files changed, 35 insertions(+)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >>> index 7c858020d14b..65161a82d4d5 100644
> >>> --- a/drivers/dma-buf/dma-buf.c
> >>> +++ b/drivers/dma-buf/dma-buf.c
> >>> @@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct
> >>> dma_buf *dmabuf,
> >>>list_add(&attach->node, &dmabuf->attachments);
> >>>
> >>>mutex_unlock(&dmabuf->lock);
> >>> +
> >>> + if (!dmabuf->ops->dynamic_sgt_mapping) {
> >>> + struct sg_table *sgt;
> >>> +
> >>> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> >>> + if (!sgt)
> >>> + sgt = ERR_PTR(-ENOMEM);
> >>> + if (IS_ERR(sgt)) {
> >>> + dma_buf_detach(dmabuf, attach);
> >>> + return ERR_CAST(sgt);
> >>> + }
> >>> + attach->sgt = sgt;
> >>> + }
> >>> +
> >>>return attach;
> >>>
> >>> err_attach:
> >>> @@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
> >>> dma_buf_attachment *attach)
> >>>if (WARN_ON(!dmabuf || !attach))
> >>>return;
> >>>
> >>> + if (attach->sgt)
> >>> + dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
> >>> +DMA_BIDIRECTIONAL);
> >>> +
> >>>mutex_lock(&dmabuf->lock);
> >>>list_del(&attach->node);
> >>>if (dmabuf->ops->detach)
> >>> @@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct
> >>> dma_buf_attachment *attach,
> >>>if (WARN_ON(!attach || !attach->dmabuf))
> >>>return ERR_PTR(-EINVAL);
> >>>
> >>> + if (attach->sgt)
> >>> + return attach->sgt;
> >>> +
> >> I am concerned by this change to make caching the sg_table the default
> >> behavior as this will result in the exporter's map_dma_buf/unmap_dma_buf
> >> calls are no longer being called in
> >> dma_buf_map_attachment/dma_buf_unmap_attachment.
> > Probably this concern from Liam got lost between versions of your
> > patches; could we please request a reply to these points here?
>
> Sorry I indeed never got this mail, but this is actually not an issue
> because Daniel had similar concerns and we didn't made this the default
> in the final version.
>
> >> This seems concerning to me as it appears to ignore the cache maintenance
> >> aspect of the map_dma_buf/unmap_dma_buf calls.
> >> For example won't this potentially cause issues for clients of ION.
> >>
> >> If we had the following
> >> - #1 dma_buf_attach coherent_device
> >> - #2 dma_buf attach non_coherent_device
> >> - #3 dma_buf_map_attachment non_coherent_device
> >> - #4 non_coherent_device writes to buffer
> >> - #5 dma_buf_unmap_attachment non_coherent_device
> >> - #6 dma_buf_map_attachment coherent_device
> >> - #7 coherent_device reads buffer
> >> - #8 dma_buf_unmap_attachment coherent_device
> >>
> >> There wouldn't be any CMO at step #5 anymore (specifically no invalidate)
> >> so now at step #7 the coherent_device could read a stale cache line.
> >>
> >> Also, now by default dma_buf_unmap_attachment no longer removes the
> >> mappings from the iommu, so now by default dma_buf_unmap_attachment is not
> >> doing what I would expect and clients are losing the potential sandboxing
> >> benefits of removing the mappings.
> >> Shouldn't this caching behavior be something that clients opt into instead
> >> of being the default?
>
> Well, it seems you are making incorrect assumptions about the cache
> maintenance of DMA-buf here.
>
> At least for all DRM devices I'm aware of mapping/unmapping an
> attachment does *NOT* have any cache maintenance implications.
>
> E.g. the use case you describe above would certainly fail with amdgpu,
> radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the
> exporter from reading/writing to that buffer (just the opposite actually).
>
> All of them assume perfectly coherent access to the underlying memory.
> As far as I know there is no documented cache maintenance requirements
> for DMA-buf.
I think it is documented. It's just that on x86, we ignore that
because the dma-api pretends there's never a need for cache flushing
on x86, and that everything snoops the cpu caches. Which isn't true
since over 20 ago when AGP happened. The actual rules for x86 dma-buf
are very much ad-hoc (and we occasionally
Re: [PATCHv6 4/4] drm/omap: add support for manually updated displays
On Wed 2019-04-03 17:11:09, Tony Lindgren wrote: > * Sebastian Reichel [190403 20:14]: > > This adds the required infrastructure for manually updated displays, > > such as DSI command mode panels. While those panels often support > > partial updates we currently always do a full refresh. > > > > The display will be refreshed when something calls the dirty callback, > > such as libdrm's drmModeDirtyFB(). This is currently being done at least > > by the kernel console and Xorg (with modesetting driver) in their > > default configuration. Weston does not implement this and the fbdev > > backend does not work (display will not update). Weston's DRM backend > > uses double buffering and the page flip will also trigger a display > > refresh. > > I've tested this with Linux next and the latest lm3532 > patches and it works fine as long as we leave out the > backlight = <&lcd_backlight> entry from dts like I > replied in the lm3532 tread. So as far as I'm concerned, > we're good to go: > > Tested-by: Tony Lindgren I've tested this on 5.2-rc1, and it is still neccessary, still needed, and still not merged. How can I help? Can the patches simply be picked up for drm tree? Tested-by: Pavel Machek Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #11 from alvarex ---
> The second one is 811fa9a79cf ("mesa: unreference current winsys buffers
> when unbinding winsys buffers").
>
I'm going to try reverting that commit and building anyway.(In reply to alvarex
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init
From: Sean Paul
This rename makes it more clear that everything initialized in the _init
function must be cleaned up in a6xx_gmu_remove. This will hopefully
dissuade people from using device managed resources (for reasons laid
out in the previous patch).
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 701b813fa38a..26f44a187eda 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1256,7 +1256,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
}
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
{
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
struct platform_device *pdev = of_find_device_by_node(node);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index e74dce474250..1f9f4b0a9656 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -854,7 +854,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
/* FIXME: How do we gracefully handle this? */
BUG_ON(!node);
- ret = a6xx_gmu_probe(a6xx_gpu, node);
+ ret = a6xx_gmu_init(a6xx_gpu, node);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index b46279eb18c5..64399554f2dd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -53,7 +53,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu);
int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/msm/a6xx: Remove devm calls from gmu driver
From: Sean Paul
The gmu driver is initalized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
If the gpu bind is run again (eg: if there's a probe defer somewhere in msm),
these resources will be initialized again for the same device, creating multiple
references. In the case of irqs, this causes failures since the irqs are
not shared (nor should they be).
This patch removes all devm_* calls and manually cleans things up in
gmu_remove.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 7465423e9b71..701b813fa38a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -505,9 +505,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
err:
if (!IS_ERR_OR_NULL(pdcptr))
- devm_iounmap(gmu->dev, pdcptr);
+ iounmap(pdcptr);
if (!IS_ERR_OR_NULL(seqptr))
- devm_iounmap(gmu->dev, seqptr);
+ iounmap(seqptr);
}
/*
@@ -1197,7 +1197,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
}
- ret = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ ret = ioremap(res->start, resource_size(res));
if (!ret) {
DRM_DEV_ERROR(&pdev->dev, "Unable to map the %s registers\n",
name);
return ERR_PTR(-EINVAL);
@@ -1213,10 +1213,10 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
struct platform_device *pdev,
irq = platform_get_irq_byname(pdev, name);
- ret = devm_request_irq(&pdev->dev, irq, handler, IRQF_TRIGGER_HIGH,
- name, gmu);
+ ret = request_irq(irq, handler, IRQF_TRIGGER_HIGH, name, gmu);
if (ret) {
- DRM_DEV_ERROR(&pdev->dev, "Unable to get interrupt %s\n", name);
+ DRM_DEV_ERROR(&pdev->dev, "Unable to get interrupt %s %d\n",
+ name, ret);
return ret;
}
@@ -1241,12 +1241,18 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
dev_pm_domain_detach(gmu->gxpd, false);
}
+ iounmap(gmu->mmio);
+ gmu->mmio = NULL;
+
a6xx_gmu_memory_free(gmu, gmu->hfi);
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+
gmu->initialized = false;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/msm/a6xx: Check for ERR or NULL before iounmap
From: Sean Paul pdcptr and seqptr aren't necessarily valid, check them before trying to unmap them. Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 742c8ff9a61c..7465423e9b71 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -504,8 +504,10 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) wmb(); err: - devm_iounmap(gmu->dev, pdcptr); - devm_iounmap(gmu->dev, seqptr); + if (!IS_ERR_OR_NULL(pdcptr)) + devm_iounmap(gmu->dev, pdcptr); + if (!IS_ERR_OR_NULL(seqptr)) + devm_iounmap(gmu->dev, seqptr); } /* -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/msm/a6xx: Remove duplicate irq disable from remove
From: Sean Paul a6xx_gmu_stop() already calls this function via shutdown or force_stop, so it's not necessary to call it twice. This also knocks the irq depth count out of sync, so nice to avoid. Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index aa84edb25d91..742c8ff9a61c 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1239,7 +1239,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) dev_pm_domain_detach(gmu->gxpd, false); } - a6xx_gmu_irq_disable(gmu); a6xx_gmu_memory_free(gmu, gmu->hfi); iommu_detach_device(gmu->domain, gmu->dev); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH 1/5] drm/msm/a6xx: Avoid freeing gmu resources multiple times
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
resources for a second time. This causes a great boom.
Fix this by adding an initialized member to gmu which is set on
successful probe and cleared on removal.
Signed-off-by: Sean Paul
---
Resending as part of the set since some later patches depend on it
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 38e2cfa9cec7..aa84edb25d91 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -74,7 +74,7 @@ bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -90,7 +90,7 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -695,7 +695,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
int status, ret;
- if (WARN(!gmu->mmio, "The GMU is not set up yet\n"))
+ if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
return 0;
gmu->hung = false;
@@ -765,7 +765,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
{
u32 reg;
- if (!gmu->mmio)
+ if (!gmu->initialized)
return true;
reg = gmu_read(gmu, REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS);
@@ -1227,7 +1227,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
{
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return;
a6xx_gmu_stop(a6xx_gpu);
@@ -1245,6 +1245,8 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+
+ gmu->initialized = false;
}
int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
@@ -1309,6 +1311,8 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
/* Set up the HFI queues */
a6xx_hfi_init(gmu);
+ gmu->initialized = true;
+
return 0;
err:
a6xx_gmu_memory_free(gmu, gmu->hfi);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index bedd8e6a63aa..39a26dd63674 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -75,6 +75,7 @@ struct a6xx_gmu {
struct a6xx_hfi_queue queues[2];
+ bool initialized;
bool hung;
};
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #10 from alvarex ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> > (In reply to Ropid from comment #6)
> > @alvarex:
> >
> > Try starting chromium with this command line here, it makes it show
> > corruption everywhere for me here:
> >
> > chromium --ignore-gpu-blacklist --enable-gpu-rasterization
> > --enable-native-gpu-memory-buffers --enable-zero-copy
> > --disable-gpu-driver-bug-workarounds
> >
>
> Same here so I did a bisect.
> There are 2 problematic commits, making the bisect a bit more complicated.
>
> The first one has already been solved by d6053bf2a170.
> The second one is 811fa9a79cf ("mesa: unreference current winsys buffers
> when unbinding winsys buffers").
>
> Using master + this commit reverted: no more corruption in chromium.
for me it doesn't happen on chrome with 64 bits libs, (I couldn't compile
32bits) I tried several versions of chrome, but not that precise one. not sure
if it is the same bug. what version of chrome does steam use?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
Am 22.05.19 um 18:17 schrieb Sumit Semwal:
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
On Tue, 16 Apr 2019, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment
unless the driver explicitly says to not do so.
---
drivers/dma-buf/dma-buf.c | 24
include/linux/dma-buf.h | 11 +++
2 files changed, 35 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..65161a82d4d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
list_add(&attach->node, &dmabuf->attachments);
mutex_unlock(&dmabuf->lock);
+
+ if (!dmabuf->ops->dynamic_sgt_mapping) {
+ struct sg_table *sgt;
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ dma_buf_detach(dmabuf, attach);
+ return ERR_CAST(sgt);
+ }
+ attach->sgt = sgt;
+ }
+
return attach;
err_attach:
@@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
+ if (attach->sgt)
+ dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
+DMA_BIDIRECTIONAL);
+
mutex_lock(&dmabuf->lock);
list_del(&attach->node);
if (dmabuf->ops->detach)
@@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
+ if (attach->sgt)
+ return attach->sgt;
+
I am concerned by this change to make caching the sg_table the default
behavior as this will result in the exporter's map_dma_buf/unmap_dma_buf
calls are no longer being called in
dma_buf_map_attachment/dma_buf_unmap_attachment.
Probably this concern from Liam got lost between versions of your
patches; could we please request a reply to these points here?
Sorry I indeed never got this mail, but this is actually not an issue
because Daniel had similar concerns and we didn't made this the default
in the final version.
This seems concerning to me as it appears to ignore the cache maintenance
aspect of the map_dma_buf/unmap_dma_buf calls.
For example won't this potentially cause issues for clients of ION.
If we had the following
- #1 dma_buf_attach coherent_device
- #2 dma_buf attach non_coherent_device
- #3 dma_buf_map_attachment non_coherent_device
- #4 non_coherent_device writes to buffer
- #5 dma_buf_unmap_attachment non_coherent_device
- #6 dma_buf_map_attachment coherent_device
- #7 coherent_device reads buffer
- #8 dma_buf_unmap_attachment coherent_device
There wouldn't be any CMO at step #5 anymore (specifically no invalidate)
so now at step #7 the coherent_device could read a stale cache line.
Also, now by default dma_buf_unmap_attachment no longer removes the
mappings from the iommu, so now by default dma_buf_unmap_attachment is not
doing what I would expect and clients are losing the potential sandboxing
benefits of removing the mappings.
Shouldn't this caching behavior be something that clients opt into instead
of being the default?
Well, it seems you are making incorrect assumptions about the cache
maintenance of DMA-buf here.
At least for all DRM devices I'm aware of mapping/unmapping an
attachment does *NOT* have any cache maintenance implications.
E.g. the use case you describe above would certainly fail with amdgpu,
radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the
exporter from reading/writing to that buffer (just the opposite actually).
All of them assume perfectly coherent access to the underlying memory.
As far as I know there is no documented cache maintenance requirements
for DMA-buf.
The IOMMU concern on the other hand is certainly valid and I perfectly
agree that keeping the mapping time as short as possible is desirable.
Regards,
Christian.
Liam
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110731] ui issues
https://bugs.freedesktop.org/show_bug.cgi?id=110731 Andre Klapper changed: What|Removed |Added Product|DRI |Spam Resolution|--- |INVALID Status|NEW |RESOLVED Component|DRM/AMDgpu-pro |Two Group||spam --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #9 from Pierre-Eric Pelloux-Prayer ---
> (In reply to Ropid from comment #6)
> @alvarex:
>
> Try starting chromium with this command line here, it makes it show
> corruption everywhere for me here:
>
> chromium --ignore-gpu-blacklist --enable-gpu-rasterization
> --enable-native-gpu-memory-buffers --enable-zero-copy
> --disable-gpu-driver-bug-workarounds
>
Same here so I did a bisect.
There are 2 problematic commits, making the bisect a bit more complicated.
The first one has already been solved by d6053bf2a170.
The second one is 811fa9a79cf ("mesa: unreference current winsys buffers when
unbinding winsys buffers").
Using master + this commit reverted: no more corruption in chromium.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/vmwgfx: remove custom ioctl io encoding check
From: Emil Velikov
Drop the custom ioctl io encoding check - core drm does it for us.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 2cb6ae219e43..f65542639b55 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1147,9 +1147,6 @@ static long vmw_generic_ioctl(struct file *filp, unsigned
int cmd,
return -EACCES;
}
- if (unlikely(ioctl->cmd != cmd))
- goto out_io_encoding;
-
flags = ioctl->flags;
} else if (!drm_ioctl_flags(nr, &flags))
return -EINVAL;
@@ -1169,12 +1166,6 @@ static long vmw_generic_ioctl(struct file *filp,
unsigned int cmd,
ttm_read_unlock(&vmaster->lock);
return ret;
-
-out_io_encoding:
- DRM_ERROR("Invalid command format, ioctl %d\n",
- nr - DRM_COMMAND_BASE);
-
- return -EINVAL;
}
static long vmw_unlocked_ioctl(struct file *filp, unsigned int cmd,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
From: Emil Velikov
Currently vmw_execbuf_ioctl() open-codes the permission checking, size
extending and copying that is already done in core drm.
Kill all the duplication, adding a few comments for clarity.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Thomas, VMware team,
Please give this some testing on your end. I've only tested it against
mesa-master.
Thanks
Emil
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
3 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d3f108f7e52d..2cb6ae219e43 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -186,7 +186,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
+ VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
DRM_RENDER_ALLOW),
@@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file *filp,
unsigned int cmd,
&vmw_ioctls[nr - DRM_COMMAND_BASE];
if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
- ret = (long) drm_ioctl_permit(ioctl->flags, file_priv);
- if (unlikely(ret != 0))
- return ret;
-
- if (unlikely((cmd & (IOC_IN | IOC_OUT)) != IOC_IN))
- goto out_io_encoding;
-
- return (long) vmw_execbuf_ioctl(dev, arg, file_priv,
- _IOC_SIZE(cmd));
+ return ioctl_func(filp, cmd, arg);
} else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) {
if (!drm_is_current_master(file_priv) &&
!capable(CAP_SYS_ADMIN))
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 9be2176cc260..f5bfac85f793 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -910,8 +910,8 @@ static inline struct page *vmw_piter_page(struct vmw_piter
*viter)
* Command submission - vmwgfx_execbuf.c
*/
-extern int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
-struct drm_file *file_priv, size_t size);
+extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
extern int vmw_execbuf_process(struct drm_file *file_priv,
struct vmw_private *dev_priv,
void __user *user_commands,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 2ff7ba04d8c8..767e2b99618d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3977,54 +3977,40 @@ void vmw_execbuf_release_pinned_bo(struct vmw_private
*dev_priv)
mutex_unlock(&dev_priv->cmdbuf_mutex);
}
-int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
- struct drm_file *file_priv, size_t size)
+int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
{
struct vmw_private *dev_priv = vmw_priv(dev);
- struct drm_vmw_execbuf_arg arg;
+ struct drm_vmw_execbuf_arg *arg = data;
int ret;
- static const size_t copy_offset[] = {
- offsetof(struct drm_vmw_execbuf_arg, context_handle),
- sizeof(struct drm_vmw_execbuf_arg)};
struct dma_fence *in_fence = NULL;
- if (unlikely(size < copy_offset[0])) {
- VMW_DEBUG_USER("Invalid command size, ioctl %d\n",
- DRM_VMW_EXECBUF);
- return -EINVAL;
- }
-
- if (copy_from_user(&arg, (void __user *) data, copy_offset[0]) != 0)
- return -EFAULT;
-
/*
* Extend the ioctl argument while maintaining backwards compatibility:
-* We take different code paths depending on the value of arg.version.
+* We take different code paths depending on the value of arg->version.
+*
+* Note: The ioctl argument is extended and zeropadded by core DRM.
*/
- if (unlikely(arg.version > DRM_VMW_EXECBUF_VERSION ||
-arg.version == 0)) {
+ if (unlikely(arg->version > DRM_VMW_EXECBUF_VERSION ||
+arg->version == 0)) {
VMW_DEBUG_USER("Incorrect exec
[PATCH 2/5] drm/vmgfx: kill off unused init_mutex
From: Emil Velikov
According to the docs - prevents firstopen/lastclose races. Yet never
used in practise.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index a38f06909fb6..d3f108f7e52d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -664,7 +664,6 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
INIT_LIST_HEAD(&dev_priv->res_lru[i]);
}
- mutex_init(&dev_priv->init_mutex);
init_waitqueue_head(&dev_priv->fence_queue);
init_waitqueue_head(&dev_priv->fifo_queue);
dev_priv->fence_queue_waiters = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 96983c47fb40..9be2176cc260 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -484,11 +484,6 @@ struct vmw_private {
spinlock_t resource_lock;
struct idr res_idr[vmw_res_max];
- /*
-* Block lastclose from racing with firstopen.
-*/
-
- struct mutex init_mutex;
/*
* A resource manager for kernel-only surfaces and
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: make drm_ioctl_permit() internal
From: Emil Velikov
As of earlier commit the function is used only within drm core.
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_ioctl.c | 3 +--
include/drm/drm_ioctl.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 2263e3ddd822..0646c0bd5535 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -523,7 +523,7 @@ int drm_version(struct drm_device *dev, void *data,
* Returns:
* Zero if allowed, -EACCES otherwise.
*/
-int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
+static int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
{
/* ROOT_ONLY is only for CAP_SYS_ADMIN */
if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)))
@@ -546,7 +546,6 @@ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
return 0;
}
-EXPORT_SYMBOL(drm_ioctl_permit);
#define DRM_IOCTL_DEF(ioctl, _func, _flags)\
[DRM_IOCTL_NR(ioctl)] = { \
diff --git a/include/drm/drm_ioctl.h b/include/drm/drm_ioctl.h
index fafb6f592c4b..f3fba529cb1b 100644
--- a/include/drm/drm_ioctl.h
+++ b/include/drm/drm_ioctl.h
@@ -163,7 +163,6 @@ struct drm_ioctl_desc {
.name = #ioctl \
}
-int drm_ioctl_permit(u32 flags, struct drm_file *file_priv);
long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
long drm_ioctl_kernel(struct file *, drm_ioctl_t, void *, u32);
#ifdef CONFIG_COMPAT
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] vmwgfx: drop empty lastclose stub
From: Emil Velikov
Core DRM is safe when the callback is NULL.
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index be25ce9440ad..a38f06909fb6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1200,10 +1200,6 @@ static long vmw_compat_ioctl(struct file *filp, unsigned
int cmd,
}
#endif
-static void vmw_lastclose(struct drm_device *dev)
-{
-}
-
static void vmw_master_init(struct vmw_master *vmaster)
{
ttm_lock_init(&vmaster->lock);
@@ -1568,7 +1564,6 @@ static struct drm_driver driver = {
DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER | DRIVER_ATOMIC,
.load = vmw_driver_load,
.unload = vmw_driver_unload,
- .lastclose = vmw_lastclose,
.get_vblank_counter = vmw_get_vblank_counter,
.enable_vblank = vmw_enable_vblank,
.disable_vblank = vmw_disable_vblank,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: pwm_bl: Set pin to sleep state when powered down
When the driver probes, the PWM pin is automatically configured to its default state, which should be the "pwm" function. However, at this point we don't know the actual level of the pin, which may be active or inactive. As a result, if the driver probes without enabling the backlight, the PWM pin might be active, and the backlight would be lit way before being officially enabled. To work around this, if the probe function doesn't enable the backlight, the pin is set to its sleep state instead of the default one, until the backlight is enabled. When the backlight is disabled, the pin is reset to its sleep state. Signed-off-by: Paul Cercueil --- drivers/video/backlight/pwm_bl.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index fb45f866b923..422f7903b382 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -50,6 +51,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb) struct pwm_state state; int err; + pinctrl_pm_select_default_state(pb->dev); + pwm_get_state(pb->pwm, &state); if (pb->enabled) return; @@ -90,6 +93,8 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb) regulator_disable(pb->power_supply); pb->enabled = false; + + pinctrl_pm_select_sleep_state(pb->dev); } static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness) @@ -626,6 +631,10 @@ static int pwm_backlight_probe(struct platform_device *pdev) backlight_update_status(bl); platform_set_drvdata(pdev, bl); + + if (bl->props.power == FB_BLANK_POWERDOWN) + pinctrl_pm_select_sleep_state(&pdev->dev); + return 0; err_alloc: -- 2.21.0.593.g511ec345e18
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #8 from Ropid --- $ chromium --version Chromium 74.0.3729.157 Arch Linux -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #7 from alvarex --- (In reply to Ropid from comment #6) > @alvarex: > > Try starting chromium with this command line here, it makes it show > corruption everywhere for me here: > > chromium --ignore-gpu-blacklist --enable-gpu-rasterization > --enable-native-gpu-memory-buffers --enable-zero-copy > --disable-gpu-driver-bug-workarounds > > About Visual Studio Code, I see corruption when I click on the main menu and > move the mouse around to open and close the different menus there. no the bug doesn't trigger with chromium unless this error has something to do maybe chrome is not detecting the gpu (same as steam) > ac: Unknown GPU, using 0 for raster_config > [1:7:0522/132124.876161:ERROR:command_buffer_proxy_impl.cc(125)] > ContextResult::kTransientFailure: Failed to send > GpuChannelMsg_CreateCommandBuffer. > [31337:31346:0522/132131.668335:ERROR:browser_process_sub_thread.cc(217)] > Waited 322 ms for network service @Ropid what version of chromium are u using?? -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #6 from Ropid --- @alvarex: Try starting chromium with this command line here, it makes it show corruption everywhere for me here: chromium --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy --disable-gpu-driver-bug-workarounds About Visual Studio Code, I see corruption when I click on the main menu and move the mouse around to open and close the different menus there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
>
> On Tue, 16 Apr 2019, Christian König wrote:
>
> > To allow a smooth transition from pinning buffer objects to dynamic
> > invalidation we first start to cache the sg_table for an attachment
> > unless the driver explicitly says to not do so.
> >
> > ---
> > drivers/dma-buf/dma-buf.c | 24
> > include/linux/dma-buf.h | 11 +++
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 7c858020d14b..65161a82d4d5 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct
> > dma_buf *dmabuf,
> > list_add(&attach->node, &dmabuf->attachments);
> >
> > mutex_unlock(&dmabuf->lock);
> > +
> > + if (!dmabuf->ops->dynamic_sgt_mapping) {
> > + struct sg_table *sgt;
> > +
> > + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> > + if (!sgt)
> > + sgt = ERR_PTR(-ENOMEM);
> > + if (IS_ERR(sgt)) {
> > + dma_buf_detach(dmabuf, attach);
> > + return ERR_CAST(sgt);
> > + }
> > + attach->sgt = sgt;
> > + }
> > +
> > return attach;
> >
> > err_attach:
> > @@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
> > dma_buf_attachment *attach)
> > if (WARN_ON(!dmabuf || !attach))
> > return;
> >
> > + if (attach->sgt)
> > + dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
> > +DMA_BIDIRECTIONAL);
> > +
> > mutex_lock(&dmabuf->lock);
> > list_del(&attach->node);
> > if (dmabuf->ops->detach)
> > @@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct
> > dma_buf_attachment *attach,
> > if (WARN_ON(!attach || !attach->dmabuf))
> > return ERR_PTR(-EINVAL);
> >
> > + if (attach->sgt)
> > + return attach->sgt;
> > +
>
> I am concerned by this change to make caching the sg_table the default
> behavior as this will result in the exporter's map_dma_buf/unmap_dma_buf
> calls are no longer being called in
> dma_buf_map_attachment/dma_buf_unmap_attachment.
Probably this concern from Liam got lost between versions of your
patches; could we please request a reply to these points here?
>
> This seems concerning to me as it appears to ignore the cache maintenance
> aspect of the map_dma_buf/unmap_dma_buf calls.
> For example won't this potentially cause issues for clients of ION.
>
> If we had the following
> - #1 dma_buf_attach coherent_device
> - #2 dma_buf attach non_coherent_device
> - #3 dma_buf_map_attachment non_coherent_device
> - #4 non_coherent_device writes to buffer
> - #5 dma_buf_unmap_attachment non_coherent_device
> - #6 dma_buf_map_attachment coherent_device
> - #7 coherent_device reads buffer
> - #8 dma_buf_unmap_attachment coherent_device
>
> There wouldn't be any CMO at step #5 anymore (specifically no invalidate)
> so now at step #7 the coherent_device could read a stale cache line.
>
> Also, now by default dma_buf_unmap_attachment no longer removes the
> mappings from the iommu, so now by default dma_buf_unmap_attachment is not
> doing what I would expect and clients are losing the potential sandboxing
> benefits of removing the mappings.
> Shouldn't this caching behavior be something that clients opt into instead
> of being the default?
>
> Liam
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/TODO: add a task to kill DRM_UNLOCKED
On Wed, May 22, 2019 at 04:47:02PM +0100, Emil Velikov wrote: > From: Emil Velikov > > Should minimise the copy/paste mistakes, fixed with previous patches. > > Cc: Daniel Vetter > Signed-off-by: Emil Velikov > --- > Daniel, not 100% sold on the idea. That plus listing you as a contact > point ;-) > > What do you thing? > Emil > --- > Documentation/gpu/todo.rst | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 66f05f4e469f..9e67d125f2fd 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -397,6 +397,25 @@ Some of these date from the very introduction of KMS in > 2008 ... >end, for which we could add drm_*_cleanup_kfree(). And then there's the > (for >historical reasons) misnamed drm_primary_helper_destroy() function. > > +Use DRM_LOCKED instead of DRM_UNLOCKED > +-- > + > +DRM_UNLOCKED is a remainder from the legacy DRM drivers. Seemingly drivers > get > +tricked by it and it ends up in the driver private ioctls. > + > +Today no more legacy drivers are allowed and most core DRM ioctls are > unlocked. > + > +Introduce DRM_LOCKED, use it to annotate only the relevant ioctls and kill > the > +old DRM_UNLOCKED. > + > +Patch series should be split as follows: > + - Patch 1: drm: add the new DRM_LOCKED flag and honour it > + - Patch 2: drm: convert core ioctls from DRM_UNLOCKED to DRM_LOCKED > + - Patch 3-...: drm/driverX: convert driver ioctls from ... > + - Patch X: drm: remove no longer used DRM_UNLOCKED, drop todo item Seems like too much bother for legacy drivers ... What I'd do is something a lot cheaper, since all we're touching here are legacy drivers: Remove DRM_UNLOCKED from everything except the old vblank ioctl. That one we need to keep, because it freezes X: commit 8f4ff2b06afcd6f151868474a432c603057eaf56 Author: Ilija Hadzic Date: Mon Oct 31 17:46:18 2011 -0400 drm: do not sleep on vblank while holding a mutex Anything else I think is either never used by legacy userspace, or just doesn't matter. That's simple enough that I don't think we really need a todo for it :-) I guess if you want to kill DRM_UNLOCKED you could replace the check with ioctl->func == drm_vblank_ioctl, ofc only in the DRIVER_LEGACY path. On patches 1-3 in your series: Reviewed-by: Daniel Vetter Cheers, Daniel > + > +Contact: Emil Velikov, Daniel Vetter > + > Better Testing > == > > -- > 2.21.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #5 from alvarex --- I need help, I build up mesa and set the git bisect good and bad commits, but steam does not start because it needs 32bits libs and I can't seem to build them. What option should I pass to meson or ninja to compile 32 bit? I can't trigger the bug on chrome, chrome or chromium do launch but the bug doesn't trigger . @Ropid what do you mean with Visual Studio Code? where should I find that extension? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/TODO: add a task to kill DRM_UNLOCKED
From: Emil Velikov Should minimise the copy/paste mistakes, fixed with previous patches. Cc: Daniel Vetter Signed-off-by: Emil Velikov --- Daniel, not 100% sold on the idea. That plus listing you as a contact point ;-) What do you thing? Emil --- Documentation/gpu/todo.rst | 19 +++ 1 file changed, 19 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 66f05f4e469f..9e67d125f2fd 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -397,6 +397,25 @@ Some of these date from the very introduction of KMS in 2008 ... end, for which we could add drm_*_cleanup_kfree(). And then there's the (for historical reasons) misnamed drm_primary_helper_destroy() function. +Use DRM_LOCKED instead of DRM_UNLOCKED +-- + +DRM_UNLOCKED is a remainder from the legacy DRM drivers. Seemingly drivers get +tricked by it and it ends up in the driver private ioctls. + +Today no more legacy drivers are allowed and most core DRM ioctls are unlocked. + +Introduce DRM_LOCKED, use it to annotate only the relevant ioctls and kill the +old DRM_UNLOCKED. + +Patch series should be split as follows: + - Patch 1: drm: add the new DRM_LOCKED flag and honour it + - Patch 2: drm: convert core ioctls from DRM_UNLOCKED to DRM_LOCKED + - Patch 3-...: drm/driverX: convert driver ioctls from ... + - Patch X: drm: remove no longer used DRM_UNLOCKED, drop todo item + +Contact: Emil Velikov, Daniel Vetter + Better Testing == -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/i915: remove irrelevant DRM_UNLOCKED flag
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: intel-...@lists.freedesktop.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ad88e6d7c04..a18c155cff88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3145,9 +3145,9 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl,
DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/virtio: remove irrelevant DRM_UNLOCKED flag
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 949a264985fc..b7f9dfe61d1c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -553,34 +553,34 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device
*dev,
struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS] = {
DRM_IOCTL_DEF_DRV(VIRTGPU_MAP, virtio_gpu_map_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_EXECBUFFER, virtio_gpu_execbuffer_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_GETPARAM, virtio_gpu_getparam_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_CREATE,
virtio_gpu_resource_create_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_RESOURCE_INFO, virtio_gpu_resource_info_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
/* make transfer async to the main ring? - no sure, can we
* thread these in the underlying GL
*/
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_FROM_HOST,
virtio_gpu_transfer_from_host_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_TRANSFER_TO_HOST,
virtio_gpu_transfer_to_host_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_WAIT, virtio_gpu_wait_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VIRTGPU_GET_CAPS, virtio_gpu_get_caps_ioctl,
- DRM_AUTH | DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_AUTH | DRM_RENDER_ALLOW),
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/tegra: remove irrelevant DRM_UNLOCKED flag
From: Emil Velikov
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/tegra/drm.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 0c5f1e6a0446..8836c113b392 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -891,33 +891,33 @@ static int tegra_gem_get_flags(struct drm_device *drm,
void *data,
static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
#ifdef CONFIG_DRM_TEGRA_STAGING
DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_gem_mmap,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_READ, tegra_syncpt_read,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_INCR, tegra_syncpt_incr,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_WAIT, tegra_syncpt_wait,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_OPEN_CHANNEL, tegra_open_channel,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_CLOSE_CHANNEL, tegra_close_channel,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags,
- DRM_UNLOCKED | DRM_RENDER_ALLOW),
+ DRM_RENDER_ALLOW),
#endif
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110575] [R9 380X] Artifacts in CSGO
https://bugs.freedesktop.org/show_bug.cgi?id=110575 --- Comment #4 from Danylo --- I'll try it later when will come home, thanks. It also happens in Minecraft but much rarer (so I wasn't patient enough to bisect with it). -- 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/cirrus: remove leftover files
On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote:
> cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
> ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
> instead of "git rm" on them so they are still in present the tree.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Sam Ravnborg
Always nice with the code removal patches.
Will you apply yourself?
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107612] [Vega10] Hard Lock [gfxhub] VMC page fault when opening Mario Kart 8 in Cemu under wine
https://bugs.freedesktop.org/show_bug.cgi?id=107612 --- Comment #7 from bibitocarlos --- Yeah, it's fixed. thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/omap: remove open-coded drm_invalid_op()
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1b9b6f5e48e1..672e0f8ad11c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -439,20 +439,6 @@ static int ioctl_get_param(struct drm_device *dev, void
*data,
return 0;
}
-static int ioctl_set_param(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
-{
- struct drm_omap_param *args = data;
-
- switch (args->param) {
- default:
- DBG("unknown parameter %lld", args->param);
- return -EINVAL;
- }
-
- return 0;
-}
-
#define OMAP_BO_USER_MASK 0x00ff /* flags settable by userspace
*/
static int ioctl_gem_new(struct drm_device *dev, void *data,
@@ -492,7 +478,7 @@ static int ioctl_gem_info(struct drm_device *dev, void
*data,
static const struct drm_ioctl_desc ioctls[DRM_COMMAND_END - DRM_COMMAND_BASE]
= {
DRM_IOCTL_DEF_DRV(OMAP_GET_PARAM, ioctl_get_param,
DRM_AUTH | DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(OMAP_SET_PARAM, ioctl_set_param,
+ DRM_IOCTL_DEF_DRV(OMAP_SET_PARAM, drm_invalid_op,
DRM_AUTH | DRM_MASTER | DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(OMAP_GEM_NEW, ioctl_gem_new,
DRM_AUTH | DRM_RENDER_ALLOW),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()
From: Emil Velikov
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 --
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index c3fd5dd39ed9..0c585dc5f5c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -244,12 +244,6 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
return 0;
}
-int
-nouveau_abi16_ioctl_setparam(ABI16_IOCTL_ARGS)
-{
- return -EINVAL;
-}
-
int
nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
{
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 36fde1ff3ad5..9275d529b947 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
@@ -6,7 +6,6 @@
struct drm_device *dev, void *data, struct drm_file *file_priv
int nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS);
-int nouveau_abi16_ioctl_setparam(ABI16_IOCTL_ARGS);
int nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS);
int nouveau_abi16_ioctl_channel_free(ABI16_IOCTL_ARGS);
int nouveau_abi16_ioctl_grobj_alloc(ABI16_IOCTL_ARGS);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 22cd45845e07..ed45ad2b72f2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1046,7 +1046,7 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
static const struct drm_ioctl_desc
nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GETPARAM, nouveau_abi16_ioctl_getparam,
DRM_AUTH|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, nouveau_abi16_ioctl_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_SETPARAM, drm_invalid_op,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_ALLOC,
nouveau_abi16_ioctl_channel_alloc, DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_CHANNEL_FREE,
nouveau_abi16_ioctl_channel_free, DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GROBJ_ALLOC, nouveau_abi16_ioctl_grobj_alloc,
DRM_AUTH|DRM_RENDER_ALLOW),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110575] [R9 380X] Artifacts in CSGO
https://bugs.freedesktop.org/show_bug.cgi?id=110575 --- Comment #3 from tempel.jul...@gmail.com --- Can you try R600_DEBUG=nohyperz? I have this kind of glitches in almost every game with OpenGL/Gallium Nine on Polaris and this variable seems to help at least in Skyrim with Gallium Nine (haven't tested anything else so far). My bug report: https://bugs.freedesktop.org/show_bug.cgi?id=110635 -- 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_edid-load: Fix a missing-check bug in drivers/gpu/drm/drm_edid_load.c
On Wed, 22 May 2019, Gen Zhang wrote:
> In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
> is dereferenced in the following codes. However, memory allocation
> functions such as kstrdup() may fail and returns NULL. Dereferencing
> this null pointer may cause the kernel go wrong. Thus we should check
> this kstrdup() operation.
> Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to
> the caller site.
strsep() handles the NULL pointer just fine, so there won't be a NULL
dereference. However this patch seems like the right thing to do anyway.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Gen Zhang
>
> ---
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index a491509..a0e107a 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -290,6 +290,8 @@ struct edid *drm_load_edid_firmware(struct drm_connector
> *connector)
>* the last one found one as a fallback.
>*/
> fwstr = kstrdup(edid_firmware, GFP_KERNEL);
> + if (!fwstr)
> + return ERR_PTR(-ENOMEM);
> edidstr = fwstr;
>
> while ((edidname = strsep(&edidstr, ","))) {
> ---
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [PATCHv2 03/22] drm/bridge: tc358767: fix ansi 8b10b use
On Mon, May 6, 2019 at 2:59 AM Tomi Valkeinen wrote: > > Hi Laurent, Andrey, > > On 03/05/2019 20:11, Laurent Pinchart wrote: > >> I agree that if the panel Andrey mentioned is still used, we need to > >> handle it somehow. But I think explicitly handling such a case is better > >> than guessing. > > > > The risk may not be worth it, I agree. I would explain this in details > > in the commit message though, and add a comment to the code as well, to > > ease future debugging. > > Andrey, do you still have the panel that doesn't work with 8b10b? Is it > used in real life (i.e. it was not just a temporary development phase > panel)? What's the model, and is there a public datasheet? Note that I am a different Andrey, and I can't speak about the original panel that caused the issue. However, production units are shipped with this panel: https://www.data-modul.com/productfinder/sites/default/files/products/NL192108AC13-02D_specification_12023727.pdf which seems to do pretty standard DP stuff. In all of my testing of Tomi's patches, I haven't seen any problems so far (I still have to test v3 though), so I think we can carefully proceed assuming that that weird panel was just a fluke. Thanks, Andrey Smirnov ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: locking bug in inet_autobind
syzbot has bisected this bug to:
commit c0d9271ecbd891cdeb0fad1edcdd99ee717a655f
Author: Yong Zhao
Date: Fri Feb 1 23:36:21 2019 +
drm/amdgpu: Delete user queue doorbell variables
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1433ece4a0
start commit: f49aa1de Merge tag 'for-5.2-rc1-tag' of git://git.kernel.o..
git tree: net-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=1633ece4a0
console output: https://syzkaller.appspot.com/x/log.txt?x=1233ece4a0
kernel config: https://syzkaller.appspot.com/x/.config?x=fc045131472947d7
dashboard link: https://syzkaller.appspot.com/bug?extid=94cc2a66fc228b23f360
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=163731f8a0
Reported-by: syzbot+94cc2a66fc228b23f...@syzkaller.appspotmail.com
Fixes: c0d9271ecbd8 ("drm/amdgpu: Delete user queue doorbell variables")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
XDC 2019: Registration & Call for Proposals now open!
Hello! Registration & Call for Proposals are now open for XDC 2019, which will take place at the Concordia University Conference Centre in Montréal, Canada on October 2-4, 2019. Thanks to LWN.net, this year we have a brand new website using the Indico platform, a fully open source event management tool! https://xdc2019.x.org If you plan on attending, please make sure to register as early as possible as space is limited! As usual, the conference is free of charge and open to the general public. Please note, as we are now based on Indico, we will no longer use the wiki for registration. You will therefore need to register via the XDC website. However, as XDC is sharing the same Indico infrastructure as LPC, if you previously registered on the LPC website (linuxplumbersconference.org), then you already have an active account and can use the same username & password to login! https://xdc2019.x.org/event/5/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2019. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://xdc2019.x.org/event/5/abstracts/ The deadline for submissions Sunday, 7 July 2019. We are looking forward to seeing you (and sharing a poutine!) in beautiful Montréal! If you have any questions, please send me an email to mark.fil...@collabora.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/xdc2019 Best, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/panfrost: Use drm_gem_shmem_map_offset()
panfrost_ioctl_mmap_bo() contains a reimplementation of
drm_gem_map_offset() but with a bug - it allows mapping imported objects
(without going through the exporter). Fix this by switching to use the
newly renamed drm_gem_map_offset() function instead which has the bonus
of simplifying the code.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d11e2281dde6..8be0cd5d6c7a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -255,26 +255,14 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev,
void *data,
struct drm_file *file_priv)
{
struct drm_panfrost_mmap_bo *args = data;
- struct drm_gem_object *gem_obj;
- int ret;
if (args->flags != 0) {
DRM_INFO("unknown mmap_bo flags: %d\n", args->flags);
return -EINVAL;
}
- gem_obj = drm_gem_object_lookup(file_priv, args->handle);
- if (!gem_obj) {
- DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
- return -ENOENT;
- }
-
- ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret == 0)
- args->offset = drm_vma_node_offset_addr(&gem_obj->vma_node);
- drm_gem_object_put_unlocked(gem_obj);
-
- return ret;
+ return drm_gem_map_offset(file_priv, dev, args->handle,
+ &args->offset);
}
static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] Allwinner H6 Mali GPU support
Hi, The Allwinner H6 has a Mali-T720 MP2 which should be supported by the new panfrost driver. This series fix two issues and introduce the dt-bindings but a simple benchmark show that it's still NOT WORKING. I'm pushing it in case someone want to continue the work. This has been tested with Mesa3D 19.1.0-RC2 and a GPU bitness patch[1]. One patch is from Icenowy Zheng where I changed the order as required by Rob Herring[2]. Thanks, Clement [1] https://gitlab.freedesktop.org/kszaq/mesa/tree/panfrost_64_32 [2] https://patchwork.kernel.org/patch/10699829/ [ 345.204813] panfrost 180.gpu: mmu irq status=1 [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02400400 [ 345.209617] Reason: TODO [ 345.209617] raw fault status: 0x82C1 [ 345.209617] decoded fault status: SLAVE FAULT [ 345.209617] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 [ 345.209617] access type 0x2: READ [ 345.209617] source id 0x8000 [ 345.729957] panfrost 180.gpu: gpu sched timeout, js=0, status=0x8, head=0x2400400, tail=0x2400400, sched_job=9e204de9 [ 346.055876] panfrost 180.gpu: mmu irq status=1 [ 346.060680] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02C00A00 [ 346.060680] Reason: TODO [ 346.060680] raw fault status: 0x810002C1 [ 346.060680] decoded fault status: SLAVE FAULT [ 346.060680] exception type 0xC1: TRANSLATION_FAULT_LEVEL1 [ 346.060680] access type 0x2: READ [ 346.060680] source id 0x8100 [ 346.561955] panfrost 180.gpu: gpu sched timeout, js=1, status=0x8, head=0x2c00a00, tail=0x2c00a00, sched_job=b55a9a85 [ 346.573913] panfrost 180.gpu: mmu irq status=1 [ 346.578707] panfrost 180.gpu: Unhandled Page fault in AS0 at VA 0x02C00B80 Change in v5: - Remove fix indent Changes in v4: - Add bus_clock probe - Fix sanity check in io-pgtable - Add vramp-delay - Merge all boards into one patch - Remove upstreamed Neil A. patch Change in v3 (Thanks to Maxime Ripard): - Reauthor Icenowy for her path Changes in v2 (Thanks to Maxime Ripard): - Drop GPU OPP Table - Add clocks and clock-names in required Clément Péron (5): drm: panfrost: add optional bus_clock iommu: io-pgtable: fix sanity check for non 48-bit mali iommu dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible arm64: dts: allwinner: Add ARM Mali GPU node for H6 arm64: dts: allwinner: Add mali GPU supply for H6 boards Icenowy Zheng (1): dt-bindings: gpu: add bus clock for Mali Midgard GPUs .../bindings/gpu/arm,mali-midgard.txt | 15 - .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 6 + .../dts/allwinner/sun50i-h6-orangepi-3.dts| 6 + .../dts/allwinner/sun50i-h6-orangepi.dtsi | 6 + .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 6 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 drivers/gpu/drm/panfrost/panfrost_device.c| 22 +++ drivers/gpu/drm/panfrost/panfrost_device.h| 1 + drivers/iommu/io-pgtable-arm.c| 2 +- 9 files changed, 76 insertions(+), 2 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/svm: Convert to use hmm_range_fault()
Convert to use hmm_range_fault().
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 93ed43c..8d56bd6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -649,7 +649,7 @@ struct nouveau_svmm {
range.values = nouveau_svm_pfn_values;
range.pfn_shift = NVIF_VMM_PFNMAP_V0_ADDR_SHIFT;
again:
- ret = hmm_vma_fault(&range, true);
+ ret = hmm_range_fault(&range, true);
if (ret == 0) {
mutex_lock(&svmm->mutex);
if (!hmm_vma_range_done(&range)) {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: mxsfb: Remove driver
On 5/20/19 3:06 PM, Fabio Estevam wrote: > There is a DRM version of the mxsfb driver for quite some time > at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining > the fbdev version any longer. > > Remove the fbdev mxsfb driver in favour of the DRM version. > > Signed-off-by: Fabio Estevam Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm/panfrost: drm_gem_map_offset() helper
Panfrost has a re-implementation of drm_gem_dumb_map_offset() with an extra bug regarding the handling of imported buffers. However we don't really want Panfrost calling _dumb functions because it's not a KMS driver. This series renames drm_gem_dumb_map_offset() to drop the '_dumb' and updates Panfrost to use it rather than it's own implementation. v2: https://lore.kernel.org/lkml/20190516141447.46839-1-steven.pr...@arm.com/ Changes since v2: * Drop the shmem helper v1: https://lore.kernel.org/lkml/20190513143244.16478-1-steven.pr...@arm.com/ Changes since v1: * Rename drm_gem_dumb_map_offset to drop _dumb * Add a shmem helper Steven Price (2): drm/gem: Rename drm_gem_dumb_map_offset() to drm_gem_map_offset() drm/panfrost: Use drm_gem_shmem_map_offset() drivers/gpu/drm/drm_dumb_buffers.c | 4 ++-- drivers/gpu/drm/drm_gem.c | 6 +++--- drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +-- drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++-- include/drm/drm_gem.h | 4 ++-- 5 files changed, 10 insertions(+), 23 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/6] dt-bindings: gpu: add bus clock for Mali Midgard GPUs
From: Icenowy Zheng Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by: Icenowy Zheng Signed-off-by: Clément Péron Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 1b1a74129141..2e8bbce35695 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -31,6 +31,12 @@ Optional properties: - clocks : Phandle to clock for the Mali Midgard device. +- clock-names : Specify the names of the clocks specified in clocks + when multiple clocks are present. +* core: clock driving the GPU itself (When only one clock is present, + assume it's this clock.) +* bus: bus clock for the GPU + - mali-supply : Phandle to regulator for the Mali device. Refer to Documentation/devicetree/bindings/regulator/regulator.txt for details. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] drm: panfrost: add optional bus_clock
Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock.
Add an optional bus_clock at the init of the panfrost driver.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_device.c | 22 ++
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 3b2bced1b015..ccb8eb2a518c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -55,11 +55,33 @@ static int panfrost_clk_init(struct panfrost_device *pfdev)
if (err)
return err;
+ pfdev->bus_clock = devm_clk_get_optional(pfdev->dev, "bus");
+ if (IS_ERR(pfdev->bus_clock)) {
+ dev_err(pfdev->dev, "get bus_clock failed %ld\n",
+ PTR_ERR(pfdev->bus_clock));
+ return PTR_ERR(pfdev->bus_clock);
+ }
+
+ if (pfdev->bus_clock) {
+ rate = clk_get_rate(pfdev->bus_clock);
+ dev_info(pfdev->dev, "bus_clock rate = %lu\n", rate);
+
+ err = clk_prepare_enable(pfdev->bus_clock);
+ if (err)
+ goto disable_clock;
+ }
+
return 0;
+
+disable_clock:
+ clk_disable_unprepare(pfdev->clock);
+
+ return err;
}
static void panfrost_clk_fini(struct panfrost_device *pfdev)
{
+ clk_disable_unprepare(pfdev->bus_clock);
clk_disable_unprepare(pfdev->clock);
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 56f452dfb490..8074f221034b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -66,6 +66,7 @@ struct panfrost_device {
void __iomem *iomem;
struct clk *clock;
+ struct clk *bus_clock;
struct regulator *regulator;
struct reset_control *rstc;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/msm: Fix improper uses of smp_mb__{before, after}_atomic()
These barriers only apply to the read-modify-write operations; in
particular, they do not apply to the atomic_set() primitive.
Replace the barriers with smp_mb()s.
Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5XX targets")
Cc: sta...@vger.kernel.org
Reported-by: "Paul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
---
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index 3d62310a535fb..ee0820ee0c664 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -39,10 +39,10 @@ static inline void set_preempt_state(struct a5xx_gpu *gpu,
* preemption or in the interrupt handler so barriers are needed
* before...
*/
- smp_mb__before_atomic();
+ smp_mb();
atomic_set(&gpu->preempt_state, new);
/* ... and after*/
- smp_mb__after_atomic();
+ smp_mb();
}
/* Write the most recent wptr for the given ring into the hardware */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: use struct_size() in kmalloc()
Use struct_size() helper to keep code simple. Signed-off-by: xiaolinkui --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 22bd21e..4717a64 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev) if (con) return 0; - con = kmalloc(sizeof(struct amdgpu_ras) + - sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT, + con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT), GFP_KERNEL|__GFP_ZERO); if (!con) return -ENOMEM; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: backlight: lm3630a: correct schema validation
The '#address-cells' and '#size-cells' properties were not defined in
the lm3630a bindings and would cause the following error when
attempting to validate the examples against the schema:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
'#address-cells', '#size-cells' do not match any of the regexes:
'^led@[01]$', 'pinctrl-[0-9]+'
Correct this by adding those two properties.
While we're here, move the ti,linear-mapping-mode property to the
led@[01] child nodes to correct the following validation error:
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
led@0: 'ti,linear-mapping-mode' does not match any of the regexes:
'pinctrl-[0-9]+'
Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings")
Signed-off-by: Brian Masney
Reported-by: Rob Herring
---
.../leds/backlight/lm3630a-backlight.yaml | 20 +--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
index 4d61fe0a98a4..f0855e248ae5 100644
--- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -23,16 +23,17 @@ properties:
reg:
maxItems: 1
- ti,linear-mapping-mode:
-description: |
- Enable linear mapping mode. If disabled, then it will use exponential
- mapping mode in which the ramp up/down appears to have a more uniform
- transition to the human eye.
-type: boolean
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
required:
- compatible
- reg
+ - '#address-cells'
+ - '#size-cells'
patternProperties:
"^led@[01]$":
@@ -73,6 +74,13 @@ patternProperties:
minimum: 0
maximum: 255
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
required:
- reg
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: lima_bo memory leak after drm_sched job destruction rework
On Fri, May 17, 2019 at 10:43 PM Grodzovsky, Andrey wrote: > On 5/17/19 3:35 PM, Erico Nunes wrote: > > Lima currently defaults to an "infinite" timeout. Setting a 500ms > > default timeout like most other drm_sched users do fixed the leak for > > me. > > I am not very clear about the problem - so you basically never allow a > time out handler to run ? And then when the job hangs for ever you get > this memory leak ? How it worked for you before this refactoring ? As > far as I remember sched->ops->free_job before this change was called > from drm_sched_job_finish which is the work scheduled from HW fence > signaled callback - drm_sched_process_job so if your job hangs for ever > anyway and this work is never scheduled when your free_job callback was > called ? In this particular case, the jobs run successfully, nothing hangs. Lima currently specifies an "infinite" timeout to the drm scheduler, so if a job did did hang, it would hang forever, I suppose. But this is not the issue. If I understand correctly it worked well before the rework because the cleanup was triggered at the end of drm_sched_process_job independently on the timeout. What I'm observing now is that even when jobs run successfully, they are not cleaned by the drm scheduler because drm_sched_cleanup_jobs seems to give up based on the status of a timeout worker. I would expect the timeout value to only be relevant in error/hung job cases. I will probably set the timeout to a reasonable value anyway, I just posted here to report that this can possibly be a bug in the drm scheduler after that rework. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: fix typos in code comments
fix eror to error Signed-off-by: Weitao Hou --- drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c index f70437aae8e0..df422440845b 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c @@ -183,8 +183,8 @@ static bool calculate_fb_and_fractional_fb_divider( *RETURNS: * It fills the PLLSettings structure with PLL Dividers values * if calculated values are within required tolerance -* It returns - true if eror is within tolerance -* - false if eror is not within tolerance +* It returns - true if error is within tolerance +* - false if error is not within tolerance */ static bool calc_fb_divider_checking_tolerance( struct calc_pll_clock_source *calc_pll_cs, -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/msm/mdp5: Fix mdp5_cfg_init error return
If mdp5_cfg_init fails because of an unknown major version, a null pointer dereference occurs. This is because the caller of init expects error pointers, but init returns NULL on error. Fix this by returning the expected values on error. Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module) Signed-off-by: Jeffrey Hugo Reviewed-by: Bjorn Andersson --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c index ea8f7d7daf7f..52e23780fce1 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c @@ -721,7 +721,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms *mdp5_kms, if (cfg_handler) mdp5_cfg_destroy(cfg_handler); - return NULL; + return ERR_PTR(ret); } static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
lima_bo memory leak after drm_sched job destruction rework
Hello, I have recently observed a memory leak issue with lima using drm-misc-next, which I initially reported here: https://gitlab.freedesktop.org/lima/linux/issues/24 It is an easily reproduceable memory leak which I was able to bisect to commit: 5918045c4ed4 drm/scheduler: rework job destruction After some investigation, it seems that after the refactor, sched->ops->free_job (in lima: lima_sched_free_job) is no longer called. With some more debugging I found that it is not being called because the job freeing is now in drm_sched_cleanup_jobs, which for lima always aborts in the initial "Don't destroy jobs while the timeout worker is running" condition. Lima currently defaults to an "infinite" timeout. Setting a 500ms default timeout like most other drm_sched users do fixed the leak for me. I can send a patch to set a 500ms timeout and have it probably working again, but I am wondering now if this is expected behaviour for drm_sched after the refactor. In particular I also noticed that drm_sched_suspend_timeout is not called anywhere. Is it expected that we now rely on a timeout parameter to cleanup jobs that ran successfully? Erico ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RE-RESEND 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
Hello Sam, On 5/8/19 11:06 AM, Daniel Vetter wrote: > On Wed, May 08, 2019 at 10:33:03AM +0200, Daniel Vetter wrote: >> On Tue, May 07, 2019 at 06:19:50PM +0200, Sam Ravnborg wrote: >>> Hi Fabio >>> >>> On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote: [Adding Sam, who is helping to review/collect panel-simple patches] On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski wrote: > > This patch adds support for the Armadeus ST0700 Adapt. It comes with a > Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so > that it can be connected on the TFT header of Armadeus Dev boards. > > Cc: sta...@vger.kernel.org # v4.19 > Reviewed-by: Rob Herring > Signed-off-by: Sébastien Szymanski >>> Reviewed-by: Sam Ravnborg >>> >>> If you wil lresend the patch I can apply it. >>> I have lost the original mail. >> >> Usually patchwork should have it already (and you can pipe the raw >> patchwork mbox into dim apply), but somehow it's not there either. >> Not sure why, sometimes this is because mails are stuck in moderation, >> sometimes because people do interesting things with their mails (e.g. smtp >> servers mangling formatting). > > patchwork was just a bit slow, it's there now: > > https://patchwork.freedesktop.org/series/60408/ > Will you take the patch from patchwork or should I resent it ? Regards, > Cheers, Daniel > -- Sébastien Szymanski Software engineer, Armadeus Systems Tel: +33 (0)9 72 29 41 44 Fax: +33 (0)9 72 28 79 26 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/6] dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible
This add the H6 mali compatible in the dt-bindings to later support specific implementation. Signed-off-by: Clément Péron Reviewed-by: Rob Herring --- .../devicetree/bindings/gpu/arm,mali-midgard.txt | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 2e8bbce35695..4bf17e1cf555 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -15,6 +15,7 @@ Required properties: + "arm,mali-t860" + "arm,mali-t880" * which must be preceded by one of the following vendor specifics: ++ "allwinner,sun50i-h6-mali" + "amlogic,meson-gxm-mali" + "rockchip,rk3288-mali" + "rockchip,rk3399-mali" @@ -49,9 +50,15 @@ Vendor-specific bindings The Mali GPU is integrated very differently from one SoC to -another. In order to accomodate those differences, you have the option +another. In order to accommodate those differences, you have the option to specify one more vendor-specific compatible, among: +- "allwinner,sun50i-h6-mali" + Required properties: + - clocks : phandles to core and bus clocks + - clock-names : must contain "core" and "bus" + - resets: phandle to GPU reset line + - "amlogic,meson-gxm-mali" Required properties: - resets : Should contain phandles of : -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110729] Broken links on Linux Man Pages
https://bugs.freedesktop.org/show_bug.cgi?id=110729 Eric Engestrom changed: What|Removed |Added Product|Mesa|DRI Version|19.1|unspecified Component|Other |libdrm QA Contact|mesa-dev@lists.freedesktop. | |org | Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org --- Comment #1 from Eric Engestrom --- We have no control over that website :) Beside, this is a libdrm issue, not Mesa, so reassigning. The actual issue is that not enough documentation has been written, including several (most) functions that have none. This is something that we've known for a while but haven't dealt with yet. -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #4 from alvarex --- yes the bug was not present on 19.0.4. I'll give it a shot, I don't compile mesa from git in a standard way, I compile it on opensuse build service. -- 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/sched: Fix static checker warning for potential NULL ptr
Am 22.05.19 um 15:57 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 90d7a82..ec7faca 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -286,16 +286,17 @@ static void drm_sched_job_timedout(struct work_struct
*work)
job = list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node);
- if (job)
+ if (job) {
job->sched->ops->timedout_job(job);
- /*
-* Guilty job did complete and hence needs to be manually removed
-* See drm_sched_stop doc.
-*/
- if (sched->free_guilty) {
- job->sched->ops->free_job(job);
- sched->free_guilty = false;
+ /*
+* Guilty job did complete and hence needs to be manually
removed
+* See drm_sched_stop doc.
+*/
+ if (sched->free_guilty) {
+ job->sched->ops->free_job(job);
+ sched->free_guilty = false;
+ }
}
spin_lock_irqsave(&sched->job_list_lock, flags);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #3 from Eric Engestrom --- (In reply to alvarex from comment #2) > now the bug has hit 19.0.5. Are you saying the bug was not present in 19.0.4, but is now present in 19.0.5? If so, that's only 22 new commits, 10 if you exclude obvious non-candidates. If you can reliably test this, that's at most 5 build & test you need to do when bisecting mesa-19.0.4..mesa-19.0.5; could you do this please? It would greatly help figure out the cause :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sched: Fix static checker warning for potential NULL ptr
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 90d7a82..ec7faca 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -286,16 +286,17 @@ static void drm_sched_job_timedout(struct work_struct
*work)
job = list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node);
- if (job)
+ if (job) {
job->sched->ops->timedout_job(job);
- /*
-* Guilty job did complete and hence needs to be manually removed
-* See drm_sched_stop doc.
-*/
- if (sched->free_guilty) {
- job->sched->ops->free_job(job);
- sched->free_guilty = false;
+ /*
+* Guilty job did complete and hence needs to be manually
removed
+* See drm_sched_stop doc.
+*/
+ if (sched->free_guilty) {
+ job->sched->ops->free_job(job);
+ sched->free_guilty = false;
+ }
}
spin_lock_irqsave(&sched->job_list_lock, flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/scheduler: rework job destruction
Thanks for letting know, I will send a fix soon.
Andrey
On 5/22/19 9:07 AM, Dan Carpenter wrote:
> [CAUTION: External Email]
>
> Hello Christian König,
>
> The patch 5918045c4ed4: "drm/scheduler: rework job destruction" from
> Apr 18, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/scheduler/sched_main.c:297 drm_sched_job_timedout()
> error: potential NULL dereference 'job'.
>
> drivers/gpu/drm/scheduler/sched_main.c
> 279 static void drm_sched_job_timedout(struct work_struct *work)
> 280 {
> 281 struct drm_gpu_scheduler *sched;
> 282 struct drm_sched_job *job;
> 283 unsigned long flags;
> 284
> 285 sched = container_of(work, struct drm_gpu_scheduler,
> work_tdr.work);
> 286 job = list_first_entry_or_null(&sched->ring_mirror_list,
> 287 struct drm_sched_job, node);
> 288
> 289 if (job)
> ^^^
> We assume that job can be NULL.
>
> 290 job->sched->ops->timedout_job(job);
> 291
> 292 /*
> 293 * Guilty job did complete and hence needs to be manually
> removed
> 294 * See drm_sched_stop doc.
> 295 */
> 296 if (sched->free_guilty) {
>
> Originally (last week) this check was "if (list_empty(&job->node))"
> which is obviously problematic if job is NULL. It's not clear to me
> that this new check ensures that job is non-NULL either.
>
> 297 job->sched->ops->free_job(job);
> ^
> Dereference.
>
> 298 sched->free_guilty = false;
> 299 }
> 300
> 301 spin_lock_irqsave(&sched->job_list_lock, flags);
> 302 drm_sched_start_timeout(sched);
> 303 spin_unlock_irqrestore(&sched->job_list_lock, flags);
> 304 }
>
> regards,
> dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
