[PATCH 07/21] bindings: display: Add compatible for A64 HDMI
HDMI on Allwinner A64 has similar like H3/H5. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index f0fd9274a25d..9ea4353caadd 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -78,6 +78,7 @@ Required properties: - compatible: value must be one of: * "allwinner,sun8i-a83t-dw-hdmi" +* "allwinner,sun50i-a64-dw-hdmi" - reg: base address and size of memory-mapped region - reg-io-width: See dw_hdmi.txt. Shall be 1. - interrupts: HDMI interrupt number -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/21] dt-bindings: clock: Add compatible for A64 DE2 CCU
Allwinner A64 has DE2 CCU which is similar to H3/H5 SoC. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/clock/sun8i-de2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt index f2fa87c4765c..7f425bc0e820 100644 --- a/Documentation/devicetree/bindings/clock/sun8i-de2.txt +++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt @@ -7,6 +7,7 @@ Required properties : - "allwinner,sun8i-h3-de2-clk" - "allwinner,sun8i-v3s-de2-clk" - "allwinner,sun50i-h5-de2-clk" + - "allwinner,sun50i-a64-de2-clk" - reg: Must contain the registers base address and length - clocks: phandle to the clocks feeding the display engine subsystem. -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 21/21] arm64: dts: allwinner: a64: sopine: Enable HDMI output
Enable HDMI output on sopine board.
Signed-off-by: Jagan Teki
---
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index abe179de35d7..72f29b78117c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_vcc1v8: vcc1v8 {
compatible = "regulator-fixed";
regulator-name = "vcc1v8";
@@ -69,6 +80,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -86,6 +101,17 @@
status = "okay";
};
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/21] arm64: dts: allwinner: a64: bananapi-m64: Enable HDMI output
Enable HDMI output on Bananpi-m64 board.
Signed-off-by: Jagan Teki
---
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 2250dec9974c..69063c1fbddf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -86,6 +97,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -99,6 +114,17 @@
status = "okay";
};
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support
On Fri, Apr 27, 2018 at 01:21:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patchset removes unused MERAM support (last user was removed > 3 years ago) from shmobile fbdev & drm drivers and then removes > MERAM driver itself. > > If it is okay to merge this patches I would like patch #1 to go > through fbdev tree and patch #2 to go through drm tree. Once they > are both upstream (v4.18) I will apply patch #3 to fbdev tree. Nice to see this cleanup, thanks. Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] drm/amd/dc: Add dc display driver (v2)
Hi Harry, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found the following commit introduced the bug: commit 4562236b3bc0a28aeb6ee93b2d8a849a4c4e1c7c Author: Harry Wentland Date: Tue Sep 12 15:58:20 2017 -0400 drm/amd/dc: Add dc display driver (v2) The regression was introduced as of v4.15-rc1 and still exists in current mainline. The commit does not need to be reverted to resolve the bug. Disabling the CONFIG_DRM_AMD_DC_PRE_VEGA option makes the bug go away. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue? Thanks, Joe [0] http://pad.lv/1761751 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/21] drm/sun4i: Enable DE2 Mixer for Allwinner 64-bit SoCs
Allwinner 64-bit SoC like H5/A64 has DE2 Mixer so enable them as default. Signed-off-by: Jagan Teki --- drivers/gpu/drm/sun4i/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index 60468a779a63..95ae04964756 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -52,7 +52,7 @@ config DRM_SUN8I_DW_HDMI config DRM_SUN8I_MIXER tristate "Support for Allwinner Display Engine 2.0 Mixer" - default MACH_SUN8I + default MACH_SUN8I || (ARM64 && ARCH_SUNXI) help Choose this option if you have an Allwinner SoC with the Allwinner Display Engine 2.0, which has a mixer to do some -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs
Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them as default. Signed-off-by: Jagan Teki --- drivers/clk/sunxi-ng/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig index 79dfd296c3d1..1fffd3bf6ff3 100644 --- a/drivers/clk/sunxi-ng/Kconfig +++ b/drivers/clk/sunxi-ng/Kconfig @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU config SUN8I_DE2_CCU bool "Support for the Allwinner SoCs DE2 CCU" + default ARM64 && ARCH_SUNXI + depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST config SUN8I_R40_CCU bool "Support for the Allwinner R40 CCU" -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/21] bindings: display: Add compatible for A64 HDMI PHY
HDMI PHY on Allwinner A64 has similar like H3/H5. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 9ea4353caadd..7dcd1d64dfe4 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -104,6 +104,7 @@ Required properties: - compatible: value must be one of: * allwinner,sun8i-a83t-hdmi-phy * allwinner,sun8i-h3-hdmi-phy +* allwinner,sun50i-a64-hdmi-phy - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the HDMI PHY * bus: the HDMI PHY interface clock -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/21] arm64: dts: allwinner: a64: a64-olinuxino: Enable HDMI output
Enable HDMI output on a64-olinuxino board.
Signed-off-by: Jagan Teki
---
.../boot/dts/allwinner/sun50i-a64-olinuxino.dts| 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 3b3081b10ecb..83329c8fec4f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -58,12 +58,38 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
};
+&de {
+ status = "okay";
+};
+
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 24/24] drm/bridge: establish a link between the bridge supplier and consumer
On 2018-04-30 17:32, Daniel Vetter wrote: > On Fri, Apr 27, 2018 at 12:31:39AM +0200, Peter Rosin wrote: >> If the bridge supplier is unbound, this will bring the bridge consumer >> down along with the bridge. Thus, there will no longer linger any >> dangling pointers from the bridge consumer (the drm_device) to some >> non-existent bridge supplier. >> >> Signed-off-by: Peter Rosin > > Minus the ->owner bikeshed I brought up in the previous patch I agree with > this approach as the best way to move forward for now. > > Acked-by: Daniel Vetter Thanks, let's see if Laurent is also on-board... > One small suggestion below, for merging I'd say pls get Jyri's > review/tested-by too, since you're both working on the same problem it > seems. Yes, I too would be very happy to see a tested-by from someone. > Aside: Do you want commit rights to drm-misc to be able to push work like > this? If that makes life easier, sure. Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
On Sat, Apr 28, 2018 at 12:34:26AM +0300, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Friday, 27 April 2018 19:57:21 EEST Kieran Bingham wrote: > > The DU1 external dot clock is provided by the fixed frequency clock > > generator X21, while the DU0 and DU3 clocks are provided by the > > programmable Versaclock5 clock generator. > > > > Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board > > and hook it up to the HDMI connector. > > > > Based on patches from Takeshi Kihara > > > > Signed-off-by: Kieran Bingham > > Reviewed-by: Laurent Pinchart Thanks, applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
HDMI on Allwinner A64 has similar behavior like H3/H5, so
reuse the same dts node details for A64.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 +++
include/dt-bindings/clock/sun50i-a64-ccu.h| 2 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 67b80bbe5bf5..da9128ae836d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -644,6 +644,34 @@
#interrupt-cells = <3>;
};
+ hdmi: hdmi@1ee {
+ compatible = "allwinner,sun50i-a64-dw-hdmi",
+"allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
+<&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+ };
+
+ hdmi_phy: hdmi-phy@1ef {
+ compatible = "allwinner,sun50i-a64-hdmi-phy",
+"allwinner,sun8i-h3-hdmi-phy";
+ reg = <0x01ef 0x1>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
+<&ccu CLK_PLL_VIDEO1>;
+ clock-names = "bus", "mod", "pll-0";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
+
rtc: rtc@1f0 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f0 0x54>;
diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h
b/include/dt-bindings/clock/sun50i-a64-ccu.h
index d66432c6e675..41c09df797ef 100644
--- a/include/dt-bindings/clock/sun50i-a64-ccu.h
+++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
@@ -45,6 +45,8 @@
#define CLK_PLL_PERIPH011
+#define CLK_PLL_VIDEO1 15
+
#define CLK_BUS_MIPI_DSI 28
#define CLK_BUS_CE 29
#define CLK_BUS_DMA30
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 23/24] drm/bridge: require the .owner to be filled in on drm_bridge_attach
On 2018-04-30 17:24, Daniel Vetter wrote: > On Fri, Apr 27, 2018 at 12:31:38AM +0200, Peter Rosin wrote: >> The .owner will be handy to have around. >> >> Signed-off-by: Peter Rosin >> --- >> drivers/gpu/drm/drm_bridge.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c >> index 9f023bd84d56..a038da696802 100644 >> --- a/drivers/gpu/drm/drm_bridge.c >> +++ b/drivers/gpu/drm/drm_bridge.c >> @@ -115,6 +115,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, >> struct drm_bridge *bridge, >> if (!encoder || !bridge) >> return -EINVAL; >> >> +if (WARN_ON(!bridge->owner)) >> +return -EINVAL; > > I think conceptually this is checked at the wrong place, and I think also > misnamed > a bit. The ->owner is essentially the struct device (and its associated > driver) that provides the drm_bridge. As such it should be filled out > already at drm_bridge_add() time, and I think the check should be in > there. For driver-internal bridges it might make sense to also check this > here, not sure. Or just require all bridges get added. The reason for the position is that while I originally had the WARN in drm_bridge_add, I found that quite a few bridges never call drm_bridge_add. So I moved it. Other options are to start requiring all bridge suppliers to call drm_bridge_add or to have the WARN in both function. Too me, it would make sense to require all bridge suppliers to call drm_bridge_add, as that enables other init stuff later, when needed. But that is a hairy patch to get right, and is probably best left as a separate series. > Wrt the name, I think we should call this pdev or something. ->owner > usually means the module owner. I think in other subsystems ->dev is used, > but in drm we use ->dev for the drm_device pointer, so totally different > thing. pdev = physical device is the best I came up with. Better > suggestions very much welcome. pdev is about as problematic as owner. To me it reads "platform device". And dev for a drm_device is also somewhat problematic, and I think that drm would have been better, but dev for drm_device is probably quite common. But one way to go is to rename the current dev to drm, so that dev is freed up for the owner/supplier device. But that is a tedious patch to write (I don't do the cocci thing). Other suggestions I can think of: odev for owner device, sdev for supplier device or just plain supplier. Cheers, Peter > -Daniel > >> + >> if (previous && (!previous->dev || previous->encoder != encoder)) >> return -EINVAL; >> >> -- >> 2.11.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
Re: [PATCH v3 1/3] drm/prime: Iterate SG DMA addresses separately
On 4/30/2018 9:54 AM, Robin Murphy wrote: > For dma_map_sg(), DMA API implementations are free to merge consecutive > segments into a single DMA mapping if conditions are suitable, thus the > resulting DMA addresses which drm_prime_sg_to_page_addr_arrays() > iterates over may be packed into fewer entries than sgt->nents implies. > > The current implementation does not account for this, meaning that its > callers either have to reject the 0 < count < nents case or risk getting > bogus DMA addresses beyond the first segment. Fortunately this is quite > easy to handle without having to rejig structures to also store the > mapped count, since the total DMA length should still be equal to the > total buffer length. All we need is a second scatterlist cursor to > iterate through the DMA addresses independently of the page addresses. > > Reviewed-by: Christian König > Signed-off-by: Robin Murphy > --- Much better Tested-by: Sinan Kaya for the first two patches. (1/3 and 2/3) -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/21] arm64: dts: allwinner: a64: pine64: Enable HDMI output
Enable HDMI output on pine64 board.
Signed-off-by: Jagan Teki
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index a75825798a71..a4ec0900a885 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -62,6 +62,21 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&ehci0 {
@@ -82,6 +97,17 @@
};
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/21] arm64: dts: allwinner: a64: Add DE2 CCU
DE2 in A64 has clock control unit and behavior is
same like H3/H5, so reuse the same in A64.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..67b80bbe5bf5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -43,9 +43,11 @@
*/
#include
+#include
#include
#include
#include
+#include
/ {
interrupt-parent = <&gic>;
@@ -168,6 +170,19 @@
#size-cells = <1>;
ranges;
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun50i-a64-de2-clk",
+"allwinner,sun50i-h5-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun50i-a64-system-controller",
"syscon";
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/21] drm/sun4i: Enable DesignWare HDMI for Allwinner 64-bit SoCs
Allwinner 64-bit SoC like H5/A64 has DesignWare HDMI so enable them as default. Signed-off-by: Jagan Teki --- drivers/gpu/drm/sun4i/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index eee6bc0eaf97..60468a779a63 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -42,6 +42,7 @@ config DRM_SUN4I_BACKEND config DRM_SUN8I_DW_HDMI tristate "Support for Allwinner version of DesignWare HDMI" + default ARM64 && ARCH_SUNXI depends on DRM_SUN4I select DRM_DW_HDMI help -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: omap2: remove rfbi
Hi, On Mon, Apr 30, 2018 at 10:06:11AM +0300, Tomi Valkeinen wrote: > On 27/04/18 21:12, Aaro Koskinen wrote: > >> You should be targeting omapdrm driver instead, fbdev subsystem is closed > >> for the new hardware support. > > > > AFAIK, based on N950 display support discussion, it's impossible to get > > anything new into omapdrm for a long time. And based on Tomi's comments, > > restoring RFBI support with omapfb should be a minor thing. > > I was perhaps a bit vague, but I didn't say it should be a minor thing. > I meant that there should be no architectural obstacles in omapfb, and I > think all the generic plumbing to enable N800 display is there in omapfb. > > That said, it still needs a real amount of work with the rfbi driver, > the encoder driver and the panel driver on N800 (the encoder and the > panel driver are not in mainline anymore). Let's see first if I get anything working. After that we can evaluate the impact properly once we see the actual patches needed. A. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/21] arm64: dts: allwinner: a64: Add HDMI pipeline
HDMI pipeline on A64 has similar behavior like A83T where
tcon1 is connected to HDMI. So reuse similar dts nodes for A64.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 83 +++
1 file changed, 83 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index da9128ae836d..f017baa4f5db 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -107,6 +107,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun50i-a64-display-engine";
+ allwinner,pipelines = <&mixer1>;
+ status = "disabled";
+ };
+
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -183,6 +189,31 @@
#reset-cells = <1>;
};
+ mixer1: mixer@120 {
+ compatible = "allwinner,sun50i-a64-de2-mixer-1",
+"allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x0120 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ reg = <1>;
+
+ mixer1_out_tcon1: endpoint {
+ remote-endpoint =
<&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
+
syscon: syscon@1c0 {
compatible = "allwinner,sun50i-a64-system-controller",
"syscon";
@@ -200,6 +231,41 @@
#dma-cells = <1>;
};
+ tcon1: lcd-controller@1c0d000 {
+ compatible = "allwinner,sun50i-a64-tcon-tv",
+"allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ reg = <0>;
+
+ tcon1_in_mixer1: endpoint {
+ remote-endpoint =
<&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
@@ -658,6 +724,23 @@
phys = <&hdmi_phy>;
phy-names = "hdmi-phy";
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+
+ hdmi_in_tcon1: endpoint {
+ remote-endpoint =
<&tcon1_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
+ };
};
hdmi_phy: hdmi-phy@1ef {
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/21] arm64: dts: allwinner: a64: nanopi-a64: Enable HDMI output
Enable HDMI output on nanopi-a64 board.
Signed-off-by: Jagan Teki
---
.../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index e2dce48fa29a..19fe7eed45e9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -57,6 +57,21 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&ehci0 {
@@ -67,6 +82,17 @@
status = "okay";
};
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
/* i2c1 connected with gpio headers like pine64, bananapi */
&i2c1 {
pinctrl-names = "default";
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/21] arm64: allwinner: Add A64 DE2 HDMI support
Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5. A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0 with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with HDMI as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf This is the first series on Allwinner A64 DE2 HDMI support which followed with previous RFC series [1] (thanks to Maxime, Jernej for comments on RFC series) and rest will add in future patches. patch 1: dt-bindings for a64 de2 ccu patch 2: add node support for a64 de2 ccu patch 3: enable DE2_CCU for Allwinner 64-bit SoCs patch 4: dt-bindings for a64 de2 pipeline patch 5: add support for a64 de2 patch 6: defconfig: enable CONFIG_DRM_SUN4I patch 7 -8: dt-bindings for a64 HDMI and HDMI PHY patch 9: add support for a64 HDMI patch 10: enable DesignWare HDMI for Allwinner 64-bit SoCs patch 11 - 12: dt-bindings for a64 mixer1 and tcon1 patch 13: enable de2 mixer for Allwinner 64-bit SoCs patch 14: add support for a64 HDMI pipeline patch 15: add support for HVCC regulator patch 16: enable HDMI out for bananapi-m64 patch 17: enable HDMI out for nanopi-a64 patch 18: enable HDMI out for orangepi-win patch 19: enable HDMI out for a64-olinuxino patch 20: enable HDMI out for pine64 patch 21: enable HDMI out for sopine Since this series added HDMI through mixer1 through tcon1, I have used CLK_PLL_VIDEO1 as pll-0 we need to update the driver to support both CLK_PLL_VIDEO0 and 1 once we have add hdmi through mixer0. Note: with pine64 and sopine, I'm unable to see any display on screen but loadded fine, request to verify anyone. Log: --- # modprobe -a sun4i-drm sun8i-mixer sun4i_tv sun4i-drm-hdmi sun8i-drm-hdmi [ 13.390465] sun4i-drm display-engine: bound 120.mixer (ops sun8i_mixer_ops [sun8i_mixer]) [ 13.399247] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 13.407113] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops sun4i_tcon_ops [sun4i_tcon]) [ 13.417386] sun8i-dw-hdmi 1ee.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_ph y) [ 13.427436] sun8i-dw-hdmi 1ee.hdmi: registered DesignWare HDMI I2C bus driver [ 13.435987] sun4i-drm display-engine: bound 1ee.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi]) [ 13.444868] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.451498] [drm] No driver support for vblank timestamp query. [ 13.96] Console: switching to colour frame buffer device 320x90 [ 14.008789] sun4i-drm display-engine: fb0: frame buffer device [ 14.028297] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [1] https://lkml.org/lkml/2018/4/24/547 Icenowy Zheng (1): drm: sun4i: add support for HVCC regulator for DWC HDMI glue Jagan Teki (20): dt-bindings: clock: Add compatible for A64 DE2 CCU arm64: dts: allwinner: a64: Add DE2 CCU clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs bindings: display: Add compatible for A64 DE2 pipeline drm/sun4i: Add support for A64 display engine arm64: defconfig: Enable CONFIG_DRM_SUN4I bindings: display: Add compatible for A64 HDMI bindings: display: Add compatible for A64 HDMI PHY arm64: dts: allwinner: a64: Add HDMI support drm/sun4i: Enable DesignWare HDMI for Allwinner 64-bit SoCs bindings: display: Add compatible for A64 Mixer1 bindings: display: Add compatible for A64 tcon-tv drm/sun4i: Enable DE2 Mixer for Allwinner 64-bit SoCs arm64: dts: allwinner: a64: Add HDMI pipeline arm64: dts: allwinner: a64: bananapi-m64: Enable HDMI output arm64: dts: allwinner: a64: nanopi-a64: Enable HDMI output arm64: dts: allwinner: a64: orangepi-win: Enable HDMI output arm64: dts: allwinner: a64: a64-olinuxino: Enable HDMI output arm64: dts: allwinner: a64: pine64: Enable HDMI output arm64: dts: allwinner: a64: sopine: Enable HDMI output .../devicetree/bindings/clock/sun8i-de2.txt| 1 + .../bindings/display/sunxi/sun4i-drm.txt | 5 + .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 26 + .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 26 + .../boot/dts/allwinner/sun50i-a64-olinuxino.dts| 26 + .../boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 26 + .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 26 + .../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 26 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 126 + arch/arm64/configs/defconfig | 1 + drivers/clk/sunxi-ng/Kconfig | 2 + drivers/gpu/drm/sun4i/Kconfig | 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 14 +++ drivers/gpu/drm/sun4i/sun8i_dw
Re: [PATCH v2 08/11] arm64: dts: r8a77965: Populate the DU instance placeholder
On Fri, Apr 27, 2018 at 05:57:19PM +0100, Kieran Bingham wrote: > The DU entity node has been previously added but only as a placeholder. > Populate the node with the properties to use the device. > > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/11] arm64: dts: r8a77965: Add FCPF and FCPV instances
On Fri, Apr 27, 2018 at 05:57:17PM +0100, Kieran Bingham wrote: > The FCPs handle the interface between various IP cores and memory. Add > the instances related to the FDPs and VSP2s. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebase to top of tree] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/21] bindings: display: Add compatible for A64 DE2 pipeline
Allwinner A64 has DE2 pipeline similar to other Allwinner SOC's like A83T, H3/H5. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 3346c1e2a7a0..f0fd9274a25d 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -343,6 +343,7 @@ Required properties: * allwinner,sun8i-h3-display-engine * allwinner,sun8i-v3s-display-engine * allwinner,sun9i-a80-display-engine +* allwinner,sun50i-a64-display-engine - allwinner,pipelines: list of phandle to the display engine frontends (DE 1.0) or mixers (DE 2.0) available. -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] arm64: dts: r8a77965: Add HDMI encoder instance
On Fri, Apr 27, 2018 at 05:57:20PM +0100, Kieran Bingham wrote: > Add the HDMI encoder to the R8A77965 DT in disabled state. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebase to top of tree] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/11] arm64: dts: r8a77965: Add VSP instances
On Fri, Apr 27, 2018 at 05:57:18PM +0100, Kieran Bingham wrote: > The r8a77965 has 4 VSP instances. > > Based on a similar patch of the R8A7796 device tree > by Laurent Pinchart . > > Signed-off-by: Takeshi Kihara > [Kieran: Rebased to top of tree, fixed sort orders] > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart Thanks, applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: omap2: remove rfbi
Hi, On Mon, Apr 30, 2018 at 05:34:59PM +0200, Bartlomiej Zolnierkiewicz wrote: > BROKEN is not an user selectable config option so without modifying > drivers/video/fbdev/omap2/omapfb/dss/Kconfig the RFBI driver is not > even included in the kernel build.. Yes, I know. It's still incorrect to state that the code "doesn't even compile". A. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/21] drm/sun4i: Add support for A64 display engine
A64 display engine has two mixers which are connected to
LVDS/RGB/MIPI-DSI and HDMI output through tcon0 and tcon1.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..c84102a750f8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -368,6 +368,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-h3-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ .compatible = "allwinner,sun9i-a80-display-engine" },
+ { .compatible = "allwinner,sun50i-a64-display-engine" },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/21] bindings: display: Add compatible for A64 tcon-tv
tcon-tv on Allwinner A64 has similar behavior like Allwinner A83T. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 5d448ef2132f..8b6b4bc43d98 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -150,6 +150,7 @@ Required properties: * allwinner,sun8i-v3s-tcon * allwinner,sun9i-a80-tcon-lcd * allwinner,sun9i-a80-tcon-tv + * allwinner,sun50i-a64-tcon-tv - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/24] drm/bridge: remove the .of_node member
On 2018-04-28 10:09, kbuild test robot wrote: > Hi Peter, > > I love your patch! Yet something to improve: > > [auto build test ERROR on v4.17-rc2] > [also build test ERROR on next-20180426] > [cannot apply to drm/drm-next robclark/msm-next > drm-exynos/exynos-drm/for-next] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Peter-Rosin/device-link-bridge-supplier-drm-device/20180428-135229 > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All errors (new ones prefixed by >>): > >drivers/gpu//drm/rockchip/rockchip_lvds.c: In function > 'rockchip_lvds_bind': >>> drivers/gpu//drm/rockchip/rockchip_lvds.c:381:24: error: 'struct >>> drm_bridge' has no member named 'of_node' > remote = lvds->bridge->of_node; >^~ > > vim +381 drivers/gpu//drm/rockchip/rockchip_lvds.c Ugh. So, patch 1/24 needs to be amended with this diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c index e67f4ea28c0e..3f33034b3f58 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master, } if (lvds->panel) remote = lvds->panel->dev->of_node; - else + else if (lvds->bridge->of_node) remote = lvds->bridge->of_node; + else + remote = lvds->bridge->owner->of_node; if (of_property_read_string(dev->of_node, "rockchip,output", &name)) /* default set it as output rgb */ lvds->output = DISPLAY_OUTPUT_RGB; and patch 22/24 with this diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c index 3f33034b3f58..8c82fa647536 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master, } if (lvds->panel) remote = lvds->panel->dev->of_node; - else if (lvds->bridge->of_node) - remote = lvds->bridge->of_node; else remote = lvds->bridge->owner->of_node; if (of_property_read_string(dev->of_node, "rockchip,output", &name)) But that is of course just a stop-gap. The real fix is to adapt to the "drm: bridge: Add support for static image formats" series from Jacopo. But that's orthogonal. Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/21] arm64: defconfig: Enable CONFIG_DRM_SUN4I
Enable DRM Support for Allwinner Display Engine, built as a module. Signed-off-by: Jagan Teki --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 8ac1feafe563..723e6a5121fa 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -410,6 +410,7 @@ CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_EXYNOS_MIC=y CONFIG_DRM_ROCKCHIP=m +CONFIG_DRM_SUN4I=m CONFIG_ROCKCHIP_ANALOGIX_DP=y CONFIG_ROCKCHIP_CDN_DP=y CONFIG_ROCKCHIP_DW_HDMI=y -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/21] drm: sun4i: add support for HVCC regulator for DWC HDMI glue
From: Icenowy Zheng
Allwinner SoCs with DWC HDMI controller have a "HVCC" power pin for the
HDMI part, and on some boards it's connected to a dedicated regulator
rather than the main 3.3v.
Add support for optional HVCC regulator. For boards that doesn't use a
dedicated regulator to power it, the default dummy regulator is used.
Signed-off-by: Icenowy Zheng
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 14 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 9f40a44b456b..7c33faff7ad4 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -73,6 +73,12 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
if (encoder->possible_crtcs == 0)
return -EPROBE_DEFER;
+ hdmi->vcc_hdmi = devm_regulator_get(dev, "hvcc");
+ if (IS_ERR(hdmi->vcc_hdmi)) {
+ dev_err(dev, "Could not get HDMI power supply\n");
+ return PTR_ERR(hdmi->vcc_hdmi);
+ }
+
hdmi->rst_ctrl = devm_reset_control_get(dev, "ctrl");
if (IS_ERR(hdmi->rst_ctrl)) {
dev_err(dev, "Could not get ctrl reset control\n");
@@ -91,6 +97,12 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
return ret;
}
+ ret = regulator_enable(hdmi->vcc_hdmi);
+ if (ret) {
+ dev_err(dev, "Cannot enable HDMI power supply\n");
+ goto err_disable_vcc;
+ }
+
ret = clk_prepare_enable(hdmi->clk_tmds);
if (ret) {
dev_err(dev, "Could not enable tmds clock\n");
@@ -143,6 +155,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
clk_disable_unprepare(hdmi->clk_tmds);
err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
+err_disable_vcc:
+ regulator_disable(hdmi->vcc_hdmi);
return ret;
}
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 79154f0f674a..c25d75ef9303 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#define SUN8I_HDMI_PHY_DBG_CTRL_REG0x
@@ -173,6 +174,7 @@ struct sun8i_dw_hdmi {
struct drm_encoder encoder;
struct sun8i_hdmi_phy *phy;
struct dw_hdmi_plat_dataplat_data;
+ struct regulator*vcc_hdmi;
struct reset_control*rst_ctrl;
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/21] arm64: dts: allwinner: a64: orangepi-win: Enable HDMI output
Enable HDMI output on Orangepi-win board.
Signed-off-by: Jagan Teki
---
.../boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index bf42690a3361..b6fdd052d473 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -57,12 +57,38 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&ehci1 {
status = "okay";
};
+&hdmi {
+ hvcc-supply = <®_dldo1>;
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/21] bindings: display: Add compatible for A64 Mixer1
Mixer1 on Allwinner A64 has similar behavior like Allwinner A83T. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 7dcd1d64dfe4..5d448ef2132f 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -313,6 +313,7 @@ Required properties: * allwinner,sun8i-a83t-de2-mixer-1 * allwinner,sun8i-h3-de2-mixer-0 * allwinner,sun8i-v3s-de2-mixer +* allwinner,sun50i-a64-de2-mixer-1 - reg: base address and size of the memory-mapped region. - clocks: phandles to the clocks feeding the mixer * bus: the mixer interface clock -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105832] radeonsi NIR missing bindless textures support
https://bugs.freedesktop.org/show_bug.cgi?id=105832 Timothy Arceri changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/radeonsi QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- 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 199577] New: amdgpu fails to return from powersaving mode
https://bugzilla.kernel.org/show_bug.cgi?id=199577 Bug ID: 199577 Summary: amdgpu fails to return from powersaving mode Product: Drivers Version: 2.5 Kernel Version: 4.17_rc3 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: adeb...@gmail.com Regression: No Created attachment 275681 --> https://bugzilla.kernel.org/attachment.cgi?id=275681&action=edit dmesg output I've been testing the new 4.17 kernel, which finally works for me with the new AMDGPU DC and DP MST monitors (4.15 and 4.16 did not). However, after the system is idle for long enough for DPMS to activate, the monitors will turn off, but never turn back on. Despite the monitors not working, I was able to SSH into the machine and obtain the output of dmesg, which is attached. I am using a Tonga GPU (Sapphire R9 380). I would be happy to test any patches that are available or provide any other necessary information. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] backlight: Remove ld9040 driver
> -Original Message- > From: Krzysztof Kozlowski > Sent: Monday, April 30, 2018 1:30 PM > To: Lee Jones ; Daniel Thompson > ; Jingoo Han ; > Bartlomiej Zolnierkiewicz ; linux- > ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; linux- > fb...@vger.kernel.org > Cc: Krzysztof Kozlowski ; Marek Szyprowski > ; Inki Dae > Subject: [PATCH 2/2] backlight: Remove ld9040 driver > > The driver for LD9040 AMOLED LCD panel was superseded with DRM driver > panel-samsung-ld9040.c. It does not support DeviceTree and respective > possible user (Exynos4210 Universal C210) is DeviceTree-only and uses > DRM version of driver.. > > Suggested-by: Marek Szyprowski > Cc: Marek Szyprowski > Cc: Inki Dae > Signed-off-by: Krzysztof Kozlowski > --- > drivers/video/backlight/Kconfig| 8 - > drivers/video/backlight/Makefile | 1 - > drivers/video/backlight/ld9040.c | 811 - > > drivers/video/backlight/ld9040_gamma.h | 202 > 4 files changed, 1022 deletions(-) > delete mode 100644 drivers/video/backlight/ld9040.c > delete mode 100644 drivers/video/backlight/ld9040_gamma.h Acked-by: Jingoo Han Best regards, Jingoo Han [.] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] backlight: Remove s6e63m0 driver
On Monday, April 30, 2018 1:30 PM, Krzysztof Kozlowski wrote: > > The driver for S6E63M0 AMOLED LCD panel is not used. It does not > support DeviceTree and respective possible users (S5Pv210 Aquila and > Goni boards) are DeviceTree-only. > > Suggested-by: Marek Szyprowski > Cc: Marek Szyprowski > Cc: Inki Dae > Signed-off-by: Krzysztof Kozlowski > --- > drivers/video/backlight/Kconfig | 8 - > drivers/video/backlight/Makefile| 1 - > drivers/video/backlight/s6e63m0.c | 857 > Acked-by: Jingoo Han Best regards, Jingoo Han [.] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g
https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #19 from Francisco Pina Martins --- Created attachment 139239 --> https://bugs.freedesktop.org/attachment.cgi?id=139239&action=edit journalctl log with KASAN_OUTLINE and kasan_multi_shot using amdgpu.ko compiled with debug info Here you go. journalctl log after booting with kasan_multi_shot and using the `amdgpu.ko` file compiled with debug info. Now this is a Frankenkernel monster if I ever saw one. I have taken the liberty of "grepping" for the pattern, and it seems that "firmware_parser_create+0xa70/0xd90" is still there. Thank you for passing this along to the DC folk. Please let me know when a patch I can test is made available. Also, if you need any more information (or try something), just ask away. At the very least, with this bug report I have discovered that the KASAN enabled kernel boots every time, at the expense of an extra second while booting. I did not notice any other performance differences between the KASAN enabled and the stock kernel (was I supposed to?). Once again, thank you, Michael for your patience guiding me through the tasks. Next time will be easier. _-) -- 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/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.
On Tue, May 1, 2018 at 1:59 AM, Eric Anholt wrote: > I had originally asked Stefan Schake to drop the pad field from the > syncobj changes that just landed, because I couldn't come up with a > reason to align to 64 bits. > > Talking with Dave Airlie about the new v3d driver's submit ioctl, we > came up with a reason: sizeof() on 64-bit platforms may align to 64 > bits, in which case the userspace will be submitting the aligned size > and the final 32 bits won't be zero-padded by the kernel. If > userspace doesn't zero-fill, then a future ABI change adding a 32-bit > field at the end could potentially cause the kernel to read undefined > data from old userspace (our userspace happens to use structure > initialization that zero-fills, but as a general rule we try not to > rely on that in the kernel). > Did a quick sizeof check on arm64 and that indeed came to 176 mod 8 = 0, suggesting we need this additional pad. So fwiw Reviewed-by: Stefan Schake Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #62 from i...@yahoo.com --- You don't even get kernel panic, the machine just freezes. Just to confirm that, add the following to the kernel line options in grub "panic=30" . Then freeze the computer again. If the kernel panics, then it should reboot after 30 seconds. Do you have a temperature reading for the Mother Board chipset? Can you make sure it doesn't overheat or something during gameplay? Use ssh to log into your computer and run `watch sensors`. You will have the last readings when the computer hangs. I think you should try to compile a vanilla kernel and enable every debug option that you can. (You can use the SUSE kernel /proc/config.gz as template). -- 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/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.
I had originally asked Stefan Schake to drop the pad field from the
syncobj changes that just landed, because I couldn't come up with a
reason to align to 64 bits.
Talking with Dave Airlie about the new v3d driver's submit ioctl, we
came up with a reason: sizeof() on 64-bit platforms may align to 64
bits, in which case the userspace will be submitting the aligned size
and the final 32 bits won't be zero-padded by the kernel. If
userspace doesn't zero-fill, then a future ABI change adding a 32-bit
field at the end could potentially cause the kernel to read undefined
data from old userspace (our userspace happens to use structure
initialization that zero-fills, but as a general rule we try not to
rely on that in the kernel).
Signed-off-by: Eric Anholt
---
danvet, could you update the "Botching up IOCTLs" post with this
explanation for why we need struct size alignment for non-array
structs?
drivers/gpu/drm/vc4/vc4_gem.c | 5 +
include/uapi/drm/vc4_drm.h| 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index a4c4be3ac6af..7910b9acedd6 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1132,6 +1132,11 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
}
+ if (args->pad2 != 0) {
+ DRM_DEBUG("Invalid pad: 0x%08x\n", args->pad2);
+ return -EINVAL;
+ }
+
exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
if (!exec) {
DRM_ERROR("malloc failure on exec struct\n");
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index 2be4fe3610b8..2cac6277a1d7 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -193,6 +193,8 @@ struct drm_vc4_submit_cl {
* render job. 0 means ignore.
*/
__u32 out_sync;
+
+ __u32 pad2;
};
/**
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE
> > > Yes, I fixed the original false positive messages myself with the swiotlb > maintainer and I was CCed in fixing the recent fallout from Chris changes as > well. So do we have a good summary of where this at now? I'm getting reports on 4.16.4 still displaying these, what hammer do I need to hit things with to get 4.16.x+1 to not do this? Is there still outstanding issues upstream. For future reference I think how this should have gone down is a) AMD implement a public CI with igt tests for all of this b) we get these patches pushed and debugged. Though to be a bit more constructive, I think you should have said at -rc6 or 7 this isn't working for this kernel cycle, push a minimal patch to back it off, even if the bug is in swiotlb, we don't just add stuff broken like this, even if it's not your bug we should have backed off for a kernel or two until we had the underlying infrastructure fixed. Otherwise we get what we have now, which is bit of a crappile, because now I've no idea if the swiotlb things people report are the false positive, or some new thing. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/vc4: Syncobj import export
Stefan Schake writes: > v2 drops the extra syncobj parameter and gets rid of the submit flags > since 0 is never a valid syncobj handle. > > This series allows userspace to submit syncobj handles for importing > a fence to wait on or exporting the job fence as part of submission. > > The primary use of this is to enable native fence fd support in Mesa. > Userspace implementation is under review and available here: This series was a joy to read. I've reviewed and pushed it to drm-misc-next, and we can land the Mesa side once it's made its way to drm-next. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings
On Mon, Apr 30, 2018 at 10:01:50PM +0100, Chris Wilson wrote:
> Quoting Matthias Kaehlcke (2018-04-30 21:51:45)
> > On Mon, Apr 30, 2018 at 09:01:49PM +0100, Chris Wilson wrote:
> > > Quoting Matthias Kaehlcke (2018-04-30 20:31:19)
> > > > On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote:
> > > > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > > > warnings to full") enabled extra warnings for i915 to spot possible
> > > > > bugs in new code, and then disabled a subset of these warnings to keep
> > > > > the current code building without warnings (with gcc). Enabling the
> > > > > extra warnings also enabled some additional clang-only warnings, as a
> > > > > result building i915 with clang currently is extremely noisy. For now
> > > > > also disable the clang warnings sign-compare, sometimes-uninitialized,
> > > > > unneeded-internal-declaration and initializer-overrides. If desired
> > > > > they can be re-enabled after the code has been fixed.
> > > > >
> > > > > Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > > > warnings to full")
> > >
> > > Do we need to backport this for a non-default build with a non-default
> > > compiler?
> >
> > If it affected a LTS build I'd say yes, but since that isn't the case
> > I think it's not necessary.
> >
> > > > > Signed-off-by: Matthias Kaehlcke
> > > > > ---
> > > > > Changes in v2:
> > > > > - rebased on drm-tip
> > > > > - added comment indicating that disabled warnings are clang warnings
> > > > >
> > > > > drivers/gpu/drm/i915/Makefile | 5 +
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > > b/drivers/gpu/drm/i915/Makefile
> > > > > index 4eee91a3a236..9717c037b582 100644
> > > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > > @@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning,
> > > > > type-limits)
> > > > > subdir-ccflags-y += $(call cc-disable-warning,
> > > > > missing-field-initializers)
> > > > > subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> > > > > subdir-ccflags-y += $(call cc-disable-warning,
> > > > > unused-but-set-variable)
> > > > > +# clang warnings
> > > > > +subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
> > >
> > > Too much mixup in the code to be fixed overnight indeed.
> > >
> > > > > +subdir-ccflags-y += $(call cc-disable-warning,
> > > > > sometimes-uninitialized)
> > >
> > > Annoyingly it appears that clang has more false positives.
> > >
> > > > > +subdir-ccflags-y += $(call cc-disable-warning,
> > > > > unneeded-internal-declaration)
> > >
> > > Example? I don't recall this one, so don't know if we should just not
> > > fix it rather than suppress. I've used ignored-attributes, perhaps that
> > > was for the same cause.
> >
> > drivers/gpu/drm/i915/intel_guc_submission.c:183:13: warning: function
> > 'has_doorbell' is not needed and will not be emitted
> > [-Wunneeded-internal-declaration]
> > static bool has_doorbell(struct intel_guc_client *client)
> >
> > The function is only called within a GEM_BUG_ON macro, which does not
> > evaluate the expression unless CONFIG_DRM_I915_DEBUG_GEM is set.
> >
> > Instead of disabling the warning it would probably be better to mark
> > has_doorbell as __maybe_unused.
>
> Hmm, if it is just this one, I would remove the use from
> intel_guc_submission and move it into selftests/
> The single use case inside intel_guc_submission isn't that interesting
> and I doubt we would miss not having the assert.
Could you take care of this? I'm not really familiar with the i915
codebase and might not put it exactly where you want it ;-)
I'd then rebase this patch and leave -Wunneeded-internal-declaration enabled.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #61 from MirceaKitsune --- (In reply to iive from comment #60) No, it never does. SysRq + R - E - S - U - B (pressed in slow order after one another) does not reboot, nor make the hard drive led flash, nor have any other noticeable effects once the freeze has occurred. -- 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/msm/gpu: Add submit queue queries
Add the capability to query information from a submit queue.
The first available parameter is for querying the number of
GPU faults (hangs) that can be attributed to the queue.
This is useful for implementing context robustness. A UMD
context can regularly query the number of faults to see
if it is responsible for any. If so it can invalidate itself.
This is also helpful for testing by confirming to the user mode
driver if a particular command stream caused a fault (or not as
the case may be).
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 12 +++-
drivers/gpu/drm/msm/msm_drv.h | 2 ++
drivers/gpu/drm/msm/msm_gpu.c | 3 +++
drivers/gpu/drm/msm/msm_submitqueue.c | 21 +
include/uapi/drm/msm_drm.h| 12
5 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 30cd514d8f7c..d01fb101d5ff 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -32,9 +32,10 @@
* - 1.3.0 - adds GMEM_BASE + NR_RINGS params, SUBMITQUEUE_NEW +
* SUBMITQUEUE_CLOSE ioctls, and MSM_INFO_IOVA flag for
* MSM_GEM_INFO ioctl.
+ * - 1.4.0 - Add SUBMITQUERY_QUERY ioctl.
*/
#define MSM_VERSION_MAJOR 1
-#define MSM_VERSION_MINOR 3
+#define MSM_VERSION_MINOR 4
#define MSM_VERSION_PATCHLEVEL 0
static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -803,6 +804,14 @@ static int msm_ioctl_submitqueue_new(struct drm_device
*dev, void *data,
args->flags, &args->id);
}
+static int msm_ioctl_submitqueue_query(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_msm_submitqueue_query *args = data;
+
+ return msm_submitqueue_query(dev, file->driver_priv, args->id,
+ args->param, args->data, args->len);
+}
static int msm_ioctl_submitqueue_close(struct drm_device *dev, void *data,
struct drm_file *file)
@@ -823,6 +832,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE, msm_ioctl_gem_madvise,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_AUTH|DRM_RENDER_ALLOW),
};
static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 48ed5b9a8580..56c666f25aa1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -320,6 +320,8 @@ struct msm_gpu_submitqueue *msm_submitqueue_get(struct
msm_file_private *ctx,
u32 id);
int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
*ctx,
u32 prio, u32 flags, u32 *id);
+int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx,
+ u32 id, u32 param, u64 data, u32 len);
int msm_submitqueue_remove(struct msm_file_private *ctx, u32 id);
void msm_submitqueue_close(struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..925532197584 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -324,6 +324,9 @@ static void recover_worker(struct work_struct *work)
if (submit) {
struct task_struct *task;
+ /* Increment the submitqueue fault count */
+ submit->queue->faults++;
+
rcu_read_lock();
task = pid_task(submit->pid, PIDTYPE_PID);
if (task) {
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index 5115f75b5b7f..e12f2bd0347d 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -120,6 +120,27 @@ int msm_submitqueue_init(struct drm_device *drm, struct
msm_file_private *ctx)
return msm_submitqueue_create(drm, ctx, default_prio, 0, NULL);
}
+int msm_submitqueue_query(struct drm_device *drm, struct msm_file_private *ctx,
+ u32 id, u32 param, u64 data, u32 len)
+{
+ struct msm_gpu_submitqueue *queue = msm_submitqueue_get(ctx, id);
+ int ret = -EINVAL;
+
+ if (!queue)
+ return -ENOENT;
+
+ if (param == MSM_SUBMITQUEUE_PARAM_FAULTS) {
+ size_t size = min_t(size_t, len, sizeof(queue->faults));
+
+ if (copy_to_user(u64_to_user_ptr(data), &queue->faults, size))
+ ret = -EFAULT;
+ }
+
+ msm_submitqueue_put(queue);
+
+ return ret;
+}
+
int msm_submitqueue_remove(struct msm_file_private *ctx, u32 id)
{
struct msm_gpu_submitqueue *entry;
diff --git a/include/uap
Re: [PATCH] drm/vc4: make function vc4_allocate_bin_bo static
Vaishali Thakkar writes: > Sparse complains with following warning: > drivers/gpu/drm/vc4/vc4_v3d.c:222:1: warning: symbol > 'vc4_allocate_bin_bo' was not declared. Should it be static? > > Make vc4_allocate_bin static as it is not used outside of > vc4_v3d.c. > > Signed-off-by: Vaishali Thakkar Applied to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Enable DSI transactions on the RPi panel.
Thierry Reding writes:
> [ Unknown signature status ]
> On Tue, Oct 31, 2017 at 12:32:58PM -0700, Eric Anholt wrote:
>> It turns out that I had just mistaken what type of write the register
>> writes were supposed to be, using DCS instead of generic long writes.
>>
>> Switching to transactions instead of using the atmel as a bridge also
>> seems to resolve the sparkling pixels problem I've had.
>>
>> Signed-off-by: Eric Anholt
>> Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
>> Touchscreen.")
>> ---
>> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 14 +-
>> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> Did you want to take this along with patch 1 through drm-misc-next? If
> so:
>
> Acked-by: Thierry Reding
I've pushed both to drm-misc-next. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings
Quoting Matthias Kaehlcke (2018-04-30 21:51:45)
> On Mon, Apr 30, 2018 at 09:01:49PM +0100, Chris Wilson wrote:
> > Quoting Matthias Kaehlcke (2018-04-30 20:31:19)
> > > On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote:
> > > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > > warnings to full") enabled extra warnings for i915 to spot possible
> > > > bugs in new code, and then disabled a subset of these warnings to keep
> > > > the current code building without warnings (with gcc). Enabling the
> > > > extra warnings also enabled some additional clang-only warnings, as a
> > > > result building i915 with clang currently is extremely noisy. For now
> > > > also disable the clang warnings sign-compare, sometimes-uninitialized,
> > > > unneeded-internal-declaration and initializer-overrides. If desired
> > > > they can be re-enabled after the code has been fixed.
> > > >
> > > > Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > > warnings to full")
> >
> > Do we need to backport this for a non-default build with a non-default
> > compiler?
>
> If it affected a LTS build I'd say yes, but since that isn't the case
> I think it's not necessary.
>
> > > > Signed-off-by: Matthias Kaehlcke
> > > > ---
> > > > Changes in v2:
> > > > - rebased on drm-tip
> > > > - added comment indicating that disabled warnings are clang warnings
> > > >
> > > > drivers/gpu/drm/i915/Makefile | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > b/drivers/gpu/drm/i915/Makefile
> > > > index 4eee91a3a236..9717c037b582 100644
> > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > @@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning,
> > > > type-limits)
> > > > subdir-ccflags-y += $(call cc-disable-warning,
> > > > missing-field-initializers)
> > > > subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> > > > subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> > > > +# clang warnings
> > > > +subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
> >
> > Too much mixup in the code to be fixed overnight indeed.
> >
> > > > +subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
> >
> > Annoyingly it appears that clang has more false positives.
> >
> > > > +subdir-ccflags-y += $(call cc-disable-warning,
> > > > unneeded-internal-declaration)
> >
> > Example? I don't recall this one, so don't know if we should just not
> > fix it rather than suppress. I've used ignored-attributes, perhaps that
> > was for the same cause.
>
> drivers/gpu/drm/i915/intel_guc_submission.c:183:13: warning: function
> 'has_doorbell' is not needed and will not be emitted
> [-Wunneeded-internal-declaration]
> static bool has_doorbell(struct intel_guc_client *client)
>
> The function is only called within a GEM_BUG_ON macro, which does not
> evaluate the expression unless CONFIG_DRM_I915_DEBUG_GEM is set.
>
> Instead of disabling the warning it would probably be better to mark
> has_doorbell as __maybe_unused.
Hmm, if it is just this one, I would remove the use from
intel_guc_submission and move it into selftests/
The single use case inside intel_guc_submission isn't that interesting
and I doubt we would miss not having the assert.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #60 from i...@yahoo.com --- (In reply to MirceaKitsune from comment #58) > (In reply to iive from comment #57) [...] > And during the netconsole test, I did enable and use the SysRq keys > (RESUB)... nothing got printed to the other machine. SysRq doesn't seen to > do anything after the freeze: Nothing happens if I press them, including the > HDD led which never flashes again indicating that even the drive is never > used any more. After hang, does SysRq+R reboot the machine? -- 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/vc4: Make sure vc4_bo_{inc, dec}_usecnt() calls are balanced
Boris Brezillon writes:
> Commit b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
> introduced a mechanism to mark some BOs as purgeable to allow the driver
> to drop them under memory pressure. In order to implement this feature
> we had to add a mechanism to mark BOs as currently used by a piece of
> hardware which materialized through the ->usecnt counter.
>
> Plane code is supposed to increment usecnt when it attaches a BO to a
> plane and decrement it when it's done with this BO, which was done in
> the ->prepare_fb() and ->cleanup_fb() hooks. The problem is, async page
> flip logic does not go through the regular atomic update path, and
> ->prepare_fb() and ->cleanup_fb() are not called in this case.
>
> Fix that by manually calling vc4_bo_{inc,dec}_usecnt() in the
> async-page-flip path.
>
> Note that all this should go away as soon as we get generic async page
> flip support in the core, in the meantime, this fix should do the
> trick.
Pushed to drm-misc-fixes. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings
On Mon, Apr 30, 2018 at 09:01:49PM +0100, Chris Wilson wrote:
> Quoting Matthias Kaehlcke (2018-04-30 20:31:19)
> > On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote:
> > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > warnings to full") enabled extra warnings for i915 to spot possible
> > > bugs in new code, and then disabled a subset of these warnings to keep
> > > the current code building without warnings (with gcc). Enabling the
> > > extra warnings also enabled some additional clang-only warnings, as a
> > > result building i915 with clang currently is extremely noisy. For now
> > > also disable the clang warnings sign-compare, sometimes-uninitialized,
> > > unneeded-internal-declaration and initializer-overrides. If desired
> > > they can be re-enabled after the code has been fixed.
> > >
> > > Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > > warnings to full")
>
> Do we need to backport this for a non-default build with a non-default
> compiler?
If it affected a LTS build I'd say yes, but since that isn't the case
I think it's not necessary.
> > > Signed-off-by: Matthias Kaehlcke
> > > ---
> > > Changes in v2:
> > > - rebased on drm-tip
> > > - added comment indicating that disabled warnings are clang warnings
> > >
> > > drivers/gpu/drm/i915/Makefile | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 4eee91a3a236..9717c037b582 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning,
> > > type-limits)
> > > subdir-ccflags-y += $(call cc-disable-warning,
> > > missing-field-initializers)
> > > subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> > > subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> > > +# clang warnings
> > > +subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
>
> Too much mixup in the code to be fixed overnight indeed.
>
> > > +subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
>
> Annoyingly it appears that clang has more false positives.
>
> > > +subdir-ccflags-y += $(call cc-disable-warning,
> > > unneeded-internal-declaration)
>
> Example? I don't recall this one, so don't know if we should just not
> fix it rather than suppress. I've used ignored-attributes, perhaps that
> was for the same cause.
drivers/gpu/drm/i915/intel_guc_submission.c:183:13: warning: function
'has_doorbell' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static bool has_doorbell(struct intel_guc_client *client)
The function is only called within a GEM_BUG_ON macro, which does not
evaluate the expression unless CONFIG_DRM_I915_DEBUG_GEM is set.
Instead of disabling the warning it would probably be better to mark
has_doorbell as __maybe_unused.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings
Quoting Matthias Kaehlcke (2018-04-30 20:31:19)
> On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote:
> > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > warnings to full") enabled extra warnings for i915 to spot possible
> > bugs in new code, and then disabled a subset of these warnings to keep
> > the current code building without warnings (with gcc). Enabling the
> > extra warnings also enabled some additional clang-only warnings, as a
> > result building i915 with clang currently is extremely noisy. For now
> > also disable the clang warnings sign-compare, sometimes-uninitialized,
> > unneeded-internal-declaration and initializer-overrides. If desired
> > they can be re-enabled after the code has been fixed.
> >
> > Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> > warnings to full")
Do we need to backport this for a non-default build with a non-default
compiler?
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > Changes in v2:
> > - rebased on drm-tip
> > - added comment indicating that disabled warnings are clang warnings
> >
> > drivers/gpu/drm/i915/Makefile | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 4eee91a3a236..9717c037b582 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning,
> > type-limits)
> > subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
> > subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> > subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> > +# clang warnings
> > +subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
Too much mixup in the code to be fixed overnight indeed.
> > +subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
Annoyingly it appears that clang has more false positives.
> > +subdir-ccflags-y += $(call cc-disable-warning,
> > unneeded-internal-declaration)
Example? I don't recall this one, so don't know if we should just not
fix it rather than suppress. I've used ignored-attributes, perhaps that
was for the same cause.
> > +subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
While we used per-file to restrict this one, I don't think we care that
much for precision with clang as well.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106317] System lock up after monitors wake from DPMS on Ryzen 3 2200g
https://bugs.freedesktop.org/show_bug.cgi?id=106317 --- Comment #5 from Kertesz Laszlo --- Tried it and there is absolutely no relevant output in dmesg. After freeze i had to force-restart the computer 5 times to pass the amdgpu loading point. Attached dmesg above. -- 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 106317] System lock up after monitors wake from DPMS on Ryzen 3 2200g
https://bugs.freedesktop.org/show_bug.cgi?id=106317 --- Comment #4 from Kertesz Laszlo --- Created attachment 139234 --> https://bugs.freedesktop.org/attachment.cgi?id=139234&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] drm/panel: Support panel detection
On Mon, Apr 30, 2018 at 7:43 PM, Boris Brezillon wrote: > On Mon, 30 Apr 2018 10:22:19 -0700 > Eric Anholt wrote: > >> Boris Brezillon writes: >> >> > Some panels are connected through extension boards an provide an easy >> > way for the main board to detect when they are present (like checking >> > for a working I2C communication with a device and making sure a >> > specific reg in this device has a consistent value). >> > >> > When this is the case, we might want to support dynamic panel detection >> > and only expose the display (and its display modes) when the panel is >> > detected, similar to the monitor detection we use for regular >> > connectors (HDMI, DVI, ...). >> > >> > This solves a problem we have on the Rpi when the panel is not >> > connected to the board but described in the DT. This prevents the whole >> > display pipeline from being exposed because one of the element (the >> > panel) is missing. >> > >> > This was posted as an RFC because I'm not sure dynamically detecting >> > panels or supporting panel hotplug is actually something we want to do. >> >> I want to clarify here: we're not trying to do panel hotplug. We're >> trying to boot-time-only detection of whether or not the standard panel >> is plugged in. >> >> Since this is something like the 6th variation of trying to get this >> driver to work whether or not the panel is plugged in at boot, I'm >> leaning toward just asking the closed source firmware to hack the DT to >> add/remove the panel's node depending on whether it can probe it on I2C. >> Relying on more closed source software in order to work around something >> so trivial is really frustrating, though. Ugh, sorry, I didn't remember the entire story here when I replied. > Well, we could still have this hack in the rpi-touchscreen-panel driver > and expose the panel without any display modes when the device is > actually not responding on the I2C bus. This way we could have the DRM > device registered and the panel display would just be unusable. Yeah that sounds like a reasonable hack to me, but I have no idea whether this was one of the earlier pile of ideas or not. Another thing that I just thought of (so might be bogus) would be a dummy bridge which only exists to transport an errno, which would then be returned from drm_of_find_panel_or_bridge instead of 0. Probably only reasonable case would be to return -ENODEV. No good idea though how to somewhat cleanly wire this through the entire stack, simplest might be to add an in errno to drm_panel. Since we use an embedded list for of_drm_find_panel we can't do the usual trick of storing the errno in the pointer. Hm, maybe we could encode panel->funcs == NULL as "sorry this panel isn't really there" and use that. Assuming we only ever want to encode ENODEV and not a pile of other errno values. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
On Mon, Apr 30, 2018 at 1:10 PM, Eric Anholt wrote: > These OpenGL ES GPUs are present in the 7268 and 7278 set top box > chips. > > v2: no changes > v3: move to gpu/, fix typo > > Signed-off-by: Eric Anholt > --- > .../devicetree/bindings/gpu/brcm,bcm-v3d.txt | 28 +++ > 1 file changed, 28 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation
On Mon, Apr 30, 2018 at 8:26 PM, Christian König
wrote:
> Am 30.04.2018 um 17:38 schrieb Daniel Vetter:
>>
>> On Sun, Apr 29, 2018 at 09:08:31AM +0200, Christian König wrote:
>>>
>>> NAK, there is a subtitle but major difference:
>>>
- if (rdev->needs_reset) {
- t = -EDEADLK;
- break;
- }
>>>
>>> Without that the whole radeon GPU reset code breaks.
>>
>> Oops I've missed that. How does this work when you register a callback
>> using ->enable_signaling and then block on it? Everything just dies?
>
>
> The short answer is we simply avoid using enable_signaling() from inside
> driver IOCTLs.
>
>> We have lots of users of that for buffer/fence sharing. A really ugly, but
>> probably working fix for this would be a kthread worker that just looks
>> for ->needs_reset and force-completes all fences with
>> dma_fence_set_error(-EIO), which is kinda what's supposed to happen here
>> anyway.
>
>
> That actually won't help. Radeon does this dance to return an error from
> dma_fence_wait() when the GPU needs a reset.
>
> This way all IOCTLs should return to userspace with -EAGAIN and when they
> are restarted we block for the running GPU reset to finish.
>
> I was against this approach, but it works as long as radeon only has to deal
> with it's own fences.
Yeah, as soon as you mix in a 2nd driver it goes boom, since you can
easily construct loops (even if they go through ->enable_signaling and
maybe just an irq handler to fire off something somewhere else).
Currently we're really bad a detecting these loops (aka there's
nothing), but I hope that the cross-release lockdep stuff gets enabled
soon. Then we could annotate dma_fences and lockdep should complain
about a lot of these issues.
Alas, problem exists already, but I'm not going to attempt to fix it.
Anyway, I'll drop this patch here.
-Daniel
>
> Christian.
>
>
>> -Daniel
>>
>>> Regards,
>>> Christian.
>>>
>>>
>>> Am 27.04.2018 um 08:17 schrieb Daniel Vetter:
It's a copy of dma_fence_default_wait, written slightly differently.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fence.c | 63
---
1 file changed, 63 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index e86f2bd38410..32690a525bfc 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -1051,72 +1051,9 @@ static const char
*radeon_fence_get_timeline_name(struct dma_fence *f)
}
}
-static inline bool radeon_test_signaled(struct radeon_fence *fence)
-{
- return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
&fence->base.flags);
-}
-
-struct radeon_wait_cb {
- struct dma_fence_cb base;
- struct task_struct *task;
-};
-
-static void
-radeon_fence_wait_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
-{
- struct radeon_wait_cb *wait =
- container_of(cb, struct radeon_wait_cb, base);
-
- wake_up_process(wait->task);
-}
-
-static signed long radeon_fence_default_wait(struct dma_fence *f, bool
intr,
-signed long t)
-{
- struct radeon_fence *fence = to_radeon_fence(f);
- struct radeon_device *rdev = fence->rdev;
- struct radeon_wait_cb cb;
-
- cb.task = current;
-
- if (dma_fence_add_callback(f, &cb.base, radeon_fence_wait_cb))
- return t;
-
- while (t > 0) {
- if (intr)
- set_current_state(TASK_INTERRUPTIBLE);
- else
- set_current_state(TASK_UNINTERRUPTIBLE);
-
- /*
-* radeon_test_signaled must be called after
-* set_current_state to prevent a race with
wake_up_process
-*/
- if (radeon_test_signaled(fence))
- break;
-
- if (rdev->needs_reset) {
- t = -EDEADLK;
- break;
- }
-
- t = schedule_timeout(t);
-
- if (t > 0 && intr && signal_pending(current))
- t = -ERESTARTSYS;
- }
-
- __set_current_state(TASK_RUNNING);
- dma_fence_remove_callback(f, &cb.base);
-
- return t;
-}
-
const struct dma_fence_ops radeon_fence_ops = {
.get_driver_name = radeon_fence_get_driver_name,
.ge
Re: [PATCH v2] drm/i915: Disable some extra clang warnings
On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote:
> Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> warnings to full") enabled extra warnings for i915 to spot possible
> bugs in new code, and then disabled a subset of these warnings to keep
> the current code building without warnings (with gcc). Enabling the
> extra warnings also enabled some additional clang-only warnings, as a
> result building i915 with clang currently is extremely noisy. For now
> also disable the clang warnings sign-compare, sometimes-uninitialized,
> unneeded-internal-declaration and initializer-overrides. If desired
> they can be re-enabled after the code has been fixed.
>
> Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
> warnings to full")
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - rebased on drm-tip
> - added comment indicating that disabled warnings are clang warnings
>
> drivers/gpu/drm/i915/Makefile | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4eee91a3a236..9717c037b582 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning, type-limits)
> subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
> subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
> subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
> +# clang warnings
> +subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
> +subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
> +subdir-ccflags-y += $(call cc-disable-warning, unneeded-internal-declaration)
> +subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>
> # Fine grained warnings disable
Ping, it seems this one swept under the radar
Thanks
Matthias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Wed, Apr 25, 2018 at 08:12:08AM +0200, Juergen Gross wrote: > On 24/04/18 22:35, Dongwon Kim wrote: > > Had a meeting with Daniel and talked about bringing out generic > > part of hyper-dmabuf to the userspace, which means we most likely > > reuse IOCTLs defined in xen-zcopy for our use-case if we follow > > his suggestion. > > > > So assuming we use these IOCTLs as they are, > > Several things I would like you to double-check.. > > > > 1. returning gref as is to the user space is still unsafe because > > it is a constant, easy to guess and any process that hijacks it can easily > > exploit the buffer. So I am wondering if it's possible to keep dmabuf-to > > -gref or gref-to-dmabuf in kernel space and add other layers on top > > of those in actual IOCTLs to add some safety.. We introduced flink like > > hyper_dmabuf_id including random number but many says even that is still > > not safe. > > grefs are usable by root only. When you have root access in dom0 you can > do evil things to all VMs even without using grants. That is in no way > different to root being able to control all other processes on the > system. I honestly didn't know about this. I believed kernel code simply can map those pages. However, out of curiosity, how is non-root usage of gref prevented in current design? Is there privilege check in grant table driver or hypercalls needed by this page mapping is only enabled for root in hypervisor level? And this is pretty critical information for any use-case using grant-table. Is there any place(doc/website) this is specified/explained? Thanks, DW > > > Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation
Am 30.04.2018 um 17:38 schrieb Daniel Vetter:
On Sun, Apr 29, 2018 at 09:08:31AM +0200, Christian König wrote:
NAK, there is a subtitle but major difference:
- if (rdev->needs_reset) {
- t = -EDEADLK;
- break;
- }
Without that the whole radeon GPU reset code breaks.
Oops I've missed that. How does this work when you register a callback
using ->enable_signaling and then block on it? Everything just dies?
The short answer is we simply avoid using enable_signaling() from inside
driver IOCTLs.
We have lots of users of that for buffer/fence sharing. A really ugly, but
probably working fix for this would be a kthread worker that just looks
for ->needs_reset and force-completes all fences with
dma_fence_set_error(-EIO), which is kinda what's supposed to happen here
anyway.
That actually won't help. Radeon does this dance to return an error from
dma_fence_wait() when the GPU needs a reset.
This way all IOCTLs should return to userspace with -EAGAIN and when
they are restarted we block for the running GPU reset to finish.
I was against this approach, but it works as long as radeon only has to
deal with it's own fences.
Christian.
-Daniel
Regards,
Christian.
Am 27.04.2018 um 08:17 schrieb Daniel Vetter:
It's a copy of dma_fence_default_wait, written slightly differently.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fence.c | 63 ---
1 file changed, 63 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index e86f2bd38410..32690a525bfc 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -1051,72 +1051,9 @@ static const char *radeon_fence_get_timeline_name(struct
dma_fence *f)
}
}
-static inline bool radeon_test_signaled(struct radeon_fence *fence)
-{
- return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->base.flags);
-}
-
-struct radeon_wait_cb {
- struct dma_fence_cb base;
- struct task_struct *task;
-};
-
-static void
-radeon_fence_wait_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
-{
- struct radeon_wait_cb *wait =
- container_of(cb, struct radeon_wait_cb, base);
-
- wake_up_process(wait->task);
-}
-
-static signed long radeon_fence_default_wait(struct dma_fence *f, bool intr,
-signed long t)
-{
- struct radeon_fence *fence = to_radeon_fence(f);
- struct radeon_device *rdev = fence->rdev;
- struct radeon_wait_cb cb;
-
- cb.task = current;
-
- if (dma_fence_add_callback(f, &cb.base, radeon_fence_wait_cb))
- return t;
-
- while (t > 0) {
- if (intr)
- set_current_state(TASK_INTERRUPTIBLE);
- else
- set_current_state(TASK_UNINTERRUPTIBLE);
-
- /*
-* radeon_test_signaled must be called after
-* set_current_state to prevent a race with wake_up_process
-*/
- if (radeon_test_signaled(fence))
- break;
-
- if (rdev->needs_reset) {
- t = -EDEADLK;
- break;
- }
-
- t = schedule_timeout(t);
-
- if (t > 0 && intr && signal_pending(current))
- t = -ERESTARTSYS;
- }
-
- __set_current_state(TASK_RUNNING);
- dma_fence_remove_callback(f, &cb.base);
-
- return t;
-}
-
const struct dma_fence_ops radeon_fence_ops = {
.get_driver_name = radeon_fence_get_driver_name,
.get_timeline_name = radeon_fence_get_timeline_name,
.enable_signaling = radeon_fence_enable_signaling,
.signaled = radeon_fence_is_signaled,
- .wait = radeon_fence_default_wait,
- .release = NULL,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE
Am 30.04.2018 um 18:33 schrieb Michel Dänzer: On 2018-04-29 09:02 AM, Christian König wrote: Am 29.04.2018 um 01:02 schrieb Michel Dänzer: On 2018-04-28 06:30 PM, Ilia Mirkin wrote: On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote: From: Michel Dänzer Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled) try to allocate huge pages. However, not all drivers can take advantage of huge pages, but they would incur the overhead for allocating and freeing them anyway. Now, drivers which can take advantage of huge pages need to set the new flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag no longer incur any overhead for allocating or freeing huge pages. v2: * Also guard swapping of consecutive pages in ttm_get_pages * Reword commit log, hopefully clearer now Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer Both I and lots of other people, based on reports, are still seeing plenty of issues with this as late as 4.16.4. "lots of other people", "plenty of issues" sounds a bit exaggerated from what I've seen. FWIW, while I did see the original messages myself, I haven't seen any since Christian's original fix (see below), neither with amdgpu nor radeon, even before this patch you followed up to. Admittedly I'm on nouveau, but others have reported issues with radeon/amdgpu as well. It's been going on since the feature was merged in v4.15, with what seems like little investigation from the authors introducing the feature. That's not a fair assessment. See https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and following comments. Christian fixed the original issue in d0bc0c2a31c95002d37c3cc511ffdcab851b3256 "swiotlb: suppress warning when __GFP_NOWARN is set". Christian did his best to try and get the fix in before 4.15 final, but for reasons beyond his control, it was delayed until 4.16-rc1 and then backported to 4.15.5. Unfortunately, there was an swiotlb regression (not directly related to Christian's work) shortly after this fix, also in 4.16-rc1, which is now fixed in 4.17-rc1 and will be backported to 4.16.y. And that's exactly the reason why I intentionally kept this enabled for all users of the TTM DMA page pool and not put it behind a flag. This change has surfaced quite a number of bugs in the swiotlb code which could have caused issues before. It's just that those code path where never exercised massively before. Additional to that using huge pages is beneficial for the MM and CPU TLB (not implemented yet) even when the GPU driver can't make much use of it. Do I understand correctly that you're against this patch? Not completely, I've considered adding that multiple times myself. I'm just torn apart between keeping it enabled so that the underlying bugs gets fixed and disabling it for a better end user experience. But in general I would opt out for a pool configuration option, not a per driver flag. AFAIU the only benefit of huge pages with a driver which doesn't take advantage of them directly is "for the MM". Can you describe a bit more what that benefit is exactly? When transparent huge pages are in effect we should have more huge pages than small pages in the system allocator. So by enforcing allocation of small pages we fragment the huge pages once more and give khugepaged quite a bunch of work todo to gather them together into huge pages again. Is it expected to outweigh the cost of allocating / freeing huge pages? Yes, and actually quite well (at least in theory). It looks like there's at least one more bug left, but it's not clear yet when that was introduced, whether it's directly related to Christian's work, or indeed what the impact is. Let's not get ahead of ourselves. Well my patches surfaced the problems, but the underlying issues where present even before those changes and I'm very well involved in fixing the underlying issues. I even considered to just revert the huge page path for the DMA pool allocator, but it's just that the TTM patches seem to work exactly as they are intended. So that doesn't feel like doing the right thing here. I agree. Has anyone reported this to the DMA/SWIOTLB developers? Yes, I fixed the original false positive messages myself with the swiotlb maintainer and I was CCed in fixing the recent fallout from Chris changes as well. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] V3D DRM driver
This is a resend of the V3D driver for the DT binding nitpicks. Eric Anholt (2): dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs. drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+ .../devicetree/bindings/gpu/brcm,bcm-v3d.txt | 28 + Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/v3d/Kconfig | 9 + drivers/gpu/drm/v3d/Makefile | 18 + drivers/gpu/drm/v3d/v3d_bo.c | 379 ++ drivers/gpu/drm/v3d/v3d_debugfs.c | 191 + drivers/gpu/drm/v3d/v3d_drv.c | 371 ++ drivers/gpu/drm/v3d/v3d_drv.h | 294 drivers/gpu/drm/v3d/v3d_fence.c | 58 ++ drivers/gpu/drm/v3d/v3d_gem.c | 663 ++ drivers/gpu/drm/v3d/v3d_irq.c | 206 ++ drivers/gpu/drm/v3d/v3d_mmu.c | 122 drivers/gpu/drm/v3d/v3d_regs.h| 295 drivers/gpu/drm/v3d/v3d_sched.c | 228 ++ drivers/gpu/drm/v3d/v3d_trace.h | 82 +++ drivers/gpu/drm/v3d/v3d_trace_points.c| 9 + include/uapi/drm/v3d_drm.h| 191 + 20 files changed, 3156 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt create mode 100644 drivers/gpu/drm/v3d/Kconfig create mode 100644 drivers/gpu/drm/v3d/Makefile create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c create mode 100644 include/uapi/drm/v3d_drm.h -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+
This driver will be used to support Mesa on the Broadcom 7268 and 7278 platforms. V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's complicated CL/shader validation scheme. This massively changes the GEM behavior, so I've forked off to a new driver. v2: Mark SUBMIT_CL as needing DRM_AUTH. coccinelle fixes from kbuild test robot. Drop personal git link from MAINTAINERS. Don't double-map dma-buf imported BOs. Add kerneldoc about needing MMU eviction. Drop prime vmap/unmap stubs. Delay mmap offset setup to mmap time. Use drm_dev_init instead of _alloc. Use ktime_get() for wait_bo timeouts. Drop drm_can_sleep() usage, since we don't modeset. Switch page tables back to WC (debug change to coherent had slipped in). Switch drm_gem_object_unreference_unlocked() to drm_gem_object_put_unlocked(). Simplify overflow mem handling by not sharing overflow mem between jobs. v3: no changes Signed-off-by: Eric Anholt Acked-by: Daniel Vetter --- Documentation/gpu/drivers.rst | 1 + MAINTAINERS| 8 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/v3d/Kconfig| 9 + drivers/gpu/drm/v3d/Makefile | 18 + drivers/gpu/drm/v3d/v3d_bo.c | 379 ++ drivers/gpu/drm/v3d/v3d_debugfs.c | 191 +++ drivers/gpu/drm/v3d/v3d_drv.c | 371 ++ drivers/gpu/drm/v3d/v3d_drv.h | 294 +++ drivers/gpu/drm/v3d/v3d_fence.c| 58 +++ drivers/gpu/drm/v3d/v3d_gem.c | 663 + drivers/gpu/drm/v3d/v3d_irq.c | 206 drivers/gpu/drm/v3d/v3d_mmu.c | 122 + drivers/gpu/drm/v3d/v3d_regs.h | 295 +++ drivers/gpu/drm/v3d/v3d_sched.c| 228 + drivers/gpu/drm/v3d/v3d_trace.h| 82 +++ drivers/gpu/drm/v3d/v3d_trace_points.c | 9 + include/uapi/drm/v3d_drm.h | 191 +++ 19 files changed, 3128 insertions(+) create mode 100644 drivers/gpu/drm/v3d/Kconfig create mode 100644 drivers/gpu/drm/v3d/Makefile create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c create mode 100644 include/uapi/drm/v3d_drm.h diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index d3ab6abae838..f982558fc25d 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -10,6 +10,7 @@ GPU Driver Documentation tegra tinydrm tve200 + v3d vc4 bridge/dw-hdmi xen-front diff --git a/MAINTAINERS b/MAINTAINERS index bca3c32fb141..46c49c02d87b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4795,6 +4795,14 @@ S: Maintained F: drivers/gpu/drm/omapdrm/ F: Documentation/devicetree/bindings/display/ti/ +DRM DRIVERS FOR V3D +M: Eric Anholt +S: Supported +F: drivers/gpu/drm/v3d/ +F: include/uapi/drm/v3d_drm.h +F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVERS FOR VC4 M: Eric Anholt T: git git://github.com/anholt/linux diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 757825ac60df..1c73a455fdb1 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -267,6 +267,8 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig" source "drivers/gpu/drm/imx/Kconfig" +source "drivers/gpu/drm/v3d/Kconfig" + source "drivers/gpu/drm/vc4/Kconfig" source "drivers/gpu/drm/etnaviv/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 9d66657ea117..7a401edd8761 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ +obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ obj-$(CONFIG_DRM_SIS) += sis/ diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig new file mode 100644 index ..a0c0259355bd --- /dev/null +++ b/drivers/gpu/drm/v3d/Kconfig @@ -0,0 +1,9 @@ +config DRM_V3D + tristate "Broadcom V3D 3.x and newer" + depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST + depends on DRM + depends on COMMON_CLK + select DRM_SCHED + help + Choose thi
[PATCH v3 1/2] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
These OpenGL ES GPUs are present in the 7268 and 7278 set top box
chips.
v2: no changes
v3: move to gpu/, fix typo
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/gpu/brcm,bcm-v3d.txt | 28 +++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
new file mode 100644
index ..c907aa8dd755
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
@@ -0,0 +1,28 @@
+Broadcom V3D GPU
+
+Only the Broadcom V3D 3.x and newer GPUs are covered by this binding.
+For V3D 2.x, see brcm,bcm-vc4.txt.
+
+Required properties:
+- compatible: Should be "brcm,7268-v3d" or "brcm,7278-v3d"
+- reg: Physical base addresses and lengths of the register areas
+- reg-names: Names for the register areas. The "hub", "bridge", and "core0"
+ register areas are always required. The "gca" register area
+ is required if the GCA cache controller is present.
+- interrupts: The interrupt numbers. The first interrupt is for the hub,
+ while the following interrupts are for the cores.
+ See bindings/interrupt-controller/interrupts.txt
+
+Optional properties:
+- clocks: The core clock the unit runs on
+
+v3d {
+ compatible = "brcm,7268-v3d";
+ reg = <0xf1204000 0x100>,
+ <0xf120 0x4000>,
+ <0xf1208000 0x4000>,
+ <0xf1204100 0x100>;
+ reg-names = "bridge", "hub", "core0", "gca";
+ interrupts = <0 78 4>,
+<0 77 4>;
+};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/17] drm/virtio: Remove unecessary dma_fence_ops
Daniel Vetter writes: > dma_fence_default_wait is the default now, same for the trivial > enable_signaling implementation. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/17] drm/qxl: Remove unecessary dma_fence_ops
Daniel Vetter writes: > dma_fence_default_wait is the default now, same for the trivial > enable_signaling implementation. Drop the mention of dma_fence_default_wait, since this one doesn't use that? Other than that, Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/17] drm: Remove unecessary dma_fence_ops
Daniel Vetter writes: > dma_fence_default_wait is the default now, same for the trivial > enable_signaling implementation. > > Signed-off-by: Daniel Vetter Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/17] drm/vc4: Remove unecessary dma_fence_ops
Daniel Vetter writes: > dma_fence_default_wait is the default now, same for the trivial > enable_signaling implementation. > > Signed-off-by: Daniel Vetter Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/17] dma-fence: remove fill_driver_data callback
Daniel Vetter writes:
> Noticed while I was typing docs. Entirely unused.
>
> Signed-off-by: Daniel Vetter
> ---
> include/linux/dma-fence.h | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9d6f39bf2111..f9a6848f8558 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -217,16 +217,6 @@ struct dma_fence_ops {
>*/
> void (*release)(struct dma_fence *fence);
>
> - /**
> - * @fill_driver_data:
> - *
> - * Callback to fill in free-form debug info Returns amount of bytes
> - * filled, or negative error on failure.
> - *
> - * This callback is optional.
> - */
> - int (*fill_driver_data)(struct dma_fence *fence, void *data, int size);
> -
There's a reference to this one from timeline_value_str() as well.
Could you fix that up?
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/17] dma-fence: Some kerneldoc polish for dma-fence.h
Daniel Vetter writes: > + /** > + * @fill_driver_data: > + * > + * Callback to fill in free-form debug info Returns amount of bytes > + * filled, or negative error on failure. Maybe this "Returns" should be on a new line? Or at least a '.' in between. Other than that, Reviewed-by: Eric Anholt Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] drm/panel: Support panel detection
On Mon, 30 Apr 2018 10:22:19 -0700 Eric Anholt wrote: > Boris Brezillon writes: > > > Some panels are connected through extension boards an provide an easy > > way for the main board to detect when they are present (like checking > > for a working I2C communication with a device and making sure a > > specific reg in this device has a consistent value). > > > > When this is the case, we might want to support dynamic panel detection > > and only expose the display (and its display modes) when the panel is > > detected, similar to the monitor detection we use for regular > > connectors (HDMI, DVI, ...). > > > > This solves a problem we have on the Rpi when the panel is not > > connected to the board but described in the DT. This prevents the whole > > display pipeline from being exposed because one of the element (the > > panel) is missing. > > > > This was posted as an RFC because I'm not sure dynamically detecting > > panels or supporting panel hotplug is actually something we want to do. > > I want to clarify here: we're not trying to do panel hotplug. We're > trying to boot-time-only detection of whether or not the standard panel > is plugged in. > > Since this is something like the 6th variation of trying to get this > driver to work whether or not the panel is plugged in at boot, I'm > leaning toward just asking the closed source firmware to hack the DT to > add/remove the panel's node depending on whether it can probe it on I2C. > Relying on more closed source software in order to work around something > so trivial is really frustrating, though. Well, we could still have this hack in the rpi-touchscreen-panel driver and expose the panel without any display modes when the device is actually not responding on the I2C bus. This way we could have the DRM device registered and the panel display would just be unusable. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] backlight: Remove ld9040 driver
The driver for LD9040 AMOLED LCD panel was superseded with DRM driver
panel-samsung-ld9040.c. It does not support DeviceTree and respective
possible user (Exynos4210 Universal C210) is DeviceTree-only and uses
DRM version of driver..
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki Dae
Signed-off-by: Krzysztof Kozlowski
---
drivers/video/backlight/Kconfig| 8 -
drivers/video/backlight/Makefile | 1 -
drivers/video/backlight/ld9040.c | 811 -
drivers/video/backlight/ld9040_gamma.h | 202
4 files changed, 1022 deletions(-)
delete mode 100644 drivers/video/backlight/ld9040.c
delete mode 100644 drivers/video/backlight/ld9040_gamma.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index be0c130b6597..2202daf2ab4f 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -111,14 +111,6 @@ config LCD_HP700
If you have an HP Jornada 700 series handheld (710/720/728)
say Y to enable LCD control driver.
-config LCD_LD9040
- tristate "LD9040 AMOLED LCD Driver"
- depends on SPI && BACKLIGHT_CLASS_DEVICE
- default n
- help
- If you have an LD9040 Panel, say Y to enable its
- control driver.
-
config LCD_AMS369FG06
tristate "AMS369FG06 AMOLED LCD Driver"
depends on SPI && BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8773fdd64e99..0b327c0cb750 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_LCD_HX8357)+= hx8357.o
obj-$(CONFIG_LCD_ILI922X) += ili922x.o
obj-$(CONFIG_LCD_ILI9320) += ili9320.o
obj-$(CONFIG_LCD_L4F00242T03) += l4f00242t03.o
-obj-$(CONFIG_LCD_LD9040) += ld9040.o
obj-$(CONFIG_LCD_LMS283GF05) += lms283gf05.o
obj-$(CONFIG_LCD_LMS501KF03) += lms501kf03.o
obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o
diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
deleted file mode 100644
index 677f8abba27c..
--- a/drivers/video/backlight/ld9040.c
+++ /dev/null
@@ -1,811 +0,0 @@
-/*
- * ld9040 AMOLED LCD panel driver.
- *
- * Copyright (c) 2011 Samsung Electronics
- * Author: Donghwa Lee
- * Derived from drivers/video/backlight/s6e63m0.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "ld9040_gamma.h"
-
-#define SLEEPMSEC 0x1000
-#define ENDDEF 0x2000
-#defineDEFMASK 0xFF00
-#define COMMAND_ONLY 0xFE
-#define DATA_ONLY 0xFF
-
-#define MIN_BRIGHTNESS 0
-#define MAX_BRIGHTNESS 24
-
-struct ld9040 {
- struct device *dev;
- struct spi_device *spi;
- unsigned intpower;
- unsigned intcurrent_brightness;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
- struct lcd_platform_data*lcd_pd;
-
- struct mutexlock;
- bool enabled;
-};
-
-static struct regulator_bulk_data supplies[] = {
- { .supply = "vdd3", },
- { .supply = "vci", },
-};
-
-static void ld9040_regulator_enable(struct ld9040 *lcd)
-{
- int ret = 0;
- struct lcd_platform_data *pd = NULL;
-
- pd = lcd->lcd_pd;
- mutex_lock(&lcd->lock);
- if (!lcd->enabled) {
- ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
- if (ret)
- goto out;
-
- lcd->enabled = true;
- }
- msleep(pd->power_on_delay);
-out:
- mutex_unlock(&lcd->lock);
-}
-
-static void ld9040_regulator_disable(struct ld9040 *lcd)
-{
- int ret = 0;
-
- mutex_lock(&lcd->lock);
- if (lcd->enabled) {
- ret = regulator_bulk_disable(ARRAY_SIZE(supplies), supplies);
- if (ret)
- goto out;
-
- lcd->enabled = false;
- }
-out:
- mutex_unlock(&lcd->lock);
-}
-
-static const unsigned short seq_swreset[] = {
- 0x01, COMMAND_ONLY,
- ENDDEF, 0x00
-};
-
-static const unsigned short seq_user_setting[] = {
- 0xF0, 0x5A,
-
- DATA_ONLY, 0x5A,
- ENDDEF, 0x00
-};
-
-static const unsigned short seq_elvss_on[] = {
- 0xB1, 0x0D,
-
- DATA_ONLY, 0x00,
- DATA_ONLY, 0x16,
- ENDDEF, 0x00
-};
-
-static const unsigned short seq_gtcon[] = {
- 0xF7, 0x09,
-
[PATCH 1/2] backlight: Remove s6e63m0 driver
The driver for S6E63M0 AMOLED LCD panel is not used. It does not
support DeviceTree and respective possible users (S5Pv210 Aquila and
Goni boards) are DeviceTree-only.
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki Dae
Signed-off-by: Krzysztof Kozlowski
---
drivers/video/backlight/Kconfig | 8 -
drivers/video/backlight/Makefile| 1 -
drivers/video/backlight/s6e63m0.c | 857
drivers/video/backlight/s6e63m0_gamma.h | 266 --
4 files changed, 1132 deletions(-)
delete mode 100644 drivers/video/backlight/s6e63m0.c
delete mode 100644 drivers/video/backlight/s6e63m0_gamma.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5d2d0d7e8100..be0c130b6597 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -111,14 +111,6 @@ config LCD_HP700
If you have an HP Jornada 700 series handheld (710/720/728)
say Y to enable LCD control driver.
-config LCD_S6E63M0
- tristate "S6E63M0 AMOLED LCD Driver"
- depends on SPI && BACKLIGHT_CLASS_DEVICE
- default n
- help
- If you have an S6E63M0 LCD Panel, say Y to enable its
- LCD control driver.
-
config LCD_LD9040
tristate "LD9040 AMOLED LCD Driver"
depends on SPI && BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 19da71d518bf..8773fdd64e99 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_LCD_LMS283GF05) += lms283gf05.o
obj-$(CONFIG_LCD_LMS501KF03) += lms501kf03.o
obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o
obj-$(CONFIG_LCD_PLATFORM) += platform_lcd.o
-obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
obj-$(CONFIG_LCD_TDO24M) += tdo24m.o
obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
obj-$(CONFIG_LCD_VGG2432A4)+= vgg2432a4.o
diff --git a/drivers/video/backlight/s6e63m0.c
b/drivers/video/backlight/s6e63m0.c
deleted file mode 100644
index 3c4a22a3063a..
--- a/drivers/video/backlight/s6e63m0.c
+++ /dev/null
@@ -1,857 +0,0 @@
-/*
- * S6E63M0 AMOLED LCD panel driver.
- *
- * Author: InKi Dae
- *
- * Derived from drivers/video/omap/lcd-apollon.c
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "s6e63m0_gamma.h"
-
-#define SLEEPMSEC 0x1000
-#define ENDDEF 0x2000
-#defineDEFMASK 0xFF00
-#define COMMAND_ONLY 0xFE
-#define DATA_ONLY 0xFF
-
-#define MIN_BRIGHTNESS 0
-#define MAX_BRIGHTNESS 10
-
-struct s6e63m0 {
- struct device *dev;
- struct spi_device *spi;
- unsigned intpower;
- unsigned intcurrent_brightness;
- unsigned intgamma_mode;
- unsigned intgamma_table_count;
- struct lcd_device *ld;
- struct backlight_device *bd;
- struct lcd_platform_data*lcd_pd;
-};
-
-static const unsigned short seq_panel_condition_set[] = {
- 0xF8, 0x01,
- DATA_ONLY, 0x27,
- DATA_ONLY, 0x27,
- DATA_ONLY, 0x07,
- DATA_ONLY, 0x07,
- DATA_ONLY, 0x54,
- DATA_ONLY, 0x9f,
- DATA_ONLY, 0x63,
- DATA_ONLY, 0x86,
- DATA_ONLY, 0x1a,
- DATA_ONLY, 0x33,
- DATA_ONLY, 0x0d,
- DATA_ONLY, 0x00,
- DATA_ONLY, 0x00,
-
- ENDDEF, 0x
-};
-
-static const unsigned short seq_display_condition_set[] = {
- 0xf2, 0x02,
- DATA_ONLY, 0x03,
- DATA_ONLY, 0x1c,
- DATA_ONLY, 0x10,
- DATA_ONLY, 0x10,
-
- 0xf7, 0x03,
- DATA_ONLY, 0x00,
- DATA_ONLY, 0x00,
-
- ENDDEF, 0x
-};
-
-static const unsigned short seq_gamma_setting[] = {
- 0xfa, 0x00,
- DATA_ONLY, 0x18,
- DATA_ONLY, 0x08,
- DATA_ONLY, 0x24,
- DATA_ONLY, 0x64,
- DATA_ONLY, 0x56,
- DATA_ONLY, 0x33,
- DATA_ONLY, 0xb6,
- DATA_ONLY, 0xba,
- DATA_ONLY, 0xa8,
- DATA_ONLY, 0xac,
- DATA_ONLY, 0xb1,
- DATA_ONLY, 0x9d,
- DATA_ONLY, 0xc1,
- DATA_ONLY, 0xc1,
- DATA_ONLY, 0xb7,
- DATA_ONLY, 0x00,
- DATA_ONLY, 0x9c,
- DATA_ONLY, 0x00,
- DATA_ONLY, 0x9f,
- DATA_ONLY, 0x00,
- DATA_ONLY, 0xd6,
-
- 0xfa, 0x01,
-
- ENDDEF, 0x
-};
-
-static const unsigned short seq_etc_condition_set[] = {
- 0xf6, 0x00,
- DATA_ONLY, 0x8c,
-
Re: [RFC PATCH 0/3] drm/panel: Support panel detection
Boris Brezillon writes: > Some panels are connected through extension boards an provide an easy > way for the main board to detect when they are present (like checking > for a working I2C communication with a device and making sure a > specific reg in this device has a consistent value). > > When this is the case, we might want to support dynamic panel detection > and only expose the display (and its display modes) when the panel is > detected, similar to the monitor detection we use for regular > connectors (HDMI, DVI, ...). > > This solves a problem we have on the Rpi when the panel is not > connected to the board but described in the DT. This prevents the whole > display pipeline from being exposed because one of the element (the > panel) is missing. > > This was posted as an RFC because I'm not sure dynamically detecting > panels or supporting panel hotplug is actually something we want to do. I want to clarify here: we're not trying to do panel hotplug. We're trying to boot-time-only detection of whether or not the standard panel is plugged in. Since this is something like the 6th variation of trying to get this driver to work whether or not the panel is plugged in at boot, I'm leaning toward just asking the closed source firmware to hack the DT to add/remove the panel's node depending on whether it can probe it on I2C. Relying on more closed source software in order to work around something so trivial is really frustrating, though. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/3] drm/panel: Support panel detection
Hi Daniel,
On Mon, 30 Apr 2018 18:08:47 +0200
Daniel Vetter wrote:
> On Mon, Apr 30, 2018 at 04:43:21PM +0200, Boris Brezillon wrote:
> > Some panels might be connected through extension boards and might not
> > be available when the system boots. Extend the panel interface to
> > support panel detection.
> >
> > An optional ->detect() hook is added and, if implemented, will be called
> > every time the panel user wants to know if the panel is connected or
> > disconnected.
> >
> > We also add a ->polled field which should encode the type of polling the
> > DRM core should do (DRM_CONNECTOR_POLL_HPD, DRM_CONNECTOR_POLL_CONNECT
> > and DRM_CONNECTOR_POLL_DISCONNECT flags).
> >
> > Signed-off-by: Boris Brezillon
>
> Hm, not sure panel detection makes much sense, the entire idea behind
> drm_panel is to hard-code a fixed/built-in panel. The only thing panels
> may report through the connection status is whether the lid is closed or
> not. Yes we should probably document that somewhere.
>
> If you have a panel-that-can-be-hotplugged a drm_bridge that implemens the
> drm_connector is probably the way to go.
That does not really work for the rpi panel case because we use an I2C
message to detect the presence of the panel. So, unless we decide to
attach the I2C client to the bridge device instead of attaching it to
the panel that's not really possible, and I'm not sure doing that is a
good thing either.
I guess the only alternative to solve the issue I'm trying to solve is
drm_bridge hotplug, so that we allow the DRM device to be registered
even if not all of its leaf nodes (i.e. bridges and connectors) are
ready to be used.
>
> > ---
> > include/drm/drm_panel.h | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 14ac240a1f64..718cc1f746ab 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -24,6 +24,7 @@
> > #ifndef __DRM_PANEL_H__
> > #define __DRM_PANEL_H__
> >
> > +#include
> > #include
> > #include
> >
> > @@ -68,6 +69,7 @@ struct display_timing;
> > * the panel. This is the job of the .unprepare() function.
> > */
> > struct drm_panel_funcs {
> > + int (*detect)(struct drm_panel *panel);
>
> Kerneldoc for this please. Would also be really good to switch this struct
> of function pointers over to the in-line style, and put the paragraphs
> relevant for a given callback into it's dedicated comment.
Not useful anymore since the idea appeared to be bad ;-).
Thanks for the quick feedback.
Boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE
On 2018-04-29 09:02 AM, Christian König wrote: > Am 29.04.2018 um 01:02 schrieb Michel Dänzer: >> On 2018-04-28 06:30 PM, Ilia Mirkin wrote: >>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer >>> wrote: From: Michel Dänzer Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled) try to allocate huge pages. However, not all drivers can take advantage of huge pages, but they would incur the overhead for allocating and freeing them anyway. Now, drivers which can take advantage of huge pages need to set the new flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag no longer incur any overhead for allocating or freeing huge pages. v2: * Also guard swapping of consecutive pages in ttm_get_pages * Reword commit log, hopefully clearer now Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer >>> Both I and lots of other people, based on reports, are still seeing >>> plenty of issues with this as late as 4.16.4. >> "lots of other people", "plenty of issues" sounds a bit exaggerated from >> what I've seen. FWIW, while I did see the original messages myself, I >> haven't seen any since Christian's original fix (see below), neither >> with amdgpu nor radeon, even before this patch you followed up to. >> >> >>> Admittedly I'm on nouveau, but others have reported issues with >>> radeon/amdgpu as well. It's been going on since the feature was merged >>> in v4.15, with what seems like little investigation from the authors >>> introducing the feature. >> That's not a fair assessment. See >> https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and following >> comments. >> >> Christian fixed the original issue in >> d0bc0c2a31c95002d37c3cc511ffdcab851b3256 "swiotlb: suppress warning when >> __GFP_NOWARN is set". Christian did his best to try and get the fix in >> before 4.15 final, but for reasons beyond his control, it was delayed >> until 4.16-rc1 and then backported to 4.15.5. >> >> Unfortunately, there was an swiotlb regression (not directly related to >> Christian's work) shortly after this fix, also in 4.16-rc1, which is now >> fixed in 4.17-rc1 and will be backported to 4.16.y. > > And that's exactly the reason why I intentionally kept this enabled for > all users of the TTM DMA page pool and not put it behind a flag. > > This change has surfaced quite a number of bugs in the swiotlb code > which could have caused issues before. It's just that those code path > where never exercised massively before. > > Additional to that using huge pages is beneficial for the MM and CPU TLB > (not implemented yet) even when the GPU driver can't make much use of it. Do I understand correctly that you're against this patch? AFAIU the only benefit of huge pages with a driver which doesn't take advantage of them directly is "for the MM". Can you describe a bit more what that benefit is exactly? Is it expected to outweigh the cost of allocating / freeing huge pages? >> It looks like there's at least one more bug left, but it's not clear yet >> when that was introduced, whether it's directly related to Christian's >> work, or indeed what the impact is. Let's not get ahead of ourselves. > > Well my patches surfaced the problems, but the underlying issues where > present even before those changes and I'm very well involved in fixing > the underlying issues. > > I even considered to just revert the huge page path for the DMA pool > allocator, but it's just that the TTM patches seem to work exactly as > they are intended. So that doesn't feel like doing the right thing here. I agree. Has anyone reported this to the DMA/SWIOTLB developers? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/3] drm/panel: Support panel detection
On Mon, Apr 30, 2018 at 04:43:21PM +0200, Boris Brezillon wrote:
> Some panels might be connected through extension boards and might not
> be available when the system boots. Extend the panel interface to
> support panel detection.
>
> An optional ->detect() hook is added and, if implemented, will be called
> every time the panel user wants to know if the panel is connected or
> disconnected.
>
> We also add a ->polled field which should encode the type of polling the
> DRM core should do (DRM_CONNECTOR_POLL_HPD, DRM_CONNECTOR_POLL_CONNECT
> and DRM_CONNECTOR_POLL_DISCONNECT flags).
>
> Signed-off-by: Boris Brezillon
Hm, not sure panel detection makes much sense, the entire idea behind
drm_panel is to hard-code a fixed/built-in panel. The only thing panels
may report through the connection status is whether the lid is closed or
not. Yes we should probably document that somewhere.
If you have a panel-that-can-be-hotplugged a drm_bridge that implemens the
drm_connector is probably the way to go.
> ---
> include/drm/drm_panel.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 14ac240a1f64..718cc1f746ab 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -24,6 +24,7 @@
> #ifndef __DRM_PANEL_H__
> #define __DRM_PANEL_H__
>
> +#include
> #include
> #include
>
> @@ -68,6 +69,7 @@ struct display_timing;
> * the panel. This is the job of the .unprepare() function.
> */
> struct drm_panel_funcs {
> + int (*detect)(struct drm_panel *panel);
Kerneldoc for this please. Would also be really good to switch this struct
of function pointers over to the in-line style, and put the paragraphs
relevant for a given callback into it's dedicated comment.
-Daniel
> int (*disable)(struct drm_panel *panel);
> int (*unprepare)(struct drm_panel *panel);
> int (*prepare)(struct drm_panel *panel);
> @@ -90,6 +92,7 @@ struct drm_panel {
> struct drm_connector *connector;
> struct device *dev;
>
> + u8 polled;
> const struct drm_panel_funcs *funcs;
>
> struct list_head list;
> @@ -186,6 +189,15 @@ static inline int drm_panel_get_modes(struct drm_panel
> *panel)
> return panel ? -ENOSYS : -EINVAL;
> }
>
> +static inline int drm_panel_detect(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->detect)
> + return panel->funcs->detect(panel);
> +
> + /* Consider the panel as connected by default. */
> + return panel ? connector_status_connected : -EINVAL;
> +}
> +
> void drm_panel_init(struct drm_panel *panel);
>
> int drm_panel_add(struct drm_panel *panel);
> --
> 2.14.1
>
--
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
Re: [PATCH v3] drm: rcar-du: track dma-buf fences
On Mon, Apr 30, 2018 at 02:02:04PM +0200, Emre Ucan wrote: > We have to check dma-buf reservation objects of our framebuffers before > we use them. Otherwise, another driver might be writing on the same > buffer which we are using. This would cause visible tearing effects > on display. > > We can use existing atomic helper functions to solve this problem. > > v2 changes: > - Remove drm_atomic_helper_wait_for_fences() call in rcar_du_kms.c. > The commit_tail() function in drm_atomic_helper.c, which calls our > atomic_commit_tail() implementation, already calls it. > - Remove proposed rcar_du_vsp_set_fence_for_plane() function. > Call drm_gem_fb_prepare_fb(), which calls > drm_atomic_set_fence_for_plane(). > > v3 changes: > - Sort the added header file alphabetically. > - Check return value of drm_gem_fb_prepare_fb() and clean up in the case > of error. > > Signed-off-by: Emre Ucan Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > index 2c260c3..73c7948 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -237,6 +238,10 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane > *plane, > } > } > > + ret = drm_gem_fb_prepare_fb(plane, state); > + if (ret) > + goto fail; > + > return 0; > > fail: > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] drm/amd/dc: Add dc display driver (v2)
Replied on the ticket. If this is about non-functioning LVDS or VGA I'm aware of it and trying to find time to find a good solution. Harry On 2018-04-30 11:14 AM, Joseph Salisbury wrote: > Hi Harry, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found the following commit introduced the bug: > > > commit 4562236b3bc0a28aeb6ee93b2d8a849a4c4e1c7c > Author: Harry Wentland > Date: Tue Sep 12 15:58:20 2017 -0400 > > drm/amd/dc: Add dc display driver (v2) > > > The regression was introduced as of v4.15-rc1 and still exists in > current mainline. The commit does not need to be reverted to resolve > the bug. Disabling the CONFIG_DRM_AMD_DC_PRE_VEGA option makes the bug > go away. > > I was hoping to get your feedback, since you are the patch author. Do > you think gathering any additional data will help diagnose this issue? > > > Thanks, > > Joe > > > [0] http://pad.lv/1761751 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation
On Sun, Apr 29, 2018 at 09:08:31AM +0200, Christian König wrote:
> NAK, there is a subtitle but major difference:
>
> > - if (rdev->needs_reset) {
> > - t = -EDEADLK;
> > - break;
> > - }
>
> Without that the whole radeon GPU reset code breaks.
Oops I've missed that. How does this work when you register a callback
using ->enable_signaling and then block on it? Everything just dies?
We have lots of users of that for buffer/fence sharing. A really ugly, but
probably working fix for this would be a kthread worker that just looks
for ->needs_reset and force-completes all fences with
dma_fence_set_error(-EIO), which is kinda what's supposed to happen here
anyway.
-Daniel
>
> Regards,
> Christian.
>
>
> Am 27.04.2018 um 08:17 schrieb Daniel Vetter:
> > It's a copy of dma_fence_default_wait, written slightly differently.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: amd-...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/radeon/radeon_fence.c | 63 ---
> > 1 file changed, 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> > b/drivers/gpu/drm/radeon/radeon_fence.c
> > index e86f2bd38410..32690a525bfc 100644
> > --- a/drivers/gpu/drm/radeon/radeon_fence.c
> > +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> > @@ -1051,72 +1051,9 @@ static const char
> > *radeon_fence_get_timeline_name(struct dma_fence *f)
> > }
> > }
> > -static inline bool radeon_test_signaled(struct radeon_fence *fence)
> > -{
> > - return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->base.flags);
> > -}
> > -
> > -struct radeon_wait_cb {
> > - struct dma_fence_cb base;
> > - struct task_struct *task;
> > -};
> > -
> > -static void
> > -radeon_fence_wait_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
> > -{
> > - struct radeon_wait_cb *wait =
> > - container_of(cb, struct radeon_wait_cb, base);
> > -
> > - wake_up_process(wait->task);
> > -}
> > -
> > -static signed long radeon_fence_default_wait(struct dma_fence *f, bool
> > intr,
> > -signed long t)
> > -{
> > - struct radeon_fence *fence = to_radeon_fence(f);
> > - struct radeon_device *rdev = fence->rdev;
> > - struct radeon_wait_cb cb;
> > -
> > - cb.task = current;
> > -
> > - if (dma_fence_add_callback(f, &cb.base, radeon_fence_wait_cb))
> > - return t;
> > -
> > - while (t > 0) {
> > - if (intr)
> > - set_current_state(TASK_INTERRUPTIBLE);
> > - else
> > - set_current_state(TASK_UNINTERRUPTIBLE);
> > -
> > - /*
> > -* radeon_test_signaled must be called after
> > -* set_current_state to prevent a race with wake_up_process
> > -*/
> > - if (radeon_test_signaled(fence))
> > - break;
> > -
> > - if (rdev->needs_reset) {
> > - t = -EDEADLK;
> > - break;
> > - }
> > -
> > - t = schedule_timeout(t);
> > -
> > - if (t > 0 && intr && signal_pending(current))
> > - t = -ERESTARTSYS;
> > - }
> > -
> > - __set_current_state(TASK_RUNNING);
> > - dma_fence_remove_callback(f, &cb.base);
> > -
> > - return t;
> > -}
> > -
> > const struct dma_fence_ops radeon_fence_ops = {
> > .get_driver_name = radeon_fence_get_driver_name,
> > .get_timeline_name = radeon_fence_get_timeline_name,
> > .enable_signaling = radeon_fence_enable_signaling,
> > .signaled = radeon_fence_is_signaled,
> > - .wait = radeon_fence_default_wait,
> > - .release = NULL,
> > };
>
--
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
Re: [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences
On Sun, Apr 29, 2018 at 09:11:31AM +0200, Christian König wrote:
> Am 27.04.2018 um 08:17 schrieb Daniel Vetter:
> > When this was introduced in
> >
> > commit a519435a96597d8cd96123246fea4ae5a6c90b02
> > Author: Christian König
> > Date: Tue Oct 20 16:34:16 2015 +0200
> >
> > dma-buf/fence: add fence_wait_any_timeout function v2
> >
> > there was a restriction added that this only works if the dma-fence
> > uses the dma_fence_default_wait hook. Which works for amdgpu, which is
> > the only caller. Well, until you share some buffers with e.g. i915,
> > then you get an -EINVAL.
> >
> > But there's really no reason for this, because all drivers must
> > support callbacks. The special ->wait hook is only as an optimization;
> > if the driver needs to create a worker thread for an active callback,
> > then it can avoid to do that if it knows that there's a process
> > context available already. So ->wait is just an optimization, just
> > using the logic in dma_fence_default_wait() should work for all
> > drivers.
> >
> > Let's remove this restriction.
>
> Mhm, that was intentional introduced because for radeon that is not only an
> optimization, but mandatory for correct operation.
>
> On the other hand radeon isn't using this function, so it should be fine as
> long as the Intel driver can live with it.
Well dma-buf already requires that dma_fence_add_callback works correctly.
And so do various users of it as soon as you engage in a bit of buffer
sharing. I guess whomever cares about buffer sharing with radeon gets to
fix this (you need to spawn a kthread or whatever in ->enable_signaling
which does the same work as your optimized ->wait callback).
But yeah, I'm definitely not making things work with this series, just a
bit more obvious that there's a problem already.
-Daniel
>
> Christian.
>
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Sumit Semwal
> > Cc: Gustavo Padovan
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Christian König
> > Cc: Alex Deucher
> > ---
> > drivers/dma-buf/dma-fence.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 7b5b40d6b70e..59049375bd19 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -503,11 +503,6 @@ dma_fence_wait_any_timeout(struct dma_fence **fences,
> > uint32_t count,
> > for (i = 0; i < count; ++i) {
> > struct dma_fence *fence = fences[i];
> > - if (fence->ops->wait != dma_fence_default_wait) {
> > - ret = -EINVAL;
> > - goto fence_rm_cb;
> > - }
> > -
> > cb[i].task = current;
> > if (dma_fence_add_callback(fence, &cb[i].base,
> >dma_fence_default_wait_cb)) {
>
--
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
Re: [PATCH] video: fbdev: omap2: remove rfbi
On Friday, April 27, 2018 09:25:37 PM Aaro Koskinen wrote:
> Hi,
>
> On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"):
> >
> > The RFBI driver has not worked nor compiled for many years. There are
>
> What is the build failure you are seeing?
>
> When removing the "BROKEN", it seems to compile fine, only some sparse
> warnings:
BROKEN is not an user selectable config option so without modifying
drivers/video/fbdev/omap2/omapfb/dss/Kconfig the RFBI driver is not
even included in the kernel build..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 24/24] drm/bridge: establish a link between the bridge supplier and consumer
On Fri, Apr 27, 2018 at 12:31:39AM +0200, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
>
> Signed-off-by: Peter Rosin
Minus the ->owner bikeshed I brought up in the previous patch I agree with
this approach as the best way to move forward for now.
Acked-by: Daniel Vetter
One small suggestion below, for merging I'd say pls get Jyri's
review/tested-by too, since you're both working on the same problem it
seems.
Aside: Do you want commit rights to drm-misc to be able to push work like
this?
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_bridge.c | 18 ++
> include/drm/drm_bridge.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index a038da696802..f0c79043ec43 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -124,12 +125,25 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> struct drm_bridge *bridge,
> if (bridge->dev)
> return -EBUSY;
>
> + if (encoder->dev->dev != bridge->owner) {
You might end up with a NULL encoder->dev->dev. Perhaps check that and
bail with a WARN_ON?
> + bridge->link = device_link_add(encoder->dev->dev,
> +bridge->owner, 0);
> + if (!bridge->link) {
> + dev_err(bridge->owner, "failed to link bridge to %s\n",
> + dev_name(encoder->dev->dev));
> + return -EINVAL;
> + }
> + }
> +
> bridge->dev = encoder->dev;
> bridge->encoder = encoder;
>
> if (bridge->funcs->attach) {
> ret = bridge->funcs->attach(bridge);
> if (ret < 0) {
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> bridge->dev = NULL;
> bridge->encoder = NULL;
> return ret;
> @@ -156,6 +170,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> if (bridge->funcs->detach)
> bridge->funcs->detach(bridge);
>
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> +
> bridge->dev = NULL;
> }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3bc659f3e7d2..9a386559a41a 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> * @list: to keep track of all added bridges
> * @timings: the timing specification for the bridge, if any (may
> * be NULL)
> + * @link: drm consumer <-> bridge supplier
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -271,6 +272,7 @@ struct drm_bridge {
> struct drm_bridge *next;
> struct list_head list;
> const struct drm_bridge_timings *timings;
> + struct device_link *link;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 23/24] drm/bridge: require the .owner to be filled in on drm_bridge_attach
On Fri, Apr 27, 2018 at 12:31:38AM +0200, Peter Rosin wrote: > The .owner will be handy to have around. > > Signed-off-by: Peter Rosin > --- > drivers/gpu/drm/drm_bridge.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 9f023bd84d56..a038da696802 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -115,6 +115,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct > drm_bridge *bridge, > if (!encoder || !bridge) > return -EINVAL; > > + if (WARN_ON(!bridge->owner)) > + return -EINVAL; I think conceptually this is checked at the wrong place, and I think also misnamed a bit. The ->owner is essentially the struct device (and its associated driver) that provides the drm_bridge. As such it should be filled out already at drm_bridge_add() time, and I think the check should be in there. For driver-internal bridges it might make sense to also check this here, not sure. Or just require all bridges get added. Wrt the name, I think we should call this pdev or something. ->owner usually means the module owner. I think in other subsystems ->dev is used, but in drm we use ->dev for the drm_device pointer, so totally different thing. pdev = physical device is the best I came up with. Better suggestions very much welcome. -Daniel > + > if (previous && (!previous->dev || previous->encoder != encoder)) > return -EINVAL; > > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ARM: dts: Modernize the Vexpress PL111 integration
On 27/04/18 20:54, Linus Walleij wrote:
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by connecting
the PL111 pads to it, making it use EDID or fallback values
to drive the monitor.
The also has to use the reserved memory through the
CMA pool rather than by open coding a memory region and
remapping it explicitly in the driver. To achieve this,
a reserved-memory node must exist in the root of the
device tree, so we need to pull that out of the
motherboard .dtsi include files, and push it into each
top-level device tree instead.
We do the same manouver for all the Versatile Express
boards, taking into account the different location of the
video RAM depending on which chip select is used on
each platform.
This plays nicely with the new PL111 DRM driver and
follows the standard ways of assigning bridges and
memory pools for graphics.
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 51 +--
arch/arm/boot/dts/vexpress-v2m.dtsi | 52 ++--
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 +++
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 14 +++
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 +++
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 41 ---
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 14 +++
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++--
8 files changed, 119 insertions(+), 118 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 7b8ff5b3b912..51517c832b9b 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -43,11 +43,6 @@
bank-width = <4>;
};
- v2m_video_ram: vram@2, {
- compatible = "arm,vexpress-vram";
- reg = <2 0x 0x0080>;
- };
-
ethernet@2,0200 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x0200 0x1>;
@@ -224,6 +219,21 @@
dvi-transmitter@39 {
compatible = "sil,sii9022-tpi",
"sil,sii9022";
reg = <0x39>;
+ #address-cells = <1>;
+ #size-cells = <0>;
These aren't used, since the ports node has no "reg" property to decode.
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
Similarly, if this "reg" is only there to satisfy the unit address the
whole business could just be elided at this level too - I don't think
it's particularly meaningful if the SiI9022 doesn't have multiple
addressable inputs itself.
+
+ dvi_bridge_in:
endpoint {
+ remote-endpoint =
<&clcd_pads>;
+ };
+ };
+ };
};
dvi-transmitter@60 {
@@ -254,37 +264,16 @@
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
- memory-region = <&v2m_video_ram>;
- max-memory-bandwidth = <5035>; /*
16bpp @ 25.175MHz */
+ /* 800x600 16bpp @36MHz works fine */
+ max-memory-bandwidth = <5400>;
+ memory-region = <&vram>;
port {
- v2m_clcd_pads: endpoint {
- remote-endpoint =
<&v2m_clcd_panel>;
+ clcd_pads: endpoint {
+ remote-endpoint =
<&dvi_bridge_in>;
Re: [PATCH 00/24] device link, bridge supplier <-> drm device
On Fri, Apr 27, 2018 at 01:40:21AM +0300, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patches. > > On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote: > > Hi! > > > > It was noted by Russel King [1] that bridges (not using components) > > might disappear unexpectedly if the owner of the bridge was unbound. > > Jyri Sarha had previously noted the same thing with panels [2]. Jyri > > came up with using device links to resolve the panel issue, which > > was also my (independent) reaction to the note from Russel. > > > > This series builds up to the addition of that link in the last > > patch, but in my opinion the other 23 patches do have merit on their > > own. > > > > The last patch needs testing, while the others look trivial. That > > said, I might have missed some subtlety. > > I don't think this is the way to go. We have a real lifetime management > problem with bridges, and device links are just trying to hide the problem > under the carpet. They will further corner us by making a real fix much more > difficult to implement. I'll try to comment further in the next few days on > what I think a better solution would be, but in a nutshell I believe that > drm_bridge objects need to be refcounted, with a .release() operation to free > the bridge resources when the reference count drops to zero. This shouldn't > be > difficult to implement and I'm willing to help. I agree that refcounting is the proper fix if bridges can be hot-unplugged, independently of the overall drm_device. And yes retro-shoehorning refcounting is "fun", but it's also not impossible. I've done it a few times by now in drm. Otoh, refcounting has a pretty serious cost - we're still blowing up drm_framebuffer refcounting in corner cases at shocking regularity, and that's something that's been refcounted for years by now. As long as we don't have a clearly defined need to make bridges hotpluggable then I think not paying the hefty bill just yet is the correct technical decision. This patch series here looks like a reasonable way to tie the lifetimes together a bit more closely and should fix the bugs we have right now. Cheers, Daniel PS: Yes there's cases where you can hotplug display blocks on a SoC. To my knowledge they're all covered by hotplugging the entire drm_device (plus all the statically associated bits like drm_bridge/crtc/plane/encoder). And we're already working on fixing up drm_device to at least make it possible to write a correct hot-unpluggable driver in theory. We'll see whether anyone manages to pull that off in practice :-) > > > [1] https://lkml.org/lkml/2018/4/23/769 > > [2] https://www.spinics.net/lists/dri-devel/msg174275.html > > > > Peter Rosin (24): > > drm/bridge: allow optionally specifying an .owner device > > drm/bridge: adv7511: provide an .owner device > > drm/bridge/analogix: core: specify the .owner of the bridge > > drm/bridge: analogix-anx78xx: provide an .owner device > > drm/bridge: vga-dac: provide an .owner device > > drm/bridge: lvds-encoder: provide an .owner device > > drm/bridge: megachips-stdp-ge-b850v3-fw: provide an .owner device > > drm/bridge: nxp-ptn3460: provide an .owner device > > drm/bridge: panel: provide an .owner device > > drm/bridge: ps8622: provide an .owner device > > drm/bridge: sii902x: provide an .owner device > > drm/bridge: sii9234: provide an .owner device > > drm/bridge: sii8620: provide an .owner device > > drm/bridge: synopsys: provide an .owner device for the bridges > > drm/bridge: tc358767: provide an .owner device > > drm/bridge: ti-tfp410: provide an .owner device > > drm/exynos: mic: provide an .owner device for the bridge > > drm/mediatek: hdmi: provide an .owner device for the bridge > > drm/msm: specify the .owner of the bridges > > drm/rcar-du: lvds: provide an .owner device for the bridge > > drm/sti: provide an .owner device for the bridges > > drm/bridge: remove the .of_node member > > drm/bridge: require the .owner to be filled in on drm_bridge_attach > > drm/bridge: establish a link between the bridge supplier and consumer > > > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 + > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > drivers/gpu/drm/bridge/lvds-encoder.c | 2 +- > > .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > drivers/gpu/drm/bridge/panel.c | 4 +--- > > drivers/gpu/drm/bridge/parade-ps8622.c | 2 +- > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > drivers/gpu/drm/bridge/sii9234.c | 2 +- > > drivers/gpu/drm/bridge/sil-sii8620.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +--- > > drivers/
Re: [PATCH] drm/rect: Fix drm_rect_rotation_inv() docs
On Thu, Apr 26, 2018 at 05:16:31PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > An overeager sed has corrupted the drm_rect_rotation_inv() > documentation. Fix it up. > > Looks like it wasn't entirely correct before the sed fail > either. We were missing _rect_ from the function names, which > also explains why the sed hit these by accident. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_rect.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c > index 9817c1445ba9..a3783ecea297 100644 > --- a/drivers/gpu/drm/drm_rect.c > +++ b/drivers/gpu/drm/drm_rect.c > @@ -373,8 +373,8 @@ EXPORT_SYMBOL(drm_rect_rotate); > * them when doing a rotatation and its inverse. > * That is, if you do :: > * > - * DRM_MODE_PROP_ROTATE(&r, width, height, rotation); > - * DRM_MODE_ROTATE_inv(&r, width, height, rotation); > + * drm_rect_rotate(&r, width, height, rotation); > + * drm_rect_rotate_inv(&r, width, height, rotation); > * > * you will always get back the original rectangle. > */ > -- > 2.16.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100891] failed to send pre message kernel output delays booting/suspending/resuming
https://bugs.freedesktop.org/show_bug.cgi?id=100891 --- Comment #7 from MichaelLong --- Created attachment 139230 --> https://bugs.freedesktop.org/attachment.cgi?id=139230&action=edit recent lspci output -- 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 v7 1/2] drm: content-type property for HDMI connector
On Fri, Apr 27, 2018 at 10:40:00PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:34:41AM +0300, StanLis wrote:
> > From: Stanislav Lisovskiy
> >
> > Added content_type property to drm_connector_state
> > in order to properly handle external HDMI TV content-type setting.
> >
> > v2:
> > * Moved helper function which attaches content type property
> >to the drm core, as was suggested.
> >Removed redundant connector state initialization.
> >
> > v3:
> > * Removed caps in drm_content_type_enum_list.
> >After some discussion it turned out that HDMI Spec 1.4
> >was wrongly assuming that IT Content(itc) bit doesn't affect
> >Content type states, however itc bit needs to be manupulated
> >as well. In order to not expose additional property for itc,
> >for sake of simplicity it was decided to bind those together
> >in same "content type" property.
> >
> > v4:
> > * Added it_content checking in intel_digital_connector_atomic_check.
> >Fixed documentation for new content type enum.
> >
> > v5:
> > * Moved patch revision's description to commit messages.
> >
> > v6:
> > * Minor naming fix for the content type enumeration string.
> >
> > v7:
> > * Fix parameter name for documentation and parameter alignment
> >in order not to get warning. Added Content Type description to
> >new HDMI connector properties section.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > Documentation/gpu/drm-kms.rst| 6 +++
> > Documentation/gpu/kms-properties.csv | 1 +
> > drivers/gpu/drm/drm_atomic.c | 17 +++
> > drivers/gpu/drm/drm_connector.c | 74
> > drivers/gpu/drm/drm_edid.c | 2 +
> > include/drm/drm_connector.h | 18 +++
> > include/drm/drm_mode_config.h| 5 ++
> > include/uapi/drm/drm_mode.h | 7 +++
> > 8 files changed, 130 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 1dffd1ac4cd4..e233c2626bd0 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -517,6 +517,12 @@ Standard Connector Properties
> > .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > :doc: standard connector properties
> >
> > +HDMI Specific Connector Properties
> > +-
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > + :doc: HDMI connector properties
> > +
> > Plane Composition Properties
> >
> >
> > diff --git a/Documentation/gpu/kms-properties.csv
> > b/Documentation/gpu/kms-properties.csv
> > index 6b28b014cb7d..3567c986bd7d 100644
> > --- a/Documentation/gpu/kms-properties.csv
> > +++ b/Documentation/gpu/kms-properties.csv
> > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> > Values,Object attached,De
> > ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > Max=0x",Connector,property to suggest an X offset for a connector
> > ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to
> > suggest an Y offset for a connector
> > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > }",Connector,TDB
> > +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"",
> > ""Cinema"", ""Game"" }",Connector,TBD
> > i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> > ""Limited 16:235"" }",Connector,"When this property is set to Limited
> > 16:235 and CTM is set, the hardware will be programmed with the result of
> > the multiplication of CTM by the limited range matrix to ensure the pixels
> > normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
> > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> > etc.",Connector,TBD
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 7d25c42f22db..479499f5848e 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > state->link_status = val;
> > } else if (property == config->aspect_ratio_property) {
> > state->picture_aspect_ratio = val;
> > + } else if (property == config->content_type_property) {
> > + /*
> > +* Lowest two bits of content_type property control
> > +* content_type, bit 2 controls itc bit.
> > +* It was decided to have a single property called
> > +* content_type, instead of content_type and itc.
> > +*/
> > + state->content_type = val & 3;
> > + state->it_content = val >> 2;
> > } else if (property == connector->scaling_mode_property) {
> > state->scaling_mode = val;
> > } else if (property == connector->content_protec
[Bug 100891] failed to send pre message kernel output delays booting/suspending/resuming
https://bugs.freedesktop.org/show_bug.cgi?id=100891 --- Comment #6 from MichaelLong --- Created attachment 139229 --> https://bugs.freedesktop.org/attachment.cgi?id=139229&action=edit dmesg output of kernel 4.17-rc3 -- 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 100891] failed to send pre message kernel output delays booting/suspending/resuming
https://bugs.freedesktop.org/show_bug.cgi?id=100891 --- Comment #5 from MichaelLong --- Update: >From time to time I'm testing this card with newer kernels along with the most recent set of firmware files. The only difference I was able to observe is that the amount of debug messages is less and less with every new kernel. With kernel 4.9 there were so many debug messages emitted that the monitor was in standby for more than 10min, now e.g. with 4.17-rc3 there only a few messages (see newer dmesg output), hardly noticeable. Unfortunately the result remains the same: Shortly after booting, the GPU temperature is rising constantly, the fans are not starting to spin. My guess is that eventually the card will overheat or go into some sort of emergency mode. I was always shutting down earlier. In the meantime I was also able to test the card in a few other PC systems. Interestingly the card is working there without any of the above mentioned issues. The affected mainboard I'm trying to use the card with is an ASUS X99-E WS 3.1 (https://www.asus.com/Commercial-Servers-Workstations/X99E_WSUSB_31/). Other cards are running fine. Right now I'm using a 'VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM]' without problems. In the current state this R9 380X is unusable for me. Please let me know if there is any chance to get this fixed. I'm happy to test out any patches if needed. -- 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: igt trouble with planes shared between multiple CRTCs (Re: [PATCH v2 0/8] R-Car DU: Support CRC calculation)
On Mon, Apr 30, 2018 at 04:55:24PM +0200, Daniel Vetter wrote:
> On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > (Removing the linux-media mailing list from CC as it is out of scope)
> >
> > You enquired on IRC whether this patch series passes the igt CRC tests.
> >
> > # ./kms_pipe_crc_basic --run-subtest read-crc-pipe-A
> > IGT-Version: 1.22-gf447f5fc531d (aarch64) (Linux:
> > 4.17.0-rc1-00085-g56e849d93cc9 aarch64)
> > read-crc-pipe-A: Testing connector LVDS-1 using pipe A
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> > function igt_pipe_crc_start, file igt_debugfs.c:764:
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> > pipe_crc->crc_fd != -1
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5, Input/output
> > error
> > Stack trace:
> > Subtest read-crc-pipe-A failed.
> > DEBUG
> > (kms_pipe_crc_basic:1638) DEBUG: Test requirement passed: !(pipe >=
> > data->display.n_pipes)
> > (kms_pipe_crc_basic:1638) INFO: read-crc-pipe-A: Testing connector LVDS-1
> > using pipe A
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: set_pipe(A)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: Selecting pipe A
> > (kms_pipe_crc_basic:1638) DEBUG: Clearing the fb with color (0.00,1.00,0.00)
> > (kms_pipe_crc_basic:1638) igt-fb-DEBUG:
> > igt_create_fb_with_bo_size(width=1024, height=768, format=0x34325258,
> > tiling=0x0, size=0)
> > (kms_pipe_crc_basic:1638) igt-fb-DEBUG:
> > igt_create_fb_with_bo_size(handle=1, pitch=4096)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: Test requirement passed: plane_idx
> > >= 0 && plane_idx < pipe->n_planes
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_fb(140)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_size
> > (1024x768)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: fb_set_position(0,0)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: fb_set_size(1024x768)
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: commit {
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: SetCrtc pipe
> > A, fb 140, src (0, 0), mode 1024x768
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe A,
> > disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> > plane 2, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> > plane 3, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> > plane 4, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe B,
> > disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> > plane 1, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> > plane 2, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> > plane 3, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> > plane 4, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe C,
> > disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> > plane 1, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> > plane 2, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> > plane 3, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> > plane 4, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> > disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> > disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> > plane 2, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> > plane 3, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> > plane 4, disabling
> > (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: }
> > (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> > '/sys/kernel/debug/dri/0'
> > (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> > '/sys/kernel/debug/dri/0'
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> > function igt_pipe_crc_start, file igt_debugfs.c:764:
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> > pipe_crc->crc_fd != -1
> > (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5, Input/output
> > error
> > (kms_pipe_crc_basic:1638) igt-core-INFO: Stack trace:
> > END
> > Subtest read-crc-pipe-A: FAIL (0.061s)
> >
> > I think the answer is no, but I don't think it's the fault of this patch
> > series. Opening the CRC data file returns -EIO because the CRTC is not
> > active,
> > and I'm trying to find out why that is the case. The debug
[Bug 105018] Kernel panic when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=105018 --- Comment #32 from L.S.S. --- So it seems there definitely is a regression on 4.17 on this issue (the patches are not required as the lines were already there in 4.17). This time it isn't a kernel panic, but an "invalid opcode" error caused by dm_update_crtcs_state that was called by amdgpu_dm_atomic_check. The issue is not 100% reproducible, but still means going to standby with an AMD GPU and DC is still dangerous and may result in losses of unsaved work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express
On 27/04/18 19:51, Linus Walleij wrote: On Fri, Apr 27, 2018 at 5:02 PM, Robin Murphy wrote: I dug a little bit and it seems pl111_modeset_init() is deferring because it can't find endpoint 0. And given that that's apparently pointing at some non-existent panel rather than the DVI encoder as I would (naively) expect, I can at least form a self-consistent explanation and give up on the grounds that I'm probably missing some important DT changes. Yeah it does help if I also send the required DT changes :/ Sorry for my absentmindedness, I'll shoot it off right now so you can test it. Hooray, thanks for that. For these 2 patches with a V2P-CA15_A7 tile and the DT fixed up, Tested-by: Robin Murphy Framebuffer console and /dev/fb0 access for the motherboard CLCD works, and it keeps out of the way as expected with CONFIG_DRM_HDLCD=y. I can't convince an X session to start, but that appears more to do with sii902x falling apart*, which I can't be bothered to even try debugging. Robin. *specifically, lots of this, which I imagine is related to xorg trying to either read the EDID or change mode: ... [ 243.439669] i2c i2c-0: sendbytes: NAK bailout. [ 243.454247] i2c i2c-0: sendbytes: NAK bailout. [ 247.743261] i2c i2c-0: sendbytes: NAK bailout. [ 247.770281] sii902x 0-0039: failed to read status (-6) [ 247.786609] i2c i2c-0: sendbytes: NAK bailout. [ 248.118522] i2c i2c-0: sendbytes: NAK bailout. [ 248.145485] sii902x 0-0039: failed to read status (-6) [ 248.177800] i2c i2c-0: sendbytes: NAK bailout. [ 258.256500] i2c i2c-0: sendbytes: NAK bailout. [ 258.274763] i2c i2c-0: sendbytes: NAK bailout. [ 268.499637] i2c i2c-0: sendbytes: NAK bailout. [ 268.517899] i2c i2c-0: sendbytes: NAK bailout. ... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: igt trouble with planes shared between multiple CRTCs (Re: [PATCH v2 0/8] R-Car DU: Support CRC calculation)
On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> (Removing the linux-media mailing list from CC as it is out of scope)
>
> You enquired on IRC whether this patch series passes the igt CRC tests.
>
> # ./kms_pipe_crc_basic --run-subtest read-crc-pipe-A
> IGT-Version: 1.22-gf447f5fc531d (aarch64) (Linux:
> 4.17.0-rc1-00085-g56e849d93cc9 aarch64)
> read-crc-pipe-A: Testing connector LVDS-1 using pipe A
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> function igt_pipe_crc_start, file igt_debugfs.c:764:
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> pipe_crc->crc_fd != -1
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5, Input/output
> error
> Stack trace:
> Subtest read-crc-pipe-A failed.
> DEBUG
> (kms_pipe_crc_basic:1638) DEBUG: Test requirement passed: !(pipe >=
> data->display.n_pipes)
> (kms_pipe_crc_basic:1638) INFO: read-crc-pipe-A: Testing connector LVDS-1
> using pipe A
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: set_pipe(A)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: Selecting pipe A
> (kms_pipe_crc_basic:1638) DEBUG: Clearing the fb with color (0.00,1.00,0.00)
> (kms_pipe_crc_basic:1638) igt-fb-DEBUG:
> igt_create_fb_with_bo_size(width=1024, height=768, format=0x34325258,
> tiling=0x0, size=0)
> (kms_pipe_crc_basic:1638) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=1,
> pitch=4096)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: Test requirement passed: plane_idx
> >= 0 && plane_idx < pipe->n_planes
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_fb(140)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_size
> (1024x768)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: fb_set_position(0,0)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: fb_set_size(1024x768)
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: commit {
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: SetCrtc pipe A,
> fb 140, src (0, 0), mode 1024x768
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe A,
> disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A, plane
> 2, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A, plane
> 3, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A, plane
> 4, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe B,
> disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B, plane
> 1, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B, plane
> 2, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B, plane
> 3, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B, plane
> 4, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe C,
> disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C, plane
> 1, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C, plane
> 2, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C, plane
> 3, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C, plane
> 4, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D, plane
> 2, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D, plane
> 3, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D, plane
> 4, disabling
> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: }
> (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> '/sys/kernel/debug/dri/0'
> (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> '/sys/kernel/debug/dri/0'
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> function igt_pipe_crc_start, file igt_debugfs.c:764:
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> pipe_crc->crc_fd != -1
> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5, Input/output
> error
> (kms_pipe_crc_basic:1638) igt-core-INFO: Stack trace:
> END
> Subtest read-crc-pipe-A: FAIL (0.061s)
>
> I think the answer is no, but I don't think it's the fault of this patch
> series. Opening the CRC data file returns -EIO because the CRTC is not active,
> and I'm trying to find out why that is the case. The debug log shows a commit
> that seems strange to me, enabling pipe A and immediately disabling right
> afterwards. After some investigation I believe that this is caused by sharing
> primary planes between CRTCs.
>
> The R-Car DU groups CRTCs by two and shares 5 plane
[Bug 106199] Cannot get back into DM after logoff (Linux 4.16.2+)
https://bugs.freedesktop.org/show_bug.cgi?id=106199 --- Comment #10 from Harry Wentland --- A fix should land in 4.16 stable soon: https://www.spinics.net/lists/stable-commits/msg86375.html -- 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
[RFC PATCH 1/3] drm/panel: Support panel detection
Some panels might be connected through extension boards and might not
be available when the system boots. Extend the panel interface to
support panel detection.
An optional ->detect() hook is added and, if implemented, will be called
every time the panel user wants to know if the panel is connected or
disconnected.
We also add a ->polled field which should encode the type of polling the
DRM core should do (DRM_CONNECTOR_POLL_HPD, DRM_CONNECTOR_POLL_CONNECT
and DRM_CONNECTOR_POLL_DISCONNECT flags).
Signed-off-by: Boris Brezillon
---
include/drm/drm_panel.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 14ac240a1f64..718cc1f746ab 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -24,6 +24,7 @@
#ifndef __DRM_PANEL_H__
#define __DRM_PANEL_H__
+#include
#include
#include
@@ -68,6 +69,7 @@ struct display_timing;
* the panel. This is the job of the .unprepare() function.
*/
struct drm_panel_funcs {
+ int (*detect)(struct drm_panel *panel);
int (*disable)(struct drm_panel *panel);
int (*unprepare)(struct drm_panel *panel);
int (*prepare)(struct drm_panel *panel);
@@ -90,6 +92,7 @@ struct drm_panel {
struct drm_connector *connector;
struct device *dev;
+ u8 polled;
const struct drm_panel_funcs *funcs;
struct list_head list;
@@ -186,6 +189,15 @@ static inline int drm_panel_get_modes(struct drm_panel
*panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_detect(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->detect)
+ return panel->funcs->detect(panel);
+
+ /* Consider the panel as connected by default. */
+ return panel ? connector_status_connected : -EINVAL;
+}
+
void drm_panel_init(struct drm_panel *panel);
int drm_panel_add(struct drm_panel *panel);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
