[PULL] drm-misc-fixes
Hi Daniel, Dave, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2021-11-18: A infoframe corruption fix for nouveau, a wrong free function usage fix for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for drm/scheduler refcounting and a probing fix for efifb. The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-11-18 for you to fetch changes up to fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee: fbdev: Prevent probing generic drivers if a FB is already registered (2021-11-17 10:15:05 +0100) A infoframe corruption fix for nouveau, a wrong free function usage fix for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for drm/scheduler refcounting and a probing fix for efifb. Christian König (1): drm/scheduler: fix drm_sched_job_add_implicit_dependencies Hans Verkuil (1): drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrame Javier Martinez Canillas (1): fbdev: Prevent probing generic drivers if a FB is already registered Julian Braha (1): drm/sun4i: fix unmet dependency on RESET_CONTROLLER for PHY_SUN6I_MIPI_DPHY Maxime Ripard (1): Merge drm/drm-fixes into drm-misc-fixes Rob Clark (1): drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder Thomas Zimmermann (1): drm/cma-helper: Release non-coherent memory with dma_free_noncoherent() drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++-- drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c | 1 - drivers/gpu/drm/scheduler/sched_main.c | 6 +- drivers/gpu/drm/sun4i/Kconfig| 1 + drivers/video/fbdev/efifb.c | 11 +++ drivers/video/fbdev/simplefb.c | 11 +++ 6 files changed, 35 insertions(+), 4 deletions(-) signature.asc Description: PGP signature
[PATCH 07/12] dt-bindings: display: rockchip: Add binding for VOP2
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip-vop2.yaml | 114 ++
1 file changed, 114 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
new file mode 100644
index 0..d566c423f9d8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC display controller (VOP2)
+
+description:
+ VOP2 (Video Output Processor v2) is the display controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+enum:
+ - rockchip,rk3568-vop
+ - rockchip,rk3566-vop
+
+ reg:
+minItems: 1
+items:
+ - description:
+ Must contain one entry corresponding to the base address and length
+ of the register space.
+ - description:
+ Can optionally contain a second entry corresponding to
+ the CRTC gamma LUT address.
+
+ interrupts:
+maxItems: 1
+description:
+ The VOP interrupt is shared by several interrupt sources, such as
+ frame start (VSYNC), line flag and other status interrupts.
+
+ clocks:
+items:
+ - description: Clock for ddr buffer transfer.
+ - description: Clock for the ahb bus to R/W the phy regs.
+ - description: Pixel clock for video port 0.
+ - description: Pixel clock for video port 1.
+ - description: Pixel clock for video port 2.
+
+ clock-names:
+items:
+ - const: aclk_vop
+ - const: hclk_vop
+ - const: dclk_vp0
+ - const: dclk_vp1
+ - const: dclk_vp2
+
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+
+ assigned-clocks:
+maxItems: 2
+
+ assigned-clock-rates:
+maxItems: 2
+
+ iommus:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+vop: vop@fe04 {
+ compatible = "rockchip,rk3568-vop";
+ reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+ interrupts = ;
+ clocks = < ACLK_VOP>,
+ < HCLK_VOP>,
+ < DCLK_VOP0>,
+ < DCLK_VOP1>,
+ < DCLK_VOP2>;
+ clock-names = "aclk_vop",
+"hclk_vop",
+"dclk_vp0",
+"dclk_vp1",
+"dclk_vp2";
+ power-domains = < RK3568_PD_VO>;
+ iommus = <_mmu>;
+ vop_out: port {
+#address-cells = <1>;
+#size-cells = <0>;
+vp0_out_dsi0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vp0>;
+};
+vp0_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_in_vp0>;
+};
+ };
+};
--
2.30.2
[PATCH 09/12] arm64: dts: rockchip: rk356x: Add HDMI nodes
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 6ebf7c14e096a..53be61a7ce595 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -472,18 +472,36 @@ vp0: port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+
+ vp0_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vp0>;
+ status = "disabled";
+ };
};
vp1: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ vp1_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vp1>;
+ status = "disabled";
+ };
};
vp2: port@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
+
+ vp2_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_vp2>;
+ status = "disabled";
+ };
};
};
};
@@ -499,6 +517,53 @@ vop_mmu: iommu@fe043e00 {
status = "disabled";
};
+ hdmi: hdmi@fe0a {
+ compatible = "rockchip,rk3568-dw-hdmi";
+ reg = <0x0 0xfe0a 0x0 0x2>;
+ interrupts = ;
+ clocks = < PCLK_HDMI_HOST>,
+< CLK_HDMI_SFR>,
+< CLK_HDMI_CEC>,
+< HCLK_VOP>;
+ clock-names = "iahb", "isfr", "cec", "hclk";
+ power-domains = < RK3568_PD_VO>;
+ reg-io-width = <4>;
+ rockchip,grf = <>;
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_scl _sda _cec>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in_vp0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_hdmi>;
+ status = "disabled";
+ };
+
+ hdmi_in_vp1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_out_hdmi>;
+ status = "disabled";
+ };
+
+ hdmi_in_vp2: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <_out_hdmi>;
+ status = "disabled";
+ };
+ };
+ };
+ };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
--
2.30.2
Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
Hi Sascha Hauer, On 2021/11/17 下午10:33, Sascha Hauer wrote: This series adds initial graphics support for the Rockchip RK356[68] SoCs. Graphics support is based around the VOP2 controller which replaces the VOP controller found on earlier Rockchip SoCs. The driver has been tested with HDMI support included in this series and MIPI-DSI which is not included because it needs some more work. The driver is taken from the downstream Rockchip kernel Yes, you do know this is from Rockchip kernel. Could you point me out where is the information about original author in your commit? and heavily polished, most non standard features have been removed for now. I don't agree with this, we do believe you have do some clean up to meet the requirement of upstream, but all the framework and feature implement are from Rockchip engineer, we have made a great effort to make everything work which block us to upstream this driver for now. NAK for this series. - Kever
[PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 184e2aa2416af..156e001492173 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -106,6 +106,12 @@ _rgmii_clk
status = "okay";
};
+ {
+ status = "okay";
+ avdd-0v9-supply = <_image>;
+ avdd-1v8-supply = <_image>;
+};
+
{
status = "okay";
@@ -390,3 +396,21 @@ {
{
status = "okay";
};
+
+ {
+ status = "okay";
+ assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
+ assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
+};
+
+_mmu {
+ status = "okay";
+};
+
+_in_vp0 {
+ status = "okay";
+};
+
+_out_hdmi {
+ status = "okay";
+};
--
2.30.2
Re: [PATCH 12/12] drm: rockchip: Add VOP2 driver
On Wed, Nov 17, 2021 at 07:05:33PM +0100, Nicolas Frattaroli wrote: > On Mittwoch, 17. November 2021 15:33:47 CET Sascha Hauer wrote: > > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. > > It replaces the VOP unit found in the older Rockchip SoCs. > > > > This driver has been derived from the downstream Rockchip Kernel and > > heavily modified: > > > > - All nonstandard DRM properties have been removed > > - dropped struct vop2_plane_state and pass around less data between > > functions > > - Dropped all DRM_FORMAT_* not known on upstream > > - rework register access to get rid of excessively used macros > > > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > > board. Overlay support is tested with the modetest utility. AFBC support > > is still present in the driver, but currently untested due to the lack > > of suitable image sources. Also the driver has been tested with weston > > using pixman and (yet to be upstreamed) panfrost driver support. > > > > Signed-off-by: Sascha Hauer > > --- > > Hi Sascha, > > thank you very much for your work on this! I gave it a try tonight, > and unfortunately it appears to currently always attempt to use > 1920x1080p60 as the mode regardless of the monitor. For example, > on an old 720p monitor I had laying around: > > [ 225.732342] rockchip-drm display-subsystem: [drm] Update mode to > 1920x1080p60, type: 11 for vp0, output 0x0800 HDMI0 > > This results in a broken picture (all white with occasional glitches). > Somebody else observed the same behaviour on a 1440p monitor. Unfortunately all my monitors I have here have exactly 1920x1080p60, so I didn't notice. Anyway, when I try another mode like 1280x1024 which should be supported as well then my monitor responds with "out of range", so something is indeed fishy here. I'll have a look into it. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 05/12] of: graph: Allow disabled endpoints
There are cases in which a SoC allows many different routes between
components, but not all of them make sense for a board. With this patch
we allow standard status = "disabled" properties for ports. With this
a SoC level dtsi file can describe all possible ports and only the ones
that make sense for the given hardware are enabled at board level.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_of.c | 6 ++
drivers/of/property.c| 3 +++
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 37c34146eea83..c2fd9fe505767 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -67,10 +67,8 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
for_each_endpoint_of_node(port, ep) {
remote_port = of_graph_get_remote_port(ep);
- if (!remote_port) {
- of_node_put(ep);
- return 0;
- }
+ if (!remote_port)
+ continue;
possible_crtcs |= drm_of_crtc_port_mask(dev, remote_port);
diff --git a/drivers/of/property.c b/drivers/of/property.c
index a3483484a5a2a..40f8da7baa0a9 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -730,6 +730,9 @@ EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
*/
struct device_node *of_graph_get_remote_endpoint(const struct device_node
*node)
{
+ if (!of_device_is_available(node))
+ return NULL;
+
/* Get remote endpoint node. */
return of_parse_phandle(node, "remote-endpoint", 0);
}
--
2.30.2
[PATCH 01/12] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
From: Benjamin Gaignard Define a new compatible for rk3568 HDMI. This version of HDMI hardware block needs two new clocks hclk_vio and hclk to provide phy reference clocks. Signed-off-by: Benjamin Gaignard Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20210707120323.401785-2-benjamin.gaign...@collabora.com Signed-off-by: Sascha Hauer --- .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index da3b889ad8fcd..53fa42479d5b7 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -23,6 +23,7 @@ properties: - rockchip,rk3288-dw-hdmi - rockchip,rk3328-dw-hdmi - rockchip,rk3399-dw-hdmi + - rockchip,rk3568-dw-hdmi reg-io-width: const: 4 @@ -49,8 +50,11 @@ properties: - vpll - enum: - grf + - hclk_vio + - vpll + - enum: + - hclk - vpll - - const: vpll ddc-i2c-bus: $ref: /schemas/types.yaml#/definitions/phandle -- 2.30.2
Re: [PATCH 11/12] drm/rockchip: Make VOP driver optional
On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote: > Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer: > > With upcoming VOP2 support VOP won't be the only choice anymore, so make > > the VOP driver optional. > > > > Signed-off-by: Sascha Hauer > > --- > > arch/arm/configs/multi_v7_defconfig | 1 + > > arch/arm64/configs/defconfig| 1 + > > drivers/gpu/drm/rockchip/Kconfig| 7 +++ > > drivers/gpu/drm/rockchip/Makefile | 3 ++- > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- > > 5 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/configs/multi_v7_defconfig > > b/arch/arm/configs/multi_v7_defconfig > > index c951aeed2138c..fc123e8f3e2f9 100644 > > --- a/arch/arm/configs/multi_v7_defconfig > > +++ b/arch/arm/configs/multi_v7_defconfig > > @@ -667,6 +667,7 @@ CONFIG_DRM_EXYNOS_DPI=y > > CONFIG_DRM_EXYNOS_DSI=y > > CONFIG_DRM_EXYNOS_HDMI=y > > CONFIG_DRM_ROCKCHIP=m > > +CONFIG_ROCKCHIP_VOP=y > > CONFIG_ROCKCHIP_ANALOGIX_DP=y > > CONFIG_ROCKCHIP_DW_HDMI=y > > CONFIG_ROCKCHIP_DW_MIPI_DSI=y > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > index f2e2b9bdd7024..a623386473dc9 100644 > > --- a/arch/arm64/configs/defconfig > > +++ b/arch/arm64/configs/defconfig > > @@ -682,6 +682,7 @@ CONFIG_DRM_EXYNOS_DSI=y > > CONFIG_DRM_EXYNOS_HDMI=y > > CONFIG_DRM_EXYNOS_MIC=y > > CONFIG_DRM_ROCKCHIP=m > > +CONFIG_ROCKCHIP_VOP=y > > CONFIG_ROCKCHIP_ANALOGIX_DP=y > > CONFIG_ROCKCHIP_CDN_DP=y > > CONFIG_ROCKCHIP_DW_HDMI=y > > diff --git a/drivers/gpu/drm/rockchip/Kconfig > > b/drivers/gpu/drm/rockchip/Kconfig > > index 9f1ecefc39332..a1c4158259099 100644 > > --- a/drivers/gpu/drm/rockchip/Kconfig > > +++ b/drivers/gpu/drm/rockchip/Kconfig > > @@ -21,8 +21,15 @@ config DRM_ROCKCHIP > > > > if DRM_ROCKCHIP > > > > +config ROCKCHIP_VOP > > + bool "Rockchip VOP driver" > > would this benefit from a default-y ? > For builds reusing preexisting .configs. I enabled CONFIG_ROCKCHIP_VOP for all configs in the tree that enable CONFIG_DRM_ROCKCHIP, so defconfig users shouldn't see any surprises. That won't help users of custom configs of course. I don't know what's preferred in such cases, I can change to default-y if you like. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 04/12] drm/rockchip: dw_hdmi: add regulator support
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip,dw-hdmi.yaml| 6 ++
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 58 ++-
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 53fa42479d5b7..293b2cfbf739f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -28,6 +28,12 @@ properties:
reg-io-width:
const: 4
+ avdd-0v9-supply:
+description: A 0.9V supply that powers up the SoC internal circuitry.
+
+ avdd-1v8-supply:
+description: A 0.9V supply that powers up the SoC internal circuitry.
+
clocks:
minItems: 2
items:
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 29608c25e2d0e..b8fe56c89cdc9 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -83,6 +84,8 @@ struct rockchip_hdmi {
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+ struct regulator *avdd_0v9;
+ struct regulator *avdd_1v8;
struct phy *phy;
};
@@ -222,6 +225,22 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
hdmi->vpll_clk = hdmi->clks[RK_HDMI_CLK_VPLL].clk;
hdmi->grf_clk = hdmi->clks[RK_HDMI_CLK_GRF].clk;
+ hdmi->avdd_0v9 = devm_regulator_get_optional(hdmi->dev, "avdd-0v9");
+ if (IS_ERR(hdmi->avdd_0v9)) {
+ if (PTR_ERR(hdmi->avdd_0v9) != -ENODEV)
+ return PTR_ERR(hdmi->avdd_0v9);
+
+ hdmi->avdd_0v9 = NULL;
+ }
+
+ hdmi->avdd_1v8 = devm_regulator_get_optional(hdmi->dev, "avdd-1v8");
+ if (IS_ERR(hdmi->avdd_1v8)) {
+ if (PTR_ERR(hdmi->avdd_1v8) != -ENODEV)
+ return PTR_ERR(hdmi->avdd_1v8);
+
+ hdmi->avdd_1v8 = NULL;
+ }
+
return 0;
}
@@ -559,11 +578,27 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ if (hdmi->avdd_0v9) {
+ ret = regulator_enable(hdmi->avdd_0v9);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd0v9:
%d\n", ret);
+ goto err_avdd_0v9;
+ }
+ }
+
+ if (hdmi->avdd_1v8) {
+ ret = regulator_enable(hdmi->avdd_1v8);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd1v8:
%d\n", ret);
+ goto err_avdd_1v8;
+ }
+ }
+
ret = clk_bulk_prepare_enable(RK_HDMI_NCLOCKS_HDMI, hdmi->clks);
if (ret) {
DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
ret);
- return ret;
+ goto err_clk;
}
if (hdmi->chip_data == _chip_data) {
@@ -587,10 +622,21 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
*/
if (IS_ERR(hdmi->hdmi)) {
ret = PTR_ERR(hdmi->hdmi);
- drm_encoder_cleanup(encoder);
- clk_bulk_disable_unprepare(RK_HDMI_NCLOCKS_HDMI, hdmi->clks);
+ goto err_bind;
}
+ return 0;
+
+err_bind:
+ clk_bulk_disable_unprepare(RK_HDMI_NCLOCKS_HDMI, hdmi->clks);
+ drm_encoder_cleanup(encoder);
+err_clk:
+ if (hdmi->avdd_1v8)
+ regulator_disable(hdmi->avdd_1v8);
+err_avdd_1v8:
+ if (hdmi->avdd_0v9)
+ regulator_disable(hdmi->avdd_0v9);
+err_avdd_0v9:
return ret;
}
@@ -601,6 +647,12 @@ static void dw_hdmi_rockchip_unbind(struct device *dev,
struct device *master,
dw_hdmi_unbind(hdmi->hdmi);
clk_bulk_disable_unprepare(RK_HDMI_NCLOCKS_HDMI, hdmi->clks);
+
+ if (hdmi->avdd_1v8)
+ regulator_disable(hdmi->avdd_1v8);
+
+ if (hdmi->avdd_0v9)
+ regulator_disable(hdmi->avdd_0v9);
}
static const struct component_ops dw_hdmi_rockchip_ops = {
--
2.30.2
[PATCH 03/12] drm/rockchip: dw_hdmi: add rk3568 support
From: Benjamin Gaignard
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
This version of the HDMI hardware block needs a new clock to provide
the phy reference clock: hclk. As this is the third clock the driver
uses it is switched to devm_clk_bulk_get_optional() to simplify the
clock handling.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 74 +++--
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8677c82716784..29608c25e2d0e 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -50,6 +50,10 @@
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
+#define RK3568_GRF_VO_CON1 0x0364
+#define RK3568_HDMI_SDAIN_MSK BIT(15)
+#define RK3568_HDMI_SCLIN_MSK BIT(14)
+
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
/**
@@ -64,11 +68,18 @@ struct rockchip_hdmi_chip_data {
u32 lcdsel_lit;
};
+#define RK_HDMI_CLK_VPLL 0
+#define RK_HDMI_CLK_HCLK 1
+#define RK_HDMI_CLK_GRF2
+#define RK_HDMI_NCLOCKS3
+#define RK_HDMI_NCLOCKS_HDMI 2
+
struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
const struct rockchip_hdmi_chip_data *chip_data;
+ struct clk_bulk_data clks[RK_HDMI_NCLOCKS];
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
@@ -189,6 +200,7 @@ static const struct dw_hdmi_phy_config
rockchip_phy_config[] = {
static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
{
struct device_node *np = hdmi->dev->of_node;
+ int ret;
hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(hdmi->regmap)) {
@@ -196,25 +208,19 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
return PTR_ERR(hdmi->regmap);
}
- hdmi->vpll_clk = devm_clk_get(hdmi->dev, "vpll");
- if (PTR_ERR(hdmi->vpll_clk) == -ENOENT) {
- hdmi->vpll_clk = NULL;
- } else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
- return -EPROBE_DEFER;
- } else if (IS_ERR(hdmi->vpll_clk)) {
- DRM_DEV_ERROR(hdmi->dev, "failed to get vpll clock\n");
- return PTR_ERR(hdmi->vpll_clk);
- }
+ hdmi->clks[RK_HDMI_CLK_VPLL].id = "vpll";
+ hdmi->clks[RK_HDMI_CLK_HCLK].id = "hclk";
+ hdmi->clks[RK_HDMI_CLK_GRF].id = "grf";
+ ret = devm_clk_bulk_get_optional(hdmi->dev, RK_HDMI_NCLOCKS,
hdmi->clks);
+ printk("%s: %d 0x%08lx 0x%08lx 0x%08lx\n", __func__, ret,
+ (unsigned long)hdmi->clks[0].clk,
+ (unsigned long)hdmi->clks[1].clk,
+ (unsigned long)hdmi->clks[2].clk);
+ if (ret)
+ return ret;
- hdmi->grf_clk = devm_clk_get(hdmi->dev, "grf");
- if (PTR_ERR(hdmi->grf_clk) == -ENOENT) {
- hdmi->grf_clk = NULL;
- } else if (PTR_ERR(hdmi->grf_clk) == -EPROBE_DEFER) {
- return -EPROBE_DEFER;
- } else if (IS_ERR(hdmi->grf_clk)) {
- DRM_DEV_ERROR(hdmi->dev, "failed to get grf clock\n");
- return PTR_ERR(hdmi->grf_clk);
- }
+ hdmi->vpll_clk = hdmi->clks[RK_HDMI_CLK_VPLL].clk;
+ hdmi->grf_clk = hdmi->clks[RK_HDMI_CLK_GRF].clk;
return 0;
}
@@ -257,7 +263,7 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct
drm_encoder *encoder,
{
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
- clk_set_rate(hdmi->vpll_clk, adj_mode->clock * 1000);
+ clk_set_rate(hdmi->clks[RK_HDMI_CLK_VPLL].clk, adj_mode->clock * 1000);
}
static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
@@ -467,6 +473,19 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data
= {
.use_drm_infoframe = true,
};
+static struct rockchip_hdmi_chip_data rk3568_chip_data = {
+ .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
+ .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mpll_cfg = rockchip_mpll_cfg,
+ .cur_ctr= rockchip_cur_ctr,
+ .phy_config = rockchip_phy_config,
+ .phy_data = _chip_data,
+ .use_drm_infoframe = true,
+};
+
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3228-dw-hdmi",
.data = _hdmi_drv_data
@@ -480,6 +499,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[]
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
.data = _hdmi_drv_data
},
+ { .compatible = "rockchip,rk3568-dw-hdmi",
+ .data = _hdmi_drv_data
+ },
{},
};
[PATCH 08/12] arm64: dts: rockchip: rk356x: Add VOP2 nodes
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 46d9552f60284..6ebf7c14e096a 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -447,6 +447,58 @@ gmac1_mtl_tx_setup: tx-queues-config {
};
};
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <_out>;
+ };
+
+ vop: vop@fe04 {
+ compatible = "rockchip,rk3568-vop";
+ reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+ reg-names = "regs", "gamma_lut";
+ rockchip,grf = <>;
+ interrupts = ;
+ clocks = < ACLK_VOP>, < HCLK_VOP>, < DCLK_VOP0>,
< DCLK_VOP1>, < DCLK_VOP2>;
+ clock-names = "aclk_vop", "hclk_vop", "dclk_vp0", "dclk_vp1",
"dclk_vp2";
+ iommus = <_mmu>;
+ power-domains = < RK3568_PD_VO>;
+ status = "disabled";
+
+ vop_out: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vp0: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ vp1: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ vp2: port@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+ };
+ };
+
+ vop_mmu: iommu@fe043e00 {
+ compatible = "rockchip,rk3568-iommu";
+ reg = <0x0 0xfe043e00 0x0 0x100>, <0x0 0xfe043f00 0x0 0x100>;
+ interrupts = ;
+ interrupt-names = "vop_mmu";
+ clocks = < ACLK_VOP>, < HCLK_VOP>;
+ clock-names = "aclk", "iface";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
--
2.30.2
[PATCH 11/12] drm/rockchip: Make VOP driver optional
With upcoming VOP2 support VOP won't be the only choice anymore, so make the VOP driver optional. Signed-off-by: Sascha Hauer --- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig| 1 + drivers/gpu/drm/rockchip/Kconfig| 7 +++ drivers/gpu/drm/rockchip/Makefile | 3 ++- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- 5 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index c951aeed2138c..fc123e8f3e2f9 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -667,6 +667,7 @@ CONFIG_DRM_EXYNOS_DPI=y CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_ROCKCHIP=m +CONFIG_ROCKCHIP_VOP=y CONFIG_ROCKCHIP_ANALOGIX_DP=y CONFIG_ROCKCHIP_DW_HDMI=y CONFIG_ROCKCHIP_DW_MIPI_DSI=y diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index f2e2b9bdd7024..a623386473dc9 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -682,6 +682,7 @@ CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_EXYNOS_MIC=y CONFIG_DRM_ROCKCHIP=m +CONFIG_ROCKCHIP_VOP=y CONFIG_ROCKCHIP_ANALOGIX_DP=y CONFIG_ROCKCHIP_CDN_DP=y CONFIG_ROCKCHIP_DW_HDMI=y diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 9f1ecefc39332..a1c4158259099 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -21,8 +21,15 @@ config DRM_ROCKCHIP if DRM_ROCKCHIP +config ROCKCHIP_VOP + bool "Rockchip VOP driver" + help + This selects support for the VOP driver. You should enable it + on all older SoCs up to RK3399. + config ROCKCHIP_ANALOGIX_DP bool "Rockchip specific extensions for Analogix DP driver" + depends on ROCKCHIP_VOP help This selects support for Rockchip SoC specific extensions for the Analogix Core DP driver. If you want to enable DP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 17a9e7eb2130d..cd6e7bb5ce9c5 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -4,9 +4,10 @@ # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ - rockchip_drm_gem.o rockchip_drm_vop.o rockchip_vop_reg.o + rockchip_drm_gem.o rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o +rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o rockchip_vop_reg.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index e4ebe60b3cc1a..64fa5fd62c01a 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -473,7 +473,7 @@ static int __init rockchip_drm_init(void) int ret; num_rockchip_sub_drivers = 0; - ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP); + ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_ROCKCHIP_VOP); ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver, CONFIG_ROCKCHIP_LVDS); ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver, -- 2.30.2
Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
On Wed, Nov 17, 2021 at 08:54:37AM -0600, Rob Herring wrote:
> On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
> >
> > This series adds initial graphics support for the Rockchip RK356[68]
> > SoCs. Graphics support is based around the VOP2 controller which
> > replaces the VOP controller found on earlier Rockchip SoCs. The driver
> > has been tested with HDMI support included in this series and MIPI-DSI
> > which is not included because it needs some more work. The driver is
> > taken from the downstream Rockchip kernel and heavily polished, most non
> > standard features have been removed for now. I tested the driver with
> > the libdrm modetest utility and also with weston with both pixman and
> > panfrost driver support. Michael Riesch reported the driver to work on
> > the RK3566 as well, but device tree support for this SoC is not yet
> > included in this series.
>
> Can you outline what exactly you want to disable? I don't think
> 'status' is the right way. I think between the parent device being
> disabled, an incomplete graph and user configuration choice that
> should be enough to disable parts.
The VOP2 on the RK3568 has three CRTCS, or video ports (VP) in Rockchip
nomenclature. Each of them can be connected to the different outputs,
like HDMI, MIPI-DSI and so on. In the device tree the CRTCs are
described as of-graph ports with links to the HDMI, MIPI-DSI nodes.
An example limited to HDMI looks like this:
vop: vop@fe04 {
compatible = "rockchip,rk3568-vop";
vop_out: ports {
vp0: port@0 {
vp0_out_hdmi: endpoint@0 {
reg = <0>;
remote-endpoint = <_in_vp0>;
status = "disabled";
};
... MIPI, dP, ...
};
vp1: port@1 {
vp1_out_hdmi: endpoint@0 {
reg = <0>;
remote-endpoint = <_in_vp1>;
status = "disabled";
};
... MIPI, dP, ...
};
vp2: port@2 {
...
};
};
};
hdmi: hdmi@fe0a {
compatible = "rockchip,rk3568-dw-hdmi";
ports {
hdmi_in: port@0 {
hdmi_in_vp0: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_hdmi>;
status = "disabled";
};
hdmi_in_vp1: endpoint@1 {
reg = <1>;
remote-endpoint = <_out_hdmi>;
status = "disabled";
};
...
};
};
};
Theoretically every VP can be routed to every output, but depending on
the board there are some constraints. For example for the three vps
there are only two PLLs for the pixel clock, and the HDMI port is
hardwired to one single PLL. To avoid different VPs setting conflicting
rates on a PLL we can only allow a subset of the possible routes.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 02/12] drm/rockchip: dw_hdmi: Do not leave clock enabled in error case
The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 830bdd5e9b7ce..8677c82716784 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -529,13 +529,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
- ret = clk_prepare_enable(hdmi->vpll_clk);
- if (ret) {
- DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
- ret);
- return ret;
- }
-
hdmi->phy = devm_phy_optional_get(dev, "hdmi");
if (IS_ERR(hdmi->phy)) {
ret = PTR_ERR(hdmi->phy);
@@ -544,6 +537,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ ret = clk_prepare_enable(hdmi->vpll_clk);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
+ ret);
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, _hdmi_rockchip_encoder_helper_funcs);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
--
2.30.2
RE: [PATCH 00/15] iio: buffer-dma: write() and new DMABUF based API
> -Original Message- > From: Paul Cercueil > Sent: Mittwoch, 17. November 2021 13:50 > To: Daniel Vetter > Cc: Jonathan Cameron ; Hennerich, Michael > ; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Christian König > ; linaro-mm-...@lists.linaro.org; Alexandru > Ardelean ; linux-me...@vger.kernel.org > Subject: Re: [PATCH 00/15] iio: buffer-dma: write() and new DMABUF based > API > > [External] > > Hi Daniel, > > Le mar., nov. 16 2021 at 17:02:25 +0100, Daniel Vetter a > écrit : > > On Mon, Nov 15, 2021 at 02:57:37PM +, Paul Cercueil wrote: > >> Hi Daniel, > >> > >> Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter > >> a écrit : > >> > On Mon, Nov 15, 2021 at 02:19:10PM +, Paul Cercueil wrote: > >> > > Hi Jonathan, > >> > > > >> > > This patchset introduces a new userspace interface based on > >> DMABUF > > objects, to complement the existing fileio based API. > >> > > > >> > > The advantage of this DMABUF based interface vs. the fileio > > >> > interface, is that it avoids an extra copy of the data between the > >> > > kernel and userspace. This is particularly userful for > >> high-speed > > devices which produce several megabytes or even > >> gigabytes of data > > per > > second. > >> > > > >> > > The first few patches [01/15] to [03/15] are not really > >> related, but > > allow to reduce the size of the patches that > >> introduce the new API. > >> > > > >> > > Patch [04/15] to [06/15] enables write() support to the > >> buffer-dma > > implementation of the buffer API, to continue the > >> work done by > > Mihail Chindris. > >> > > > >> > > Patches [07/15] to [12/15] introduce the new DMABUF based API. > >> > > > >> > > Patches [13/15] and [14/15] add support for cyclic buffers, > >> only > > through > > the new API. A cyclic buffer will be repeated > >> on the output until > > the > > buffer is disabled. > >> > > > >> > > Patch [15/15] adds documentation about the new API. > >> > > > >> > > For now, the API allows you to alloc DMABUF objects and mmap() > >> them > > to > > read or write the samples. It does not yet allow > >> to import DMABUFs > > parented to other subsystems, but that should > >> eventually be possible > > once it's wired. > >> > > > >> > > This patchset is inspired by the "mmap interface" that was > > > >> previously > > submitted by Alexandru Ardelean and Lars-Peter > >> Clausen, so it would > > be > > great if I could get a review from > >> you guys. Alexandru's commit was > > signed with his @analog.com > >> address but he doesn't work at ADI > > anymore, > > so I believe > >> I'll need him to sign with a new email. > >> > > >> > Why dma-buf? dma-buf looks like something super generic and > >> useful, > until > you realize that there's a metric ton of > >> gpu/accelerator bagage piled > in. > >> > So unless buffer sharing with a gpu/video/accel/whatever device is > >> the > goal here, and it's just for a convenient way to get at buffer > >> handles, > this doesn't sound like a good idea. > >> > >> Good question. The first reason is that a somewhat similar API was > >> intented before[1], but refused upstream as it was kind of > >> re-inventing the wheel. > >> > >> The second reason, is that we want to be able to share buffers too, > >> not with gpu/video but with the network (zctap) and in the future > >> with USB > >> (functionFS) too. > >> > >> [1]: > >> https://urldefense.com/v3/__https://lore.kernel.org/linux-iio/2021021 > >> 7073638.21681-1- > alexandru.ardel...@analog.com/T/__;!!A3Ni8CS0y2Y!p67g > >> > KdXW2zXUxASbwbCKzXgcwxEo1R3h4AumAE6QHiSPyI3KYaz9TmGpnSIF3wsQ > c3gAgQ$ > > > > Hm is that code merged already in upstream already? > > No, it was never merged. > > > I know that dma-buf looks really generic, but like I said if there's > > no need ever to interface with any of the gpu buffer sharing it might > > be better to use something else (like get_user_pages maybe, would that > > work?). > > If it was such a bad idea, why didn't you say it in the first place when you > replied to my request for feedback? [1] > > I don't think we have any other solution. We can design a custom API to pass > buffers between IIO and user space, but that won't allow us to share these > buffers with other subsystems. If dma-buf is not a generic solution, then we > need a generic solution. I don't think we need another generic solution - dma-buf is the solution: >From https://www.kernel.org/doc/html/v5.15/driver-api/dma-buf.html: " The dma-buf subsystem provides the framework for sharing buffers for hardware (DMA) access across multiple device drivers and subsystems, and for synchronizing asynchronous hardware access." That's sounds pretty much like what we need. It lives under linux/drivers/dma-buf if it would be a video only shouldn't this be documented somewhere, and perhaps the code should be somewhere else?
[PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
This series adds initial graphics support for the Rockchip RK356[68] SoCs. Graphics support is based around the VOP2 controller which replaces the VOP controller found on earlier Rockchip SoCs. The driver has been tested with HDMI support included in this series and MIPI-DSI which is not included because it needs some more work. The driver is taken from the downstream Rockchip kernel and heavily polished, most non standard features have been removed for now. I tested the driver with the libdrm modetest utility and also with weston with both pixman and panfrost driver support. Michael Riesch reported the driver to work on the RK3566 as well, but device tree support for this SoC is not yet included in this series. The HDMI changes are based on patches from Benjamin Gaignard, but modified a bit as I found out that the HDMI port on the RK3568 only needs one additional clock, not two. Also I added regulator support which is needed to get the HDMI up on the rk3568-EVB board. All review and testing feedback welcome Sascha Benjamin Gaignard (2): dt-bindings: display: rockchip: Add compatible for rk3568 HDMI drm/rockchip: dw_hdmi: add rk3568 support Sascha Hauer (10): drm/rockchip: dw_hdmi: Do not leave clock enabled in error case drm/rockchip: dw_hdmi: add regulator support of: graph: Allow disabled endpoints dt-bindings: of: graph: Allow disabled endpoints dt-bindings: display: rockchip: Add binding for VOP2 arm64: dts: rockchip: rk356x: Add VOP2 nodes arm64: dts: rockchip: rk356x: Add HDMI nodes arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi drm/rockchip: Make VOP driver optional drm: rockchip: Add VOP2 driver .../display/rockchip/rockchip,dw-hdmi.yaml| 12 +- .../display/rockchip/rockchip-vop2.yaml | 114 + .../bindings/media/video-interfaces.yaml |8 + arch/arm/configs/multi_v7_defconfig |1 + .../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 117 + arch/arm64/configs/defconfig |1 + drivers/gpu/drm/drm_of.c |6 +- drivers/gpu/drm/rockchip/Kconfig | 13 + drivers/gpu/drm/rockchip/Makefile |4 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 137 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c |3 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 22 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 774 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3611 + drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 916 + drivers/of/property.c |3 + 17 files changed, 5731 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c -- 2.30.2
[PATCH 06/12] dt-bindings: of: graph: Allow disabled endpoints
There are cases in which a SoC allows many different routes between components, but not all of them make sense for a board. With this patch we allow standard status = "disabled" properties for ports. With this a SoC level dtsi file can describe all possible ports and only the ones that make sense for the given hardware are enabled at board level. Signed-off-by: Sascha Hauer --- .../devicetree/bindings/media/video-interfaces.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml index 4391dce2caee6..d7e516cd66f5f 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml @@ -84,6 +84,14 @@ properties: source) by the master device (data sink). In the master mode the data source device is also the source of the synchronization signals. + status: +enum: + - ok + - okay + - disabled +description: + Enables or disables the link. Disabled links are ignored. + bus-type: $ref: /schemas/types.yaml#/definitions/uint32 enum: -- 2.30.2
Re: [PATCH v1 1/9] mm: add zone device coherent type memory support
On Tuesday, 16 November 2021 6:30:18 AM AEDT Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should be allowed to pin such memory so that it can always be
> evicted.
>
> Signed-off-by: Alex Sierra
> ---
> include/linux/memremap.h | 8
> include/linux/mm.h | 9 +
> mm/memcontrol.c | 6 +++---
> mm/memory-failure.c | 6 +-
> mm/memremap.c| 5 -
> mm/migrate.c | 21 +
> 6 files changed, 42 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index c0e9d35889e8..ff4d398edf35 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -39,6 +39,13 @@ struct vmem_altmap {
> * A more complete discussion of unaddressable memory may be found in
> * include/linux/hmm.h and Documentation/vm/hmm.rst.
> *
> + * MEMORY_DEVICE_COHERENT:
> + * Device memory that is cache coherent from device and CPU point of view.
> This
> + * is used on platforms that have an advanced system bus (like CAPI or CXL).
> A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that
> memory
> + * type. Any page of a process can be migrated to such memory. However no one
> + * should be allowed to pin such memory so that it can always be evicted.
> + *
> * MEMORY_DEVICE_FS_DAX:
> * Host memory that has similar access semantics as System RAM i.e. DMA
> * coherent and supports page pinning. In support of coordinating page
> @@ -59,6 +66,7 @@ struct vmem_altmap {
> enum memory_type {
> /* 0 is reserved to catch uninitialized type fields */
> MEMORY_DEVICE_PRIVATE = 1,
> + MEMORY_DEVICE_COHERENT,
> MEMORY_DEVICE_FS_DAX,
> MEMORY_DEVICE_GENERIC,
> MEMORY_DEVICE_PCI_P2PDMA,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 73a52aba448f..d23b6ebd2177 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1162,6 +1162,7 @@ static inline bool page_is_devmap_managed(struct page
> *page)
> return false;
> switch (page->pgmap->type) {
> case MEMORY_DEVICE_PRIVATE:
> + case MEMORY_DEVICE_COHERENT:
> case MEMORY_DEVICE_FS_DAX:
> return true;
> default:
> @@ -1191,6 +1192,14 @@ static inline bool is_device_private_page(const struct
> page *page)
> page->pgmap->type == MEMORY_DEVICE_PRIVATE;
> }
>
> +static inline bool is_device_page(const struct page *page)
> +{
> + return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
> + is_zone_device_page(page) &&
> + (page->pgmap->type == MEMORY_DEVICE_PRIVATE ||
> + page->pgmap->type == MEMORY_DEVICE_COHERENT);
> +}
> +
> static inline bool is_pci_p2pdma_page(const struct page *page)
> {
> return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6da5020a8656..e0275ebe1198 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5695,8 +5695,8 @@ static int mem_cgroup_move_account(struct page *page,
> * 2(MC_TARGET_SWAP): if the swap entry corresponding to this pte is a
> * target for charge migration. if @target is not NULL, the entry is
> stored
> * in target->ent.
> - * 3(MC_TARGET_DEVICE): like MC_TARGET_PAGE but page is
> MEMORY_DEVICE_PRIVATE
> - * (so ZONE_DEVICE page and thus not on the lru).
> + * 3(MC_TARGET_DEVICE): like MC_TARGET_PAGE but page is
> MEMORY_DEVICE_COHERENT
> + * or MEMORY_DEVICE_PRIVATE (so ZONE_DEVICE page and thus not on the
> lru).
> * For now we such page is charge like a regular page would be as for all
> * intent and purposes it is just special memory taking the place of a
> * regular page.
> @@ -5730,7 +5730,7 @@ static enum mc_target_type get_mctgt_type(struct
> vm_area_struct *vma,
>*/
> if (page_memcg(page) == mc.from) {
> ret = MC_TARGET_PAGE;
> - if (is_device_private_page(page))
> + if (is_device_page(page))
> ret = MC_TARGET_DEVICE;
> if (target)
> target->page = page;
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 3e6449f2102a..51b55fc5172c 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1554,12 +1554,16 @@ static int memory_failure_dev_pagemap(unsigned long
> pfn, int flags,
> goto unlock;
> }
>
> - if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
> + switch (pgmap->type) {
> + case MEMORY_DEVICE_PRIVATE:
> + case MEMORY_DEVICE_COHERENT:
> /*
>* TODO: Handle HMM pages which may need coordination
>* with device-side memory.
>
Re: [PATCH v1 6/9] lib: test_hmm add module param for zone device type
On Tuesday, 16 November 2021 6:30:23 AM AEDT Alex Sierra wrote:
> In order to configure device coherent in test_hmm, two module parameters
> should be passed, which correspond to the SP start address of each
> device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
> private device type is configured.
Thanks for taking the time to add proper tests for this, as previously
mentioned I don't like the need for module parameters but understand why these
are more difficult to avoid.
However as also mentioned previously the restriction of being able to test only
private *or* coherent device pages is unnecessary and makes testing both types
harder, especially if we need to test migration between device private and
coherent pages.
> - res = request_free_mem_region(_resource, DEVMEM_CHUNK_SIZE,
> - "hmm_dmirror");
> - if (IS_ERR(res))
> - goto err_devmem;
> + if (!spm_addr_dev0 && !spm_addr_dev1) {
> + res = request_free_mem_region(_resource,
> DEVMEM_CHUNK_SIZE,
> + "hmm_dmirror");
> + if (IS_ERR_OR_NULL(res))
> + goto err_devmem;
> + devmem->pagemap.range.start = res->start;
> + devmem->pagemap.range.end = res->end;
> + devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
> + mdevice->zone_device_type = HMM_DMIRROR_MEMORY_DEVICE_PRIVATE;
> + } else if (spm_addr_dev0 && spm_addr_dev1) {
> + devmem->pagemap.range.start = MINOR(mdevice->cdevice.dev) ?
> + spm_addr_dev0 :
> + spm_addr_dev1;
It seems like it would be fairly straight forward to address this concern by
adding extra minor character devices for the coherent devices. Would it be
possible for you to try that?
> + devmem->pagemap.range.end = devmem->pagemap.range.start +
> + DEVMEM_CHUNK_SIZE - 1;
> + devmem->pagemap.type = MEMORY_DEVICE_COHERENT;
> + mdevice->zone_device_type = HMM_DMIRROR_MEMORY_DEVICE_COHERENT;
> + } else {
> + pr_err("Both spm_addr_dev parameters should be set\n");
> + }
>
> - mdevice->zone_device_type = HMM_DMIRROR_MEMORY_DEVICE_PRIVATE;
> - devmem->pagemap.type = MEMORY_DEVICE_PRIVATE;
> - devmem->pagemap.range.start = res->start;
> - devmem->pagemap.range.end = res->end;
> devmem->pagemap.nr_range = 1;
> devmem->pagemap.ops = _devmem_ops;
> devmem->pagemap.owner = mdevice;
> @@ -495,10 +517,14 @@ static bool dmirror_allocate_chunk(struct
> dmirror_device *mdevice,
> mdevice->devmem_capacity = new_capacity;
> mdevice->devmem_chunks = new_chunks;
> }
> -
> ptr = memremap_pages(>pagemap, numa_node_id());
> - if (IS_ERR(ptr))
> + if (IS_ERR_OR_NULL(ptr)) {
> + if (ptr)
> + ret = PTR_ERR(ptr);
> + else
> + ret = -EFAULT;
> goto err_release;
> + }
>
> devmem->mdevice = mdevice;
> pfn_first = devmem->pagemap.range.start >> PAGE_SHIFT;
> @@ -531,7 +557,8 @@ static bool dmirror_allocate_chunk(struct dmirror_device
> *mdevice,
>
> err_release:
> mutex_unlock(>devmem_lock);
> - release_mem_region(devmem->pagemap.range.start,
> range_len(>pagemap.range));
> + if (res)
> + release_mem_region(devmem->pagemap.range.start,
> range_len(>pagemap.range));
> err_devmem:
> kfree(devmem);
>
> @@ -1219,10 +1246,8 @@ static int dmirror_device_init(struct dmirror_device
> *mdevice, int id)
> if (ret)
> return ret;
>
> - /* Build a list of free ZONE_DEVICE private struct pages */
> - dmirror_allocate_chunk(mdevice, NULL);
> -
> - return 0;
> + /* Build a list of free ZONE_DEVICE struct pages */
> + return dmirror_allocate_chunk(mdevice, NULL);
> }
>
> static void dmirror_device_remove(struct dmirror_device *mdevice)
> @@ -1235,8 +1260,9 @@ static void dmirror_device_remove(struct dmirror_device
> *mdevice)
> mdevice->devmem_chunks[i];
>
> memunmap_pages(>pagemap);
> - release_mem_region(devmem->pagemap.range.start,
> -range_len(>pagemap.range));
> + if (devmem->pagemap.type == MEMORY_DEVICE_PRIVATE)
> + release_mem_region(devmem->pagemap.range.start,
> +
> range_len(>pagemap.range));
> kfree(devmem);
> }
> kfree(mdevice->devmem_chunks);
> diff --git a/lib/test_hmm_uapi.h b/lib/test_hmm_uapi.h
> index c42e57a6a71e..77f81e6314eb 100644
> --- a/lib/test_hmm_uapi.h
> +++ b/lib/test_hmm_uapi.h
> @@ -67,6 +67,7 @@ enum {
>
Re: [PATCH v3 5/6] drm/i915/ttm: Implement asynchronous TTM moves
Hi, Matthew
Finally got some time to look at this more in-depth, please see below.
On Mon, 2021-11-15 at 17:16 +, Matthew Auld wrote:
> On 14/11/2021 11:12, Thomas Hellström wrote:
> > Don't wait sync while migrating, but rather make the GPU blit await
> > the
> > dependencies and add a moving fence to the object.
> >
> > This also enables asynchronous VRAM management in that on eviction,
> > rather than waiting for the moving fence to expire before freeing
> > VRAM,
> > it is freed immediately and the fence is stored with the VRAM
> > manager and
> > handed out to newly allocated objects to await before clears and
> > swapins,
> > or for kernel objects before setting up gpu vmas or mapping.
> >
> > To collect dependencies before migrating, add a set of utilities
> > that
> > coalesce these to a single dma_fence.
> >
> > What is still missing for fully asynchronous operation is
> > asynchronous vma
> > unbinding, which is still to be implemented.
> >
> > This commit substantially reduces execution time in the
> > gem_lmem_swapping
> > test.
> >
> > v2:
> > - Make a couple of functions static.
> >
> > Signed-off-by: Thomas Hellström
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 10 +
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 2 +-
> > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 329
> > +--
> > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +-
> > 4 files changed, 318 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index a1df49378a0f..111a4282d779 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -326,6 +326,9 @@ static bool i915_ttm_eviction_valuable(struct
> > ttm_buffer_object *bo,
> > {
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> >
> > + if (!obj)
> > + return false;
> > +
> > /*
> > * EXTERNAL objects should never be swapped out by TTM,
> > instead we need
> > * to handle that ourselves. TTM will already skip such
> > objects for us,
> > @@ -448,6 +451,10 @@ static int
> > i915_ttm_shrinker_release_pages(struct drm_i915_gem_object *obj,
> > if (bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED)
> > return 0;
> >
> > + ret = ttm_bo_wait_ctx(bo, );
> > + if (ret)
> > + return ret;
>
>
> Why do we need this? Also not needed for the above purge case?
This is for bos with an on-going async move to system. The
intel_migrate code doesn't set up vmas, so unbinding doesn't
necessarily idle. The purge code currently idles in TTM, but in both
cases we should probably add another argument to
shrinker_release_pages() and move this wait before purge to return -
EBUSY unless we have SHRINK_ACTIVE.
>
> > +
> > bo->ttm->page_flags |= TTM_TT_FLAG_SWAPPED;
> > ret = ttm_bo_validate(bo, , );
> > if (ret) {
> > @@ -549,6 +556,9 @@ static void i915_ttm_swap_notify(struct
> > ttm_buffer_object *bo)
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > int ret = i915_ttm_move_notify(bo);
> >
> > + if (!obj)
> > + return;
>
> It looks like the i915_ttm_move_notify(bo) already dereferenced the
> GEM
> bo. Or did something in there maybe nuke it?
>
> > +
> > GEM_WARN_ON(ret);
> > GEM_WARN_ON(obj->ttm.cached_io_rsgt);
> > if (!ret && obj->mm.madv != I915_MADV_WILLNEED)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > index 82cdabb542be..9d698ad00853 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
> > @@ -37,7 +37,7 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object
> > *bo);
> > static inline struct drm_i915_gem_object *
> > i915_ttm_to_gem(struct ttm_buffer_object *bo)
> > {
> > - if (GEM_WARN_ON(bo->destroy != i915_ttm_bo_destroy))
> > + if (bo->destroy != i915_ttm_bo_destroy)
> > return NULL;
>
> So this would indicate a "ghost" object, or is this something else?
> How
> scared should we be with this, like with the above checking for NULL
> GEM
> object state? In general do you know where we need the above
> checking?
Yeah, these are ghost objects and this is a major flaw in TTM in that
some callbacks are per device and not per object. Should have been
fixed long ago :/. For the ttm_tt callbacks, obj might be NULL but we
must still be able to cope with that. For other callbacks we should
ignore the ghost objects. I'll do a second audit here.
>
> >
> > return container_of(bo, struct drm_i915_gem_object,
> > __do_not_access);
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> > index f35b386c56ca..ae2c49fc3500 100644
> > ---
Re: [PATCH] drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder
Am 18.11.21 um 04:09 schrieb Rob Clark: On Wed, Nov 17, 2021 at 5:23 PM Steev Klimaszewski wrote: On 11/17/21 1:27 AM, Christian König wrote: Am 16.11.21 um 19:30 schrieb Amit Pundir: On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote: From: Rob Clark drm_sched_job_add_dependency() could drop the last ref, so we need to do the dma_fence_get() first. It fixed the splats I saw on RB5 (sm8250 | A650). Thanks. Tested-by: Amit Pundir I've added my rb, pushed this with the original fix to drm-misc-fixes and cleaned up the obvious fallout between drm-misc-fixes and drm-misc-next in drm-tip. Thanks for the help and sorry for the noise, Christian. I've run into this splat on the Lenovo Yoga C630 on 5.16-rc1 - are these 2 patches (which fix it) going to be heading to 5.16 or were they targeted at 5.17? these should be for v5.16 Yeah, they are already queued up for -rc2. Regards, Christian. BR, -R
Re: [PATCH v2 1/6] drm/i915: move the pre_pin earlier
On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote: > > On 11/17/21 15:20, Matthew Auld wrote: > > In intel_context_do_pin_ww, when calling into the pre_pin > > hook(which is > > passed the ww context) it could in theory return -EDEADLK(which is > > very > > likely with debug kernels), once we start adding more ww locking in > > there, > > like in the next patch. If so then we need to be mindful of having > > to > > restart the do_pin at this point. > > > > If this is the kernel_context, or some other early in-kernel > > context > > where we have yet to setup the default_state, then we always > > inhibit the > > context restore, and instead rely on the delayed active_release to > > set > > the CONTEXT_VALID_BIT for us(if we even care), which should > > indicate > > that we have context switched away, and that our newly saved > > context > > state should now be valid. However, since we currently grab the > > active > > reference before the potential ww dance, we can end up setting the > > CONTEXT_VALID_BIT much too early, if we need to backoff, and then > > upon > > re-trying the do_pin, we could potentially cause the hardware to > > incorrectly load some garbage context state when later context > > switching > > to that context, but at the very least this will trigger the > > GEM_BUG_ON() in __engine_unpark. For now let's just move any ww > > dance > > stuff prior to arming the active reference. > > > > For normal user contexts this shouldn't be a concern, since we > > should > > already have the default_state ready when initialising the lrc > > state, > > and so there should be no concern with active_release somehow > > prematurely setting the CONTEXT_VALID_BIT. > > > > v2(Thomas): > > - Also re-order the union unwind Oh should this be s/union/onion/ ? > > > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > Cc: Maarten Lankhorst > > Reviewed-by: Thomas Hellström > > > > --- > > drivers/gpu/drm/i915/gt/intel_context.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c > > b/drivers/gpu/drm/i915/gt/intel_context.c > > index 5634d14052bc..4c296de1d67d 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_context.c > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c > > @@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct > > intel_context *ce, > > if (err) > > return err; > > > > - err = i915_active_acquire(>active); > > + err = ce->ops->pre_pin(ce, ww, ); > > if (err) > > goto err_ctx_unpin; > > > > - err = ce->ops->pre_pin(ce, ww, ); > > + err = i915_active_acquire(>active); > > if (err) > > - goto err_release; > > + goto err_post_unpin; > > > > err = mutex_lock_interruptible(>pin_mutex); > > if (err) > > - goto err_post_unpin; > > + goto err_release; > > > > intel_engine_pm_might_get(ce->engine); > > > > @@ -273,11 +273,11 @@ int __intel_context_do_pin_ww(struct > > intel_context *ce, > > > > err_unlock: > > mutex_unlock(>pin_mutex); > > +err_release: > > + i915_active_release(>active); > > err_post_unpin: > > if (!handoff) > > ce->ops->post_unpin(ce); > > -err_release: > > - i915_active_release(>active); > > err_ctx_unpin: > > intel_context_post_unpin(ce); > >
Re: [PATCH v1 2/9] mm: add device coherent vma selection for memory migration
On Tuesday, 16 November 2021 6:30:19 AM AEDT Alex Sierra wrote:
> This case is used to migrate pages from device memory, back to system
> memory. Device coherent type memory is cache coherent from device and CPU
> point of view.
>
> Signed-off-by: Alex Sierra
> ---
> v2:
> condition added when migrations from device coherent pages.
> ---
> include/linux/migrate.h | 1 +
> mm/migrate.c| 9 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index c8077e936691..e74bb0978f6f 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -138,6 +138,7 @@ static inline unsigned long migrate_pfn(unsigned long pfn)
> enum migrate_vma_direction {
> MIGRATE_VMA_SELECT_SYSTEM = 1 << 0,
> MIGRATE_VMA_SELECT_DEVICE_PRIVATE = 1 << 1,
> + MIGRATE_VMA_SELECT_DEVICE_COHERENT = 1 << 2,
> };
>
> struct migrate_vma {
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f74422a42192..166bfec7d85e 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2340,8 +2340,6 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> if (is_writable_device_private_entry(entry))
> mpfn |= MIGRATE_PFN_WRITE;
> } else {
> - if (!(migrate->flags & MIGRATE_VMA_SELECT_SYSTEM))
> - goto next;
> pfn = pte_pfn(pte);
> if (is_zero_pfn(pfn)) {
> mpfn = MIGRATE_PFN_MIGRATE;
> @@ -2349,6 +2347,13 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> goto next;
> }
> page = vm_normal_page(migrate->vma, addr, pte);
> + if (!is_zone_device_page(page) &&
> + !(migrate->flags & MIGRATE_VMA_SELECT_SYSTEM))
> + goto next;
> + if (is_zone_device_page(page) &&
> + (!(migrate->flags &
> MIGRATE_VMA_SELECT_DEVICE_COHERENT) ||
> + page->pgmap->owner != migrate->pgmap_owner))
> + goto next;
Thanks Alex, couple of comments on this:
1. vm_normal_page() can return NULL so you need to add a check for
page == NULL otherwise the call to is_zone_device_page(NULL) will crash.
2. The check for a coherent device page is too indirect. Being explicit and
using is_zone_device_coherent_page() instead would make it more direct and
obvious, particularly for developers who may not immediately realise that
device-private pages should never have pte_present() entries.
> mpfn = migrate_pfn(pfn) | MIGRATE_PFN_MIGRATE;
> mpfn |= pte_write(pte) ? MIGRATE_PFN_WRITE : 0;
> }
>
[Bug 214991] VC4 DRM waiting for flip down makes UI freeze a while with kernel 5.15
https://bugzilla.kernel.org/show_bug.cgi?id=214991 --- Comment #2 from Jian-Hong Pan (j...@endlessos.org) --- Created attachment 299625 --> https://bugzilla.kernel.org/attachment.cgi?id=299625=edit Full dmesg log with the v2 patch series "drm/vc4: kms: Misc fixes for HVS commits" Maxime sent v2 patch series at https://www.spinics.net/lists/dri-devel/msg323342.html System can boot into desktop environment now. However, the UI still become frozen some times and shows the same error message: [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:68:crtc-3] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:68:crtc-3] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道： > > Hi, > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to > atomic helpers") introduced a number of issues in corner cases, most of them > showing themselves in the form of either a vblank timeout or use-after-free > error. > > These patches should fix most of them, some of them still being debugged. > > Maxime > > Changes from v1: > - Prevent a null pointer dereference > > Maxime Ripard (6): > drm/vc4: kms: Wait for the commit before increasing our clock rate > drm/vc4: kms: Fix return code check > drm/vc4: kms: Add missing drm_crtc_commit_put > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > drm/vc4: kms: Don't duplicate pending commit > drm/vc4: kms: Fix previous HVS commit wait > > drivers/gpu/drm/vc4/vc4_kms.c | 42 --- > 1 file changed, 19 insertions(+), 23 deletions(-) I tested the v2 patches based on latest mainline kernel with RPi 4B. System can boot up into desktop environment. Although it still hit the bug [1], which might be under debugging, I think these patches LGTM. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214991 Tested-by: Jian-Hong Pan
[PATCH v3] drm/bridge: anx7625: Check GPIO description to avoid crash
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Acked-by: Tzung-Bi Shih
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 001fb39d9919..652ae814246d 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1098,9 +1098,18 @@ static void anx7625_init_gpio(struct anx7625_data
*platform)
/* Gpio for chip power enable */
platform->pdata.gpio_p_on =
devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR_OR_NULL(platform->pdata.gpio_p_on)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no enable gpio found\n");
+ platform->pdata.gpio_p_on = NULL;
+ }
+
/* Gpio for chip reset */
platform->pdata.gpio_reset =
devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR_OR_NULL(platform->pdata.gpio_reset)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no reset gpio found\n");
+ platform->pdata.gpio_reset = NULL;
+ }
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
--
2.25.1
[PATCH v2] drm/bridge: anx7625: Check GPIO description to avoid crash
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Acked-by: Tzung-Bi Shih
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 001fb39d9919..a872cfaf6257 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1098,9 +1098,18 @@ static void anx7625_init_gpio(struct anx7625_data
*platform)
/* Gpio for chip power enable */
platform->pdata.gpio_p_on =
devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR_OR_NULL(platform->pdata.gpio_p_on)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no enable gpio found\n");
+ platform->pdata.gpio_p_on = NULL;
+ }
+
/* Gpio for chip reset */
platform->pdata.gpio_reset =
devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR_OR_NULL(platform->pdata.gpio_reset)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no reset gpio found\n");
+ platform->pdata.gpio_p_on = NULL;
+ }
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
--
2.25.1
Re: [PATCH] drm/bridge: anx7625: Check GPIO description to avoid crash
On Thu, Nov 18, 2021 at 12:52:14PM +0800, Tzung-Bi Shih wrote:
> On Thu, Nov 18, 2021 at 11:11 AM Xin Ji wrote:
> > @@ -1098,9 +1098,18 @@ static void anx7625_init_gpio(struct anx7625_data
> > *platform)
> > /* Gpio for chip power enable */
> > platform->pdata.gpio_p_on =
> > devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
> > + if (IS_ERR(platform->pdata.gpio_p_on)) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "no enable gpio found\n");
> > + platform->pdata.gpio_p_on = NULL;
> > + }
> > +
> > /* Gpio for chip reset */
> > platform->pdata.gpio_reset =
> > devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> > + if (IS_ERR(platform->pdata.gpio_reset)) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "no reset gpio found\n");
> > + platform->pdata.gpio_p_on = NULL;
> > + }
> >
> > if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
> > platform->pdata.low_power_mode = 1;
>
> devm_gpiod_get_optional() is possible to return NULL (see
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.15.2%2Fsource%2Fdrivers%2Fgpio%2Fgpiolib-devres.c%23L250data=04%7C01%7Cxji%40analogixsemi.com%7C40e84a44676149c2544a08d9aa4f37f0%7Cb099b0b4f26c4cf59a0fd5be9acab205%7C0%7C0%7C637728079481953910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2UPuAadtM%2FObwkwE6fLhJr7uCfWN%2Fr29o4t8uqUU2Ls%3Dreserved=0).
> Thus, we should use IS_ERR_OR_NULL for checking the return value.
Hi Tzung-Bi Shih, IS_ERR_OR_NULL is better, I'll use it.
Thanks,
Xin
>
> The cases here would work fine except it will skip to print some
> informative messages.
>
> Acked-by: Tzung-Bi Shih
[pull] amdgpu, amdkfd drm-fixes-5.16
Hi Dave, Daniel, Fixes for 5.16. The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.16-2021-11-17 for you to fetch changes up to 27dfaedc0d321b4ea4e10c53e4679d6911ab17aa: drm/amd/amdgpu: fix potential memleak (2021-11-17 23:04:57 -0500) amd-drm-fixes-5.16-2021-11-17: amdgpu: - Better debugging info for SMU msgs - Better error reporting when adding IP blocks - Fix UVD powergating regression on CZ - Clock reporting fix for navi1x - OLED panel backlight fix - Fix scaling on VGA/DVI for non-DC display code - Fix GLFCLK handling for RGP on some APUs - fix potential memory leak amdkfd: - GPU reset fix Bernard Zhao (1): drm/amd/amdgpu: fix potential memleak Evan Quan (1): drm/amd/pm: avoid duplicate powergate/ungate setting Guchun Chen (1): drm/amdgpu: add error print when failing to add IP block(v2) Lijo Lazar (1): drm/amd/pm: Remove artificial freq level on Navi1x Luben Tuikov (1): drm/amd/pm: Enhanced reporting also for a stuck command Perry Yuan (1): drm/amd/pm: add GFXCLK/SCLK clocks level print support for APUs Roman Li (1): drm/amd/display: Fix OLED brightness control on eDP hongao (1): drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga and dvi connectors shaoyunl (1): drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 36 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 + .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +- drivers/gpu/drm/amd/include/amd_shared.h | 3 +- drivers/gpu/drm/amd/pm/amdgpu_dpm.c| 10 ++ drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h| 8 + .../drm/amd/pm/swsmu/smu11/cyan_skillfish_ppt.c| 22 +++-- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 13 +--- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 26 .../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 27 .../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.h | 1 + drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 8 +++-- 15 files changed, 156 insertions(+), 11 deletions(-)
[PATCH 2/2] drm/amdkfd: Implement DMA buf fd export for RDMA
Exports a DMA buf fd of a given KFD buffer handle. This is intended for
the new upstreamable RDMA solution coming to UCX and libfabric.
The corresponding user mode change (Thunk API and kfdtest) is here:
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commits/fxkamd/dmabuf
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 45 +++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 55 +++
include/uapi/linux/kfd_ioctl.h| 14 -
4 files changed, 104 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index fcbc8a9c9e06..840de82460a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -294,6 +294,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device
*adev,
uint64_t va, void *drm_priv,
struct kgd_mem **mem, uint64_t *size,
uint64_t *mmap_offset);
+int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
+ struct dma_buf **dmabuf);
int amdgpu_amdkfd_get_tile_config(struct amdgpu_device *adev,
struct tile_config *config);
void amdgpu_amdkfd_ras_poison_consumption_handler(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d53d19b9d6dc..9f57e5091fa8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -641,6 +641,21 @@ kfd_mem_attach_userptr(struct amdgpu_device *adev, struct
kgd_mem *mem,
return 0;
}
+static int kfd_mem_export_dmabuf(struct kgd_mem *mem)
+{
+ if (!mem->dmabuf) {
+ struct dma_buf *ret = amdgpu_gem_prime_export(
+ >bo->tbo.base,
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DRM_RDWR : 0);
+ if (IS_ERR(ret))
+ return PTR_ERR(ret);
+ mem->dmabuf = ret;
+ }
+
+ return 0;
+}
+
static int
kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct kgd_mem *mem,
struct amdgpu_bo **bo)
@@ -648,16 +663,9 @@ kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct
kgd_mem *mem,
struct drm_gem_object *gobj;
int ret;
- if (!mem->dmabuf) {
- mem->dmabuf = amdgpu_gem_prime_export(>bo->tbo.base,
- mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
- DRM_RDWR : 0);
- if (IS_ERR(mem->dmabuf)) {
- ret = PTR_ERR(mem->dmabuf);
- mem->dmabuf = NULL;
- return ret;
- }
- }
+ ret = kfd_mem_export_dmabuf(mem);
+ if (ret)
+ return ret;
gobj = amdgpu_gem_prime_import(adev_to_drm(adev), mem->dmabuf);
if (IS_ERR(gobj))
@@ -2065,6 +2073,23 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
return ret;
}
+int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
+ struct dma_buf **dma_buf)
+{
+ int ret;
+
+ mutex_lock(>lock);
+ ret = kfd_mem_export_dmabuf(mem);
+ if (ret)
+ goto out;
+
+ get_dma_buf(mem->dmabuf);
+ *dma_buf = mem->dmabuf;
+out:
+ mutex_unlock(>lock);
+ return ret;
+}
+
/* Evict a userptr BO by stopping the queues if necessary
*
* Runs in MMU notifier, may be in RECLAIM_FS context. This means it
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 4bfc0c8ab764..ddbc28951ac1 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1787,6 +1787,58 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
return r;
}
+static int kfd_ioctl_export_dmabuf(struct file *filep,
+ struct kfd_process *p, void *data)
+{
+ struct kfd_ioctl_export_dmabuf_args *args = data;
+ struct kfd_process_device *pdd;
+ struct dma_buf *dmabuf;
+ struct kfd_dev *dev;
+ void *mem;
+ int ret = 0;
+
+ dev = kfd_device_by_id(GET_GPU_ID(args->handle));
+ if (!dev)
+ return -EINVAL;
+
+ mutex_lock(>mutex);
+
+ pdd = kfd_get_process_device_data(dev, p);
+ if (!pdd) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
+ mem = kfd_process_device_translate_handle(pdd,
+ GET_IDR_HANDLE(args->handle));
+ if (!mem) {
+ ret = -EINVAL;
+
[PATCH 1/2] drm/amdgpu: Generalize KFD dmabuf import
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 45 ---
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 90b985436878..d53d19b9d6dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2000,30 +2000,34 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
struct amdgpu_bo *bo;
int ret;
- if (dma_buf->ops != _dmabuf_ops)
- /* Can't handle non-graphics buffers */
- return -EINVAL;
-
- obj = dma_buf->priv;
- if (drm_to_adev(obj->dev) != adev)
- /* Can't handle buffers from other devices */
- return -EINVAL;
+ obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+ if (obj->import_attach) {
+ /* Import takes an extra reference if it creates a dynamic
+* dmabuf attachment. Release that reference to avoid
+* leaking it. FIXME: I think this is a bug.
+*/
+ dma_buf_put(dma_buf);
+ }
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
- AMDGPU_GEM_DOMAIN_GTT)))
+ AMDGPU_GEM_DOMAIN_GTT))) {
/* Only VRAM and GTT BOs are supported */
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_obj;
+ }
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
- if (!*mem)
- return -ENOMEM;
+ if (!*mem) {
+ ret = -ENOMEM;
+ goto err_put_obj;
+ }
ret = drm_vma_node_allow(>vma_node, drm_priv);
- if (ret) {
- kfree(mem);
- return ret;
- }
+ if (ret)
+ goto err_free_mem;
if (size)
*size = amdgpu_bo_size(bo);
@@ -2040,7 +2044,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
| KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
| KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
- drm_gem_object_get(>tbo.base);
+ get_dma_buf(dma_buf);
+ (*mem)->dmabuf = dma_buf;
(*mem)->bo = bo;
(*mem)->va = va;
(*mem)->domain = (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2052,6 +2057,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
(*mem)->is_imported = true;
return 0;
+
+err_free_mem:
+ kfree(mem);
+err_put_obj:
+ drm_gem_object_put(obj);
+ return ret;
}
/* Evict a userptr BO by stopping the queues if necessary
--
2.32.0
Re: [PATCH] drm: change logs to print connectors in the form CONNECTOR:id:name
On Mon, Nov 15, 2021 at 12:40 PM Claudio Suarez wrote: > > On Mon, Nov 15, 2021 at 12:24:26PM +0200, Jani Nikula wrote: > > On Sun, 14 Nov 2021, Claudio Suarez wrote: > > > On Sat, Nov 13, 2021 at 09:39:46PM +0100, Sam Ravnborg wrote: > > >> Hi Claudio, > > >> > > >> On Sat, Nov 13, 2021 at 08:27:30PM +0100, Claudio Suarez wrote: > > >> > The prefered way to log connectors is [CONNECTOR:id:name]. Change it in > > >> > drm core programs. > > >> > > > >> > Suggested-by: Ville Syrjälä > > >> > Signed-off-by: Claudio Suarez > > >> > > >> While touching all these logging calls, could you convernt them to the > > >> newer drm_dbg_kms variants? > > >> DRM_DEBUG_* are all deprecated. > > >> > > > > > > Yes, I can, but it is recommended to do it in a different patch: > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes > > > > > > C: > > > "Separate your changes > > > Separate each logical change into a separate patch. > > > For example, if your changes include both bug fixes and performance > > > enhancements..." > > > > > > > > > I will study and send a new separate patch with your suggestion. > > > > I feel these logging changes are the types of changes where I'd err on > > the side of fewer patches than strictly following the above guidelines. > > To size the problem: > - there are about 3434 references to DRM_DEBUG_* in all the drm code, all > drivers. > - there are 413 references to DRM_DEBUG_* in the drm core code, only 66 of >them are related to connectors. > - there are 62 references to DRM_ERR* and 7 references to DRM_INFO in >the drm core programs. > > I meant I can make two patches: > 1 - this one with the change to CONNECTOR:id:name (29 changes) Is there a "committee" that makes or coordinates these log-facing changes ? The reason I ask is that Ive proposed that the DRM_UT_ be replaced by a set of prefix strings; "drm:core:" "drm:kms:" etc. If the DRM_DEBUG_* etc api were converted to use pr_debug, then dyndbg could optimize away the drm_debug_enabled() overheads. dyndbg would enable those classes of drm-debug callsites using #> echo module drm format drm:kms: > /proc/dyndbg/control the patchset includes a macro to declare a bit-field to implement drm.debug https://patchwork.freedesktop.org/series/96328/ how would one (hope to) coordinate changes like this ?
[PATCH] drm/bridge: anx7625: Check GPIO description to avoid crash
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 001fb39d9919..36e0ae5a1c7b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1098,9 +1098,18 @@ static void anx7625_init_gpio(struct anx7625_data
*platform)
/* Gpio for chip power enable */
platform->pdata.gpio_p_on =
devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(platform->pdata.gpio_p_on)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no enable gpio found\n");
+ platform->pdata.gpio_p_on = NULL;
+ }
+
/* Gpio for chip reset */
platform->pdata.gpio_reset =
devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(platform->pdata.gpio_reset)) {
+ DRM_DEV_DEBUG_DRIVER(dev, "no reset gpio found\n");
+ platform->pdata.gpio_p_on = NULL;
+ }
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
--
2.25.1
Re: [PATCH] drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder
On Wed, Nov 17, 2021 at 5:23 PM Steev Klimaszewski wrote: > > > On 11/17/21 1:27 AM, Christian König wrote: > > Am 16.11.21 um 19:30 schrieb Amit Pundir: > >> On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote: > >>> From: Rob Clark > >>> > >>> drm_sched_job_add_dependency() could drop the last ref, so we need > >>> to do > >>> the dma_fence_get() first. > >>> > >> It fixed the splats I saw on RB5 (sm8250 | A650). Thanks. > >> > >> Tested-by: Amit Pundir > > > > I've added my rb, pushed this with the original fix to drm-misc-fixes > > and cleaned up the obvious fallout between drm-misc-fixes and > > drm-misc-next in drm-tip. > > > > Thanks for the help and sorry for the noise, > > Christian. > > > I've run into this splat on the Lenovo Yoga C630 on 5.16-rc1 - are these > 2 patches (which fix it) going to be heading to 5.16 or were they > targeted at 5.17? these should be for v5.16 BR, -R
Re: [bug report] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
On Wed, Nov 17, 2021 at 04:47:20PM +0300, Dan Carpenter wrote:
> Hello Xin Ji,
>
> The patch 8bdfc5dae4e3: "drm/bridge: anx7625: Add anx7625 MIPI
> DSI/DPI to DP" from Sep 18, 2020, leads to the following Smatch
> static checker warning:
>
> drivers/gpu/drm/bridge/analogix/anx7625.c:1050 anx7625_init_gpio()
> warn: 'platform->pdata.gpio_p_on' could be an error pointer
>
> drivers/gpu/drm/bridge/analogix/anx7625.c:1050 anx7625_init_gpio()
> warn: 'platform->pdata.gpio_reset' could be an error pointer
Hi Dan Carpenter, thanks for the report, I'll upstream a patch to fix it.
Thanks,
Xin
>
> drivers/gpu/drm/bridge/analogix/anx7625.c
> 1037 static void anx7625_init_gpio(struct anx7625_data *platform)
> 1038 {
> 1039 struct device *dev = >client->dev;
> 1040
> 1041 DRM_DEV_DEBUG_DRIVER(dev, "init gpio\n");
> 1042
> 1043 /* Gpio for chip power enable */
> 1044 platform->pdata.gpio_p_on =
> 1045 devm_gpiod_get_optional(dev, "enable",
> GPIOD_OUT_LOW);
> 1046 /* Gpio for chip reset */
> 1047 platform->pdata.gpio_reset =
> 1048 devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> 1049
> --> 1050 if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset)
> {
> 1051 platform->pdata.low_power_mode = 1;
> 1052 DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %d,
> reset %d.\n",
> 1053
> desc_to_gpio(platform->pdata.gpio_p_on),
>
> ^
> 1054
> desc_to_gpio(platform->pdata.gpio_reset));
>
> ^^
> This will crash here but only when there is an error and debugging is
> enabled.
>
> 1055 } else {
> 1056 platform->pdata.low_power_mode = 0;
> 1057 DRM_DEV_DEBUG_DRIVER(dev, "not low power mode.\n");
> 1058 }
> 1059 }
>
> regards,
> dan carpenter
[PATCH] drm/kmb: fix potential memleak in error branch
This patch try to fix coccicheck warning:
./drivers/gpu/drm/kmb/kmb_drv.c:519:2-8: ERROR: missing put_device; call
of_find_device_by_node on line 506, but without a corresponding object release
within this function.
./drivers/gpu/drm/kmb/kmb_drv.c:522:2-8: ERROR: missing put_device; call
of_find_device_by_node on line 506, but without a corresponding object release
within this function.
./drivers/gpu/drm/kmb/kmb_drv.c:529:2-8: ERROR: missing put_device; call
of_find_device_by_node on line 506, but without a corresponding object release
within this function.
./drivers/gpu/drm/kmb/kmb_drv.c:579:1-7: ERROR: missing put_device; call
of_find_device_by_node on line 506, but without a corresponding object release
within this function.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/kmb/kmb_drv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index 961ac6fb5fcf..4a7178288ecf 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -514,8 +514,10 @@ static int kmb_probe(struct platform_device *pdev)
ret = kmb_dsi_host_bridge_init(get_device(_pdev->dev));
if (ret == -EPROBE_DEFER) {
+ of_dev_put(dsi_pdev);
return -EPROBE_DEFER;
} else if (ret) {
+ of_dev_put(dsi_pdev);
DRM_ERROR("probe failed to initialize DSI host bridge\n");
return ret;
}
@@ -523,8 +525,10 @@ static int kmb_probe(struct platform_device *pdev)
/* Create DRM device */
kmb = devm_drm_dev_alloc(dev, _driver,
struct kmb_drm_private, drm);
- if (IS_ERR(kmb))
+ if (IS_ERR(kmb)) {
+ of_dev_put(dsi_pdev);
return PTR_ERR(kmb);
+ }
dev_set_drvdata(dev, >drm);
@@ -572,6 +576,8 @@ static int kmb_probe(struct platform_device *pdev)
dev_set_drvdata(dev, NULL);
kmb_dsi_host_unregister(kmb->kmb_dsi);
+ of_dev_put(dsi_pdev);
+
return ret;
}
--
2.33.1
RPI 7" display touch controller
Greetings, I'm trying to get a RPI 7" touchscreen display working on an IMX8MM board and while I've been able to get the MIPI DSI display and backlight working I still can't seem to figure out the touch controller. It's supposed to have an FT5406 controller on it without an interrupt so I added polling support drivers/input/touchscreen/edt-ft5x06.c which I was able to verify using another touchscreen with that controller but when reading data from the FT5406 on the RPI controller the data does not make sense. These panels appear to route the I2C from the FT5406 to a STM32F103 MPU that then provides a different I2C slave interface to the 15pin connector that I'm connected to. On that I2C interface I see an i2c slave at 0x45 which is managed by the regulator driver Marek wrote (drivers/regulator/rpi-panel-attiny-regulator.c) and there is also an i2c slave at 0x38 which I assumed was the FT5406 but I believe the MPU is perhaps obfuscating that touch data. Anyone have any ideas on how to make that touch controller useful? Best regards, Tim
Re: [PATCH] drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder
On 11/17/21 1:27 AM, Christian König wrote: Am 16.11.21 um 19:30 schrieb Amit Pundir: On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote: From: Rob Clark drm_sched_job_add_dependency() could drop the last ref, so we need to do the dma_fence_get() first. It fixed the splats I saw on RB5 (sm8250 | A650). Thanks. Tested-by: Amit Pundir I've added my rb, pushed this with the original fix to drm-misc-fixes and cleaned up the obvious fallout between drm-misc-fixes and drm-misc-next in drm-tip. Thanks for the help and sorry for the noise, Christian. I've run into this splat on the Lenovo Yoga C630 on 5.16-rc1 - are these 2 patches (which fix it) going to be heading to 5.16 or were they targeted at 5.17? -- steev
Re: [PATCH v6 0/5] CMDQ refinement of Mediatek DRM driver
Hi, Jason: For this series except [v6,3/6] drm/mediatek: Detect CMDQ execution timeout (I pick v5), applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. jason-jh.lin 於 2021年10月28日 週四 下午6:19寫道： > > Change in v6: > 1. Drop the redundant checking of cmdq_vblank_cnt . > 2. fix the indent. > > Change in v5: > 1. Move mbox_free_channel to a independent patch. > > Change in v4: > 1. Add cmdq_vblank_cnt initial value to 3. > 2. Move mtk_drm_cmdq_pkt_create to the same define scope with >mtk_drm_cmdq_pkt_destroy. > > Change in v3: > 1. Revert "drm/mediatek: clear pending flag when cmdq packet is done" >and add it after the CMDQ refinement patches. > 2. Change the remove of struct cmdq_client to remove the pointer of >struct cmdq_client. > 3. Fix pkt buf alloc once but free many times. > > Changes in v2: > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() >when CONFIG_MTK_CMDQ is reachable. > > Chun-Kuang Hu (4): > drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb > drm/mediatek: Remove the pointer of struct cmdq_client > drm/mediatek: Detect CMDQ execution timeout > drm/mediatek: Add cmdq_handle in mtk_crtc > > Yongqiang Niu (1): > drm/mediatek: Clear pending flag when cmdq packet is done > > jason-jh.lin (1): > drm/mediatek: Add mbox_free_channel in mtk_drm_crtc_destroy > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 175 > 1 file changed, 151 insertions(+), 24 deletions(-) > > -- > 2.18.0 >
Re: [PATCH v5 3/6] drm/mediatek: Detect CMDQ execution timeout
Hi, Fei:
Fei Shao 於 2021年10月28日 週四 上午11:19寫道：
>
> Hi Chun-Kuang,
>
> On Thu, Oct 28, 2021 at 7:47 AM Chun-Kuang Hu wrote:
> >
> > Hi, Fei:
> >
> > Fei Shao 於 2021年10月27日 週三 下午5:32寫道：
> > >
> > > Hi Jason,
> > >
> > > On Wed, Oct 27, 2021 at 10:19 AM jason-jh.lin
> > > wrote:
> > > >
> > > > From: Chun-Kuang Hu
> > > >
> > > > CMDQ is used to update display register in vblank period, so
> > > > it should be execute in next 2 vblank. One vblank interrupt
> > > > before send message (occasionally) and one vblank interrupt
> > > > after cmdq done. If it fail to execute in next 3 vblank,
> > > > tiemout happen.
> > > >
> > > > Signed-off-by: Chun-Kuang Hu
> > > > Signed-off-by: jason-jh.lin
> > > > Reviewed-by: Chun-Kuang Hu
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 20 ++--
> > > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > index e23e3224ac67..dad1f85ee315 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > @@ -54,6 +54,7 @@ struct mtk_drm_crtc {
> > > > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > > struct cmdq_client cmdq_client;
> > > > u32 cmdq_event;
> > > > + u32 cmdq_vblank_cnt;
> > > > #endif
> > > >
> > > > struct device *mmsys_dev;
> > > > @@ -227,7 +228,10 @@ struct mtk_ddp_comp
> > > > *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc,
> > > > static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
> > > > {
> > > > struct cmdq_cb_data *data = mssg;
> > > > + struct cmdq_client *cmdq_cl = container_of(cl, struct
> > > > cmdq_client, client);
> > > > + struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct
> > > > mtk_drm_crtc, cmdq_client);
> > > >
> > > > + mtk_crtc->cmdq_vblank_cnt = 0;
> > > > cmdq_pkt_destroy(data->pkt);
> > > > }
> > > > #endif
> > > > @@ -483,6 +487,15 @@ static void mtk_drm_crtc_update_config(struct
> > > > mtk_drm_crtc *mtk_crtc,
> > > >cmdq_handle->pa_base,
> > > >cmdq_handle->cmd_buf_size,
> > > >DMA_TO_DEVICE);
> > > > + /*
> > > > +* CMDQ command should execute in next 3 vblank.
> > > > +* One vblank interrupt before send message
> > > > (occasionally)
> > > > +* and one vblank interrupt after cmdq done,
> > > > +* so it's timeout after 3 vblank interrupt.
> > > > +* If it fail to execute in next 3 vblank, timeout
> > > > happen.
> > > > +*/
> > > > + mtk_crtc->cmdq_vblank_cnt = 3;
> > > > +
> > > > mbox_send_message(mtk_crtc->cmdq_client.chan,
> > > > cmdq_handle);
> > > > mbox_client_txdone(mtk_crtc->cmdq_client.chan, 0);
> > > > }
> > > > @@ -499,11 +512,14 @@ static void mtk_crtc_ddp_irq(void *data)
> > > >
> > > > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > > if (!priv->data->shadow_register && !mtk_crtc->cmdq_client.chan)
> > > > + mtk_crtc_ddp_config(crtc, NULL);
> > > > + else if (mtk_crtc->cmdq_vblank_cnt > 0 &&
> > > > --mtk_crtc->cmdq_vblank_cnt == 0)
> > > I think atomic_dec_and_test() does what you want to do here.
> >
> > I think this operation is not necessary to be atomic operation, and
> > this statement could be reduced to
> >
> > else if (--mtk_crtc->cmdq_vblank_cnt == 0)
>
> I was thinking about using existing helpers to wrap up the counter
> operations, but I agree that it's not necessary.
> Just dropping the redundant check would be good enough.
I find one thing so that I would like this version. If we do not check
mtk_crtc->cmdq_vblank_cnt > 0, mtk_crtc->cmdq_vblank_cnt would
decrease to minus. And one day it would round to positive. So I would
pick this version instead of v6.
Regards,
Chun-Kuang.
>
>
> >
> > >
> > > > + DRM_ERROR("mtk_crtc %d CMDQ execute command timeout!\n",
> > > > + drm_crtc_index(_crtc->base));
> > > > #else
> > > > if (!priv->data->shadow_register)
> > > > -#endif
> > > > mtk_crtc_ddp_config(crtc, NULL);
> > > > -
> > > > +#endif
> > > > mtk_drm_finish_page_flip(mtk_crtc);
> > > > }
> > > >
> > > > --
> > > > 2.18.0
> > > >
[PATCH 3/3] drm/i915/gt: Improve "race-to-idle" at low frequencies
From: Chris Wilson
While the power consumption is proportional to the frequency, there is
also a static draw for active gates. The longer we are able to powergate
(rc6), the lower the static draw. Thus there is a sweetspot in the
frequency/power curve where we run at higher frequency in order to sleep
longer, aka race-to-idle. This is more evident at lower frequencies, so
let's look to bump the frequency if we think we will benefit by sleeping
longer at the higher frequency and so conserving power.
Signed-off-by: Chris Wilson
Cc: Vinay Belgaumkar
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_rps.c | 31 -
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 3675ac93ded0..6af3231982af 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -63,6 +63,22 @@ static void set(struct intel_uncore *uncore, i915_reg_t reg,
u32 val)
intel_uncore_write_fw(uncore, reg, val);
}
+static bool race_to_idle(struct intel_rps *rps, u64 busy, u64 dt)
+{
+ unsigned int this = rps->cur_freq;
+ unsigned int next = rps->cur_freq + 1;
+ u64 next_dt = next * max(busy, dt);
+
+ /*
+* Compare estimated time spent in rc6 at the next power bin. If
+* we expect to sleep longer than the estimated increased power
+* cost of running at a higher frequency, it will be reduced power
+* consumption overall.
+*/
+ return (((next_dt - this * busy) >> 10) * this * this >
+ ((next_dt - next * busy) >> 10) * next * next);
+}
+
static void rps_timer(struct timer_list *t)
{
struct intel_rps *rps = from_timer(rps, t, timer);
@@ -133,7 +149,7 @@ static void rps_timer(struct timer_list *t)
if (!max_busy[i])
break;
- busy += div_u64(max_busy[i], 1 << i);
+ busy += max_busy[i] >> i;
}
GT_TRACE(rps_to_gt(rps),
"busy:%lld [%d%%], max:[%lld, %lld, %lld],
interval:%d\n",
@@ -141,13 +157,18 @@ static void rps_timer(struct timer_list *t)
max_busy[0], max_busy[1], max_busy[2],
rps->pm_interval);
- if (100 * busy > rps->power.up_threshold * dt &&
- rps->cur_freq < rps->max_freq_softlimit) {
+ if (rps->cur_freq < rps->max_freq_softlimit &&
+ race_to_idle(rps, max_busy[0], dt)) {
+ rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
+ rps->pm_interval = 1;
+ schedule_work(>work);
+ } else if (rps->cur_freq < rps->max_freq_softlimit &&
+ 100 * busy > rps->power.up_threshold * dt) {
rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
rps->pm_interval = 1;
schedule_work(>work);
- } else if (100 * busy < rps->power.down_threshold * dt &&
- rps->cur_freq > rps->min_freq_softlimit) {
+ } else if (rps->cur_freq > rps->min_freq_softlimit &&
+ 100 * busy < rps->power.down_threshold * dt) {
rps->pm_iir |= GEN6_PM_RP_DOWN_THRESHOLD;
rps->pm_interval = 1;
schedule_work(>work);
--
2.34.0
[PATCH 2/3] drm/i915/gt: Compare average group occupancy for RPS evaluation
From: Chris Wilson
Currently, we inspect each engine individually and measure the occupancy
of that engine over the last evaluation interval. If that exceeds our
busyness thresholds, we decide to increase the GPU frequency. However,
under a load balancer, we should consider the occupancy of entire engine
groups, as work may be spread out across the group. In doing so, we
prefer wide over fast, power consumption is approximately proportional to
the square of the frequency. However, since the load balancer is greedy,
the first idle engine gets all the work, and preferrentially reuses the
last active engine, under light loads all work is assigned to one
engine, and so that engine appears very busy. But if the work happened
to overlap slightly, the workload would spread across multiple engines,
reducing each individual engine's runtime, and so reducing the rps
contribution, keeping the frequency low. Instead, when considering the
contribution, consider the contribution over the entire engine group
(capacity).
Signed-off-by: Chris Wilson
Cc: Vinay Belgaumkar
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_rps.c | 48 -
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 07ff7ba7b2b7..3675ac93ded0 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -7,6 +7,7 @@
#include "i915_drv.h"
#include "intel_breadcrumbs.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_clock_utils.h"
#include "intel_gt_irq.h"
@@ -65,26 +66,45 @@ static void set(struct intel_uncore *uncore, i915_reg_t
reg, u32 val)
static void rps_timer(struct timer_list *t)
{
struct intel_rps *rps = from_timer(rps, t, timer);
- struct intel_engine_cs *engine;
- ktime_t dt, last, timestamp;
- enum intel_engine_id id;
+ struct intel_gt *gt = rps_to_gt(rps);
+ ktime_t dt, last, timestamp = 0;
s64 max_busy[3] = {};
+ int i, j;
- timestamp = 0;
- for_each_engine(engine, rps_to_gt(rps), id) {
- s64 busy;
- int i;
+ /* Compare average occupancy over each engine group */
+ for (i = 0; i < ARRAY_SIZE(gt->engine_class); i++) {
+ s64 busy = 0;
+ int count = 0;
+
+ for (j = 0; j < ARRAY_SIZE(gt->engine_class[i]); j++) {
+ struct intel_engine_cs *engine;
- dt = intel_engine_get_busy_time(engine, );
- last = engine->stats.rps;
- engine->stats.rps = dt;
+ engine = gt->engine_class[i][j];
+ if (!engine)
+ continue;
- busy = ktime_to_ns(ktime_sub(dt, last));
- for (i = 0; i < ARRAY_SIZE(max_busy); i++) {
- if (busy > max_busy[i])
- swap(busy, max_busy[i]);
+ dt = intel_engine_get_busy_time(engine, );
+ last = engine->stats.rps;
+ engine->stats.rps = dt;
+
+ if (!intel_engine_pm_is_awake(engine))
+ continue;
+
+ busy += ktime_to_ns(ktime_sub(dt, last));
+ count++;
+ }
+
+ if (count > 1)
+ busy = div_u64(busy, count);
+ if (busy <= max_busy[ARRAY_SIZE(max_busy) - 1])
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(max_busy); j++) {
+ if (busy > max_busy[j])
+ swap(busy, max_busy[j]);
}
}
+
last = rps->pm_timestamp;
rps->pm_timestamp = timestamp;
--
2.34.0
[PATCH 1/3] drm/i915/gt: Spread virtual engines over idle engines
From: Chris Wilson
Everytime we come to the end of a virtual engine's context, re-randomise
it's siblings[]. As we schedule the siblings' tasklets in the order they
are in the array, earlier entries are executed first (when idle) and so
will be preferred when scheduling the next virtual request. Currently,
we only update the array when switching onto a new idle engine, so we
prefer to stick on the last execute engine, keeping the work compact.
However, it can be beneficial to spread the work out across idle
engines, so choose another sibling as our preferred target at the end of
the context's execution.
Signed-off-by: Chris Wilson
Cc: Vinay Belgaumkar
Cc: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 80 ---
1 file changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index ca03880fa7e4..b95bbc8fb91a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -539,6 +539,41 @@ static void execlists_schedule_in(struct i915_request *rq,
int idx)
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+ unsigned int n;
+
+ if (likely(engine == ve->siblings[0]))
+ return;
+
+ if (!intel_engine_has_relative_mmio(engine))
+ lrc_update_offsets(>context, engine);
+
+ /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+ for (n = 1; n < ve->num_siblings; n++) {
+ if (ve->siblings[n] == engine) {
+ swap(ve->siblings[n], ve->siblings[0]);
+ break;
+ }
+ }
+}
+
+static int ve_random_sibling(struct virtual_engine *ve)
+{
+ return prandom_u32_max(ve->num_siblings);
+}
+
+static int ve_random_other_sibling(struct virtual_engine *ve)
+{
+ return 1 + prandom_u32_max(ve->num_siblings - 1);
+}
+
static void
resubmit_virtual_request(struct i915_request *rq, struct virtual_engine *ve)
{
@@ -578,8 +613,23 @@ static void kick_siblings(struct i915_request *rq, struct
intel_context *ce)
rq->execution_mask != engine->mask)
resubmit_virtual_request(rq, ve);
- if (READ_ONCE(ve->request))
+ /*
+* Reschedule with a new "preferred" sibling.
+*
+* The tasklets are executed in the order of ve->siblings[], so
+* siblings[0] receives preferrential treatment of greedily checking
+* for execution of the virtual engine. At this point, the virtual
+* engine is no longer in the current GPU cache due to idleness or
+* contention, so it can be executed on any without penalty. We
+* re-randomise at this point in order to spread light loads across
+* the system, heavy overlapping loads will continue to be greedily
+* executed by the first available engine.
+*/
+ if (READ_ONCE(ve->request)) {
+ virtual_xfer_context(ve,
+ve->siblings[ve_random_other_sibling(ve)]);
tasklet_hi_schedule(>base.sched_engine->tasklet);
+ }
}
static void __execlists_schedule_out(struct i915_request * const rq,
@@ -1030,32 +1080,6 @@ first_virtual_engine(struct intel_engine_cs *engine)
return NULL;
}
-static void virtual_xfer_context(struct virtual_engine *ve,
-struct intel_engine_cs *engine)
-{
- unsigned int n;
-
- if (likely(engine == ve->siblings[0]))
- return;
-
- GEM_BUG_ON(READ_ONCE(ve->context.inflight));
- if (!intel_engine_has_relative_mmio(engine))
- lrc_update_offsets(>context, engine);
-
- /*
-* Move the bound engine to the top of the list for
-* future execution. We then kick this tasklet first
-* before checking others, so that we preferentially
-* reuse this set of bound registers.
-*/
- for (n = 1; n < ve->num_siblings; n++) {
- if (ve->siblings[n] == engine) {
- swap(ve->siblings[n], ve->siblings[0]);
- break;
- }
- }
-}
-
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
LIST_HEAD(list);
@@ -3590,7 +3614,7 @@ static void virtual_engine_initial_hint(struct
virtual_engine *ve)
* NB This does not force us to execute on this engine, it will just
* typically be the first we inspect for submission.
*/
- swp = prandom_u32_max(ve->num_siblings);
+ swp =
[PATCH 0/3] drm/i915/gt: RPS tuning for light media playback
Switch from tgl to adl, sees one particular media decode pipeline fit into a single vcs engine on adl, whereas it took two on tgl. However, it was observed that the power consumtpion for adl remained higher than for tgl. One contibution is that each engine is treated individually for rps evaluation, another is that it appears that we prefer to avoid low frequencies (with no rc6) and use slightly higher frequencies (with lots of rc6). So let's try tweaking the balancer to smear busy virtual contexts across multiple engines (trying to make adl look more like tgl), and tweak the rps evaluation to "race to idle" harder. Cc: Tvrtko Ursulin Cc: Vinay Belgaumkar Signed-off-by: Chris Wilson Chris Wilson (3): drm/i915/gt: Spread virtual engines over idle engines drm/i915/gt: Compare average group occupancy for RPS evaluation drm/i915/gt: Improve "race-to-idle" at low frequencies .../drm/i915/gt/intel_execlists_submission.c | 80 --- drivers/gpu/drm/i915/gt/intel_rps.c | 79 +- 2 files changed, 112 insertions(+), 47 deletions(-) -- 2.34.0
[PATCH v2 1/2] drm/input_helper: Add new input-handling helper
A variety of applications have found it useful to listen to
user-initiated input events to make decisions within a DRM driver, given
that input events are often the first sign that we're going to start
doing latency-sensitive activities:
* Panel self-refresh: software-directed self-refresh (e.g., with
Rockchip eDP) is especially latency sensitive. In some cases, it can
take 10s of milliseconds for a panel to exit self-refresh, which can
be noticeable. Rockchip RK3399 Chrome OS systems have always shipped
with an input_handler boost, that preemptively exits self-refresh
whenever there is input activity.
* GPU drivers: on GPU-accelerated desktop systems, we may need to
render new frames immediately after user activity. Powering up the
GPU can take enough time that it is worthwhile to start this process
as soon as there is input activity. Many Chrome OS systems also ship
with an input_handler boost that powers up the GPU.
This patch provides a small helper library that abstracts some of the
input-subsystem details around picking which devices to listen to, and
some other boilerplate. This will be used in the next patch to implement
the first bullet: preemptive exit for panel self-refresh.
Bits of this are adapted from code the Android and/or Chrome OS kernels
have been carrying for a while.
Signed-off-by: Brian Norris
---
Changes in v2:
- Honor CONFIG_INPUT dependency, via new CONFIG_DRM_INPUT_HELPER
- Remove void*; users should use container_of()
- Document the callback context
drivers/gpu/drm/Kconfig| 6 ++
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_input_helper.c | 143 +
include/drm/drm_input_helper.h | 41 +
4 files changed, 192 insertions(+)
create mode 100644 drivers/gpu/drm/drm_input_helper.c
create mode 100644 include/drm/drm_input_helper.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fb144617055b..381476b10a9d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -79,9 +79,15 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_INPUT_HELPER
+ def_bool y
+ depends on DRM_KMS_HELPER
+ depends on INPUT
+
config DRM_KMS_HELPER
tristate
depends on DRM
+ select DRM_INPUT_HELPER if INPUT
help
CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1c41156deb5f..9a6494aa45e6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,6 +56,8 @@ drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o
drm_dp_helper.o \
drm_atomic_state_helper.o drm_damage_helper.o \
drm_format_helper.o drm_self_refresh_helper.o drm_rect.o
+drm_kms_helper-$(CONFIG_DRM_INPUT_HELPER) += drm_input_helper.o
+
drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_input_helper.c
b/drivers/gpu/drm/drm_input_helper.c
new file mode 100644
index ..470f90865c7c
--- /dev/null
+++ b/drivers/gpu/drm/drm_input_helper.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Google, Inc.
+ */
+#include
+#include
+
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This helper library provides a thin wrapper around input handles, so that
+ * DRM drivers can easily perform domain-specific actions in response to user
+ * activity. e.g., if someone is moving a mouse, we're likely to want to
+ * display something soon, and we should exit panel self-refresh.
+ */
+
+static void drm_input_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int value)
+{
+ struct drm_input_handler *handler = handle->handler->private;
+
+ handler->callback(handler);
+}
+
+static int drm_input_connect(struct input_handler *handler,
+struct input_dev *dev,
+const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ int error;
+
+ handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
+ if (!handle)
+ return -ENOMEM;
+
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "drm-input-helper";
+
+ error = input_register_handle(handle);
+ if (error)
+ goto err2;
+
+ error = input_open_device(handle);
+ if (error)
+ goto err1;
+
+ return 0;
+
+err1:
+ input_unregister_handle(handle);
+err2:
+ kfree(handle);
+ return error;
+}
+
+static void drm_input_disconnect(struct input_handle *handle)
+{
+ input_close_device(handle);
+ input_unregister_handle(handle);
+ kfree(handle);
+}
+
+static const struct input_device_id drm_input_ids[] =
[PATCH v2 2/2] drm/self_refresh: Disable self-refresh on input events
To improve panel self-refresh exit latency, we speculatively start
exiting when we
receive input events. Occasionally, this may lead to false positives,
but most of the time we get a head start on coming out of PSR. Depending
on how userspace takes to produce a new frame in response to the event,
this can completely hide the exit latency.
In local tests on Chrome OS (Rockchip RK3399 eDP), we've found that the
input notifier gives us about a 50ms head start over the
fb-update-initiated exit.
Leverage a new drm_input_helper library to get easy access to
likely-relevant input event callbacks.
Inspired-by: Kristian H. Kristensen
Signed-off-by: Brian Norris
---
This was in part picked up from:
https://lore.kernel.org/all/20180405095000.9756-25-enric.balle...@collabora.com/
[PATCH v6 24/30] drm/rockchip: Disable PSR on input events
with significant rewrites/reworks:
- moved to common drm_input_helper and drm_self_refresh_helper
implementation
- track state only through crtc->state->self_refresh_active
Note that I'm relatively unfamiliar with DRM locking expectations, but I
believe access to drm_crtc->state (which helps us track redundant
transitions) is OK under the locking provided by
drm_atomic_get_crtc_state().
Changes in v2:
- Delay PSR re-entry, when already disabled
- Allow default configuration via Kconfig and modparam
- Replace void* with container_of()
drivers/gpu/drm/Kconfig | 16
drivers/gpu/drm/drm_self_refresh_helper.c | 98 +++
2 files changed, 100 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 381476b10a9d..698924ed9b6b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -84,6 +84,22 @@ config DRM_INPUT_HELPER
depends on DRM_KMS_HELPER
depends on INPUT
+config DRM_SELF_REFRESH_INPUT_BOOST_DEFAULT
+ bool "Preemptively exit panel self-refresh on input device activity" if
EXPERT
+ default y
+ depends on DRM_INPUT_HELPER
+ help
+ Allows the generic DRM panel self-refresh helpers to factor in user
+ input activity to preemptively exit panel self-refresh, in order to
+ reduce potentially-visible latency when displaying new display
+ content. This is an optimization which often will do the right thing,
+ but can be disabled for experimentation or similar.
+
+ Saying Y enables the feature by default; this can also be configured
+ by module parameter, drm_kms_helper.self_refresh_input_boost.
+
+ If in doubt, say "Y".
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
b/drivers/gpu/drm/drm_self_refresh_helper.c
index dd33fec5aabd..ba4881e683b7 100644
--- a/drivers/gpu/drm/drm_self_refresh_helper.c
+++ b/drivers/gpu/drm/drm_self_refresh_helper.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -15,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -58,17 +60,41 @@ DECLARE_EWMA(psr_time, 4, 4)
struct drm_self_refresh_data {
struct drm_crtc *crtc;
struct delayed_work entry_work;
+ struct work_struct exit_work;
+ struct drm_input_handler input_handler;
+ bool input_handler_registered;
struct mutex avg_mutex;
struct ewma_psr_time entry_avg_ms;
struct ewma_psr_time exit_avg_ms;
};
-static void drm_self_refresh_helper_entry_work(struct work_struct *work)
+static bool self_refresh_input_boost =
+ IS_ENABLED(CONFIG_DRM_SELF_REFRESH_INPUT_BOOST_DEFAULT);
+#if defined(CONFIG_DRM_INPUT_HELPER)
+module_param(self_refresh_input_boost, bool, 0644);
+MODULE_PARM_DESC(self_refresh_input_boost,
+"Enable panel self-refresh input boost [default="
+__stringify(CONFIG_DRM_SELF_REFRESH_INPUT_BOOST_DEFAULT) "]");
+#endif /* CONFIG_DRM_INPUT_HELPER */
+
+
+static void drm_self_refresh_reschedule(struct drm_self_refresh_data *sr_data)
+{
+ unsigned int delay;
+
+ mutex_lock(_data->avg_mutex);
+ delay = (ewma_psr_time_read(_data->entry_avg_ms) +
+ewma_psr_time_read(_data->exit_avg_ms)) * 2;
+ mutex_unlock(_data->avg_mutex);
+
+ mod_delayed_work(system_wq, _data->entry_work,
+msecs_to_jiffies(delay));
+}
+
+static void drm_self_refresh_transition(struct drm_self_refresh_data *sr_data,
+ bool enable)
{
- struct drm_self_refresh_data *sr_data = container_of(
- to_delayed_work(work),
- struct drm_self_refresh_data, entry_work);
struct drm_crtc *crtc = sr_data->crtc;
struct drm_device *dev = crtc->dev;
struct drm_modeset_acquire_ctx ctx;
@@ -95,6 +121,14 @@ static void drm_self_refresh_helper_entry_work(struct
work_struct *work)
goto out;
[PATCH v2 0/2] drm: Support input-boosted panel self-refresh exit
A variety of applications have found it useful to listen to user-initiated input events to make decisions within a DRM driver, given that input events are often the first sign that we're going to start doing latency-sensitive activities: * Panel self-refresh: software-directed self-refresh (e.g., with Rockchip eDP) is especially latency sensitive. In some cases, it can take 10s of milliseconds for a panel to exit self-refresh, which can be noticeable. Rockchip RK3399 Chrome OS systems have always shipped with an input_handler boost, that preemptively exits self-refresh whenever there is input activity. * GPU drivers: on GPU-accelerated desktop systems, we may need to render new frames immediately after user activity. Powering up the GPU can take enough time that it is worthwhile to start this process as soon as there is input activity. Many Chrome OS systems also ship with an input_handler boost that powers up the GPU. I implement the first bullet in this series, and I also compared with some out-of-tree patches for the second, to ensure this could be useful there too. Past work on upstreaming a variety of Chromebook display patches got held up for this particular feature, as there was some desire to make it a bit more generic, for one. See the latest here: https://lore.kernel.org/all/20180405095000.9756-25-enric.balle...@collabora.com/ [PATCH v6 24/30] drm/rockchip: Disable PSR on input events I significantly rewrote this to adapt it to the new common drm_self_refresh_helpers and to add a new drm_input_helper thin library, so I only carry my own authorship on this series. Admittedly, this "drm_input_helper" library is barely DRM-specific at all, except that all display- and GPU-related input-watchers are likely to want to watch similar device behavior (unlike, say, rfkill or led input_handler code). The approximate consensus so far seems to be that (a) this isn't much code; if we need it for other subsystems (like, cpufreq-boost), it's easy to implement similar logic (b) input subsystem maintainers think the existing input_handler abstraction is good enough So, I keep the thin input helper in drivers/gpu/drm/. v1: https://lore.kernel.org/all/20211103234018.4009771-1-briannor...@chromium.org/ Changes in v2: - Honor CONFIG_INPUT dependency, via new CONFIG_DRM_INPUT_HELPER - Remove void*; users should use container_of() - Document the callback context - Delay PSR re-entry, when already disabled - Allow default configuration via Kconfig and modparam - really CC dri-devel@lists.freedesktop.org (oops!) Brian Norris (2): drm/input_helper: Add new input-handling helper drm/self_refresh: Disable self-refresh on input events drivers/gpu/drm/Kconfig | 22 drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/drm_input_helper.c| 143 ++ drivers/gpu/drm/drm_self_refresh_helper.c | 98 --- include/drm/drm_input_helper.h| 41 +++ 5 files changed, 292 insertions(+), 14 deletions(-) create mode 100644 drivers/gpu/drm/drm_input_helper.c create mode 100644 include/drm/drm_input_helper.h -- 2.34.0.rc1.387.gb447b232ab-goog
Re: [PATCH -next] drm/amd/display: check top_pipe_to_program pointer
Applied. Thanks!
On Mon, Nov 15, 2021 at 3:10 AM Yang Li wrote:
>
> Clang static analysis reports this error
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
> Dereference of null pointer [clang-analyzer-core.NullDereference]
> if
> (top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) {
> ^
>
> top_pipe_to_program being NULL is caught as an error
> But then it is used to report the error.
>
> So add a check before using it.
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 39ad385..34382d0 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -2867,7 +2867,8 @@ static void commit_planes_for_stream(struct dc *dc,
> #endif
>
> if ((update_type != UPDATE_TYPE_FAST) &&
> stream->update_flags.bits.dsc_changed)
> - if
> (top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) {
> + if (top_pipe_to_program &&
> +
> top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) {
> if (should_use_dmub_lock(stream->link)) {
> union dmub_hw_lock_flags hw_locks = { 0 };
> struct dmub_hw_lock_inst_flags inst_flags = {
> 0 };
> --
> 1.8.3.1
>
Re: [PATCH] drm/amd/display: remove no need NULL check before kfree
Applied. Thanks!
On Mon, Nov 15, 2021 at 8:48 PM Bernard Zhao wrote:
>
> This change is to cleanup the code a bit.
>
> Signed-off-by: Bernard Zhao
> ---
> .../drm/amd/display/dc/dcn10/dcn10_resource.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> index f37551e00023..0090550d4aee 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> @@ -978,10 +978,8 @@ static void dcn10_resource_destruct(struct
> dcn10_resource_pool *pool)
> pool->base.mpc = NULL;
> }
>
> - if (pool->base.hubbub != NULL) {
> - kfree(pool->base.hubbub);
> - pool->base.hubbub = NULL;
> - }
> + kfree(pool->base.hubbub);
> + pool->base.hubbub = NULL;
>
> for (i = 0; i < pool->base.pipe_count; i++) {
> if (pool->base.opps[i] != NULL)
> @@ -1011,14 +1009,10 @@ static void dcn10_resource_destruct(struct
> dcn10_resource_pool *pool)
> for (i = 0; i < pool->base.res_cap->num_ddc; i++) {
> if (pool->base.engines[i] != NULL)
> dce110_engine_destroy(>base.engines[i]);
> - if (pool->base.hw_i2cs[i] != NULL) {
> - kfree(pool->base.hw_i2cs[i]);
> - pool->base.hw_i2cs[i] = NULL;
> - }
> - if (pool->base.sw_i2cs[i] != NULL) {
> - kfree(pool->base.sw_i2cs[i]);
> - pool->base.sw_i2cs[i] = NULL;
> - }
> + kfree(pool->base.hw_i2cs[i]);
> + pool->base.hw_i2cs[i] = NULL;
> + kfree(pool->base.sw_i2cs[i]);
> + pool->base.sw_i2cs[i] = NULL;
> }
>
> for (i = 0; i < pool->base.audio_count; i++) {
> --
> 2.33.1
>
Re: [PATCH] drm/amd/display: cleanup the code a bit
Applied. Thanks!
On Tue, Nov 16, 2021 at 4:19 AM Christian König
wrote:
>
> Am 16.11.21 um 02:34 schrieb Bernard Zhao:
> > In function dc_sink_destruct, kfree will check pointer, no need
> > to check again.
> > This change is to cleanup the code a bit.
> >
> > Signed-off-by: Bernard Zhao
>
> This one and the other patch are Acked-by: Christian König
>
>
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc_sink.c | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_sink.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_sink.c
> > index a249a0e5edd0..4b5e4d8e7735 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_sink.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_sink.c
> > @@ -33,14 +33,6 @@
> >* Private functions
> >
> > **/
> >
> > -static void dc_sink_destruct(struct dc_sink *sink)
> > -{
> > - if (sink->dc_container_id) {
> > - kfree(sink->dc_container_id);
> > - sink->dc_container_id = NULL;
> > - }
> > -}
> > -
> > static bool dc_sink_construct(struct dc_sink *sink, const struct
> > dc_sink_init_data *init_params)
> > {
> >
> > @@ -75,7 +67,7 @@ void dc_sink_retain(struct dc_sink *sink)
> > static void dc_sink_free(struct kref *kref)
> > {
> > struct dc_sink *sink = container_of(kref, struct dc_sink, refcount);
> > - dc_sink_destruct(sink);
> > + kfree(sink->dc_container_id);
> > kfree(sink);
> > }
> >
>
Re: [PATCH] drm/amd/amdgpu: fix potential memleak
Applied. Thanks!
Alex
On Mon, Nov 15, 2021 at 10:56 AM Felix Kuehling wrote:
>
> Am 2021-11-14 um 9:58 p.m. schrieb Bernard Zhao:
> > In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed
> > There is a potential memleak if not call kobject_put.
> >
> > Signed-off-by: Bernard Zhao
>
> Reviewed-by: Felix Kuehling
>
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > index 0fad2bf854ae..567df2db23ac 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
> > @@ -386,6 +386,7 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct
> > amdgpu_device *adev)
> > "%s", "xgmi_hive_info");
> > if (ret) {
> > dev_err(adev->dev, "XGMI: failed initializing kobject for
> > xgmi hive\n");
> > + kobject_put(>kobj);
> > kfree(hive);
> > hive = NULL;
> > goto pro_end;
Re: [PATCH v2] drm/amd/amdgpu: cleanup the code style a bit
Applied. Thanks!
Alex
On Mon, Nov 15, 2021 at 7:09 AM Bernard Zhao wrote:
>
> This change is to cleanup the code style a bit.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 04cf9b207e62..3fc49823f527 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -283,17 +283,15 @@ static int amdgpu_virt_init_ras_err_handler_data(struct
> amdgpu_device *adev)
>
> *data = kmalloc(sizeof(struct amdgpu_virt_ras_err_handler_data),
> GFP_KERNEL);
> if (!*data)
> - return -ENOMEM;
> + goto data_failure;
>
> bps = kmalloc_array(align_space, sizeof((*data)->bps), GFP_KERNEL);
> - bps_bo = kmalloc_array(align_space, sizeof((*data)->bps_bo),
> GFP_KERNEL);
> + if (!bps)
> + goto bps_failure;
>
> - if (!bps || !bps_bo) {
> - kfree(bps);
> - kfree(bps_bo);
> - kfree(*data);
> - return -ENOMEM;
> - }
> + bps_bo = kmalloc_array(align_space, sizeof((*data)->bps_bo),
> GFP_KERNEL);
> + if (!bps_bo)
> + goto bps_bo_failure;
>
> (*data)->bps = bps;
> (*data)->bps_bo = bps_bo;
> @@ -303,6 +301,13 @@ static int amdgpu_virt_init_ras_err_handler_data(struct
> amdgpu_device *adev)
> virt->ras_init_done = true;
>
> return 0;
> +
> +bps_bo_failure:
> + kfree(bps);
> +bps_failure:
> + kfree(*data);
> +data_failure:
> + return -ENOMEM;
> }
>
> static void amdgpu_virt_ras_release_bp(struct amdgpu_device *adev)
> --
> 2.33.1
>
Re: [PATCH] drm/amd/amdgpu: remove useless break after return
Applied thanks. If you want to make the numbering more sequential,
please also update the other dce files if you make that change.
Alex
On Mon, Nov 15, 2021 at 2:14 AM Bernard Zhao wrote:
>
> This change is to remove useless break after return.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index b200b9e722d9..8318ee8339f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -2092,22 +2092,18 @@ static int dce_v8_0_pick_dig_encoder(struct
> drm_encoder *encoder)
> return 1;
> else
> return 0;
> - break;
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> if (dig->linkb)
> return 3;
> else
> return 2;
> - break;
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> if (dig->linkb)
> return 5;
> else
> return 4;
> - break;
> case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
> return 6;
> - break;
> default:
> DRM_ERROR("invalid encoder_id: 0x%x\n",
> amdgpu_encoder->encoder_id);
> return 0;
> --
> 2.33.1
>
Re: [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm
Hi Arunpravin, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on drm-intel/for-linux-next v5.16-rc1] [cannot apply to drm-tip/drm-tip next-2027] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Arunpravin/drm-move-the-buddy-allocator-from-i915-into-common-drm/2027-041920 base: git://anongit.freedesktop.org/drm/drm drm-next config: i386-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/47fb1aeae75661971f4526efddf4ae5b5738977f git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Arunpravin/drm-move-the-buddy-allocator-from-i915-into-common-drm/2027-041920 git checkout 47fb1aeae75661971f4526efddf4ae5b5738977f # save the attached .config to linux build tree mkdir build_dir make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/intel_memory_region.c:242: >> drivers/gpu/drm/i915/selftests/intel_memory_region.c:23:10: fatal error: >> i915_buddy.h: No such file or directory 23 | #include "i915_buddy.h" | ^~ compilation terminated. vim +23 drivers/gpu/drm/i915/selftests/intel_memory_region.c 232a6ebae419193 Matthew Auld 2019-10-08 14 340be48f2c5a3c0 Matthew Auld 2019-10-25 15 #include "gem/i915_gem_context.h" b908be543e44414 Matthew Auld 2019-10-25 16 #include "gem/i915_gem_lmem.h" 232a6ebae419193 Matthew Auld 2019-10-08 17 #include "gem/i915_gem_region.h" 340be48f2c5a3c0 Matthew Auld 2019-10-25 18 #include "gem/selftests/igt_gem_utils.h" 232a6ebae419193 Matthew Auld 2019-10-08 19 #include "gem/selftests/mock_context.h" 99919be74aa3753 Thomas Hellström 2021-06-17 20 #include "gt/intel_engine_pm.h" 6804da20bb549e3 Chris Wilson 2019-10-27 21 #include "gt/intel_engine_user.h" b908be543e44414 Matthew Auld 2019-10-25 22 #include "gt/intel_gt.h" d53ec322dc7de32 Matthew Auld 2021-06-16 @23 #include "i915_buddy.h" 99919be74aa3753 Thomas Hellström 2021-06-17 24 #include "gt/intel_migrate.h" ba12993c5228015 Matthew Auld 2020-01-29 25 #include "i915_memcpy.h" d53ec322dc7de32 Matthew Auld 2021-06-16 26 #include "i915_ttm_buddy_manager.h" 01377a0d7e6648b Abdiel Janulgue 2019-10-25 27 #include "selftests/igt_flush_test.h" 2f0b97ca0211863 Matthew Auld 2019-10-08 28 #include "selftests/i915_random.h" 232a6ebae419193 Matthew Auld 2019-10-08 29 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] drm/panel-edp: modify Kconfig to prevent build error
On 11/16/21 11:58 PM, Arnd Bergmann wrote: On Wed, Nov 17, 2021 at 7:27 AM Randy Dunlap wrote: When CONFIG_DRM_KMS_HELPER=m and CONFIG_DRM_PANEL_EDP=y, there is a build error in gpu/drm/panel/panel-edp.o: arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-edp.o: in function `panel_edp_probe': panel-edp.c:(.text+0xf38): undefined reference to `drm_panel_dp_aux_backlight' Fix this by limiting DRM_PANEL_DEP by the value of the DRM_KMS_HELPER symbol. I think the analysis is correct, but this is not the correct fix since DRM_KMS_HELPER is not user-selectable. (Almost) all other drivers that rely on DRM_KMS_HELPER use 'select' for this, and mixing the two risks running into circular dependencies. Oops. Thanks for catching that. My first (local) version of the patch used select, but that got me into kconfig circular dependency chain land (ugly). Maybe your all-at-once patch can take care of that problem. I see that there are already some 'depends on DRM_KMS_HELPER' in bridge and panel drivers, so it's possible that we have to fix them all at the same to do this right. I ran into another problem like this the other day and I'm currently testing with the patch below, but I have not posted that yet since I am not fully convinced that this is the correct fix either. I'll test some with it also. thanks. -- ~Randy
Re: [PATCH v3 4/6] drm: implement a method to free unused pages
On 16/11/2021 20:18, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input argument name 'actual_size' with 'new_size'
- add more validation checks for input arguments
- add overlaps check to avoid needless searching and splitting
- merged the below patch to see the feature in action
- add free unused pages support to i915 driver
- lock drm_buddy_block_trim() function as it calls mark_free/mark_split
are all globally visible
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 108 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 10 ++
include/drm/drm_buddy.h | 4 +
3 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 0a9db2981188..943fe2ad27bf 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -284,6 +284,114 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64
e2)
return s1 <= s2 && e1 >= e2;
}
+/**
+ * drm_buddy_block_trim - free unused pages
+ *
+ * @mm: DRM buddy manager
+ * @new_size: original size requested
+ * @blocks: output list head to add allocated blocks
+ *
+ * For contiguous allocation, we round up the size to the nearest
+ * power of two value, drivers consume *actual* size, so remaining
+ * portions are unused and it can be freed.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_block_trim(struct drm_buddy_mm *mm,
+u64 new_size,
+struct list_head *blocks)
+{
+ struct drm_buddy_block *block;
+ struct drm_buddy_block *buddy;
+ u64 new_start;
+ u64 new_end;
+ LIST_HEAD(dfs);
+ u64 count = 0;
+ int err;
+
+ if (!list_is_singular(blocks))
+ return -EINVAL;
+
+ block = list_first_entry(blocks,
+struct drm_buddy_block,
+link);
+
+ if (!drm_buddy_block_is_allocated(block))
+ return -EINVAL;
+
+ if (new_size > drm_buddy_block_size(mm, block))
+ return -EINVAL;
+
+ if (!new_size && !IS_ALIGNED(new_size, mm->chunk_size))
+ return -EINVAL;
+
+ if (new_size == drm_buddy_block_size(mm, block))
+ return 0;
+
+ list_del(>link);
+
+ new_start = drm_buddy_block_offset(block);
+ new_end = new_start + new_size - 1;
+
+ mark_free(mm, block);
+
+ list_add(>tmp_link, );
+
+ do {
+ u64 block_start;
+ u64 block_end;
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+tmp_link);
+ if (!block)
+ break;
+
+ list_del(>tmp_link);
+
+ if (count == new_size)
+ return 0;
+
+ block_start = drm_buddy_block_offset(block);
+ block_end = block_start + drm_buddy_block_size(mm, block) - 1;
+
+ if (!overlaps(new_start, new_end, block_start, block_end))
+ continue;
+
+ if (contains(new_start, new_end, block_start, block_end)) {
+ BUG_ON(!drm_buddy_block_is_free(block));
+
+ /* Allocate only required blocks */
+ mark_allocated(block);
+ mm->avail -= drm_buddy_block_size(mm, block);
+ list_add_tail(>link, blocks);
+ count += drm_buddy_block_size(mm, block);
+ continue;
+ }
+
+ if (!drm_buddy_block_is_split(block)) {
Should always be true, right? But I guess depends if we want to re-use
this for generic range allocation...
+ err = split_block(mm, block);
+ if (unlikely(err))
+ goto err_undo;
+ }
+
+ list_add(>right->tmp_link, );
+ list_add(>left->tmp_link, );
+ } while (1);
+
+ return -ENOSPC;
+
+err_undo:
+ buddy = get_buddy(block);
+ if (buddy &&
+ (drm_buddy_block_is_free(block) &&
+drm_buddy_block_is_free(buddy)))
+ __drm_buddy_free(mm, block);
+ return err;
Looking at the split_block failure path. The user allocated some block,
and then tried to trim it, but this then marks it as free and removes it
from their original list(potentially also freeing it), if we fail here.
Would it be better to leave that decision to the user? If the trim()
fails, worse case we get some internal fragmentation,
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2
On Wed, Nov 17, 2021 at 10:51:39AM -0800, Matt Roper wrote: > On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote: > > On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote: > > > From: Matt Atwood > > > > > > Extend existing workaround 1409120013 to DG2. > > > > I don't see this listed for DG2. > > This seems to be problem with the DG2 query since for some reason they > marked this workaround as 'driver_change_required' rather than > 'driver_permanent_wa' in the database and that prevents it from showing > up in some of the queries properly. The DG2-specific ID number > to check is 140975. Bit of mes that one. I can't really figure out if dg2 is the only d13 platform that needs this or might there be others? -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2
On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood
> >
> > Extend existing workaround 1409120013 to DG2.
>
> I don't see this listed for DG2.
>
> >
> > Cc: José Roberto de Souza
> > Signed-off-by: Matt Atwood
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 89dc7f69baf3..e721c421cc58 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> >
> > static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> > {
> > - /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> > + /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
> > if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> > - IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> > + IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
AFAIK we're not even calling this function on dg2, so this is just dead
code. And in fact without dg2 this seems to be the same as DISPLAY_VER==12
so we shuld stop calling it on adl-p as well. We could then rip out most
of the platform checks in here.
> > intel_uncore_write(_priv->uncore, ILK_DPFC_CHICKEN,
> >DPFC_CHICKEN_COMP_DUMMY_PIXEL);
> >
> > --
> > 2.33.0
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2
On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood
> >
> > Extend existing workaround 1409120013 to DG2.
>
> I don't see this listed for DG2.
This seems to be problem with the DG2 query since for some reason they
marked this workaround as 'driver_change_required' rather than
'driver_permanent_wa' in the database and that prevents it from showing
up in some of the queries properly. The DG2-specific ID number
to check is 140975.
Matt
>
> >
> > Cc: José Roberto de Souza
> > Signed-off-by: Matt Atwood
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 89dc7f69baf3..e721c421cc58 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> >
> > static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> > {
> > - /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> > + /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
> > if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> > - IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> > + IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
> > intel_uncore_write(_priv->uncore, ILK_DPFC_CHICKEN,
> >DPFC_CHICKEN_COMP_DUMMY_PIXEL);
> >
> > --
> > 2.33.0
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [PATCH v2 1/6] drm/i915: move the pre_pin earlier
On 11/17/21 15:20, Matthew Auld wrote: In intel_context_do_pin_ww, when calling into the pre_pin hook(which is passed the ww context) it could in theory return -EDEADLK(which is very likely with debug kernels), once we start adding more ww locking in there, like in the next patch. If so then we need to be mindful of having to restart the do_pin at this point. If this is the kernel_context, or some other early in-kernel context where we have yet to setup the default_state, then we always inhibit the context restore, and instead rely on the delayed active_release to set the CONTEXT_VALID_BIT for us(if we even care), which should indicate that we have context switched away, and that our newly saved context state should now be valid. However, since we currently grab the active reference before the potential ww dance, we can end up setting the CONTEXT_VALID_BIT much too early, if we need to backoff, and then upon re-trying the do_pin, we could potentially cause the hardware to incorrectly load some garbage context state when later context switching to that context, but at the very least this will trigger the GEM_BUG_ON() in __engine_unpark. For now let's just move any ww dance stuff prior to arming the active reference. For normal user contexts this shouldn't be a concern, since we should already have the default_state ready when initialising the lrc state, and so there should be no concern with active_release somehow prematurely setting the CONTEXT_VALID_BIT. v2(Thomas): - Also re-order the union unwind Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Maarten Lankhorst Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/intel_context.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 5634d14052bc..4c296de1d67d 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -228,17 +228,17 @@ int __intel_context_do_pin_ww(struct intel_context *ce, if (err) return err; - err = i915_active_acquire(>active); + err = ce->ops->pre_pin(ce, ww, ); if (err) goto err_ctx_unpin; - err = ce->ops->pre_pin(ce, ww, ); + err = i915_active_acquire(>active); if (err) - goto err_release; + goto err_post_unpin; err = mutex_lock_interruptible(>pin_mutex); if (err) - goto err_post_unpin; + goto err_release; intel_engine_pm_might_get(ce->engine); @@ -273,11 +273,11 @@ int __intel_context_do_pin_ww(struct intel_context *ce, err_unlock: mutex_unlock(>pin_mutex); +err_release: + i915_active_release(>active); err_post_unpin: if (!handoff) ce->ops->post_unpin(ce); -err_release: - i915_active_release(>active); err_ctx_unpin: intel_context_post_unpin(ce);
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dg2: extend Wa_1409120013 to DG2
On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
I don't see this listed for DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 89dc7f69baf3..e721c421cc58 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7444,9 +7444,9 @@ static void icl_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
> + /* Wa_1409120013:tgl,rkl,adl-s,dg1,dg2 */
> if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
> - IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
> + IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv) || IS_DG2(dev_priv))
> intel_uncore_write(_priv->uncore, ILK_DPFC_CHICKEN,
> DPFC_CHICKEN_COMP_DUMMY_PIXEL);
>
> --
> 2.33.0
--
Ville Syrjälä
Intel
Re: [PATCH v3 2/6] drm: improve drm_buddy_alloc function
On 16/11/2021 20:18, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 driver to drm buddy
v2:
merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make alloc_range() block allocations as bottom-up
- optimize order computation logic
- replace uint64_t with u64, which is preferred in the kernel
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 259 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 69 ++---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +
include/drm/drm_buddy.h | 22 +-
4 files changed, 203 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 39eb1d224bec..c9b18a29f8d1 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -274,63 +274,6 @@ void drm_buddy_free_list(struct drm_buddy_mm *mm, struct
list_head *objects)
}
EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the _buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order)
-{
- struct drm_buddy_block *block = NULL;
- unsigned int i;
- int err;
-
- for (i = order; i <= mm->max_order; ++i) {
- block = list_first_entry_or_null(>free_list[i],
-struct drm_buddy_block,
-link);
- if (block)
- break;
- }
-
- if (!block)
- return ERR_PTR(-ENOSPC);
-
- BUG_ON(!drm_buddy_block_is_free(block));
-
- while (i != order) {
- err = split_block(mm, block);
- if (unlikely(err))
- goto out_free;
-
- /* Go low */
- block = block->left;
- i--;
- }
-
- mark_allocated(block);
- mm->avail -= drm_buddy_block_size(mm, block);
- kmemleak_update_trace(block);
- return block;
-
-out_free:
- if (i != order)
- __drm_buddy_free(mm, block);
- return ERR_PTR(err);
-}
-EXPORT_SYMBOL(drm_buddy_alloc);
-
static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2)
{
return s1 <= e2 && e1 >= s2;
@@ -341,52 +284,22 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64
e2)
return s1 <= s2 && e1 >= e2;
}
-/**
- * drm_buddy_alloc_range - allocate range
- *
- * @mm: DRM buddy manager to allocate from
- * @blocks: output list head to add allocated blocks
- * @start: start of the allowed range for this block
- * @size: size of the allocation
- *
- * Intended for pre-allocating portions of the address space, for example to
- * reserve a block for the initial framebuffer or similar, hence the
expectation
- * here is that drm_buddy_alloc() is still the main vehicle for
- * allocations, so if that's not the case then the drm_mm range allocator is
- * probably a much better fit, and so you should probably go use that instead.
- *
- * Note that it's safe to chain together multiple alloc_ranges
- * with the same blocks list
- *
- * Returns:
- * 0 on success, error code on failure.
- */
-int drm_buddy_alloc_range(struct drm_buddy_mm *mm,
- struct list_head *blocks,
- u64 start, u64 size)
+static struct drm_buddy_block *
+alloc_range(struct drm_buddy_mm *mm,
+ u64 start, u64 end,
+ unsigned int order)
{
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
- LIST_HEAD(allocated);
LIST_HEAD(dfs);
- u64 end;
int err;
int i;
- if (size < mm->chunk_size)
- return -EINVAL;
-
- if (!IS_ALIGNED(size | start, mm->chunk_size))
- return -EINVAL;
-
- if (range_overflows(start, size, mm->size))
- return -EINVAL;
+ end = end - 1;
for (i = 0; i < mm->n_roots; ++i)
list_add_tail(>roots[i]->tmp_link, );
- end = start + size - 1;
-
do {
u64 block_start;
Re: [PATCH 12/12] drm: rockchip: Add VOP2 driver
On Mittwoch, 17. November 2021 15:33:47 CET Sascha Hauer wrote: > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. > It replaces the VOP unit found in the older Rockchip SoCs. > > This driver has been derived from the downstream Rockchip Kernel and > heavily modified: > > - All nonstandard DRM properties have been removed > - dropped struct vop2_plane_state and pass around less data between > functions > - Dropped all DRM_FORMAT_* not known on upstream > - rework register access to get rid of excessively used macros > > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB > board. Overlay support is tested with the modetest utility. AFBC support > is still present in the driver, but currently untested due to the lack > of suitable image sources. Also the driver has been tested with weston > using pixman and (yet to be upstreamed) panfrost driver support. > > Signed-off-by: Sascha Hauer > --- Hi Sascha, thank you very much for your work on this! I gave it a try tonight, and unfortunately it appears to currently always attempt to use 1920x1080p60 as the mode regardless of the monitor. For example, on an old 720p monitor I had laying around: [ 225.732342] rockchip-drm display-subsystem: [drm] Update mode to 1920x1080p60, type: 11 for vp0, output 0x0800 HDMI0 This results in a broken picture (all white with occasional glitches). Somebody else observed the same behaviour on a 1440p monitor. Thanks, Nicolas Frattaroli
Re: [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm
On 16/11/2021 20:18, Arunpravin wrote: Move the base i915 buddy allocator code into drm - Move i915_buddy.h to include/drm - Move i915_buddy.c to drm root folder - Rename "i915" string with "drm" string wherever applicable - Rename "I915" string with "DRM" string wherever applicable - Fix header file dependencies - Fix alignment issues - add Makefile support for drm buddy - export functions and write kerneldoc description - Remove i915 selftest config check condition as buddy selftest will be moved to drm selftest folder cleanup i915 buddy references in i915 driver module and replace with drm buddy v2: - include header file in alphabetical order (Thomas) - merged changes listed in the body section into a single patch to keep the build intact (Christian, Jani) Signed-off-by: Arunpravin Any ideas for what to do with the existing selftests? Currently this series doesn't build yet for i915 due to this, and prevents throwing the series at CI.
Re: [PATCH] gpu: drm: panel-edp: Fix edp_panel_entry documentation
Quoting Doug Anderson (2021-11-17 16:49:43)
> Hi,
>
> On Wed, Nov 17, 2021 at 8:32 AM Kieran Bingham
> wrote:
> >
> > The edp_panel_entry members 'delay' and 'name' are documented, but
> > without the correct syntax for kernel doc.
> >
> > This generates the following warnings:
> >
> > drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or
> > member 'delay' not described in 'edp_panel_entry'
> > drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or
> > member 'name' not described in 'edp_panel_entry'
> >
> > Fix them accordingly.
> >
> > Fixes: 5540cf8f3e8d ("drm/panel-edp: Implement generic "edp-panel"s probed
> > by EDID")
> > Signed-off-by: Kieran Bingham
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Thanks! Pushed to drm-misc-next (though technically it's a fix, it
> didn't seem urgent enough to go through -fixes. Hopefully this is OK).
>
Certainly, I agree it's not urgent. I wasn't even sure if I should add
the Fixes tag, but I figured if I left it out someone would jump in with
it ;-)
> 1e66f04c14ab gpu: drm: panel-edp: Fix edp_panel_entry documentation
>
> -Doug
Thanks
Kieran
Re: [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm
Hi Christian,
I will make this a separate module.
Thanks,
Arun
On 17/11/21 1:33 pm, Christian König wrote:
> I've looked a bit more into this and I think we should just follow
> Thomas Zimmermann's idea to make this a separate module.
>
> Otherwise we just have the code around all the time even if it is unused
> and implementing this should be trivial.
>
> See how DRM_GEM_CMA_HELPER or DRM_VRAM_HELPER are done in
> drivers/gpu/drm/Kconfig and then have the desired effect in
> drivers/gpu/drm/Makefile
>
> Should be something like ~15 lines of additional configuration which
> saves a bit of memory on embedded systems which just need a fbdev
> replacement.
>
> Thanks,
> Christian.
>
> Am 16.11.21 um 21:18 schrieb Arunpravin:
>> Move the base i915 buddy allocator code into drm
>> - Move i915_buddy.h to include/drm
>> - Move i915_buddy.c to drm root folder
>> - Rename "i915" string with "drm" string wherever applicable
>> - Rename "I915" string with "DRM" string wherever applicable
>> - Fix header file dependencies
>> - Fix alignment issues
>> - add Makefile support for drm buddy
>> - export functions and write kerneldoc description
>> - Remove i915 selftest config check condition as buddy selftest
>>will be moved to drm selftest folder
>>
>> cleanup i915 buddy references in i915 driver module
>> and replace with drm buddy
>>
>> v2:
>>- include header file in alphabetical order (Thomas)
>>- merged changes listed in the body section into a single patch
>> to keep the build intact (Christian, Jani)
>>
>> Signed-off-by: Arunpravin
>> ---
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/drm_buddy.c | 521 ++
>> drivers/gpu/drm/drm_drv.c | 3 +
>> drivers/gpu/drm/i915/Makefile | 1 -
>> drivers/gpu/drm/i915/i915_buddy.c | 466
>> drivers/gpu/drm/i915/i915_buddy.h | 143 -
>> drivers/gpu/drm/i915/i915_module.c| 3 -
>> drivers/gpu/drm/i915/i915_scatterlist.c | 11 +-
>> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 33 +-
>> drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
>> include/drm/drm_buddy.h | 153 +
>> 11 files changed, 702 insertions(+), 638 deletions(-)
>> create mode 100644 drivers/gpu/drm/drm_buddy.c
>> delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
>> delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
>> create mode 100644 include/drm/drm_buddy.h
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 0dff40bb863c..dc61e91a3154 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -18,7 +18,7 @@ drm-y := drm_aperture.o drm_auth.o drm_cache.o \
>> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
>> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
>> drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
>> -drm_managed.o drm_vblank_work.o
>> +drm_managed.o drm_vblank_work.o drm_buddy.o
>>
>> drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
>> drm_dma.o \
>> drm_legacy_misc.o drm_lock.o drm_memory.o
>> drm_scatter.o \
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> new file mode 100644
>> index ..39eb1d224bec
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -0,0 +1,521 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2021 Intel Corporation
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +static struct kmem_cache *slab_blocks;
>> +
>> +static struct drm_buddy_block *drm_block_alloc(struct drm_buddy_mm *mm,
>> + struct drm_buddy_block *parent,
>> + unsigned int order,
>> + u64 offset)
>> +{
>> +struct drm_buddy_block *block;
>> +
>> +BUG_ON(order > DRM_BUDDY_MAX_ORDER);
>> +
>> +block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
>> +if (!block)
>> +return NULL;
>> +
>> +block->header = offset;
>> +block->header |= order;
>> +block->parent = parent;
>> +
>> +BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
>> +return block;
>> +}
>> +
>> +static void drm_block_free(struct drm_buddy_mm *mm,
>> + struct drm_buddy_block *block)
>> +{
>> +kmem_cache_free(slab_blocks, block);
>> +}
>> +
>> +static void mark_allocated(struct drm_buddy_block *block)
>> +{
>> +block->header &= ~DRM_BUDDY_HEADER_STATE;
>> +block->header |= DRM_BUDDY_ALLOCATED;
>> +
>> +list_del(>link);
>> +}
>> +
>> +static void mark_free(struct drm_buddy_mm *mm,
>> + struct drm_buddy_block *block)
>> +{
>> +block->header &= ~DRM_BUDDY_HEADER_STATE;
>> +block->header |= DRM_BUDDY_FREE;
>>
Re: [PATCH] gpu: drm: panel-edp: Fix edp_panel_entry documentation
Hi,
On Wed, Nov 17, 2021 at 8:32 AM Kieran Bingham
wrote:
>
> The edp_panel_entry members 'delay' and 'name' are documented, but
> without the correct syntax for kernel doc.
>
> This generates the following warnings:
>
> drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
> 'delay' not described in 'edp_panel_entry'
> drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
> 'name' not described in 'edp_panel_entry'
>
> Fix them accordingly.
>
> Fixes: 5540cf8f3e8d ("drm/panel-edp: Implement generic "edp-panel"s probed by
> EDID")
> Signed-off-by: Kieran Bingham
> ---
> drivers/gpu/drm/panel/panel-edp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks! Pushed to drm-misc-next (though technically it's a fix, it
didn't seem urgent enough to go through -fixes. Hopefully this is OK).
1e66f04c14ab gpu: drm: panel-edp: Fix edp_panel_entry documentation
-Doug
Re: [PATCH 02/10] drm: Add privacy-screen class (v4)
Hi Rajat, On 11/17/21 15:28, Rajat Jain wrote: > +Heikki Krogerus > > Hello Hans, Heikki, > > I have a question below, which isn't really a problem, but more of an > attempt to understand the current code and its limitations. > > On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote: >> >> On some new laptops the LCD panel has a builtin electronic privacy-screen. >> We want to export this functionality as a property on the drm connector >> object. But often this functionality is not exposed on the GPU but on some >> other (ACPI) device. >> >> This commit adds a privacy-screen class allowing the driver for these >> other devices to register themselves as a privacy-screen provider; and >> allowing the drm/kms code to get a privacy-screen provider associated >> with a specific GPU/connector combo. >> >> Changes in v2: >> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy >> code gets built as part of the main drm module rather then making it >> a tristate which builds its own module. >> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to >> drm_privacy_screen_consumer.h and define stubs when the check fails. >> Together these 2 changes fix several dependency issues. >> - Remove module related code now that this is part of the main drm.ko >> - Use drm_class as class for the privacy-screen devices instead of >> adding a separate class for this >> >> Changes in v3: >> - Make the static inline drm_privacy_screen_get_state() stub set sw_state >> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized >> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set >> >> Changes in v4: >> - Make drm_privacy_screen_set_sw_state() skip calling out to the hw if >> hw_state == new_sw_state >> >> Reviewed-by: Emil Velikov >> Reviewed-by: Lyude Paul >> Signed-off-by: Hans de Goede >> --- >> Documentation/gpu/drm-kms-helpers.rst | 15 + >> MAINTAINERS | 8 + >> drivers/gpu/drm/Kconfig | 4 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/drm_drv.c | 4 + >> drivers/gpu/drm/drm_privacy_screen.c | 403 ++ >> include/drm/drm_privacy_screen_consumer.h | 50 +++ >> include/drm/drm_privacy_screen_driver.h | 80 + >> include/drm/drm_privacy_screen_machine.h | 41 +++ >> 9 files changed, 606 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_privacy_screen.c >> create mode 100644 include/drm/drm_privacy_screen_consumer.h >> create mode 100644 include/drm/drm_privacy_screen_driver.h >> create mode 100644 include/drm/drm_privacy_screen_machine.h >> >> diff --git a/Documentation/gpu/drm-kms-helpers.rst >> b/Documentation/gpu/drm-kms-helpers.rst >> index ec2f65b31930..5bb55ec1b9b5 100644 >> --- a/Documentation/gpu/drm-kms-helpers.rst >> +++ b/Documentation/gpu/drm-kms-helpers.rst >> @@ -435,3 +435,18 @@ Legacy CRTC/Modeset Helper Functions Reference >> >> .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c >> :export: >> + >> +Privacy-screen class >> + >> + >> +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c >> + :doc: overview >> + >> +.. kernel-doc:: include/drm/drm_privacy_screen_driver.h >> + :internal: >> + >> +.. kernel-doc:: include/drm/drm_privacy_screen_machine.h >> + :internal: >> + >> +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c >> + :export: >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 28e5f0ae1009..cb94bb3b8724 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -6423,6 +6423,14 @@ F: drivers/gpu/drm/drm_panel.c >> F: drivers/gpu/drm/panel/ >> F: include/drm/drm_panel.h >> >> +DRM PRIVACY-SCREEN CLASS >> +M: Hans de Goede >> +L: dri-devel@lists.freedesktop.org >> +S: Maintained >> +T: git git://anongit.freedesktop.org/drm/drm-misc >> +F: drivers/gpu/drm/drm_privacy_screen* >> +F: include/drm/drm_privacy_screen* >> + >> DRM TTM SUBSYSTEM >> M: Christian Koenig >> M: Huang Rui >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 2a926d0de423..c686c08447ac 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS >> config DRM_LIB_RANDOM >> bool >> default n >> + >> +config DRM_PRIVACY_SCREEN >> + bool >> + default n >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 0dff40bb863c..788fc37096f6 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o >> drm-$(CONFIG_PCI) += drm_pci.o >> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o >> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o >> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o >> >> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o >> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c >> index
[Bug 214859] drm-amdgpu-init-iommu~fd-device-init.patch introduce bug
https://bugzilla.kernel.org/show_bug.cgi?id=214859 spassw...@web.de changed: What|Removed |Added CC||spassw...@web.de --- Comment #8 from spassw...@web.de --- *** Bug 214901 has been marked as a duplicate of this bug. *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214901] amdgpu freezes HP laptop at start up
https://bugzilla.kernel.org/show_bug.cgi?id=214901 spassw...@web.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from spassw...@web.de --- *** This bug has been marked as a duplicate of bug 214859 *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214921] amdgpu hangs HP Laptop on shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=214921 spassw...@web.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: Backlight control broken on UM325 (OLED) on 5.15 (bisected)
Hi Roman,
On 17.11.2021 15:26, Li, Roman wrote:
> [Public]
>
> Hi Samuel,
>
> Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Yup, that did the trick. Works as before. Thank you very much.
Samuel
>
> Thanks,
> Roman
>
> > -Original Message-
> > From: Samuel Čavoj
> > Sent: Tuesday, November 16, 2021 8:33 AM
> > To: Alex Deucher
> > Cc: Deucher, Alexander ; Li, Sun peng (Leo)
> > ; Li, Roman ; Maling list - DRI
> > developers ; LKML > ker...@vger.kernel.org>; amd-gfx list
> > Subject: Re: Backlight control broken on UM325 (OLED) on 5.15 (bisected)
> >
> > Hi Alex,
> >
> > thank you for your response.
> >
> > On 15.11.2021 10:43, Alex Deucher wrote:
> > > [...]
> > >
> > > That patch adds support for systems with multiple backlights. Do you
> > > have multiple backlight devices now? If so, does the other one work?
> >
> > No, there is still only one backlight device -- amdgpu_bl0.
> > >
> > > Can you also try this patch?
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > index 4811b0faafd9..67163c9d49e6 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > > @@ -854,8 +854,8 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
> > > if (amdgpu_device_has_dc_support(adev)) { #if
> > > defined(CONFIG_DRM_AMD_DC)
> > > struct amdgpu_display_manager *dm = >dm;
> > > - if (dm->backlight_dev[0])
> > > - atif->bd = dm->backlight_dev[0];
> > > + if (dm->backlight_dev[1])
> > > + atif->bd = dm->backlight_dev[1];
> > > #endif
> > > } else {
> > > struct drm_encoder *tmp;
> > >
> >
> > There is no difference in behaviour after applying the patch.
> >
> > Samuel
> >
> > >
> > > Alex
> > >
> > > >
> > > > Regards,
> > > > Samuel Čavoj
> > > >
> > > > [0]:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > >
> > w.reddit.com%2Fr%2FAMDLaptops%2Fcomments%2Fqst0fm%2Fafter_updating
> > _t
> > > >
> > o_linux_515_my_brightness%2Fdata=04%7C01%7CRoman.Li%40amd.co
> > m%7
> > > >
> > Ce1c766a2f7014cdb664308d9a9059cc6%7C3dd8961fe4884e608e11a82d994e1
> > 83d
> > > >
> > %7C0%7C0%7C637726663861883494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLj
> > > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000s
> > dat
> > > >
> > a=hfsaEzng9%2FjAI2F%2BKg87Tv2Mu%2FfPurCQELr62%2B%2FVF%2BQ%3D
> > mp;res
> > > > erved=0
Re: [PATCH 03/10] drm/privacy-screen: Add X86 specific arch init code
Hi Rajat,
On 11/17/21 15:13, Rajat Jain wrote:
> Hello Hans,
>
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote:
>>
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
>> controlling the privacy-screen.
>>
>> This initial version only checks for the Lenovo Thinkpad specific ACPI
>> methods for privacy-screen control.
>>
>> Reviewed-by: Emil Velikov
>> Reviewed-by: Lyude Paul
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/drm_privacy_screen_x86.c | 86
>> include/drm/drm_privacy_screen_machine.h | 5 ++
>> 3 files changed, 92 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 788fc37096f6..12997ca5670d 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>> drm-$(CONFIG_PCI) += drm_pci.o
>> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>> drm_privacy_screen_x86.o
>>
>> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
>> b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> new file mode 100644
>> index ..a2cafb294ca6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> @@ -0,0 +1,86 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright (C) 2020 Red Hat, Inc.
>> + *
>> + * Authors:
>> + * Hans de Goede
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#ifdef CONFIG_X86
>> +static struct drm_privacy_screen_lookup arch_lookup;
>> +
>> +struct arch_init_data {
>> + struct drm_privacy_screen_lookup lookup;
>> + bool (*detect)(void);
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
>> + void *context, void **return_value)
>> +{
>> + *(acpi_handle *)return_value = handle;
>> + return AE_CTRL_TERMINATE;
>> +}
>> +
>> +static bool __init detect_thinkpad_privacy_screen(void)
>> +{
>> + union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
>> + struct acpi_object_list args = { .count = 1, .pointer = , };
>> + acpi_handle ec_handle = NULL;
>> + unsigned long long output;
>> + acpi_status status;
>> +
>> + /* Get embedded-controller handle */
>> + status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL,
>> _handle);
>> + if (ACPI_FAILURE(status) || !ec_handle)
>> + return false;
>> +
>> + /* And call the privacy-screen get-status method */
>> + status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", ,
>> );
>> + if (ACPI_FAILURE(status))
>> + return false;
>> +
>> + return (output & 0x1) ? true : false;
>> +}
>> +#endif
>> +
>> +static const struct arch_init_data arch_init_data[] __initconst = {
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> + {
>> + .lookup = {
>> + .dev_id = NULL,
>> + .con_id = NULL,
>> + .provider = "privacy_screen-thinkpad_acpi",
>> + },
>> + .detect = detect_thinkpad_privacy_screen,
>> + },
>> +#endif
>> +};
>
> As I'm trying to add privacy-screen support for my platform, I'm
> trying to understand if my platform needs to make an entry in this
> static list.
>
> Do I understand it right that the reason you needed this static list
> (and this whole file really), instead of just doing a
> drm_privacy_screen_lookup_add() in the platform code in
> thinkpad_acpi.c, was because that code was executed AFTER the
> drm_connectors had already initialized>
> In other words, the privacy-screen providers (platform code) need to
> register a privacy-screen and a lookup structure, BEFORE the drm
> connectors are initialized. If the platform code that provides a
> privacy-screen is executed AFTER the drm-connector initializes, then
> we need an entry in this static list, so that the drm probe (for i915
> atleast) is DEFERRED until the privacy-screen provider registers the
> privacy-screen?
>
> OTOH, if the platform can register a privacy-screen and a lookup
> function (via drm_privacy_screen_lookup_add()) BEFORE drm probe, then
> I do not need an entry in this static list.
>
> Is this correct understanding?
Yes, this is all here to deal with probe-ordering.
On a platform where the link between connectors and device-tree
is available in something like devicetree this all becomes
much easier.
The i915 code does a:
privacy_screen = drm_privacy_screen_get(>dev, NULL);
[PATCH] gpu: drm: panel-edp: Fix edp_panel_entry documentation
The edp_panel_entry members 'delay' and 'name' are documented, but
without the correct syntax for kernel doc.
This generates the following warnings:
drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
'delay' not described in 'edp_panel_entry'
drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
'name' not described in 'edp_panel_entry'
Fix them accordingly.
Fixes: 5540cf8f3e8d ("drm/panel-edp: Implement generic "edp-panel"s probed by
EDID")
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/panel/panel-edp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index fc03046de134..176ef0c3cc1d 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -196,10 +196,10 @@ struct edp_panel_entry {
/** @panel_id: 32-bit ID for panel, encoded with
drm_edid_encode_panel_id(). */
u32 panel_id;
- /* @delay: The power sequencing delays needed for this panel. */
+ /** @delay: The power sequencing delays needed for this panel. */
const struct panel_delay *delay;
- /* @name: Name of this panel (for printing to logs). */
+ /** @name: Name of this panel (for printing to logs). */
const char *name;
};
--
2.30.2
Re: [PATCH 10/10] drm/i915: Add privacy-screen support (v3)
Hi Rajat,
On 11/17/21 14:59, Rajat Jain wrote:
> Hello Hans,
>
> I'm working on my platform's privacy-screen support based on your
> patches, and had some (I know late) questions. Would be great if you
> could please help answer. Please see inline.
>
> On Tue, Oct 5, 2021 at 1:25 PM Hans de Goede wrote:
>>
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> Changes in v3:
>> - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
>>
>> Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
>> for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
>> - Move the probe-deferral check to the intel_modeset_probe_defer() helper
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
>> drivers/gpu/drm/i915/display/intel_ddi.c | 16
>> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
>> 3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
>> b/drivers/gpu/drm/i915/display/intel_atomic.c
>> index b4e7ac51aa31..a62550711e98 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
>> @@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct
>> drm_connector *conn,
>> new_conn_state->base.picture_aspect_ratio !=
>> old_conn_state->base.picture_aspect_ratio ||
>> new_conn_state->base.content_type !=
>> old_conn_state->base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode ||
>> + new_conn_state->base.privacy_screen_sw_state !=
>> old_conn_state->base.privacy_screen_sw_state ||
>> !drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
>> crtc_state->mode_changed = true;
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index 0d4cf7fa8720..272714e07cc6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -25,6 +25,7 @@
>> *
>> */
>>
>> +#include
>> #include
>>
>> #include "i915_drv.h"
>> @@ -2946,6 +2947,7 @@ static void intel_enable_ddi_dp(struct
>> intel_atomic_state *state,
>> if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
>> intel_dp_stop_link_train(intel_dp, crtc_state);
>>
>> + drm_connector_update_privacy_screen(conn_state);
>> intel_edp_backlight_on(crtc_state, conn_state);
>>
>> if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
>> @@ -3161,6 +3163,7 @@ static void intel_ddi_update_pipe_dp(struct
>> intel_atomic_state *state,
>> intel_drrs_update(intel_dp, crtc_state);
>>
>> intel_backlight_update(state, encoder, crtc_state, conn_state);
>> + drm_connector_update_privacy_screen(conn_state);
>> }
>>
>> void intel_ddi_update_pipe(struct intel_atomic_state *state,
>> @@ -3979,6 +3982,19 @@ intel_ddi_init_dp_connector(struct intel_digital_port
>> *dig_port)
>> return NULL;
>> }
>>
>> + if (dig_port->base.type == INTEL_OUTPUT_EDP) {
>> + struct drm_device *dev = dig_port->base.base.dev;
>> + struct drm_privacy_screen *privacy_screen;
>> +
>> + privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
>
> Why pass NULL for con_id? Can we pass something more meaningful (e.g.
> "eDP-1") so that the non-KMS platform components that provide the
> privacy-screen can provide a more specific lookup? Or is that
> information (connector name) not available at the time this call is
> being made?
For the x86 ACPI case it does not matter because the static lookups
added by drivers/gpu/drm/drm_privacy_screen_x86.c do not set
a con_id in the lookup and if the lookup lack a con_id then
the value passed to drm_privacy_screen_get() is a no-op.
So, if it helps you to pass a connector-name then go for it.
As for the connecter_name already being set at this point,
I don't know, you need to check.
But also see below.
>> + if (!IS_ERR(privacy_screen)) {
>> +
>> drm_connector_attach_privacy_screen_provider(>base,
>> +
>> privacy_screen);
>> + } else if (PTR_ERR(privacy_screen) != -ENODEV) {
>> + drm_warn(dev, "Error getting privacy-screen\n");
>> + }
>> + }
>> +
>> return connector;
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 86dbe366a907..84715a779d9d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -42,6 +42,7 @@
>> #include
>> #include
Re: [PATCH 07/12] dt-bindings: display: rockchip: Add binding for VOP2
On Wed, 17 Nov 2021 15:33:42 +0100, Sascha Hauer wrote: > The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566. > The binding differs slightly from the existing VOP binding, so add a new > binding file for it. > > Signed-off-by: Sascha Hauer > --- > .../display/rockchip/rockchip-vop2.yaml | 114 ++ > 1 file changed, 114 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.example.dt.yaml: example-0: vop@fe04:reg:0: [0, 4261675008, 0, 12288] is too long From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.example.dt.yaml: example-0: vop@fe04:reg:1: [0, 4261691392, 0, 4096] is too long From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1556199 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
[PATCH] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 4d4b2a301b1a..9fba790c6af4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -205,6 +205,16 @@ _clkinout
status = "okay";
};
+ {
+ status = "okay";
+ avdd-0v9-supply = <_0v9>;
+ avdd-1v8-supply = <_1v8>;
+};
+
+_in_vp0 {
+ status = "okay";
+};
+
{
status = "okay";
@@ -546,3 +556,17 @@ bluetooth {
{
status = "okay";
};
+
+ {
+ status = "okay";
+ assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
+ assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
+};
+
+_mmu {
+ status = "okay";
+};
+
+_out_hdmi {
+ status = "okay";
+};
--
2.30.2
Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()
On 17/11/2021 23.56, Thomas Zimmermann wrote: Hi Am 17.11.21 um 15:22 schrieb Hector Martin: The dst pointer was being advanced by the clip width, not the full line stride, resulting in corruption. The clip offset was also calculated incorrectly. Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin Thanks for your patch, but you're probably on the wrong branch. We rewrote this code recently and fixed the issue in drm-misc-next. [1][2] Oops. I was on linux-next as of Nov 1. Looks like I missed it by a week! Sounds like I'm going to have to rebase/rewrite the other series I just sent too... -- Hector Martin (mar...@marcan.st) Public Key: https://mrcn.st/pub
RE: Backlight control broken on UM325 (OLED) on 5.15 (bisected)
[Public]
Hi Samuel,
Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Thanks,
Roman
> -Original Message-
> From: Samuel Čavoj
> Sent: Tuesday, November 16, 2021 8:33 AM
> To: Alex Deucher
> Cc: Deucher, Alexander ; Li, Sun peng (Leo)
> ; Li, Roman ; Maling list - DRI
> developers ; LKML ker...@vger.kernel.org>; amd-gfx list
> Subject: Re: Backlight control broken on UM325 (OLED) on 5.15 (bisected)
>
> Hi Alex,
>
> thank you for your response.
>
> On 15.11.2021 10:43, Alex Deucher wrote:
> > [...]
> >
> > That patch adds support for systems with multiple backlights. Do you
> > have multiple backlight devices now? If so, does the other one work?
>
> No, there is still only one backlight device -- amdgpu_bl0.
> >
> > Can you also try this patch?
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 4811b0faafd9..67163c9d49e6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -854,8 +854,8 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
> > if (amdgpu_device_has_dc_support(adev)) { #if
> > defined(CONFIG_DRM_AMD_DC)
> > struct amdgpu_display_manager *dm = >dm;
> > - if (dm->backlight_dev[0])
> > - atif->bd = dm->backlight_dev[0];
> > + if (dm->backlight_dev[1])
> > + atif->bd = dm->backlight_dev[1];
> > #endif
> > } else {
> > struct drm_encoder *tmp;
> >
>
> There is no difference in behaviour after applying the patch.
>
> Samuel
>
> >
> > Alex
> >
> > >
> > > Regards,
> > > Samuel Čavoj
> > >
> > > [0]:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >
> w.reddit.com%2Fr%2FAMDLaptops%2Fcomments%2Fqst0fm%2Fafter_updating
> _t
> > >
> o_linux_515_my_brightness%2Fdata=04%7C01%7CRoman.Li%40amd.co
> m%7
> > >
> Ce1c766a2f7014cdb664308d9a9059cc6%7C3dd8961fe4884e608e11a82d994e1
> 83d
> > >
> %7C0%7C0%7C637726663861883494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLj
> > >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000s
> dat
> > >
> a=hfsaEzng9%2FjAI2F%2BKg87Tv2Mu%2FfPurCQELr62%2B%2FVF%2BQ%3D
> mp;res
> > > erved=0
Re: [PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
Hi Sascha,
On 11/17/21 3:33 PM, Sascha Hauer wrote:
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 184e2aa2416af..156e001492173 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -106,6 +106,12 @@ _rgmii_clk
status = "okay";
};
+ {
+ status = "okay";
+ avdd-0v9-supply = <_image>;
+ avdd-1v8-supply = <_image>;
+};
+
{
status = "okay";
@@ -390,3 +396,21 @@ {
{
status = "okay";
};
+
+ {
+ status = "okay";
+ assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
+ assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
+};
+
+_mmu {
+ status = "okay";
+};
+
+_in_vp0 {
+ status = "okay";
+};
Minor nitpick: This should probably be sorted alphabetically.
Best regards,
Michael
+
+_out_hdmi {
+ status = "okay";
+};
Re: [PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> This enabled the VOP2 display controller along with hdmi and the
> required port routes which is enough to get a picture out of the
> hdmi port of the board.
>
> Signed-off-by: Sascha Hauer
> ---
> .../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> index 184e2aa2416af..156e001492173 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> @@ -106,6 +106,12 @@ _rgmii_clk
> status = "okay";
> };
>
> + {
> + status = "okay";
> + avdd-0v9-supply = <_image>;
> + avdd-1v8-supply = <_image>;
> +};
> +
> {
> status = "okay";
>
> @@ -390,3 +396,21 @@ {
> {
> status = "okay";
> };
> +
> + {
> + status = "okay";
> + assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
> + assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
> +};
> +
> +_mmu {
> + status = "okay";
> +};
> +
> +_in_vp0 {
> + status = "okay";
> +};
> +
> +_out_hdmi {
> + status = "okay";
> +};
You can accomplish the same thing already with:
_out_hdmi {
remote-endpoint = <_in_vp0>;
};
or:
_out_hdmi {
/delete-property/ remote-endpoint;
};
Re: [PATCH 11/12] drm/rockchip: Make VOP driver optional
Am Mittwoch, 17. November 2021, 15:50:54 CET schrieb Sascha Hauer: > On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote: > > Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer: > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make > > > the VOP driver optional. > > > > > > Signed-off-by: Sascha Hauer > > > --- > > > arch/arm/configs/multi_v7_defconfig | 1 + > > > arch/arm64/configs/defconfig| 1 + > > > drivers/gpu/drm/rockchip/Kconfig| 7 +++ > > > drivers/gpu/drm/rockchip/Makefile | 3 ++- > > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- > > > 5 files changed, 12 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/configs/multi_v7_defconfig > > > b/arch/arm/configs/multi_v7_defconfig > > > index c951aeed2138c..fc123e8f3e2f9 100644 > > > --- a/arch/arm/configs/multi_v7_defconfig > > > +++ b/arch/arm/configs/multi_v7_defconfig > > > @@ -667,6 +667,7 @@ CONFIG_DRM_EXYNOS_DPI=y > > > CONFIG_DRM_EXYNOS_DSI=y > > > CONFIG_DRM_EXYNOS_HDMI=y > > > CONFIG_DRM_ROCKCHIP=m > > > +CONFIG_ROCKCHIP_VOP=y > > > CONFIG_ROCKCHIP_ANALOGIX_DP=y > > > CONFIG_ROCKCHIP_DW_HDMI=y > > > CONFIG_ROCKCHIP_DW_MIPI_DSI=y > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > > > index f2e2b9bdd7024..a623386473dc9 100644 > > > --- a/arch/arm64/configs/defconfig > > > +++ b/arch/arm64/configs/defconfig > > > @@ -682,6 +682,7 @@ CONFIG_DRM_EXYNOS_DSI=y > > > CONFIG_DRM_EXYNOS_HDMI=y > > > CONFIG_DRM_EXYNOS_MIC=y > > > CONFIG_DRM_ROCKCHIP=m > > > +CONFIG_ROCKCHIP_VOP=y > > > CONFIG_ROCKCHIP_ANALOGIX_DP=y > > > CONFIG_ROCKCHIP_CDN_DP=y > > > CONFIG_ROCKCHIP_DW_HDMI=y > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig > > > b/drivers/gpu/drm/rockchip/Kconfig > > > index 9f1ecefc39332..a1c4158259099 100644 > > > --- a/drivers/gpu/drm/rockchip/Kconfig > > > +++ b/drivers/gpu/drm/rockchip/Kconfig > > > @@ -21,8 +21,15 @@ config DRM_ROCKCHIP > > > > > > if DRM_ROCKCHIP > > > > > > +config ROCKCHIP_VOP > > > + bool "Rockchip VOP driver" > > > > would this benefit from a default-y ? > > For builds reusing preexisting .configs. > > I enabled CONFIG_ROCKCHIP_VOP for all configs in the tree that enable > CONFIG_DRM_ROCKCHIP, so defconfig users shouldn't see any surprises. > That won't help users of custom configs of course. > > I don't know what's preferred in such cases, I can change to default-y > if you like. default-y would keep the behaviour identical for all existing configs I guess and right now vop(1) is still the most used variant and will stay that way for a while longer, so I guess my preference would be for going that route - also so that we don't drown in "my display stopped working" during 5.17 ;-) Heiko
Re: [PATCH 09/12] arm64: dts: rockchip: rk356x: Add HDMI nodes
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> index 6ebf7c14e096a..53be61a7ce595 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> @@ -472,18 +472,36 @@ vp0: port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> +
> + vp0_out_hdmi: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_in_vp0>;
> + status = "disabled";
> + };
> };
>
> vp1: port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> +
> + vp1_out_hdmi: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_in_vp1>;
> + status = "disabled";
> + };
> };
>
> vp2: port@2 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2>;
> +
> + vp2_out_hdmi: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_in_vp2>;
> + status = "disabled";
> + };
> };
> };
> };
> @@ -499,6 +517,53 @@ vop_mmu: iommu@fe043e00 {
> status = "disabled";
> };
>
> + hdmi: hdmi@fe0a {
> + compatible = "rockchip,rk3568-dw-hdmi";
> + reg = <0x0 0xfe0a 0x0 0x2>;
> + interrupts = ;
> + clocks = < PCLK_HDMI_HOST>,
> +< CLK_HDMI_SFR>,
> +< CLK_HDMI_CEC>,
> +< HCLK_VOP>;
> + clock-names = "iahb", "isfr", "cec", "hclk";
> + power-domains = < RK3568_PD_VO>;
> + reg-io-width = <4>;
> + rockchip,grf = <>;
> + #sound-dai-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_scl _sda _cec>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hdmi_in: port@0 {
The schema says there is only 1 'port' node. Please run schema
validation when making DT changes.
However, an HDMI bridge should also define an output port to a
connector node (or another bridge). So the fix is to allow 'port@0'
and add an output port.
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hdmi_in_vp0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_out_hdmi>;
> + status = "disabled";
> + };
> +
> + hdmi_in_vp1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_out_hdmi>;
> + status = "disabled";
> + };
> +
> + hdmi_in_vp2: endpoint@2 {
> + reg = <2>;
> + remote-endpoint = <_out_hdmi>;
> + status = "disabled";
> + };
> + };
> + };
> + };
> +
> qos_gpu: qos@fe128000 {
> compatible = "rockchip,rk3568-qos", "syscon";
> reg = <0x0 0xfe128000 0x0 0x20>;
> --
> 2.30.2
>
[PATCH 3/3] drm/simpledrm: Enable XRGB2101010 format
This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2c84f2ea1fa2..b4b69f3a7e79 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,7 +571,7 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
- //DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XRGB2101010,
//DRM_FORMAT_ARGB2101010,
};
--
2.33.0
[PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 64 +
include/drm/drm_format_helper.h | 4 ++
2 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 69fde60e36b3..5998e57d6ff2 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -378,6 +378,60 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
unsigned int dst_pitch
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, u32 *sbuf,
+ unsigned int pixels)
+{
+ unsigned int x;
+
+ for (x = 0; x < pixels; x++) {
+ *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_dstclip - Convert XRGB to XRGB2101010
clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: destination buffer pitch
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ *
+ * This function applies clipping on dst, i.e. the destination is a
+ * full (iomem) framebuffer but only the clip rect content is copied over.
+ */
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+ unsigned int dst_pitch, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_rect *clip)
+{
+ size_t linepixels = clip->x2 - clip->x1;
+ size_t dst_len = linepixels * 4;
+ unsigned int y, lines = clip->y2 - clip->y1;
+ void *dbuf;
+
+ dbuf = kmalloc(dst_len, GFP_KERNEL);
+ if (!dbuf)
+ return;
+
+ vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+ dst += clip_offset(clip, dst_pitch, sizeof(u32));
+ for (y = 0; y < lines; y++) {
+ drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+ memcpy_toio(dst, dbuf, dst_len);
+ vaddr += fb->pitches[0];
+ dst += dst_pitch;
+ }
+
+ kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_dstclip);
+
/**
* drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
* @dst: 8-bit grayscale destination buffer
@@ -464,6 +518,10 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned
int dst_pitch,
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+ if (fb_format == DRM_FORMAT_ARGB2101010)
+ fb_format = DRM_FORMAT_XRGB2101010;
+ if (dst_format == DRM_FORMAT_ARGB2101010)
+ dst_format = DRM_FORMAT_XRGB2101010;
if (dst_format == fb_format) {
drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
@@ -482,6 +540,12 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned
int dst_pitch,
vmap, fb, clip);
return 0;
}
+ } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+ if (fb_format == DRM_FORMAT_XRGB) {
+ drm_fb_xrgb_to_xrgb2101010_dstclip(dst, dst_pitch,
+ vmap, fb, clip);
+ return 0;
+ }
}
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index e86925cf07b9..a0faa710878b 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -29,6 +29,10 @@ void drm_fb_xrgb_to_rgb888(void *dst, void *src, struct
drm_framebuffer *fb,
void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, unsigned int
dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+ unsigned int dst_pitch, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_rect *clip);
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
--
2.33.0
[PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen
This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 481b48bde047..2c84f2ea1fa2 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
#include
@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
module_platform_driver(simpledrm_platform_driver);
+static int __init simpledrm_init(void)
+{
+ struct device_node *np;
+
+ if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
+ for_each_child_of_node(of_chosen, np) {
+ if (of_device_is_compatible(np, "simple-framebuffer"))
+ of_platform_device_create(np, NULL, NULL);
+ }
+ }
+
+ return 0;
+}
+
+fs_initcall(simpledrm_init);
+
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL v2");
--
2.33.0
[PATCH 0/3] drm/simpledrm: Apple M1 / DT platform support fixes
Hi DRM folks, This short series makes simpledrm work on Apple M1 (including Pro/Max) platforms the way simplefb already does, by adding XRGB2101010 support and making it bind to framebuffers in /chosen the same way simplefb does. This avoids breaking the bootloader-provided framebuffer console when simpledrm is selected to replace simplefb, as these FBs always seem to be 10-bit (at least when a real screen is attached). Hector Martin (3): drm/simpledrm: Bind to OF framebuffers in /chosen drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_dstclip() drm/simpledrm: Enable XRGB2101010 format drivers/gpu/drm/drm_format_helper.c | 64 + drivers/gpu/drm/tiny/simpledrm.c| 19 - include/drm/drm_format_helper.h | 4 ++ 3 files changed, 86 insertions(+), 1 deletion(-) -- 2.33.0
Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
Thanks for your patch, but you're probably on the wrong branch. We
rewrote this code recently and fixed the issue in drm-misc-next. [1][2]
If anything, this patch could go into stable. If anyone wants to merge
it there, then
Acked-by: Thomas Zimmermann
Best regards
Thomas
[1]
https://lore.kernel.org/dri-devel/2020103702.374-5-tzimmerm...@suse.de/
[2]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=53bc2098d2b6ccff25fe13f9345cbb5c0ef34a99
---
drivers/gpu/drm/drm_format_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index e676921422b8..12bc6b45e95b 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -366,12 +366,12 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
unsigned int dst_pitch
return;
vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
- dst += clip_offset(clip, dst_pitch, sizeof(u16));
+ dst += clip_offset(clip, dst_pitch, 3);
for (y = 0; y < lines; y++) {
drm_fb_xrgb_to_rgb888_line(dbuf, vaddr, linepixels);
memcpy_toio(dst, dbuf, dst_len);
vaddr += fb->pitches[0];
- dst += dst_len;
+ dst += dst_pitch;
}
kfree(dbuf);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote: > > This series adds initial graphics support for the Rockchip RK356[68] > SoCs. Graphics support is based around the VOP2 controller which > replaces the VOP controller found on earlier Rockchip SoCs. The driver > has been tested with HDMI support included in this series and MIPI-DSI > which is not included because it needs some more work. The driver is > taken from the downstream Rockchip kernel and heavily polished, most non > standard features have been removed for now. I tested the driver with > the libdrm modetest utility and also with weston with both pixman and > panfrost driver support. Michael Riesch reported the driver to work on > the RK3566 as well, but device tree support for this SoC is not yet > included in this series. Can you outline what exactly you want to disable? I don't think 'status' is the right way. I think between the parent device being disabled, an incomplete graph and user configuration choice that should be enough to disable parts. Rob
[PATCH 3/5] drm/vc4: Remove conflicting framebuffers before callind bind_all
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 16abc3a3d601..8ab89f805826 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -251,6 +251,10 @@ static int vc4_drm_bind(struct device *dev) if (ret) return ret; + ret = drm_aperture_remove_framebuffers(false, _drm_driver); + if (ret) + return ret; + ret = component_bind_all(dev, drm); if (ret) return ret; @@ -259,10 +263,6 @@ static int vc4_drm_bind(struct device *dev) if (ret) goto unbind_all; - ret = drm_aperture_remove_framebuffers(false, _drm_driver); - if (ret) - goto unbind_all; - ret = vc4_kms_load(drm); if (ret < 0) goto unbind_all; -- 2.33.1
[PATCH 5/5] ARM: dts: rpi: Add the firmware node to vc4
Add the firmware phandle to the vc4 node so that we can send it the
message that we're done with the firmware display.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 87ddcad76083..bc5dc51ba579 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -67,6 +67,10 @@ {
power-domains = < RPI_POWER_DOMAIN_USB>;
};
+ {
+ raspberrypi,firmware = <>;
+};
+
{
power-domains = < RPI_POWER_DOMAIN_VEC>;
status = "okay";
--
2.33.1
[PATCH 4/5] drm/vc4: Notify the firmware when DRM is in charge
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 19 +++
drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8ab89f805826..d09fa9c130da 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -37,6 +37,8 @@
#include
#include
+#include
+
#include "uapi/drm/vc4_drm.h"
#include "vc4_drv.h"
@@ -251,10 +253,27 @@ static int vc4_drm_bind(struct device *dev)
if (ret)
return ret;
+ node = of_parse_phandle(dev->of_node, "raspberrypi,firmware", 0);
+ if (node) {
+ vc4->firmware = rpi_firmware_get(node);
+ of_node_put(node);
+
+ if (!vc4->firmware)
+ return -EPROBE_DEFER;
+ }
+
ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret)
return ret;
+ if (vc4->firmware) {
+ ret = rpi_firmware_property(vc4->firmware,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE,
+ NULL, 0);
+ if (ret)
+ drm_warn(drm, "Couldn't stop firmware display driver:
%d\n", ret);
+ }
+
ret = component_bind_all(dev, drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4329e09d357c..b840654c53a9 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -76,6 +76,8 @@ struct vc4_dev {
unsigned int irq;
+ struct rpi_firmware *firmware;
+
struct vc4_hvs *hvs;
struct vc4_v3d *v3d;
struct vc4_dpi *dpi;
--
2.33.1
[PATCH 2/5] firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
b/include/soc/bcm2835/raspberrypi-firmware.h
index 73ad784fca96..811ea668c4a1 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -91,6 +91,7 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_POE_HAT_VAL =0x00030049,
RPI_FIRMWARE_SET_POE_HAT_VAL =0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
+ RPI_FIRMWARE_NOTIFY_DISPLAY_DONE =0x00030066,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.33.1
[PATCH 1/5] dt-bindings: display: vc4: Add optional phandle to firmware
The firmware can free all the resources it was using to run the display engine that won't be needed once the kernel has taken over. Thus, we need a phandle to the firmware DT node to be able to send that message when relevant. Signed-off-by: Maxime Ripard --- .../devicetree/bindings/display/brcm,bcm2835-vc4.yaml| 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml index 49a5e041aa49..18de6912b833 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml @@ -21,6 +21,11 @@ properties: - brcm,bcm2835-vc4 - brcm,cygnus-vc4 + raspberrypi,firmware: +$ref: "/schemas/types.yaml#/definitions/phandle" +description: > + Phandle to the firmware node + required: - compatible -- 2.33.1
[PATCH 0/5] drm/vc4: Use the firmware to stop the display pipeline
Hi, The VC4 driver has had limited support to disable the HDMI controllers and pixelvalves at boot if the firmware has enabled them. However, this proved to be limited, and a bit unreliable so a new firmware command has been introduced some time ago to make it free all its resources and disable any display output it might have enabled. This series takes advantage of that command to call it once the transition from simplefb to the KMS driver has been done. Let me know what you think, Maxime Maxime Ripard (5): dt-bindings: display: vc4: Add optional phandle to firmware firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE drm/vc4: Remove conflicting framebuffers before callind bind_all drm/vc4: Notify the firmware when DRM is in charge ARM: dts: rpi: Add the firmware node to vc4 .../bindings/display/brcm,bcm2835-vc4.yaml| 5 arch/arm/boot/dts/bcm2835-rpi.dtsi| 4 +++ drivers/gpu/drm/vc4/vc4_drv.c | 27 --- drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ include/soc/bcm2835/raspberrypi-firmware.h| 1 + 5 files changed, 35 insertions(+), 4 deletions(-) -- 2.33.1
Re: [PATCH 11/12] drm/rockchip: Make VOP driver optional
Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer: > With upcoming VOP2 support VOP won't be the only choice anymore, so make > the VOP driver optional. > > Signed-off-by: Sascha Hauer > --- > arch/arm/configs/multi_v7_defconfig | 1 + > arch/arm64/configs/defconfig| 1 + > drivers/gpu/drm/rockchip/Kconfig| 7 +++ > drivers/gpu/drm/rockchip/Makefile | 3 ++- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- > 5 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index c951aeed2138c..fc123e8f3e2f9 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -667,6 +667,7 @@ CONFIG_DRM_EXYNOS_DPI=y > CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_DRM_ROCKCHIP=m > +CONFIG_ROCKCHIP_VOP=y > CONFIG_ROCKCHIP_ANALOGIX_DP=y > CONFIG_ROCKCHIP_DW_HDMI=y > CONFIG_ROCKCHIP_DW_MIPI_DSI=y > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index f2e2b9bdd7024..a623386473dc9 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -682,6 +682,7 @@ CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_DRM_EXYNOS_MIC=y > CONFIG_DRM_ROCKCHIP=m > +CONFIG_ROCKCHIP_VOP=y > CONFIG_ROCKCHIP_ANALOGIX_DP=y > CONFIG_ROCKCHIP_CDN_DP=y > CONFIG_ROCKCHIP_DW_HDMI=y > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig > index 9f1ecefc39332..a1c4158259099 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -21,8 +21,15 @@ config DRM_ROCKCHIP > > if DRM_ROCKCHIP > > +config ROCKCHIP_VOP > + bool "Rockchip VOP driver" would this benefit from a default-y ? For builds reusing preexisting .configs. Heiko > + help > + This selects support for the VOP driver. You should enable it > + on all older SoCs up to RK3399. > + > config ROCKCHIP_ANALOGIX_DP > bool "Rockchip specific extensions for Analogix DP driver" > + depends on ROCKCHIP_VOP > help > This selects support for Rockchip SoC specific extensions > for the Analogix Core DP driver. If you want to enable DP > diff --git a/drivers/gpu/drm/rockchip/Makefile > b/drivers/gpu/drm/rockchip/Makefile > index 17a9e7eb2130d..cd6e7bb5ce9c5 100644 > --- a/drivers/gpu/drm/rockchip/Makefile > +++ b/drivers/gpu/drm/rockchip/Makefile > @@ -4,9 +4,10 @@ > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ > - rockchip_drm_gem.o rockchip_drm_vop.o rockchip_vop_reg.o > + rockchip_drm_gem.o > rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o > > +rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o rockchip_vop_reg.o > rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o > rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o > rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index e4ebe60b3cc1a..64fa5fd62c01a 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -473,7 +473,7 @@ static int __init rockchip_drm_init(void) > int ret; > > num_rockchip_sub_drivers = 0; > - ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP); > + ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_ROCKCHIP_VOP); > ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver, > CONFIG_ROCKCHIP_LVDS); > ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver, >
[PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index e676921422b8..12bc6b45e95b 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -366,12 +366,12 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
unsigned int dst_pitch
return;
vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
- dst += clip_offset(clip, dst_pitch, sizeof(u16));
+ dst += clip_offset(clip, dst_pitch, 3);
for (y = 0; y < lines; y++) {
drm_fb_xrgb_to_rgb888_line(dbuf, vaddr, linepixels);
memcpy_toio(dst, dbuf, dst_len);
vaddr += fb->pitches[0];
- dst += dst_len;
+ dst += dst_pitch;
}
kfree(dbuf);
--
2.33.0
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0
Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> * maximum clocks following a vblank miss (see do_rps_boost()).
> */
> if (!state->rps_interactive) {
> - intel_rps_mark_interactive(_priv->gt.rps, true);
> + intel_rps_mark_interactive(_priv->gt0.rps, true);
This should be across all gt, so probably wants a fresh interface that
takes i915 and does for_each_gt in a later patch. (Since we could be
rendering on a remote tile to present on a display.)
> state->rps_interactive = true;
> }
>
> @@ -851,7 +851,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> return;
>
> if (state->rps_interactive) {
> - intel_rps_mark_interactive(_priv->gt.rps, false);
> + intel_rps_mark_interactive(_priv->gt0.rps, false);
> state->rps_interactive = false;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac66717..d4fcd8f236476 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -838,7 +838,7 @@ __intel_display_resume(struct drm_device *dev,
> static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
> {
> return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> - intel_has_gpu_reset(_priv->gt));
> + intel_has_gpu_reset(_priv->gt0));
All these display consumers probably want to use
dev_priv->ggtt->vm.gt, since the scanout capable GGTT would seem to be
the defining feature.
to_scanout_gt(i915) ?
> static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ebd775cb1661c..c62253d0af044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct
> drm_i915_private *i915,
> * colateral damage, and we should not pretend we can by
> * exposing the interface.
> */
> - if (!intel_has_reset_engine(>gt))
> + if (!intel_has_reset_engine(>gt0))
> return -ENODEV;
Prep for all gt. A lot of these need an all-gt interface so we don't
have for_each_gt spread all other the place.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index ef22d4ed66ad6..69ad407eb15f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -166,7 +166,7 @@ static struct dma_fence *i915_ttm_accel_move(struct
> ttm_buffer_object *bo,
> enum i915_cache_level src_level, dst_level;
> int ret;
>
> - if (!i915->gt.migrate.context || intel_gt_is_wedged(>gt))
> + if (!i915->gt0.migrate.context || intel_gt_is_wedged(>gt0))
This should already be looking at lmem->gt
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 8f8bea08e734d..176ea5c7d422f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private
> *i915)
> disabled |= (I915_SCHEDULER_CAP_ENABLED |
> I915_SCHEDULER_CAP_PRIORITY);
>
> - if (intel_uc_uses_guc_submission(>gt.uc))
> + if (intel_uc_uses_guc_submission(>gt0.uc))
This shouldn't be looking at gt at all, but if it must, that information
must be coming via engine->gt. Kind of renders the mapping moot
currently.
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 07ff7ba7b2b71..63089e671a242 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
> return 0;
>
> with_intel_runtime_pm(>runtime_pm, wakeref) {
> - struct intel_ips *ips = >gt.rps.ips;
> + struct intel_ips *ips = >gt0.rps.ips;
Make mchdev_get() return the gt or rps, at the slight cost of making the
drm_dev_put() more complicated (but can be pushed into a mchdev_put for
symmetry).
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a9727447c0379..4bfedc04f5c70 100644
[PATCH v2 6/6] drm/i915: Drain the ttm delayed workqueue too
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8eb6de5cae9..b02694ee6546 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1809,6 +1809,7 @@ static inline void i915_gem_drain_freed_objects(struct
drm_i915_private *i915)
*/
while (atomic_read(>mm.free_count)) {
flush_work(>mm.free_work);
+ flush_delayed_work(>bdev.wq);
rcu_barrier();
}
}
--
2.31.1
