date:20220311

The VOP2 has an interface mux which decides to which encoder(s) a CRTC
is routed to. The encoders and CRTCs are connected via of_graphs in the
device tree. When given an encoder the VOP2 driver needs to know to
which internal register setting this encoder matches. For this the VOP2
binding offers different endpoints, one for each possible encoder. The
endpoint ids of these endpoints are used as a key from an encoders
device tree description to the internal register setting.

This patch adds the key aka endpoint id to struct rockchip_encoder plus
a function to read the endpoint id starting from the encoders device
node.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v6:
- new patch

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 33 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  4 ++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index bec207de45440..7920a4f44f693 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -236,6 +236,39 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
 static struct platform_driver *rockchip_sub_drivers[MAX_ROCKCHIP_SUB_DRIVERS];
 static int num_rockchip_sub_drivers;
 
+/*
+ * Get the endpoint id of the remote endpoint of the given encoder. This
+ * information is used by the VOP2 driver to identify the encoder.
+ *
+ * @rkencoder: The encoder to get the remote endpoint id from
+ * @np: The encoder device node
+ * @port: The number of the port leading to the VOP2
+ * @reg: The endpoint number leading to the VOP2
+ */
+int rockchip_drm_encoder_set_crtc_endpoint_id(struct rockchip_encoder 
*rkencoder,
+ struct device_node *np, int port, 
int reg)
+{
+   struct of_endpoint ep;
+   struct device_node *en, *ren;
+   int ret;
+
+   en = of_graph_get_endpoint_by_regs(np, port, reg);
+   if (!en)
+   return -ENOENT;
+
+   ren = of_graph_get_remote_endpoint(en);
+   if (!ren)
+   return -ENOENT;
+
+   ret = of_graph_parse_endpoint(ren, &ep);
+   if (ret)
+   return ret;
+
+   rkencoder->crtc_endpoint_id = ep.id;
+
+   return 0;
+}
+
 /*
  * Check if a vop endpoint is leading to a rockchip subdriver or bridge.
  * Should be called from the component bind stage of the drivers
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 686f687a76a37..1f66a447acada 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -49,6 +49,7 @@ struct rockchip_drm_private {
 };
 
 struct rockchip_encoder {
+   int crtc_endpoint_id;
struct drm_encoder encoder;
 };
 
@@ -57,7 +58,8 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
 int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
-
+int rockchip_drm_encoder_set_crtc_endpoint_id(struct rockchip_encoder 
*rencoder,
+ struct device_node *np, int port, 
int reg);
 int rockchip_drm_endpoint_is_subdriver(struct device_node *ep);
 extern struct platform_driver cdn_dp_driver;
 extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
-- 
2.30.2

[PATCH v8 10/24] dt-bindings: display: rockchip: dw-hdmi: Add additional clock

The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. It is not needed for the HDMI controller
itself, but to make the SoC internal busses work.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v7:
- rename hclk to niu

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml| 7 ++-
 1 file changed, 6 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 e6b8437a1e2d1..1df61cb420744 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -33,12 +33,13 @@ properties:
 items:
   - {}
   - {}
-  # The next three clocks are all optional, but shall be specified in this
+  # The next four clocks are all optional, but shall be specified in this
   # order when present.
   - description: The HDMI CEC controller main clock
   - description: Power for GRF IO
   - description: External clock for some HDMI PHY (old clock name, 
deprecated)
   - description: External clock for some HDMI PHY (new name)
+  - description: NIU clock, needed on rk356x for SoC internal bus circuitry
 
   clock-names:
 minItems: 2
@@ -50,13 +51,17 @@ properties:
   - grf
   - vpll
   - ref
+  - niu
   - enum:
   - grf
   - vpll
   - ref
+  - niu
   - enum:
   - vpll
   - ref
+  - niu
+  - const: niu
 
   ddc-i2c-bus:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.2

[PATCH v8 03/24] drm/rockchip: dw_hdmi: rename vpll clock to reference clock

"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old device trees.

Signed-off-by: Sascha Hauer 
Reviewed-by: Dmitry Osipenko 
---

Notes:
Changes since v6:
- Simplify by using devm_clk_get_optional() instead of devm_clk_get()

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 27 +++--
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 06c9ddef6f362..912181429880a 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -69,7 +69,7 @@ struct rockchip_hdmi {
struct regmap *regmap;
struct rockchip_encoder encoder;
const struct rockchip_hdmi_chip_data *chip_data;
-   struct clk *vpll_clk;
+   struct clk *ref_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
struct phy *phy;
@@ -201,14 +201,15 @@ 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) {
+   hdmi->ref_clk = devm_clk_get_optional(hdmi->dev, "ref");
+   if (!hdmi->ref_clk)
+   hdmi->ref_clk = devm_clk_get_optional(hdmi->dev, "vpll");
+
+   if (PTR_ERR(hdmi->ref_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);
+   } else if (IS_ERR(hdmi->ref_clk)) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to get reference clock\n");
+   return PTR_ERR(hdmi->ref_clk);
}
 
hdmi->grf_clk = devm_clk_get(hdmi->dev, "grf");
@@ -262,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->ref_clk, adj_mode->clock * 1000);
 }
 
 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
@@ -542,9 +543,9 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   ret = clk_prepare_enable(hdmi->vpll_clk);
+   ret = clk_prepare_enable(hdmi->ref_clk);
if (ret) {
-   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
+   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI reference 
clock: %d\n",
  ret);
return ret;
}
@@ -563,7 +564,7 @@ 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_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->ref_clk);
}
 
return ret;
@@ -575,7 +576,7 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
 
dw_hdmi_unbind(hdmi->hdmi);
-   clk_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->ref_clk);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
-- 
2.30.2

[PATCH v8 04/24] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name

"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
This patch adds "ref" as a new alternative clock name for "vpll"

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

Changes since v3:
- Keep old clock name for compatibility reasons

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml  | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index da3b889ad8fcd..0400f67e5f2c9 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -36,7 +36,8 @@ properties:
   # order when present.
   - description: The HDMI CEC controller main clock
   - description: Power for GRF IO
-  - description: External clock for some HDMI PHY
+  - description: External clock for some HDMI PHY (old clock name, 
deprecated)
+  - description: External clock for some HDMI PHY (new name)
 
   clock-names:
 minItems: 2
@@ -47,10 +48,14 @@ properties:
   - cec
   - grf
   - vpll
+  - ref
   - enum:
   - grf
   - vpll
-  - const: vpll
+  - ref
+  - enum:
+  - vpll
+  - ref
 
   ddc-i2c-bus:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.2

[PATCH v8 15/24] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

From: Nickey Yang 

add 594Mhz configuration parameters in rockchip_phy_config

Signed-off-by: Nickey Yang 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index f56c79c60d149..081a2740be645 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -192,6 +192,7 @@ static const struct dw_hdmi_phy_config 
rockchip_phy_config[] = {
{ 7425,  0x8009, 0x0004, 0x0272},
{ 14850, 0x802b, 0x0004, 0x028d},
{ 29700, 0x8039, 0x0005, 0x028d},
+   { 59400, 0x8039, 0x, 0x019d},
{ ~0UL,  0x, 0x, 0x}
 };
 
-- 
2.30.2

[PATCH v8 24/24] dt-bindings: display: rockchip: dw-hdmi: fix ports description

Current port description doesn't cover all possible cases. It currently
expects one single port with two endpoints.

When the HDMI connector is described in the device tree there can be two
ports, first one going to the VOP and the second one going to the connector.

Also on SoCs which only have a single VOP there will be only one
endpoint instead of two.

This patch addresses both issues. With this there can either be a single
port ("port") , or two of them ("port@0", "port@1") when the connector
is also in the device tree. Also the first or only port can either have
one endpoint ("endpoint") for single VOP SoCs or two ("endpoint@0",
"endpoint@1") for dual VOP SoCs.

Signed-off-by: Sascha Hauer 
Reviewed-by: Rob Herring 
---

Notes:
Changes since v6:
- Add Reviewed-by: Rob Herring 
Changes since v5:
- new patch

Changes since v7:
- Drop unnecessary hclk

Changes since v5:
- Drop unnecessary #size-cells/#address-cells from nodes with only single 
endpoint

 .../display/rockchip/rockchip,dw-hdmi.yaml| 24 +++
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index ff5cf9fe20904..1f2fd579c510e 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -102,27 +102,21 @@ properties:
   ports:
 $ref: /schemas/graph.yaml#/properties/ports
 
-properties:
-  port:
-$ref: /schemas/graph.yaml#/$defs/port-base
-unevaluatedProperties: false
+patternProperties:
+  "^port(@0)?$":
+$ref: /schemas/graph.yaml#/properties/port
 description: Input of the DWC HDMI TX
-
 properties:
+  endpoint:
+description: Connection to the VOP
   endpoint@0:
-$ref: /schemas/graph.yaml#/properties/endpoint
 description: Connection to the VOPB
-
   endpoint@1:
-$ref: /schemas/graph.yaml#/properties/endpoint
 description: Connection to the VOPL
-
-required:
-  - endpoint@0
-  - endpoint@1
-
-required:
-  - port
+properties:
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output of the DWC HDMI TX
 
   rockchip,grf:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.2

[PATCH v8 05/24] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'

The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.

Signed-off-by: Sascha Hauer 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 080457a68e3c7..d0add619b0d22 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1884,7 +1884,7 @@ hdmi: hdmi@ff94 {
 <&cru SCLK_HDMI_CEC>,
 <&cru PCLK_VIO_GRF>,
 <&cru PLL_VPLL>;
-   clock-names = "iahb", "isfr", "cec", "grf", "vpll";
+   clock-names = "iahb", "isfr", "cec", "grf", "ref";
power-domains = <&power RK3399_PD_HDCP>;
reg-io-width = <4>;
rockchip,grf = <&grf>;
-- 
2.30.2

[PATCH v8 12/24] drm/rockchip: dw_hdmi: Use auto-generated tables

From: Douglas Anderson 

The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor.  Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway).  It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.

In  I've gone through the work to figure
out how to generate this table automatically.  Let's now use the
automatically generated table and then we'll never need to look at it
again.

We only support 8-bit mode right now and only support a small number
of clock rates and I've verified that the only 8-bit rate that was
affected was 148.5.  That mode appears to have been wrong in the old
table.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v5:
- Add missing Signed-off-by me

Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
 1 file changed, 69 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7adf9044cb73b..265b615bfacdc 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -92,80 +92,88 @@ static struct rockchip_hdmi *to_rockchip_hdmi(struct 
drm_encoder *encoder)
 
 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
{
-   2700, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   30666000, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40f3, 0x },
},
-   }, {
-   3600, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   3680, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   4000, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   4600, {
+   { 0x00b3, 0x },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   5400, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   61333000, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   6500, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   7360, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   6600, {
-   { 0x013e, 0x0003},
-   { 0x217e, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   9200, {
+   { 0x0072, 0x0001 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   7425, {
-   { 0x0072, 0x0001},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   122666000, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   8350, {
-   { 0x0072, 0x0001},
+   },  {
+   14720, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10800, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   18400, {
+   { 0x0051, 0x0002 },
+   { 0x214c, 0x0003 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10650, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   22000, {
+

[PATCH v8 01/24] drm/rockchip: Embed drm_encoder into rockchip_decoder

The VOP2 driver needs rockchip specific information for a drm_encoder.

This patch creates a struct rockchip_encoder with a struct drm_encoder
embedded in it. This is used throughout the rockchip driver instead of
struct drm_encoder directly.

The information the VOP2 drivers needs is the of_graph endpoint node
of the encoder. To ease bisectability this is added here.

While at it convert the different encoder-to-driverdata macros to
static inline functions in order to gain type safety and readability.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v5:
- new patch

 .../gpu/drm/rockchip/analogix_dp-rockchip.c   | 32 +++--
 drivers/gpu/drm/rockchip/cdn-dp-core.c| 18 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.h|  2 +-
 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 17 ++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c   | 11 --
 drivers/gpu/drm/rockchip/inno_hdmi.c  | 32 +++--
 drivers/gpu/drm/rockchip/rk3066_hdmi.c| 34 ---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   | 10 ++
 drivers/gpu/drm/rockchip/rockchip_lvds.c  | 26 --
 9 files changed, 122 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8abb5ac26807e..bb33c6c217f77 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -40,8 +40,6 @@
 
 #define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
 
-#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
-
 /**
  * struct rockchip_dp_chip_data - splite the grf setting of kind of chips
  * @lcdsel_grf_reg: grf register offset of lcdc select
@@ -59,7 +57,7 @@ struct rockchip_dp_chip_data {
 struct rockchip_dp_device {
struct drm_device*drm_dev;
struct device*dev;
-   struct drm_encoder   encoder;
+   struct rockchip_encoder  encoder;
struct drm_display_mode  mode;
 
struct clk   *pclk;
@@ -73,6 +71,18 @@ struct rockchip_dp_device {
struct analogix_dp_plat_data plat_data;
 };
 
+static struct rockchip_dp_device *encoder_to_dp(struct drm_encoder *encoder)
+{
+   struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+   return container_of(rkencoder, struct rockchip_dp_device, encoder);
+}
+
+static struct rockchip_dp_device *pdata_encoder_to_dp(struct 
analogix_dp_plat_data *plat_data)
+{
+   return container_of(plat_data, struct rockchip_dp_device, plat_data);
+}
+
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
 {
reset_control_assert(dp->rst);
@@ -84,7 +94,7 @@ static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
 
 static int rockchip_dp_poweron_start(struct analogix_dp_plat_data *plat_data)
 {
-   struct rockchip_dp_device *dp = to_dp(plat_data);
+   struct rockchip_dp_device *dp = pdata_encoder_to_dp(plat_data);
int ret;
 
ret = clk_prepare_enable(dp->pclk);
@@ -105,7 +115,7 @@ static int rockchip_dp_poweron_start(struct 
analogix_dp_plat_data *plat_data)
 
 static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
 {
-   struct rockchip_dp_device *dp = to_dp(plat_data);
+   struct rockchip_dp_device *dp = pdata_encoder_to_dp(plat_data);
 
clk_disable_unprepare(dp->pclk);
 
@@ -166,7 +176,7 @@ struct drm_crtc *rockchip_dp_drm_get_new_crtc(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_enable(struct drm_encoder *encoder,
   struct drm_atomic_state *state)
 {
-   struct rockchip_dp_device *dp = to_dp(encoder);
+   struct rockchip_dp_device *dp = encoder_to_dp(encoder);
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int ret;
@@ -208,7 +218,7 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_disable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
 {
-   struct rockchip_dp_device *dp = to_dp(encoder);
+   struct rockchip_dp_device *dp = encoder_to_dp(encoder);
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state = NULL;
int ret;
@@ -297,7 +307,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device 
*dp)
 
 static int rockchip_dp_drm_create_encoder(struct rockchip_dp_device *dp)
 {
-   struct drm_encoder *encoder = &dp->encoder;
+   struct drm_encoder *encoder = &dp->encoder.encoder;
struct drm_device *drm_dev = dp->drm_dev;
struct device *dev = dp->dev;
int ret;
@@ -333,7 +343,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   dp->plat_data.encoder = &dp->encoder;
+   dp->plat_data.encoder = &dp->encoder.encoder;
 
ret = analogix_dp_bind

[PATCH v8 07/24] dt-bindings: display: rockchip: dw-hdmi: 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 
Signed-off-by: Sascha Hauer 
---
 .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 0400f67e5f2c9..e6b8437a1e2d1 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
-- 
2.30.2

[PATCH v8 23/24] 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 
Reviewed-by: Rob Herring 
---

Notes:
Changes since v5:
- Add Robs Reviewed-by:

Changes since v4:
- Fix clk names in example
- Drop unnecessary assigned-clocks, assigned-clock-rates and 
assigned-clock-parents

Changes since v3:
- drop redundant _vop suffix from clock names

Changes since v3:
- new patch

 .../display/rockchip/rockchip-vop2.yaml   | 140 ++
 1 file changed, 140 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..655d9b327f7d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%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,rk3566-vop
+  - rockchip,rk3568-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
+  - const: hclk
+  - const: dclk_vp0
+  - const: dclk_vp1
+  - const: dclk_vp2
+
+  rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  Phandle to GRF regs used for misc control
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP0
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP1
+
+  port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP2
+
+  iommus:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+vop: vop@fe04 {
+compatible = "rockchip,rk3568-vop";
+reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+interrupts = ;
+clocks = <&cru ACLK_VOP>,
+ <&cru HCLK_VOP>,
+ <&cru DCLK_VOP0>,
+ <&cru DCLK_VOP1>,
+ <&cru DCLK_VOP2>;
+clock-names = "aclk",
+  "hclk",
+  "dclk_vp0",
+  "dclk_vp1",
+  "dclk_vp2";
+power-domains = <&power RK3568_PD_VO>;
+iommus = <&vop_mmu>;
+vop_out: ports {
+#address-cells = <1>;
+#size-cells = <0>;
+vp0: port@0 {
+reg = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+vp1: port@1 {
+reg = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+vp2: port@2 {
+reg = <2>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+};
+};
+

[PATCH v8 22/24] drm: rockchip: Add VOP2 driver

From: Andy Yan 

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
- Drop all waiting for framesyncs

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
on the cluster windows is tested with weston-simple-dmabuf-egl on
weston using the (yet to be upstreamed) panfrost driver support.

Signed-off-by: Andy Yan 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v6:
- Drop device tree parsing during runtime
- Fix typo in Kconfig help text

Changes since v5:
- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t
- Use spin_lock rather than spin_lock_irqsave
- replace printk with drm_dbg
- break some overlong lines

Changes since v4:
- Avoid stack frame overflow by not allocating big array on the stack

Changes since v3:
- Sort includes
- fix typos
- Drop spinlock
- Use regmap_set_bits()/regmap_clear_bits()
- simplify vop2_scale_factor()
- simplify vop2_afbc_transform_offset()

Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

Changes since v4:
- Add Robs Ack

Changes since v3:
- Bring back gamma_lut regs
- Drop redundant _vop suffix from clock names

Changes since v5:
- Drop unnecessary #size-cells/#address-cells from nodes with only single 
endpoint

Changes since v5:
- consistently use u8/u16/u32 rather than uint8_t/uint16_t/uint32_t
- Use spin_lock rather than spin_lock_irqsave
- replace printk with drm_dbg
- break some overlong lines

Changes since v4:
- Avoid stack frame overflow by not allocating big array on the stack

Changes since v3:
- Sort includes
- fix typos
- Drop spinlock
- Use regmap_set_bits()/regmap_clear_bits()
- simplify vop2_scale_factor()
- simplify vop2_afbc_transform_offset()

Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

 drivers/gpu/drm/rockchip/Kconfig |6 +
 drivers/gpu/drm/rockchip/Makefile|1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h  |6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h  |   15 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2686 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  477 
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c |  281 ++
 9 files changed, 3474 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index b9b156308460a..f033971103610 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -28,6 +28,12 @@ config ROCKCHIP_VOP
  This selects support for the VOP driver. You should enable it
  on all older SoCs up to RK3399.
 
+config ROCKCHIP_VOP2
+   bool "Rockchip VOP2 driver"
+   help
+ This selects support for the VOP2 driver. You should enable it
+ on all newer SoCs beginning from RK3568.
+
 config ROCKCHIP_ANALOGIX_DP
bool "Rockchip specific extensions for Analogix DP driver"
depends on ROCKCHIP_VOP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index dfc5512fdb9f1..3ff7b21c04149 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchip_drm_gem.o
 
+rockchipdrm-$(CONFIG_ROCKCHIP_VOP2) += rockchip_drm_vop2.o rockchip_vop2_reg.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
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index cf8dba96a7dee..7bebb293eb555 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -492,6 +492,7 @@ static int __init rockchip_drm_init(void)
 
num_rockchip_sub_drivers = 0;
ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_ROCKCHIP_VOP);
+

[PATCH v8 17/24] 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 
Acked-by: Rob Herring 
---

Notes:
Changes since v6:
- Change RK3568_ prefix to ROCKCHIP_ prefix
- start counting from one instead of zero

Changes since v4:
- Add Robs Ack

Changes since v3:
- Bring back gamma_lut regs
- Drop redundant _vop suffix from clock names

 arch/arm64/boot/dts/rockchip/rk3566.dtsi |  4 ++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  4 ++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 51 
 include/dt-bindings/soc/rockchip,vop2.h  | 14 +++
 4 files changed, 73 insertions(+)
 create mode 100644 include/dt-bindings/soc/rockchip,vop2.h

diff --git a/arch/arm64/boot/dts/rockchip/rk3566.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3566.dtsi
index 3839eef5e4f76..595fa2562cb8e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566.dtsi
@@ -18,3 +18,7 @@ power-domain@RK3568_PD_PIPE {
#power-domain-cells = <0>;
};
 };
+
+&vop {
+   compatible = "rockchip,rk3566-vop";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 2fd313a295f8a..1e55efb6fcfde 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -95,3 +95,7 @@ power-domain@RK3568_PD_PIPE {
#power-domain-cells = <0>;
};
 };
+
+&vop {
+   compatible = "rockchip,rk3568-vop";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index a68033a239750..19d8e67c4698b 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -129,6 +129,11 @@ opp-18 {
};
};
 
+   display_subsystem: display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <&vop_out>;
+   };
+
firmware {
scmi: scmi {
compatible = "arm,scmi-smc";
@@ -451,6 +456,52 @@ gmac1_mtl_tx_setup: tx-queues-config {
};
};
 
+   vop: vop@fe04 {
+   reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+   reg-names = "regs", "gamma_lut";
+   interrupts = ;
+   clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>, <&cru DCLK_VOP0>,
+<&cru DCLK_VOP1>, <&cru DCLK_VOP2>;
+   clock-names = "aclk", "hclk", "dclk_vp0", "dclk_vp1", 
"dclk_vp2";
+   iommus = <&vop_mmu>;
+   power-domains = <&power RK3568_PD_VO>;
+   rockchip,grf = <&grf>;
+   status = "disabled";
+
+   vop_out: ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vp0: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   vp1: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   vp2: port@2 {
+   reg = <2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+   };
+
+   vop_mmu: iommu@fe043e00 {
+   compatible = "rockchip,rk3568-iommu";
+   reg = <0x0 0xfe043e00 0x0 0x100>, <0x0 0xfe043f00 0x0 0x100>;
+   interrupts = ;
+   clocks = <&cru ACLK_VOP>, <&cru 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>;
diff --git a/include/dt-bindings/soc/rockchip,vop2.h 
b/include/dt-bindings/soc/rockchip,vop2.h
new file mode 100644
index 0..6e66a802b96a5
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip,vop2.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+
+#ifndef __DT_BINDINGS_ROCKCHIP_VOP2_H
+#define __DT_BINDINGS_ROCKCHIP_VOP2_H
+
+#define ROCKCHIP_VOP2_EP_RGB0  1
+#define ROCKCHIP_VOP2_EP_HDMI0 2
+#define ROCKCHIP_VOP2_EP_EDP0  3
+#define ROCKCHIP_VOP2_EP_MIPI0 4
+#define ROCKCHIP_VOP2_EP_LVDS0 5
+#define ROCKCHIP_VOP2_EP_MIPI1 6
+#define ROCKCHIP_VOP2_EP_LVDS1 7
+
+#endif /* __DT_BINDINGS_ROCKCHIP_VOP2_H */
-- 
2.30.2

[PATCH v8 09/24] drm/rockchip: dw_hdmi: Add support for niu clk

The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. This clock is not needed for the HDMI
controller itself, but to make the SoC internal bus logic work. From the
reference manual:

> 2.8.6 NIU Clock gating reliance
>
> A part of niu clocks have a dependence on another niu clock in order to
> sharing the internal bus. When these clocks are in use, another niu
> clock must be opened, and cannot be gated.  These clocks and the special
> clock on which they are relied are as following:
>
> Clocks which have dependency The clock which can not be gated
> -
> ...
> pclk_vo_niu, hclk_vo_s_niu   hclk_vo_niu
> ...

The clock framework does not support turning on a clock whenever another
clock is turned on, so this patch adds support for the dependent clock
to the HDMI driver. We call it "NIU", which is for "Native Interface
Unit"

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v7:
- rename hclk to niu

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fe4f9556239ac..7adf9044cb73b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -76,6 +76,7 @@ struct rockchip_hdmi {
const struct rockchip_hdmi_chip_data *chip_data;
struct clk *ref_clk;
struct clk *grf_clk;
+   struct clk *niu_clk;
struct dw_hdmi *hdmi;
struct regulator *avdd_0v9;
struct regulator *avdd_1v8;
@@ -229,6 +230,14 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->niu_clk = devm_clk_get_optional(hdmi->dev, "niu");
+   if (PTR_ERR(hdmi->niu_clk) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->niu_clk)) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to get niu clock\n");
+   return PTR_ERR(hdmi->niu_clk);
+   }
+
hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
if (IS_ERR(hdmi->avdd_0v9))
return PTR_ERR(hdmi->avdd_0v9);
@@ -596,6 +605,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
goto err_clk;
}
 
+   ret = clk_prepare_enable(hdmi->niu_clk);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI hclk clock: 
%d\n",
+ ret);
+   goto err_clk;
+   }
+
if (hdmi->chip_data == &rk3568_chip_data) {
regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
 HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
-- 
2.30.2

[PATCH v8 06/24] drm/rockchip: dw_hdmi: add rk3568 support

Add a new dw_hdmi_plat_data struct and new compatible for rk3568.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 912181429880a..b64cc62c7b5af 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)
 
 /**
@@ -473,6 +477,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 = &rk3568_chip_data,
+   .use_drm_infoframe = true,
+};
+
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3228-dw-hdmi",
  .data = &rk3228_hdmi_drv_data
@@ -486,6 +503,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] 
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
  .data = &rk3399_hdmi_drv_data
},
+   { .compatible = "rockchip,rk3568-dw-hdmi",
+ .data = &rk3568_hdmi_drv_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
@@ -520,6 +540,9 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
encoder = &hdmi->encoder.encoder;
 
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+   rockchip_drm_encoder_set_crtc_endpoint_id(&hdmi->encoder,
+ dev->of_node, 0, 0);
+
/*
 * If we failed to find the CRTC(s) which this encoder is
 * supposed to be connected to, it's because the CRTC has
@@ -550,6 +573,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   if (hdmi->chip_data == &rk3568_chip_data) {
+   regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
+HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK,
+  RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK));
+   }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
 
-- 
2.30.2

[PATCH v8 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

From: Michael Riesch 

Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.

Signed-off-by: Michael Riesch 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v5:
- Drop reg property from single endpoint node

Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

 .../boot/dts/rockchip/rk3566-quartz64-a.dts   | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 166399b7f13f0..ddb7857bef099 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include "rk3566.dtsi"
 
 / {
@@ -35,6 +36,17 @@ fan: gpio_fan {
#cooling-cells = <2>;
};
 
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -205,6 +217,24 @@ &gmac1m0_clkinout
status = "okay";
 };
 
+&hdmi {
+   avdd-0v9-supply = <&vdda_0v9>;
+   avdd-1v8-supply = <&vcc_1v8>;
+   status = "okay";
+};
+
+&hdmi_in {
+   hdmi_in_vp0: endpoint {
+   remote-endpoint = <&vp0_out_hdmi>;
+   };
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c0 {
status = "okay";
 
@@ -551,3 +581,20 @@ bluetooth {
 &uart2 {
status = "okay";
 };
+
+&vop {
+   assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+   assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+   status = "okay";
+};
+
+&vop_mmu {
+   status = "okay";
+};
+
+&vp0 {
+   vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+   reg = ;
+   remote-endpoint = <&hdmi_in_vp0>;
+   };
+};
-- 
2.30.2

[PATCH v8 19/24] 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 
---

Notes:
Changes since v5:
- Drop reg property from single endpoint node

Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

 .../boot/dts/rockchip/rk3568-evb1-v10.dts | 47 +++
 1 file changed, 47 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..792735d424716 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 #include 
 #include 
+#include 
 #include "rk3568.dtsi"
 
 / {
@@ -33,6 +34,17 @@ dc_12v: dc-12v {
regulator-max-microvolt = <1200>;
};
 
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
vcc3v3_sys: vcc3v3-sys {
compatible = "regulator-fixed";
regulator-name = "vcc3v3_sys";
@@ -106,6 +118,24 @@ &gmac1m1_rgmii_clk
status = "okay";
 };
 
+&hdmi {
+   avdd-0v9-supply = <&vdda0v9_image>;
+   avdd-1v8-supply = <&vcca1v8_image>;
+   status = "okay";
+};
+
+&hdmi_in {
+   hdmi_in_vp0: endpoint {
+   remote-endpoint = <&vp0_out_hdmi>;
+   };
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c0 {
status = "okay";
 
@@ -390,3 +420,20 @@ &sdmmc0 {
 &uart2 {
status = "okay";
 };
+
+&vop {
+   assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+   assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+   status = "okay";
+};
+
+&vop_mmu {
+   status = "okay";
+};
+
+&vp0 {
+   vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+   reg = ;
+   remote-endpoint = <&hdmi_in_vp0>;
+   };
+};
-- 
2.30.2

[PATCH v8 00/24] drm/rockchip: RK356x VOP2 support

v8 is here. The only change this time is the renaming of hclk to niu.
The background is that I needed to add a new clock to the HDMI controller
driver to make it work on rk356x. The purpose of this clock was not
clear, but during v7 discussions it turned out that this clock is not
needed for the HDMI controller itself, but SoC internal logic demands
that this clock must be turned on whenever pclk_vo is turned on. This
logic is in the reference manual described as "NIU" (Native Interface
Unit), so I renamed the clock from hclk to niu.

Sascha


Changes since v7:
- rename hclk to niu

Changes since v6:
- Move of_graph parsing out of runtime code to initialization

Changes since v5:
- Add new patch to fix dw-hdmi of_graph binding
- Drop "drm/encoder: Add of_graph port to struct drm_encoder" and solve
  issue internally in the driver
- make checkpatch cleaner

Changes since v4:
- Reorder patches in a way that binding/dts/driver patches are closer together
- Drop clk patches already applied by Heiko

Changes since v3:
- added changelog to each patch
- Add 4k support to hdmi driver
- rebase on v5.17-rc1

Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion

Changes since v1:
- drop all unnecessary waiting for frames within atomic modeset and plane update
- Cluster subwin support removed
- gamma support removed
- unnecessary irq_lock removed
- interrupt handling simplified
- simplified zpos handling
- drop is_alpha_support(), use fb->format->has_alpha instead
- use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi 
regulators
- Use fixed number of planes per video port
- Drop homegrown regmap code from vop2 driver (not complete yet)
- Add separate include file for vop2 driver to not pollute the vop include

Andy Yan (1):
  drm: rockchip: Add VOP2 driver

Benjamin Gaignard (1):
  dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568
HDMI

Douglas Anderson (2):
  drm/rockchip: dw_hdmi: Use auto-generated tables
  drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

Michael Riesch (1):
  arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

Nickey Yang (1):
  drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

Sascha Hauer (18):
  drm/rockchip: Embed drm_encoder into rockchip_decoder
  drm/rockchip: Add crtc_endpoint_id to rockchip_encoder
  drm/rockchip: dw_hdmi: rename vpll clock to reference clock
  dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
  arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
  drm/rockchip: dw_hdmi: add rk3568 support
  drm/rockchip: dw_hdmi: add regulator support
  drm/rockchip: dw_hdmi: Add support for niu clk
  dt-bindings: display: rockchip: dw-hdmi: Add additional clock
  dt-bindings: display: rockchip: dw-hdmi: Add regulator support
  drm/rockchip: dw_hdmi: drop mode_valid hook
  dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
  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
  dt-bindings: display: rockchip: Add binding for VOP2
  dt-bindings: display: rockchip: dw-hdmi: fix ports description

 .../display/rockchip/rockchip,dw-hdmi.yaml|   53 +-
 .../display/rockchip/rockchip-vop2.yaml   |  140 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi  |2 +-
 .../boot/dts/rockchip/rk3566-quartz64-a.dts   |   47 +
 arch/arm64/boot/dts/rockchip/rk3566.dtsi  |4 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts |   47 +
 arch/arm64/boot/dts/rockchip/rk3568.dtsi  |4 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi  |   83 +
 drivers/gpu/drm/rockchip/Kconfig  |   14 +
 drivers/gpu/drm/rockchip/Makefile |4 +-
 .../gpu/drm/rockchip/analogix_dp-rockchip.c   |   32 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c|   18 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.h|2 +-
 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   |   17 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c   |  292 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   32 +-
 drivers/gpu/drm/rockchip/rk3066_hdmi.c|   34 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |   36 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   20 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   15 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 2686 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h  |  477 +++
 drivers/gpu/drm/rockchip/rockchip_lvds.c  |   26 +-
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c  |  281 ++
 include/dt-bindings/soc/rockchip,vop2.h   |   14 +
 26 files changed, 418

[PATCH v8 14/24] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

From: Douglas Anderson 

Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL.  In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin.  We believe that
lowering the bandwidth like this is safe given sufficient testing.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 4f912cbea73bb..f56c79c60d149 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -181,20 +181,8 @@ static const struct dw_hdmi_mpll_config 
rockchip_mpll_cfg[] = {
 static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
/*  pixelclkbpp8bpp10   bpp12 */
{
-   4000,  { 0x0018, 0x0018, 0x0018 },
-   }, {
-   6500,  { 0x0028, 0x0028, 0x0028 },
-   }, {
-   6600,  { 0x0038, 0x0038, 0x0038 },
-   }, {
-   7425,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   8350,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   14625, { 0x0038, 0x0038, 0x0038 },
-   }, {
-   14850, { 0x, 0x0038, 0x0038 },
-   }, {
+   6, { 0x, 0x, 0x },
+   },  {
~0UL,  { 0x, 0x, 0x},
}
 };
-- 
2.30.2

[PATCH v8 13/24] drm/rockchip: dw_hdmi: drop mode_valid hook

The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a frequency range up to which the entry works, not as a frequency that
must match the pixel clock. The downstream Kernel also does not have
this check, so drop it to allow for more display resolutions.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 265b615bfacdc..4f912cbea73bb 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -257,26 +257,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return 0;
 }
 
-static enum drm_mode_status
-dw_hdmi_rockchip_mode_valid(struct dw_hdmi *hdmi, void *data,
-   const struct drm_display_info *info,
-   const struct drm_display_mode *mode)
-{
-   const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
-   int pclk = mode->clock * 1000;
-   bool valid = false;
-   int i;
-
-   for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
-   if (pclk == mpll_cfg[i].mpixelclock) {
-   valid = true;
-   break;
-   }
-   }
-
-   return (valid) ? MODE_OK : MODE_BAD;
-}
-
 static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
 {
 }
@@ -442,7 +422,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -459,7 +438,6 @@ static struct rockchip_hdmi_chip_data rk3288_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3288_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,
@@ -479,7 +457,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3328_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,
@@ -497,7 +474,6 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3399_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,
@@ -510,7 +486,6 @@ static struct rockchip_hdmi_chip_data rk3568_chip_data = {
 };
 
 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,
-- 
2.30.2

[PATCH v8 08/24] 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 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++--
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b64cc62c7b5af..fe4f9556239ac 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 
@@ -76,6 +77,8 @@ struct rockchip_hdmi {
struct clk *ref_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+   struct regulator *avdd_0v9;
+   struct regulator *avdd_1v8;
struct phy *phy;
 };
 
@@ -226,6 +229,14 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
+   if (IS_ERR(hdmi->avdd_0v9))
+   return PTR_ERR(hdmi->avdd_0v9);
+
+   hdmi->avdd_1v8 = devm_regulator_get(hdmi->dev, "avdd-1v8");
+   if (IS_ERR(hdmi->avdd_1v8))
+   return PTR_ERR(hdmi->avdd_1v8);
+
return 0;
 }
 
@@ -566,11 +577,23 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   ret = regulator_enable(hdmi->avdd_0v9);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd0v9: %d\n", ret);
+   goto err_avdd_0v9;
+   }
+
+   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_prepare_enable(hdmi->ref_clk);
if (ret) {
DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI reference 
clock: %d\n",
  ret);
-   return ret;
+   goto err_clk;
}
 
if (hdmi->chip_data == &rk3568_chip_data) {
@@ -594,10 +617,19 @@ 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_disable_unprepare(hdmi->ref_clk);
+   goto err_bind;
}
 
+   return 0;
+
+err_bind:
+   clk_disable_unprepare(hdmi->ref_clk);
+   drm_encoder_cleanup(encoder);
+err_clk:
+   regulator_disable(hdmi->avdd_1v8);
+err_avdd_1v8:
+   regulator_disable(hdmi->avdd_0v9);
+err_avdd_0v9:
return ret;
 }
 
@@ -608,6 +640,9 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
 
dw_hdmi_unbind(hdmi->hdmi);
clk_disable_unprepare(hdmi->ref_clk);
+
+   regulator_disable(hdmi->avdd_1v8);
+   regulator_disable(hdmi->avdd_0v9);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
-- 
2.30.2

[PATCH v8 18/24] arm64: dts: rockchip: rk356x: Add HDMI nodes

Add support for the HDMI port found on RK3568.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v7:
- Rename hclk to niu

Changes since v5:
- Drop unnecessary #size-cells/#address-cells from nodes with only single 
endpoint

 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 19d8e67c4698b..0a94d59b33ba4 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -502,6 +502,38 @@ vop_mmu: iommu@fe043e00 {
status = "disabled";
};
 
+   hdmi: hdmi@fe0a {
+   compatible = "rockchip,rk3568-dw-hdmi";
+   reg = <0x0 0xfe0a 0x0 0x2>;
+   interrupts = ;
+   clocks = <&cru PCLK_HDMI_HOST>,
+<&cru CLK_HDMI_SFR>,
+<&cru CLK_HDMI_CEC>,
+<&pmucru CLK_HDMI_REF>,
+<&cru HCLK_VO>;
+   clock-names = "iahb", "isfr", "cec", "ref", "niu";
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
+   power-domains = <&power RK3568_PD_VO>;
+   reg-io-width = <4>;
+   rockchip,grf = <&grf>;
+   #sound-dai-cells = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   reg = <0>;
+   };
+
+   hdmi_out: port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
-- 
2.30.2

[PATCH v8 16/24] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional

None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

 .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index a48b0e842218f..ff5cf9fe20904 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -94,6 +94,7 @@ properties:
   The unwedge pinctrl entry shall drive the DDC SDA line low. This is
   intended to work around a hardware errata that can cause the DDC I2C
   bus to be wedged.
+minItems: 1
 items:
   - const: default
   - const: unwedge
-- 
2.30.2

[PATCH v8 11/24] dt-bindings: display: 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 the binding for these supplies.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 1df61cb420744..a48b0e842218f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -28,6 +28,17 @@ properties:
   reg-io-width:
 const: 4
 
+  avdd-0v9-supply:
+description:
+  A 0.9V supply that powers up the SoC internal circuitry. The actual pin 
name
+  varies between the different SoCs and is usually HDMI_TX_AVDD_0V9 or 
sometimes
+  HDMI_AVDD_1V0.
+
+  avdd-1v8-supply:
+description:
+  A 1.8V supply that powers up the SoC internal circuitry. The pin name on 
the
+  SoC usually is HDMI_TX_AVDD_1V8.
+
   clocks:
 minItems: 2
 items:
-- 
2.30.2

[PATCH v8 21/24] 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 
---
 drivers/gpu/drm/rockchip/Kconfig| 8 
 drivers/gpu/drm/rockchip/Makefile   | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 9f1ecefc39332..b9b156308460a 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -21,8 +21,16 @@ config DRM_ROCKCHIP
 
 if DRM_ROCKCHIP
 
+config ROCKCHIP_VOP
+   bool "Rockchip VOP driver"
+   default y
+   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 1a56f696558ca..dfc5512fdb9f1 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -4,8 +4,9 @@
 # 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_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 7920a4f44f693..cf8dba96a7dee 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -491,7 +491,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

[PATCH] video: fbdev: fix warning comparing pointer to 0

2022-03-11 Thread Haowen Bai

Fix the following coccicheck warning:
drivers/video/fbdev/offb.c:415:13-14: WARNING comparing pointer to 0

Signed-off-by: Haowen Bai 
---
 drivers/video/fbdev/offb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 4501e84..afdb6aa 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -412,7 +412,7 @@ static void __init offb_init_fb(const char *name,
 
info = framebuffer_alloc(sizeof(u32) * 16, NULL);
 
-   if (info == 0) {
+   if (!info) {
release_mem_region(res_start, res_size);
return;
}
-- 
2.7.4

Re: [PATCH v1 1/3] mm: split vm_normal_pages for LRU and non-LRU handling

2022-03-11 Thread David Hildenbrand

On 10.03.22 18:26, Alex Sierra wrote:
> DEVICE_COHERENT pages introduce a subtle distinction in the way
> "normal" pages can be used by various callers throughout the kernel.
> They behave like normal pages for purposes of mapping in CPU page
> tables, and for COW. But they do not support LRU lists, NUMA
> migration or THP. Therefore we split vm_normal_page into two
> functions vm_normal_any_page and vm_normal_lru_page. The latter will
> only return pages that can be put on an LRU list and that support
> NUMA migration, KSM and THP.
> 
> We also introduced a FOLL_LRU flag that adds the same behaviour to
> follow_page and related APIs, to allow callers to specify that they
> expect to put pages on an LRU list.
> 

I still don't see the need for s/vm_normal_page/vm_normal_any_page/. And
as this patch is dominated by that change, I'd suggest (again) to just
drop it as I don't see any value of that renaming. No specifier implies any.

The general idea of this change LGTM.

I wonder how this interacts with the actual DEVICE_COHERENT coherent
series. Is this a preparation? Should it be part of the DEVICE_COHERENT
series?

IOW, should this patch start with

"With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW, they do not support LRU lists, NUMA migration or THP. [...]"

But then, I'm confused by patch 2 and 3, because it feels more like we'd
already have DEVICE_COHERENT then ("hmm_is_coherent_type").

-- 
Thanks,

David / dhildenb

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

2022-03-11 Thread Dmitry Baryshkov

On Fri, 11 Mar 2022 at 11:06, Vinod Polimera  wrote:
>
>
>
> > -Original Message-
> > From: Stephen Boyd 
> > Sent: Wednesday, March 9, 2022 1:36 AM
> > To: quic_vpolimer ;
> > devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > freedr...@lists.freedesktop.org; linux-arm-...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
> > diand...@chromium.org; quic_kalyant 
> > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > rate property for mdp clk
> >
> > WARNING: This email originated from outside of Qualcomm. Please be wary
> > of any links or attachments, and do not enable macros.
> >
> > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > Kernel clock driver assumes that initial rate is the
> > > max rate for that clock and was not allowing it to scale
> > > beyond the assigned clock value.
> >
> > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > is preventing the frequency from changing beyond the assigned value.
>
> Folowing the comment of Stephen, i have checked a bit more. it appears that 
> clock driver is not setting the max clock from assgined clocks, dpu driver is 
> doing that.
> i am planning to fix it as below.
> 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> 2) remove unnecessary checks in the core_perf library. If rate doesn't match 
> with the entries in the opp table, it will throw error, hence furthur checks 
> are not needed.
> 3) no changes in dt are required. (we can drop all the posted ones)

Why? They made perfect sense. The dts assignments should be replaced
by the opp setting in the bind function, as this would also set the
performance point of the respective power domain.

>
> Changes :
> ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
> }
>  }
>
> -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> -{
> -   struct dss_clk *core_clk = kms->perf.core_clk;
> -
> -   if (core_clk->max_rate && (rate > core_clk->max_rate))
> -   rate = core_clk->max_rate;
> -
> -   core_clk->rate = rate;
> -   return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> -}
> -
>  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
>  {
> u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>
> trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
>
> -   ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> +   ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
> if (ret) {
> DPU_ERROR("failed to set %s clock rate %llu\n",
> kms->perf.core_clk->clk_name, 
> clk_rate);
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c

This file has been removed in msm/next

> @@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
> continue;
> mp->clk_config[i].rate = rate;
> mp->clk_config[i].type = DSS_CLK_PCLK;
> -   mp->clk_config[i].max_rate = rate;
> +   mp->clk_config[i].max_rate = ULONG_MAX;
> }
>
> mp->num_clk = num_clk;
> --```
>
> Thanks,
> Vinod.
>
> >
> > >
> > > Drop the assigned clock rate property and vote on the mdp clock as per
> > > calculated value during the usecase.
> > >
> > > Changes in v2:
> > > - Remove assigned-clock-rate property and set mdp clk during resume
> > sequence.
> > > - Add fixes tag.
> > >
> > > Changes in v3:
> > > - Remove extra line after fixes tag.(Stephen Boyd)
> >
> > This changelog should be removed.
> >
> > >
> > > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> >
> > I thought folks were saying that this is bad to keep? I don't really
> > mind either way, but I guess it's better to drop the fixes tag because
> > this is largely a performance improvement?
> >
> > > Signed-off-by: Vinod Polimera 
> > > Reviewed-by: Stephen Boyd 



-- 
With best wishes
Dmitry

Re: [PATCH 1/3] drm/msm/gpu: Rename runtime suspend/resume functions

2022-03-11 Thread AngeloGioacchino Del Regno


Il 11/03/22 00:46, Rob Clark ha scritto:

From: Rob Clark 



Hey Rob,
looks like you've somehow lost the commit description on this one!

Cheers,
Angelo


Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH v15 01/22] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195

2022-03-11 Thread AngeloGioacchino Del Regno


Il 11/03/22 02:54, Nancy.Lin ha scritto:

Add vdosys1 RDMA definition.

Signed-off-by: Nancy.Lin 


Reviewed-by: AngeloGioacchino Del Regno 



---
  .../arm/mediatek/mediatek,mdp-rdma.yaml   | 86 +++
  1 file changed, 86 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml

diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
new file mode 100644
index ..6ab773569462
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mdp-rdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MDP RDMA
+
+maintainers:
+  - Matthias Brugger 
+
+description: |
+  The mediatek MDP RDMA stands for Read Direct Memory Access.
+  It provides real time data to the back-end panel driver, such as DSI,
+  DPI and DP_INTF.
+  It contains one line buffer to store the sufficient pixel data.
+  RDMA device node must be siblings to the central MMSYS_CONFIG node.
+  For a description of the MMSYS_CONFIG binding, see
+  Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for 
details.
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - const: mediatek,mt8195-vdo1-rdma
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  power-domains:
+description: A phandle and PM domain specifier as defined by bindings of
+  the power controller specified by phandle. See
+  Documentation/devicetree/bindings/power/power-domain.yaml for details.
+
+  clocks:
+items:
+  - description: RDMA Clock
+
+  iommus:
+description:
+  This property should point to the respective IOMMU block with master 
port as argument,
+  see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for 
details.
+
+  mediatek,gce-client-reg:
+description:
+  The register of display function block to be set by gce. There are 4 
arguments,
+  such as gce node, subsys id, offset and register size. The subsys id 
that is
+  mapping to the register of display function blocks is defined in the gce 
header
+  include/include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - power-domains
+  - clocks
+  - iommus
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+#include 
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+vdo1_rdma0: mdp-rdma@1c104000 {
+compatible = "mediatek,mt8195-vdo1-rdma";
+reg = <0 0x1c104000 0 0x1000>;
+interrupts = ;
+clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
+power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
+iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
+mediatek,gce-client-reg = <&gce0 SUBSYS_1c10 0x4000 0x1000>;
+};
+};

[PATCH 0/2 RESEND] Mitigate race condition problems when unbinding DRM driver

2022-03-11 Thread Ricardo Cañuelo

Hi all,

I'm sending these patches to try to improve the current situation for a
particular corner case (DRM driver unbinding).

I could reproduce a specific race condition during the unbinding of the
mediatek-drm driver that caused an invalid memory address. The race
condition is triggered by a userspace event (gnome-shell requesting a
DRM GET_CONNECTOR ioctl) while the encoders and drivers are in the
process of being disabled.

While I tried to mitigate this by making a small change in the
parade-ps8640 driver (for the bridge I'm testing on) and by making a
couple of functions in drm_bridge.c more robust, this is only a symptom
of a larger problem that might not be getting enough attention,
understandably, because this is an unusual corner case.

The scenario looks like this:

: unbind mediatek-drm   +
  ||
   |
  ||
 ...   |
  |   ...
mtk_dsi_unbind |
  ||
  `- drm_encoder_cleanup   v
  |   | gnome-shell
 ...  `- drm_bridge_detach *<-- ioctl (GET_CONNECTOR)
   |

   |
  ...
   |
   |
  ps8640_bridge_get_edid
 |
  `drm_bridge_chain_post_disable

which causes drm_bridge_chain_post_disable() to walk the bridge chain
after the bridge has already been detached and removed from the list. I
guess a more radical and subsystem-wide solution would be to not allow
or to block certain ioctl calls once the driver has started to unbind,
but I'd like to hear your opinion on this.

This was tested on an Acer Chromebook R13 (Elm, MT8173) running Debian
Sid, the command that triggers the race condition is

echo mediatek-drm.12.auto > /sys/bus/platform/drivers/mediatek-drm/unbind

Cheers,
Ricardo

Ricardo Cañuelo (2):
  drm/bridge: parade-ps8640: avoid race condition on driver unbinding
  drm/bridge: Add extra checks in pre_enable and post_enable

 drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++---
 drivers/gpu/drm/drm_bridge.c   | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

--
2.25.1

[PATCH 1/2 RESEND] drm/bridge: parade-ps8640: avoid race condition on driver unbinding

2022-03-11 Thread Ricardo Cañuelo

When unbinding a DRM master driver there's a race condition that
sometimes results in an invalid vm access when userspace (gnome-shell)
issues a DRM_IOCTL_MODE_GETCONNECTOR ioctl right after a bridge has been
removed from an encoder's bridge chain.

This means that once a bridge has been disabled and gone through
ps8640_post_disable(), if ps8640_bridge_get_edid() runs afterwards as a
result of that ioctl call it will call drm_bridge_chain_pre_enable()
and drm_bridge_chain_post_disable() again in a bridge that has been
already detached.

Setting `ps_bridge->pre_enabled = false` at a later stage of the
bringdown path and calling drm_bridge_chain_pre_enable() inside
ps8640_bridge_get_edid() only if needed avoid this, although a proper
subsystem-wide fix would be the proper solution, since the same type of
race conditions might happen somewhere else.

Tested on an Acer Chromebook R13 (Elm, MT8173) with Debian Sid.

Signed-off-by: Ricardo Cañuelo 
---
 drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 3f17337ee389..a927787a89bf 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -434,8 +434,6 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 {
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
 
-   ps_bridge->pre_enabled = false;
-
ps8640_bridge_vdo_control(ps_bridge, DISABLE);
pm_runtime_put_sync_suspend(&ps_bridge->page[PAGE0_DP_CNTL]->dev);
 }
@@ -487,6 +485,7 @@ static void ps8640_bridge_detach(struct drm_bridge *bridge)
drm_dp_aux_unregister(&ps_bridge->aux);
if (ps_bridge->link)
device_link_del(ps_bridge->link);
+   ps_bridge->pre_enabled = false;
 }
 
 static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
@@ -508,7 +507,8 @@ static struct edid *ps8640_bridge_get_edid(struct 
drm_bridge *bridge,
 * EDID, for this chip, we need to do a full poweron, otherwise it will
 * fail.
 */
-   drm_bridge_chain_pre_enable(bridge);
+   if (poweroff)
+   drm_bridge_chain_pre_enable(bridge);
 
edid = drm_get_edid(connector,
ps_bridge->page[PAGE0_DP_CNTL]->adapter);
-- 
2.25.1

[PATCH 2/2 RESEND] drm/bridge: Add extra checks in pre_enable and post_enable

2022-03-11 Thread Ricardo Cañuelo

Depending on the bridge code, certain userspace events during a driver
teardown (such as a DRM ioctl call) might cause a race condition where
the drm_bridge_chain_pre_enable() and drm_bridge_chain_post_enable()
functions could be called for a bridge that has just been detached and
removed from the bridge chain of an encoder.

This change makes these functions a bit more robust by bailing out if
the bridge has already been detached.

Tested on an Acer Chromebook R13 (Elm, MT8173) with Debian Sid.

Signed-off-by: Ricardo Cañuelo 
---
 drivers/gpu/drm/drm_bridge.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c96847fc0ebc..e074aa456dd1 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -529,7 +529,7 @@ void drm_bridge_chain_post_disable(struct drm_bridge 
*bridge)
 {
struct drm_encoder *encoder;
 
-   if (!bridge)
+   if (!bridge || !bridge->dev)
return;
 
encoder = bridge->encoder;
@@ -585,7 +585,7 @@ void drm_bridge_chain_pre_enable(struct drm_bridge *bridge)
struct drm_encoder *encoder;
struct drm_bridge *iter;
 
-   if (!bridge)
+   if (!bridge || !bridge->dev)
return;
 
encoder = bridge->encoder;
-- 
2.25.1

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)

2022-03-11 Thread Daniel Vetter

On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy  wrote:
>
> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> more framebuffers/scanout buffers results in only one that is mappable/
> fenceable. Therefore, pageflipping between these 2 FBs where only one
> is mappable/fenceable creates latencies large enough to miss alternate
> vblanks thereby producing less optimal framerate.
>
> This mainly happens because when i915_gem_object_pin_to_display_plane()
> is called to pin one of the FB objs, the associated vma is identified
> as misplaced and therefore i915_vma_unbind() is called which unbinds and
> evicts it. This misplaced vma gets subseqently pinned only when
> i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
> results in a latency of ~10ms and happens every other vblank/repaint cycle.
> Therefore, to fix this issue, we try to see if there is space to map
> at-least two objects of a given size and return early if there isn't. This
> would ensure that we do not try with PIN_MAPPABLE for any objects that
> are too big to map thereby preventing unncessary unbind.
>
> Testcase:
> Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
> with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
> a frame ~7ms before the next vblank, the latencies seen between atomic
> commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
> it misses the vblank every other frame.
>
> Here is the ftrace snippet that shows the source of the ~10ms latency:
>   i915_gem_object_pin_to_display_plane() {
> 0.102 us   |i915_gem_object_set_cache_level();
> i915_gem_object_ggtt_pin_ww() {
> 0.390 us   |  i915_vma_instance();
> 0.178 us   |  i915_vma_misplaced();
>   i915_vma_unbind() {
>   __i915_active_wait() {
> 0.082 us   |i915_active_acquire_if_busy();
> 0.475 us   |  }
>   intel_runtime_pm_get() {
> 0.087 us   |intel_runtime_pm_acquire();
> 0.259 us   |  }
>   __i915_active_wait() {
> 0.085 us   |i915_active_acquire_if_busy();
> 0.240 us   |  }
>   __i915_vma_evict() {
> ggtt_unbind_vma() {
>   gen8_ggtt_clear_range() {
> 10507.255 us |}
> 10507.689 us |  }
> 10508.516 us |   }
>
> v2: Instead of using bigjoiner checks, determine whether a scanout
> buffer is too big by checking to see if it is possible to map
> two of them into the ggtt.
>
> v3 (Ville):
> - Count how many fb objects can be fit into the available holes
>   instead of checking for a hole twice the object size.
> - Take alignment constraints into account.
> - Limit this large scanout buffer check to >= Gen 11 platforms.
>
> v4:
> - Remove existing heuristic that checks just for size. (Ville)
> - Return early if we find space to map at-least two objects. (Tvrtko)
> - Slightly update the commit message.
>
> v5: (Tvrtko)
> - Rename the function to indicate that the object may be too big to
>   map into the aperture.
> - Account for guard pages while calculating the total size required
>   for the object.
> - Do not subject all objects to the heuristic check and instead
>   consider objects only of a certain size.
> - Do the hole walk using the rbtree.
> - Preserve the existing PIN_NONBLOCK logic.
> - Drop the PIN_MAPPABLE check while pinning the VMA.
>
> v6: (Tvrtko)
> - Return 0 on success and the specific error code on failure to
>   preserve the existing behavior.
>
> v7: (Ville)
> - Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
>   size < ggtt->mappable_end / 4 checks.
> - Drop the redundant check that is based on previous heuristic.
>
> v8:
> - Make sure that we are holding the mutex associated with ggtt vm
>   as we traverse the hole nodes.
>
> v9: (Tvrtko)
> - Use mutex_lock_interruptible_nested() instead of mutex_lock().
>
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: Tvrtko Ursulin 
> Cc: Manasi Navare 
> Reviewed-by: Tvrtko Ursulin 
> Signed-off-by: Vivek Kasireddy 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 128 +++-
>  1 file changed, 94 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9747924cc57b..e0d731b3f215 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -49,6 +49,7 @@
>  #include "gem/i915_gem_pm.h"
>  #include "gem/i915_gem_region.h"
>  #include "gem/i915_gem_userptr.h"
> +#include "gem/i915_gem_tiling.h"
>  #include "gt/intel_engine_user.h"
>  #include "gt/intel_gt.h"
>  #include "gt/intel_gt_pm.h"
> @@ -882,6 +883,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
> spin_unlock(&obj->vma.lock);
>  }
>
> +static int
> +i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
> +u64 alignment, u64 flags)

Tvrtko asked me to ack the first patch, but th

Re: [PATCH v15 00/22] Add MediaTek SoC DRM (vdosys1) support for mt8195

2022-03-11 Thread AngeloGioacchino Del Regno

Il 11/03/22 02:54, Nancy.Lin ha scritto:

The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.

Add DRM and these modules support by the patches below:

Hello maintainers,

I have tested this series (and its dependencies - where [1] is needed to even
be able to apply this one) on multiple machines featuring different MediaTek
SoCs and everything works as expected on both oldies and new ones.

I want to make sure you know that series [1] is also fine and has R-b tags,
apart from the first commit (1/8) that in my opinion should be removed (or
simply ignored while applying, as it's not impacting on any other change in
that series, nor in this one).

In my opinion, the two (vdosys0 and 1) series are ready to be picked.

[1]: https://patchwork.kernel.org/project/linux-mediatek/list/?series=620795

Thank you all,
Angelo

Changes in v15:
- fix ethdr uppercase hex number in dts

Changes in v14:
- remove MTK_MMSYS 64 bit dependency
- add ethdr.yaml back and fix dt_schema check fail

Resend v13
- add related maintainer in maillist

Changes in v13:
- fix reviewer comment in v12
- fix rdma dt-binding format
- fix dts node naming
- fix 32 bit build error
- modify 64bit dependency for mtk-mmsys
- rebase to vdosys0 series v16. (ref [5])

Changes in v12:
- fix reviewer comment in v11
- modify mbox index
- refine dma dev for ovl_adaptor sub driver

Changes in v11:
- remove ethdr vblank spin lock
- refine ovl_adaptor print message

Changes in v10:
- refine ethdr reset control using
devm_reset_control_array_get_optional_exclusive
- fix ovl_adaptor mtk_ovl_adaptor_clk_enable error handle issue

Changes in v9:
- rebase on kernel-5.16-rc1
- rebase on vdosys0 series v13. (ref [5])
- fix ovl_adaptor sub driver is brought up unintentionally
- fix clang build test fail- duplicate ethdr/mdp_rdma
init_module/cleanup_module symbol issue

Changes in v8:
- separate merge async reset to new patch.
- separate drm ovl_adaptor sub driver to new patch.
- fix reviewer comment in v7.

Changes in v7:
- rebase on vdosys0 series v12 (ref[5])
- add dma description in ethdr binding document.
- refine vdosys1 bit definition of mmsys routing table.
- separate merge modification into 3 pathces.
- separate mutex modification into 2 patches.
- add plane color coding for mdp_rdma csc.
- move mdp_rdma pm control to ovl_adaptor.
- fix reviewer comment in v6.

Changes in v6:
- rebase on kernel-5.15-rc1.
- change mbox label to gce0 for dts node of vdosys1.
- modify mmsys reset num for mt8195.
- rebase on vdosys0 series v10. (ref [5])
- use drm to bring up ovl_adaptor driver.
- move drm iommu/mutex check from kms init to drm bind.
- modify rdma binding doc location. (Documentation/devicetree/bindings/arm/)
- modify for reviewer's comment in v5.

Changes in v5:
- add mmsys reset controller reference.

Changes in v4:
- use merge common driver for merge1~4.
- refine ovl_adaptor rdma driver.
- use ovl_adaptor ddp_comp function instead of ethdr.
- modify for reviewer's comment in v3.

Changes in v3:
- modify for reviewer's comment in v2.
- add vdosys1 2 pixels align limit.
- add mixer odd offset support.

Changes in v2:
- Merge PSEUDO_OVL and ETHDR into one DRM component.
- Add mmsys config API for vdosys1 hardware setting.
- Add mmsys reset control using linux reset framework.

Signed-off-by: Nancy.Lin

This series are based on the following patch:
[1] arm64: dts: Add mediatek SoC mt8195 and evaluation board

https://patchwork.kernel.org/project/linux-mediatek/patch/20220112114724.1953-4-tinghan.s...@mediatek.com/
[2] arm64: dts: mt8195: add IOMMU and smi nodes

https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26682-15-tinghan.s...@mediatek.com/
[3] arm64: dts: mt8195: add gce node

https://patchwork.kernel.org/project/linux-mediatek/patch/20220126090109.32143-1-jason-jh@mediatek.com/
[4] [v2] arm64: dts: mt8195: add display node for vdosys0

https://patchwork.kernel.org/project/linux-mediatek/patch/20220225021535.2655-1-jason-jh@mediatek.com/
[5] Add MediaTek SoC DRM (vdosys0) support for mt8195
https://patchwork.kernel.org/project/linux-mediatek/list/?series=620795
[6] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU

https://patchwork.kernel.org/project/linux-mediatek/patch/20220217113453.13658-2-yong...@mediatek.com/

Nancy.Lin (22):
dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195
dt-bindings: reset: mt8195: add vdosys1 reset control bit
dt-bindings: mediatek: add ethdr definition for mt8195
soc: mediatek: add mtk-mmsys support for mt8195 vdosys1
soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1
soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195
vdosys1
soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1
soc: mediatek: change the mutex defines and the mutex_mod type
soc: mediatek: add mtk-mutex support for mt8195 vdosys1

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Improve long running OCL w/a for GuC submission

2022-03-11 Thread Tvrtko Ursulin




On 10/03/2022 20:24, John Harrison wrote:

On 3/10/2022 01:27, Tvrtko Ursulin wrote:

On 09/03/2022 21:16, John Harrison wrote:

On 3/8/2022 01:41, Tvrtko Ursulin wrote:

On 03/03/2022 22:37, john.c.harri...@intel.com wrote:

From: John Harrison 

A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.

However, this does not work well in GuC submission mode. In GuC mode,
the pre-emption timeout is how GuC detects hung contexts and triggers
a per engine reset. Thus, disabling the timeout means also losing all
per engine reset ability. A full GT reset will still occur when the
heartbeat finally expires, but that is a much more destructive and
undesirable mechanism.

The purpose of the workaround is actually to give OpenCL tasks longer
to reach a pre-emption point after a pre-emption request has been
issued. This is necessary because Gen12 does not support mid-thread
pre-emption and OpenCL can have long running threads.

So, rather than disabling the timeout completely, just set it to a
'long' value.

v2: Review feedback from Tvrtko - must hard code the 'long' value
instead of determining it algorithmically. So make it an extra CONFIG
definition. Also, remove the execlist centric comment from the
existing pre-emption timeout CONFIG option given that it applies to
more than just execlists.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 
 (v1)

Acked-by: Michal Mrozek 
---
  drivers/gpu/drm/i915/Kconfig.profile  | 26 
+++

  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 ++--
  2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile

index 39328567c200..7cc38d25ee5c 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT
  default 640 # milliseconds
  help
    How long to wait (in milliseconds) for a preemption event 
to occur
-  when submitting a new context via execlists. If the current 
context
-  does not hit an arbitration point and yield to HW before the 
timer
-  expires, the HW will be reset to allow the more important 
context

-  to execute.
+  when submitting a new context. If the current context does 
not hit
+  an arbitration point and yield to HW before the timer 
expires, the
+  HW will be reset to allow the more important context to 
execute.

+
+  This is adjustable via
+  /sys/class/drm/card?/engine/*/preempt_timeout_ms
+
+  May be 0 to disable the timeout.
+
+  The compiled in default may get overridden at driver probe 
time on
+  certain platforms and certain engines which will be 
reflected in the

+  sysfs control.
+
+config DRM_I915_PREEMPT_TIMEOUT_COMPUTE
+    int "Preempt timeout for compute engines (ms, jiffy granularity)"
+    default 7500 # milliseconds
+    help
+  How long to wait (in milliseconds) for a preemption event to 
occur
+  when submitting a new context to a compute capable engine. 
If the
+  current context does not hit an arbitration point and yield 
to HW
+  before the timer expires, the HW will be reset to allow the 
more

+  important context to execute.
      This is adjustable via
    /sys/class/drm/card?/engine/*/preempt_timeout_ms
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c

index 4185c7338581..cc0954ad836a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -438,9 +438,14 @@ static int intel_engine_setup(struct intel_gt 
*gt, enum intel_engine_id id,

  engine->props.timeslice_duration_ms =
  CONFIG_DRM_I915_TIMESLICE_DURATION;
  -    /* Override to uninterruptible for OpenCL workloads. */
+    /*
+ * Mid-thread pre-emption is not available in Gen12. 
Unfortunately,
+ * some OpenCL workloads run quite long threads. That means 
they get

+ * reset due to not pre-empting in a timely manner. So, bump the
+ * pre-emption timeout value to be much higher for compute 
engines.

+ */
  if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
I915_ENGINE_HAS_RCS_REG_STATE))

-    engine->props.preempt_timeout_ms = 0;
+    engine->props.preempt_timeout_ms = 
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE;


I wouldn't go as far as adding a config option since as it is it 
only applies to Gen12 but Kconfig text says nothing about that. And 
I am not saying you should add a Gen12 specific config option, that 
would be weird. So IMO just drop it.


You were the one arguing that the driver was illegally overriding the 
user's explicitly chosen settings, including the compile time config 


This is a bit out of context and illegally don't think use

[PATCH v2] drm/bridge: anx7625: Fix not correct get property counts

2022-03-11 Thread Xin Ji

The property length which returns from "of_get_property", it means array
bytes count if the property has prefix as "/bits/ 8". The driver should
call function "of_property_read_u8_array" to get correct array value.

Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI input feature")
Signed-off-by: Xin Ji 

---
V1 -> V2: Fix Sam comment, use of_property_read_u8_array to get array
value
---
 drivers/gpu/drm/bridge/analogix/anx7625.c | 8 
 drivers/gpu/drm/bridge/analogix/anx7625.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index c6a9a02ed762..628cbf769141 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1598,8 +1598,8 @@ static int anx7625_get_swing_setting(struct device *dev,
num_regs = DP_TX_SWING_REG_CNT;
 
pdata->dp_lane0_swing_reg_cnt = num_regs;
-   of_property_read_u32_array(dev->of_node, "analogix,lane0-swing",
-  pdata->lane0_reg_data, num_regs);
+   of_property_read_u8_array(dev->of_node, "analogix,lane0-swing",
+ pdata->lane0_reg_data, num_regs);
}
 
if (of_get_property(dev->of_node,
@@ -1608,8 +1608,8 @@ static int anx7625_get_swing_setting(struct device *dev,
num_regs = DP_TX_SWING_REG_CNT;
 
pdata->dp_lane1_swing_reg_cnt = num_regs;
-   of_property_read_u32_array(dev->of_node, "analogix,lane1-swing",
-  pdata->lane1_reg_data, num_regs);
+   of_property_read_u8_array(dev->of_node, "analogix,lane1-swing",
+ pdata->lane1_reg_data, num_regs);
}
 
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h 
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index edbbfe410a56..2c340f16f2c3 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -426,9 +426,9 @@ struct anx7625_platform_data {
int mipi_lanes;
int audio_en;
int dp_lane0_swing_reg_cnt;
-   int lane0_reg_data[DP_TX_SWING_REG_CNT];
int dp_lane1_swing_reg_cnt;
-   int lane1_reg_data[DP_TX_SWING_REG_CNT];
+   u8 lane0_reg_data[DP_TX_SWING_REG_CNT];
+   u8 lane1_reg_data[DP_TX_SWING_REG_CNT];
u32 low_power_mode;
struct device_node *mipi_host_node;
 };
-- 
2.25.1

Re: [PATCH V3 05/13] drm: bridge: icn6211: Add DSI lane count DT property parsing


On 3/10/22 15:18, Maxime Ripard wrote:

On Thu, Mar 10, 2022 at 01:47:13PM +0100, Marek Vasut wrote:

On 3/10/22 11:53, Maxime Ripard wrote:

On Tue, Mar 08, 2022 at 10:41:05PM +0100, Marek Vasut wrote:

On 3/8/22 17:21, Maxime Ripard wrote:

On Tue, Mar 08, 2022 at 03:47:22PM +0100, Marek Vasut wrote:

On 3/8/22 14:49, Maxime Ripard wrote:

On Tue, Mar 08, 2022 at 02:27:40PM +0100, Marek Vasut wrote:

On 3/8/22 13:51, Maxime Ripard wrote:

On Tue, Mar 08, 2022 at 11:29:59AM +0100, Marek Vasut wrote:

On 3/8/22 11:07, Jagan Teki wrote:

On Tue, Mar 8, 2022 at 3:19 PM Marek Vasut  wrote:


On 3/8/22 09:03, Jagan Teki wrote:

Hi,

[...]


@@ -314,7 +321,9 @@ static const struct drm_bridge_funcs chipone_bridge_funcs = 
{
static int chipone_parse_dt(struct chipone *icn)
{
   struct device *dev = icn->dev;
+   struct device_node *endpoint;
   struct drm_panel *panel;
+   int dsi_lanes;
   int ret;

   icn->vdd1 = devm_regulator_get_optional(dev, "vdd1");
@@ -350,15 +359,42 @@ static int chipone_parse_dt(struct chipone *icn)
   return PTR_ERR(icn->enable_gpio);
   }

+   endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
+   dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
+   icn->host_node = of_graph_get_remote_port_parent(endpoint);
+   of_node_put(endpoint);
+
+   if (!icn->host_node)
+   return -ENODEV;


The non-ports-based OF graph returns a -19 example on the Allwinner
Display pipeline in R16 [1].

We need to have a helper to return host_node for non-ports as I have
done it for drm_of_find_bridge.

[1] https://patchwork.amarulasolutions.com/patch/1805/


The link points to a patch marked "DO NOT MERGE", maybe that patch is
missing the DSI host port@0 OF graph link ? Both port@0 and port@1 are
required, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml#n53

What is "non-ports-based OF graph" ?

I don't see drm_of_find_bridge() in linux-next , what is that ?


port@0 is optional as some of the DSI host OF-graph represent the
bridge or panel as child nodes instead of ports. (i think dt-binding
has to fix it to make port@0 optional)


The current upstream DT binding document says:

 required:
   - port@0
   - port@1

So port@0 is mandatory.


In the binding, sure, but fundamentally the DT excerpt Jagan provided is
correct. If the bridge supports DCS, there's no reason to use the OF
graph in the first place: the bridge node will be a child node of the
MIPI-DSI controller (and there's no obligation to use the OF-graph for a
MIPI-DSI controller).

I believe port@0 should be made optional (or downright removed if
MIPI-DCS in the only control bus).


That's out of scope of this series anyway, so Jagan can implement patches
for that mode if needed.


Not really? You can't count on the port@0 being there generally
speaking, so you can't count on data-lanes being there either, which
exactly what you're doing in this patch.


I can because the upstream DT bindings currently say port@0 must be present,
see above. If that requirement should be relaxed, sure, but that's a
separate series.


And another upstream DT bindings say that you don't need them at all.


Which "another upstream DT bindings" do you refer to ?


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt


Yes, there's a conflict. Yes, it's unfortunate. But the generic DSI
binding is far more relevant than a single bridge driver.


That seems to be the wrong way around, how can generic subsystem-wide
binding take precedence over specific driver binding ?


This is the binding of the bus. You're part of that bus. You're a child
node of that bus, but nothing ever mandates that your parent node uses
the same convention. And some don't. And since your bridge can be
connected to pretty much any DSI controller, you have to use the lowest
common denominator, not make up some new constraints that not all
controller will be able to comply with.


It seems to me the ICN6211 DT bindings currently further constraint the
generic DSI bus bindings, and that seems OK to me.

Let me reiterate this again -- if someone wants to relax the requirements
currently imposed by the ICN6211 DT bindings, fine, but that can be done in
a separate patchset AND that needs DT bindings update. Furthermore, there
are no users of this ICN6211 bridge in upstream DTs, so there is currently
no bridge which would operate without OF graph using this driver.


And let me reiterate this again: something that used to work for a user
doesn't anymore when your series is applied. This is a textbook
regression. I suggested a way forward, that you don't like for some
reason, fine. But pushing through a regression is just not acceptable.


How can

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Improve long running OCL w/a for GuC submission

2022-03-11 Thread Tvrtko Ursulin




On 11/03/2022 10:07, Tvrtko Ursulin wrote:


On 10/03/2022 20:24, John Harrison wrote:

On 3/10/2022 01:27, Tvrtko Ursulin wrote:

On 09/03/2022 21:16, John Harrison wrote:

On 3/8/2022 01:41, Tvrtko Ursulin wrote:

On 03/03/2022 22:37, john.c.harri...@intel.com wrote:

From: John Harrison 

A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.

However, this does not work well in GuC submission mode. In GuC mode,
the pre-emption timeout is how GuC detects hung contexts and triggers
a per engine reset. Thus, disabling the timeout means also losing all
per engine reset ability. A full GT reset will still occur when the
heartbeat finally expires, but that is a much more destructive and
undesirable mechanism.

The purpose of the workaround is actually to give OpenCL tasks longer
to reach a pre-emption point after a pre-emption request has been
issued. This is necessary because Gen12 does not support mid-thread
pre-emption and OpenCL can have long running threads.

So, rather than disabling the timeout completely, just set it to a
'long' value.

v2: Review feedback from Tvrtko - must hard code the 'long' value
instead of determining it algorithmically. So make it an extra CONFIG
definition. Also, remove the execlist centric comment from the
existing pre-emption timeout CONFIG option given that it applies to
more than just execlists.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 
 (v1)

Acked-by: Michal Mrozek 
---
  drivers/gpu/drm/i915/Kconfig.profile  | 26 
+++

  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 ++--
  2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile

index 39328567c200..7cc38d25ee5c 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT
  default 640 # milliseconds
  help
    How long to wait (in milliseconds) for a preemption event 
to occur
-  when submitting a new context via execlists. If the current 
context
-  does not hit an arbitration point and yield to HW before 
the timer
-  expires, the HW will be reset to allow the more important 
context

-  to execute.
+  when submitting a new context. If the current context does 
not hit
+  an arbitration point and yield to HW before the timer 
expires, the
+  HW will be reset to allow the more important context to 
execute.

+
+  This is adjustable via
+  /sys/class/drm/card?/engine/*/preempt_timeout_ms
+
+  May be 0 to disable the timeout.
+
+  The compiled in default may get overridden at driver probe 
time on
+  certain platforms and certain engines which will be 
reflected in the

+  sysfs control.
+
+config DRM_I915_PREEMPT_TIMEOUT_COMPUTE
+    int "Preempt timeout for compute engines (ms, jiffy 
granularity)"

+    default 7500 # milliseconds
+    help
+  How long to wait (in milliseconds) for a preemption event 
to occur
+  when submitting a new context to a compute capable engine. 
If the
+  current context does not hit an arbitration point and yield 
to HW
+  before the timer expires, the HW will be reset to allow the 
more

+  important context to execute.
      This is adjustable via
    /sys/class/drm/card?/engine/*/preempt_timeout_ms
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c

index 4185c7338581..cc0954ad836a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -438,9 +438,14 @@ static int intel_engine_setup(struct intel_gt 
*gt, enum intel_engine_id id,

  engine->props.timeslice_duration_ms =
  CONFIG_DRM_I915_TIMESLICE_DURATION;
  -    /* Override to uninterruptible for OpenCL workloads. */
+    /*
+ * Mid-thread pre-emption is not available in Gen12. 
Unfortunately,
+ * some OpenCL workloads run quite long threads. That means 
they get

+ * reset due to not pre-empting in a timely manner. So, bump the
+ * pre-emption timeout value to be much higher for compute 
engines.

+ */
  if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
I915_ENGINE_HAS_RCS_REG_STATE))

-    engine->props.preempt_timeout_ms = 0;
+    engine->props.preempt_timeout_ms = 
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE;


I wouldn't go as far as adding a config option since as it is it 
only applies to Gen12 but Kconfig text says nothing about that. And 
I am not saying you should add a Gen12 specific config option, that 
would be weird. So IMO just drop it.


You were the one arguing that the driver was illegally overriding 
the user's explicitly chosen settings, including the compile time 
config 


This is a

Re: [Intel-gfx] [PATCH v2 0/8] Some more bits for small BAR enabling

2022-03-11 Thread Das, Nirmoy


The series is Acked-by: Nirmoy Das 


On 10/03/2022 13:27, Matthew Auld wrote:

The leftover bits around dealing with stolen-local memory + small BAR, plus
some related fixes.

v2: some tweaks based on feedback from Ville

[PATCH 1/2] dma-buf: add dma_fence_unwrap

2022-03-11 Thread Christian König

Add a general purpose helper to deep dive into dma_fence_chain/dma_fence_array
structures and iterate over all the fences in them.

This is useful when we need to flatten out all fences in those structures.

Signed-off-by: Christian König 
---
 Documentation/driver-api/dma-buf.rst  |   6 +
 drivers/dma-buf/Makefile  |   1 +
 drivers/dma-buf/selftests.h   |   1 +
 drivers/dma-buf/st-dma-fence-unwrap.c | 279 ++
 include/linux/dma-fence-unwrap.h  |  99 +
 5 files changed, 386 insertions(+)
 create mode 100644 drivers/dma-buf/st-dma-fence-unwrap.c
 create mode 100644 include/linux/dma-fence-unwrap.h

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 2cd7db82d9fe..7209500f08c8 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -194,6 +194,12 @@ DMA Fence Chain
 .. kernel-doc:: include/linux/dma-fence-chain.h
:internal:
 
+DMA Fence unwrap
+
+
+.. kernel-doc:: include/linux/dma-fence-unwrap.h
+   :internal:
+
 DMA Fence uABI/Sync File
 
 
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 511805dbeb75..4c9eb53ba3f8 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -12,6 +12,7 @@ dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
st-dma-fence-chain.o \
+   st-dma-fence-unwrap.o \
st-dma-resv.o
 
 obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
index 97d73aaa31da..851965867d9c 100644
--- a/drivers/dma-buf/selftests.h
+++ b/drivers/dma-buf/selftests.h
@@ -12,4 +12,5 @@
 selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
 selftest(dma_fence, dma_fence)
 selftest(dma_fence_chain, dma_fence_chain)
+selftest(dma_fence_unwrap, dma_fence_unwrap)
 selftest(dma_resv, dma_resv)
diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c 
b/drivers/dma-buf/st-dma-fence-unwrap.c
new file mode 100644
index ..d821faaebe93
--- /dev/null
+++ b/drivers/dma-buf/st-dma-fence-unwrap.c
@@ -0,0 +1,279 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright (C) 2022 Advanced Micro Devices, Inc.
+ */
+
+#include 
+#if 0
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+#include "selftest.h"
+
+#define CHAIN_SZ (4 << 10)
+
+static struct kmem_cache *slab_fences;
+
+static inline struct mock_fence {
+   struct dma_fence base;
+   spinlock_t lock;
+} *to_mock_fence(struct dma_fence *f) {
+   return container_of(f, struct mock_fence, base);
+}
+
+static const char *mock_name(struct dma_fence *f)
+{
+   return "mock";
+}
+
+static void mock_fence_release(struct dma_fence *f)
+{
+   kmem_cache_free(slab_fences, to_mock_fence(f));
+}
+
+static const struct dma_fence_ops mock_ops = {
+   .get_driver_name = mock_name,
+   .get_timeline_name = mock_name,
+   .release = mock_fence_release,
+};
+
+static struct dma_fence *mock_fence(void)
+{
+   struct mock_fence *f;
+
+   f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+   if (!f)
+   return NULL;
+
+   spin_lock_init(&f->lock);
+   dma_fence_init(&f->base, &mock_ops, &f->lock, 0, 0);
+
+   return &f->base;
+}
+
+static struct dma_fence *mock_array(unsigned int num_fences, ...)
+{
+   struct dma_fence_array *array;
+   struct dma_fence **fences;
+   va_list valist;
+   int i;
+
+   fences = kcalloc(num_fences, sizeof(*fences), GFP_KERNEL);
+   if (!fences)
+   return NULL;
+
+   va_start(valist, num_fences);
+   for (i = 0; i < num_fences; ++i)
+   fences[i] = va_arg(valist, typeof(*fences));
+   va_end(valist);
+
+   array = dma_fence_array_create(num_fences, fences,
+  dma_fence_context_alloc(1),
+  1, false);
+   if (!array)
+   goto cleanup;
+   return &array->base;
+
+cleanup:
+   for (i = 0; i < num_fences; ++i)
+   dma_fence_put(fences[i]);
+   kfree(fences);
+   return NULL;
+}
+
+static struct dma_fence *mock_chain(struct dma_fence *prev,
+   struct dma_fence *fence)
+{
+   struct dma_fence_chain *f;
+
+   f = dma_fence_chain_alloc();
+   if (!f) {
+   dma_fence_put(prev);
+   dma_fence_put(fence);
+   return NULL;
+   }
+
+   dma_fence_chain_init(f, prev, fence, 1);
+   return &f->base;
+}
+
+static int sanitycheck(void *arg)
+{
+   struct dma_fence *f, *chain, *array;
+   int err = 0;
+
+   f = mock_fence();
+   if (!f)
+   return -ENOMEM;
+
+   array = mock_array(1, f);
+   if (!array)
+   return -ENOMEM;
+
+   chain = mock_chain(NULL, array);
+   if (!chain)
+   return -ENOMEM;
+
+

[PATCH 2/2] dma-buf/sync-file: fix warning about fence containers

2022-03-11 Thread Christian König

The dma_fence_chain containers can show up in sync_files as well resulting in
warnings that those can't be added to dma_fence_array containers when merging
multiple sync_files together.

Solve this by using the dma_fence_unwrap iterator to deep dive into the
contained fences and then add those flatten out into a dma_fence_array.

Signed-off-by: Christian König 
---
 drivers/dma-buf/sync_file.c | 141 +++-
 1 file changed, 73 insertions(+), 68 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 394e6e1e9686..b8dea4ec123b 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2012 Google, Inc.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -172,20 +173,6 @@ static int sync_file_set_fence(struct sync_file *sync_file,
return 0;
 }
 
-static struct dma_fence **get_fences(struct sync_file *sync_file,
-int *num_fences)
-{
-   if (dma_fence_is_array(sync_file->fence)) {
-   struct dma_fence_array *array = 
to_dma_fence_array(sync_file->fence);
-
-   *num_fences = array->num_fences;
-   return array->fences;
-   }
-
-   *num_fences = 1;
-   return &sync_file->fence;
-}
-
 static void add_fence(struct dma_fence **fences,
  int *i, struct dma_fence *fence)
 {
@@ -210,86 +197,97 @@ static void add_fence(struct dma_fence **fences,
 static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
 struct sync_file *b)
 {
+   struct dma_fence *a_fence, *b_fence, **fences;
+   struct dma_fence_unwrap a_iter, b_iter;
+   unsigned int index, num_fences;
struct sync_file *sync_file;
-   struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
-   int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
 
sync_file = sync_file_alloc();
if (!sync_file)
return NULL;
 
-   a_fences = get_fences(a, &a_num_fences);
-   b_fences = get_fences(b, &b_num_fences);
-   if (a_num_fences > INT_MAX - b_num_fences)
-   goto err;
+   num_fences = 0;
+   dma_fence_unwrap_for_each(a_fence, &a_iter, a->fence)
+   ++num_fences;
+   dma_fence_unwrap_for_each(b_fence, &b_iter, b->fence)
+   ++num_fences;
 
-   num_fences = a_num_fences + b_num_fences;
+   if (num_fences > INT_MAX)
+   goto err_free_sync_file;
 
fences = kcalloc(num_fences, sizeof(*fences), GFP_KERNEL);
if (!fences)
-   goto err;
+   goto err_free_sync_file;
 
/*
-* Assume sync_file a and b are both ordered and have no
-* duplicates with the same context.
+* We can't guarantee that fences in both a and b are ordered, but it is
+* still quite likely.
 *
-* If a sync_file can only be created with sync_file_merge
-* and sync_file_create, this is a reasonable assumption.
+* So attempt to order the fences as we pass over them and merge fences
+* with the same context.
 */
-   for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
-   struct dma_fence *pt_a = a_fences[i_a];
-   struct dma_fence *pt_b = b_fences[i_b];
 
-   if (pt_a->context < pt_b->context) {
-   add_fence(fences, &i, pt_a);
+   index = 0;
+   for (a_fence = dma_fence_unwrap_first(a->fence, &a_iter),
+b_fence = dma_fence_unwrap_first(b->fence, &b_iter);
+a_fence || b_fence; ) {
+
+   if (!b_fence) {
+   add_fence(fences, &index, a_fence);
+   a_fence = dma_fence_unwrap_next(&a_iter);
+
+   } else if (!a_fence) {
+   add_fence(fences, &index, b_fence);
+   b_fence = dma_fence_unwrap_next(&b_iter);
+
+   } else if (a_fence->context < b_fence->context) {
+   add_fence(fences, &index, a_fence);
+   a_fence = dma_fence_unwrap_next(&a_iter);
 
-   i_a++;
-   } else if (pt_a->context > pt_b->context) {
-   add_fence(fences, &i, pt_b);
+   } else if (b_fence->context < a_fence->context) {
+   add_fence(fences, &index, b_fence);
+   b_fence = dma_fence_unwrap_next(&b_iter);
+
+   } else if (__dma_fence_is_later(a_fence->seqno, b_fence->seqno,
+   a_fence->ops)) {
+   add_fence(fences, &index, a_fence);
+   a_fence = dma_fence_unwrap_next(&a_iter);
+   b_fence = dma_fence_unwrap_next(&b_iter);
 
-   i_b++;
} else {
-   if (__dma_fe

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/display: Check mappable aperture when pinning preallocated vma

2022-03-11 Thread Matthew Auld

On Thu, 10 Mar 2022 at 12:28, Matthew Auld  wrote:
>
> From: CQ Tang 
>
> When system does not have mappable aperture, ggtt->mappable_end=0. In
> this case if we pass PIN_MAPPABLE when pinning vma, the pinning code
> will return -ENOSPC. So conditionally set PIN_MAPPABLE if HAS_GMCH().
>
> Suggested-by: Chris P Wilson 
> Signed-off-by: CQ Tang 
> Cc: Radhakrishna Sripada 
> Cc: Ap Kamal 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Ville Syrjälä 

This at least prevents incorrectly using PIN_MAPPABLE on discrete,
Reviewed-by: Matthew Auld 

> ---
>  drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 5227e5b35206..f797fcef18fc 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -51,6 +51,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> struct drm_i915_gem_object *obj;
> struct i915_vma *vma;
> u32 base, size;
> +   u64 pinctl;
>
> if (!mem || plane_config->size == 0)
> return NULL;
> @@ -101,7 +102,10 @@ initial_plane_vma(struct drm_i915_private *i915,
> if (IS_ERR(vma))
> goto err_obj;
>
> -   if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | 
> base))
> +   pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base;
> +   if (HAS_GMCH(i915))
> +   pinctl |= PIN_MAPPABLE;
> +   if (i915_vma_pin(vma, 0, 0, pinctl))
> goto err_obj;
>
> if (i915_gem_object_is_tiled(obj) &&
> --
> 2.34.1
>

Re: [PATCH v2] drm/bridge: anx7625: Fix not correct get property counts

2022-03-11 Thread Sam Ravnborg

Hi Xin.

On Fri, Mar 11, 2022 at 06:35:25PM +0800, Xin Ji wrote:
> The property length which returns from "of_get_property", it means array
> bytes count if the property has prefix as "/bits/ 8". The driver should
> call function "of_property_read_u8_array" to get correct array value.
> 
> Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI input feature")
> Signed-off-by: Xin Ji 
> 
> ---
> V1 -> V2: Fix Sam comment, use of_property_read_u8_array to get array
> value
> ---
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 8 
>  drivers/gpu/drm/bridge/analogix/anx7625.h | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index c6a9a02ed762..628cbf769141 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1598,8 +1598,8 @@ static int anx7625_get_swing_setting(struct device *dev,
>   num_regs = DP_TX_SWING_REG_CNT;
>  
>   pdata->dp_lane0_swing_reg_cnt = num_regs;
> - of_property_read_u32_array(dev->of_node, "analogix,lane0-swing",
> -pdata->lane0_reg_data, num_regs);
> + of_property_read_u8_array(dev->of_node, "analogix,lane0-swing",
> +   pdata->lane0_reg_data, num_regs);

The current implementation do a two step approach. First is find the
number of elements and then read the elements.
The number of elements is only used to limit what is read.

I suggest to use:

of_property_read_u8_array(dev->of_node, "analogix,lane0-swing",
  pdata->lane0_reg_data, DP_TX_SWING_REG_CNT);

Then you a guaranteed to read at maximum DP_TX_SWING_REG_CNT entries.
And as the number of elements is not stored anywhere that should be fine.

This looks simpler and matches what we for example do in
drivers/gpu/drm/arm/malidp_drv.c - the only user in gpu/ of
of_property_read_u8_array().


Sam

Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

2022-03-11 Thread Johannes Berg

On Tue, 2022-03-01 at 09:45 -0800, Rob Clark wrote:
> On Mon, Feb 28, 2022 at 10:49 PM David Laight  wrote:
> > 
> > From: Abhinav Kumar
> > > Sent: 28 February 2022 21:38
> > ...
> > > We also did some profiling around how much increasing the block size
> > > helps and here is the data:
> > > 
> > > Block sizecost
> > > 
> > > 4KB   229s
> > > 8KB86s
> > 
> > You must have an O(n^2) operation in there - find it.
> 
> The problem is how the devcoredump/sysfs interface works, which
> results in "re-rendering" the output for each block.. it's fine for
> moderate size sysfs files, but scales quite badly once you get into
> couple MB size sysfs files.
> 
> It could be fixed by having some way to keep state across successive
> read callbacks.

I'm not sure that's true? Perhaps for dev_coredumpm(), but only if you
implemented read() badly.

If you have e.g. dev_coredumpsg() or dev_coredumpv() that's just a
simple read from the existing buffer.

johannes

[PATCH v3 0/4] Ingenic DRM bridge_atomic_enable proposal

Hello, v3 :

Drop -spi in the compatible string, adjust bindings doc accordingly 

KR
Christophe



Hello, this is the v2 for my set of patches :

- use dev_err_probe() instead of dev_err() in the newvision panel
driver probe function

- add bindings documentation for the Leadtek ltk035c5444t

Cheers - Christophe



Hello, this is a set of patches to allow the upstreaming of the
NV3052C panel found in the Anbernic RG350M mips gaming handheld.

It was never upstreamed so far due to a longstanding graphical
bug, which I propose to solve by introducing ingenic_drm_bridge_atomic_enable
in the drm driver so the CRTC can be enabled after the panel itself slept
out, and not before as it used to.

After the drm change, 2 of the existing panels have to be modified accordingly
to introduce missing .enable and .disable in their code.

Christophe Branchereau (4):
  drm/ingenic : add ingenic_drm_bridge_atomic_enable
  drm/panel: Add panel driver for NewVision NV3052C based LCDs
  drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and
.disable
  dt-bindings: display/panel: Add Leadtek ltk035c5444t

 .../display/panel/leadtek,ltk035c5444t.yaml   |  59 +++
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  19 +-
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-abt-y030xx067a.c  |  23 +-
 drivers/gpu/drm/panel/panel-innolux-ej030na.c |  31 +-
 .../gpu/drm/panel/panel-newvision-nv3052c.c   | 497 ++
 7 files changed, 627 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c

-- 
2.35.1

[PATCH v3 1/4] drm/ingenic : add ingenic_drm_bridge_atomic_enable

This allows the CRTC to be enabled after panels have slept out,
and before their display is turned on, solving a graphical bug
on the newvision nv3502c

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821..51512f41263e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -226,6 +226,18 @@ static int ingenic_drm_update_pixclk(struct notifier_block 
*nb,
}
 }
 
+static void ingenic_drm_bridge_atomic_enable(struct drm_bridge *bridge,
+struct drm_bridge_state 
*old_bridge_state)
+{
+   struct ingenic_drm *priv = drm_device_get_priv(bridge->dev);
+
+   regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
+
+   regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
+  JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
+  JZ_LCD_CTRL_ENABLE);
+}
+
 static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
@@ -237,17 +249,11 @@ static void ingenic_drm_crtc_atomic_enable(struct 
drm_crtc *crtc,
if (WARN_ON(IS_ERR(priv_state)))
return;
 
-   regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
-
/* Set addresses of our DMA descriptor chains */
next_id = priv_state->use_palette ? HWDESC_PALETTE : 0;
regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv, next_id));
regmap_write(priv->map, JZ_REG_LCD_DA1, dma_hwdesc_addr(priv, 1));
 
-   regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
-  JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
-  JZ_LCD_CTRL_ENABLE);
-
drm_crtc_vblank_on(crtc);
 }
 
@@ -968,6 +974,7 @@ static const struct drm_encoder_helper_funcs 
ingenic_drm_encoder_helper_funcs =
 
 static const struct drm_bridge_funcs ingenic_drm_bridge_funcs = {
.attach = ingenic_drm_bridge_attach,
+   .atomic_enable  = ingenic_drm_bridge_atomic_enable,
.atomic_check   = ingenic_drm_bridge_atomic_check,
.atomic_reset   = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
-- 
2.35.1

[PATCH v3 2/4] drm/panel: Add panel driver for NewVision NV3052C based LCDs

This driver supports the NewVision NV3052C based LCDs. Right now, it
only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which
can be found in the Anbernic RG-350M handheld console.

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-newvision-nv3052c.c   | 497 ++
 3 files changed, 507 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bb2e47229c68..40084f709789 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -283,6 +283,15 @@ config DRM_PANEL_NEC_NL8048HL11
  panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
  as a module, choose M here.
 
+config DRM_PANEL_NEWVISION_NV3052C
+   tristate "NewVision NV3052C RGB/SPI panel"
+   depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select DRM_MIPI_DBI
+   help
+ Say Y here if you want to enable support for the panels built
+ around the NewVision NV3052C display controller.
+
 config DRM_PANEL_NOVATEK_NT35510
tristate "Novatek NT35510 RGB panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5740911f637c..42a7ab54234b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += 
panel-leadtek-ltk500hd1829.o
 obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
+obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) += panel-newvision-nv3052c.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c 
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
new file mode 100644
index ..fc31df0dee12
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NevVision NV3052C IPS LCD panel driver
+ *
+ * Copyright (C) 2020, Paul Cercueil 
+ * Copyright (C) 2022, Christophe Branchereau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct nv3052c_panel_info {
+   const struct drm_display_mode *display_modes;
+   unsigned int num_modes;
+   u16 width_mm, height_mm;
+   u32 bus_format, bus_flags;
+};
+
+struct nv3052c {
+   struct device *dev;
+   struct drm_panel panel;
+   struct mipi_dbi dbi;
+
+   const struct nv3052c_panel_info *panel_info;
+
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+};
+
+struct nv3052c_reg {
+   u8 cmd;
+   u8 val;
+};
+
+static const struct nv3052c_reg nv3052c_panel_regs[] = {
+   { 0xff, 0x30 },
+   { 0xff, 0x52 },
+   { 0xff, 0x01 },
+   { 0xe3, 0x00 },
+   { 0x40, 0x00 },
+   { 0x03, 0x40 },
+   { 0x04, 0x00 },
+   { 0x05, 0x03 },
+   { 0x08, 0x00 },
+   { 0x09, 0x07 },
+   { 0x0a, 0x01 },
+   { 0x0b, 0x32 },
+   { 0x0c, 0x32 },
+   { 0x0d, 0x0b },
+   { 0x0e, 0x00 },
+   { 0x23, 0xa0 },
+
+   { 0x24, 0x0c },
+   { 0x25, 0x06 },
+   { 0x26, 0x14 },
+   { 0x27, 0x14 },
+
+   { 0x38, 0xcc },
+   { 0x39, 0xd7 },
+   { 0x3a, 0x4a },
+
+   { 0x28, 0x40 },
+   { 0x29, 0x01 },
+   { 0x2a, 0xdf },
+   { 0x49, 0x3c },
+   { 0x91, 0x77 },
+   { 0x92, 0x77 },
+   { 0xa0, 0x55 },
+   { 0xa1, 0x50 },
+   { 0xa4, 0x9c },
+   { 0xa7, 0x02 },
+   { 0xa8, 0x01 },
+   { 0xa9, 0x01 },
+   { 0xaa, 0xfc },
+   { 0xab, 0x28 },
+   { 0xac, 0x06 },
+   { 0xad, 0x06 },
+   { 0xae, 0x06 },
+   { 0xaf, 0x03 },
+   { 0xb0, 0x08 },
+   { 0xb1, 0x26 },
+   { 0xb2, 0x28 },
+   { 0xb3, 0x28 },
+   { 0xb4, 0x33 },
+   { 0xb5, 0x08 },
+   { 0xb6, 0x26 },
+   { 0xb7, 0x08 },
+   { 0xb8, 0x26 },
+   { 0xf0, 0x00 },
+   { 0xf6, 0xc0 },
+
+   { 0xff, 0x30 },
+   { 0xff, 0x52 },
+   { 0xff, 0x02 },
+   { 0xb0, 0x0b },
+   { 0xb1, 0x16 },
+   { 0xb2, 0x17 },
+   { 0xb3, 0x2c },
+   { 0xb4, 0x32 },
+   { 0xb5, 0x3b },
+   { 0xb6, 0x29 },
+   { 0xb7, 0x40 },
+   { 0xb8, 0x0d },
+   { 0xb9, 0x05 },
+   { 0xba, 0x12 },
+   { 0xbb, 0x10 },
+   { 0xbc, 0x12 },
+   { 0xbd, 0x15 },
+   { 0xbe, 0x19 },
+   { 0xbf, 0x0e },
+   { 0xc0, 0x16 },
+   { 0xc1, 0x0a },
+   { 0xd0, 0x0c },
+   { 0xd1, 0x17 }

[PATCH v3 3/4] drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and .disable

Following the introduction of bridge_atomic_enable in the ingenic
drm driver, the crtc is enabled between .prepare and .enable, if
it exists.

Add it so the backlight is only enabled after the crtc is, to avoid
graphical issues.

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/panel/panel-abt-y030xx067a.c  | 23 --
 drivers/gpu/drm/panel/panel-innolux-ej030na.c | 31 ---
 2 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c 
b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
index f043b484055b..b5736344e3ec 100644
--- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
+++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
@@ -183,8 +183,6 @@ static int y030xx067a_prepare(struct drm_panel *panel)
goto err_disable_regulator;
}
 
-   msleep(120);
-
return 0;
 
 err_disable_regulator:
@@ -202,6 +200,25 @@ static int y030xx067a_unprepare(struct drm_panel *panel)
return 0;
 }
 
+static int y030xx067a_enable(struct drm_panel *panel)
+{
+   if (panel->backlight) {
+   /* Wait for the picture to be ready before enabling backlight */
+   msleep(120);
+   }
+
+   return 0;
+}
+
+static int y030xx067a_disable(struct drm_panel *panel)
+{
+   struct y030xx067a *priv = to_y030xx067a(panel);
+
+   regmap_clear_bits(priv->map, 0x06, REG06_XPSAVE);
+
+   return 0;
+}
+
 static int y030xx067a_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
 {
@@ -239,6 +256,8 @@ static int y030xx067a_get_modes(struct drm_panel *panel,
 static const struct drm_panel_funcs y030xx067a_funcs = {
.prepare= y030xx067a_prepare,
.unprepare  = y030xx067a_unprepare,
+   .enable = y030xx067a_enable,
+   .disable= y030xx067a_disable,
.get_modes  = y030xx067a_get_modes,
 };
 
diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c 
b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
index c558de3f99be..6de7370185cd 100644
--- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
+++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
@@ -80,8 +80,6 @@ static const struct reg_sequence ej030na_init_sequence[] = {
{ 0x47, 0x08 },
{ 0x48, 0x0f },
{ 0x49, 0x0f },
-
-   { 0x2b, 0x01 },
 };
 
 static int ej030na_prepare(struct drm_panel *panel)
@@ -109,8 +107,6 @@ static int ej030na_prepare(struct drm_panel *panel)
goto err_disable_regulator;
}
 
-   msleep(120);
-
return 0;
 
 err_disable_regulator:
@@ -128,6 +124,31 @@ static int ej030na_unprepare(struct drm_panel *panel)
return 0;
 }
 
+static int ej030na_enable(struct drm_panel *panel)
+{
+   struct ej030na *priv = to_ej030na(panel);
+
+   /* standby off */
+   regmap_write(priv->map, 0x2b, 0x01);
+
+   if (panel->backlight) {
+   /* Wait for the picture to be ready before enabling backlight */
+   msleep(120);
+   }
+
+   return 0;
+}
+
+static int ej030na_disable(struct drm_panel *panel)
+{
+   struct ej030na *priv = to_ej030na(panel);
+
+   /* standby on */
+   regmap_write(priv->map, 0x2b, 0x00);
+
+   return 0;
+}
+
 static int ej030na_get_modes(struct drm_panel *panel,
 struct drm_connector *connector)
 {
@@ -165,6 +186,8 @@ static int ej030na_get_modes(struct drm_panel *panel,
 static const struct drm_panel_funcs ej030na_funcs = {
.prepare= ej030na_prepare,
.unprepare  = ej030na_unprepare,
+   .enable = ej030na_enable,
+   .disable= ej030na_disable,
.get_modes  = ej030na_get_modes,
 };
 
-- 
2.35.1

[PATCH v3 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

Add binding for the leadtek ltk035c5444t, which is a 640x480
mipi-dbi over spi / 24-bit RGB panel based on the newvision
NV03052C chipset.

It is found in the Anbernic RG350M mips handheld.

Signed-off-by: Christophe Branchereau 
---
 .../display/panel/leadtek,ltk035c5444t.yaml   | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml 
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
new file mode 100644
index ..9e728f8ce0cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk035c5444t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek ltk035c5444t 3.5" (640x480 pixels) 24-bit IPS LCD panel
+
+maintainers:
+  - Paul Cercueil 
+  - Christophe Branchereau 
+
+allOf:
+  - $ref: panel-common.yaml#
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+  compatible:
+const: leadtek,ltk035c5444t
+
+  backlight: true
+  port: true
+  power-supply: true
+  reg: true
+  reset-gpios: true
+
+required:
+  - compatible
+  - power-supply
+  - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk035c5444t";
+reg = <0>;
+
+spi-3wire;
+spi-max-frequency = <3125000>;
+
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <&panel_output>;
+};
+};
+};
+};
-- 
2.35.1

Re: [PATCH v2] drm/amdgpu: Add support for drm_privacy_screen

2022-03-11 Thread Hans de Goede

Hi All,

On 3/9/22 18:53, Rajat Jain wrote:
> On Wed, Mar 9, 2022 at 7:06 AM Sean Paul  wrote:
>>
>> From: Sean Paul 
>>
>> This patch adds the necessary hooks to make amdgpu aware of privacy
>> screens. On devices with privacy screen drivers (such as thinkpad-acpi),
>> the amdgpu driver will defer probe until it's ready and then sync the sw
>> and hw state on each commit the connector is involved and enabled.
>>
>> Changes in v2:
>> -Tweaked the drm_privacy_screen_get() error check to avoid logging
>>  errors when privacy screen is absent (Hans)
>>
>> Signed-off-by: Sean Paul 
>> Link: https://patchwork.freedesktop.org/patch/477640/ #v1
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  9 +
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  3 +++
>>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  | 16 +++-
>>  3 files changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 2ab675123ae3..e2cfae56c020 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -26,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "amdgpu_drv.h"
>> @@ -1988,6 +1989,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>>  {
>> struct drm_device *ddev;
>> struct amdgpu_device *adev;
>> +   struct drm_privacy_screen *privacy_screen;
>> unsigned long flags = ent->driver_data;
>> int ret, retry = 0, i;
>> bool supports_atomic = false;
>> @@ -2063,6 +2065,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>> size = pci_resource_len(pdev, 0);
>> is_fw_fb = amdgpu_is_fw_framebuffer(base, size);
>>
>> +   /* If the LCD panel has a privacy screen, defer probe until its 
>> ready */
>> +   privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
>> +   if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == 
>> -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>> +
>> +   drm_privacy_screen_put(privacy_screen);
>> +
>> /* Get rid of things like offb */
>> ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
>> &amdgpu_kms_driver);
>> if (ret)
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index e1d3db3fe8de..9e2bb6523add 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -9781,6 +9781,9 @@ static void amdgpu_dm_atomic_commit_tail(struct 
>> drm_atomic_state *state)
>> if (acrtc) {
>> new_crtc_state = 
>> drm_atomic_get_new_crtc_state(state, &acrtc->base);
>> old_crtc_state = 
>> drm_atomic_get_old_crtc_state(state, &acrtc->base);
>> +
>> +   /* Sync the privacy screen state between hw and sw */
>> +   drm_connector_update_privacy_screen(new_con_state);
>> }
>>
>> /* Skip any modesets/resets */
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> index 740435ae3997..594a8002975a 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> @@ -27,6 +27,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "dm_services.h"
>>  #include "amdgpu.h"
>>  #include "amdgpu_dm.h"
>> @@ -506,6 +507,7 @@ void amdgpu_dm_initialize_dp_connector(struct 
>> amdgpu_display_manager *dm,
>>struct amdgpu_dm_connector 
>> *aconnector,
>>int link_index)
>>  {
>> +   struct drm_device *dev = dm->ddev;
>> struct dc_link_settings max_link_enc_cap = {0};
>>
>> aconnector->dm_dp_aux.aux.name =
>> @@ -519,8 +521,20 @@ void amdgpu_dm_initialize_dp_connector(struct 
>> amdgpu_display_manager *dm,
>> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
>>   &aconnector->base);
>>
>> -   if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
>> +   if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +   struct drm_privacy_screen *privacy_screen)
>> +
>> +   /* Reference given up in drm_connector_cleanup() */
>> +   privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
> 
> Can we try to be more specific when looking up for privacy screen, e.g.:
> 
> privacy_screen = drm_privacy_screen_get(dev->dev,  "eDP-1");
> (and then also making the corresponding change in arch_init_data[] in
> drm_privacy_screen_x86.c"

So I just checked and yes I think we can be more specific at least
for the thinkpad_acpi supporte

[PATCH 0/2] drm/i915: Avoid explicit IRQ-off sections.

2022-03-11 Thread Sebastian Andrzej Siewior

Hi,

these two patches are from the RT queue. They avoid IRQ-off checks and
IRQ-off regions which are not valid/ possible on PREEMPT_RT and are not
needed on !PREEMPT_RT.

Sebastian

[PATCH 1/2] drm/i915/gt: Queue and wait for the irq_work item.

2022-03-11 Thread Sebastian Andrzej Siewior

Disabling interrupts and invoking the irq_work function directly breaks
on PREEMPT_RT.
PREEMPT_RT does not invoke all irq_work from hardirq context because
some of the user have spinlock_t locking in the callback function.
These locks are then turned into a sleeping locks which can not be
acquired with disabled interrupts.

Using irq_work_queue() has the benefit that the irqwork will be invoked
in the regular context. In general there is "no" delay between enqueuing
the callback and its invocation because the interrupt is raised right
away on architectures which support it (which includes x86).

Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.

Reported-by: Clark Williams 
Signed-off-by: Sebastian Andrzej Siewior 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 209cf265bf746..98efeb97a6ba6 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -311,9 +311,8 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
/* Kick the work once more to drain the signalers, and disarm the irq */
irq_work_sync(&b->irq_work);
while (READ_ONCE(b->irq_armed) && !atomic_read(&b->active)) {
-   local_irq_disable();
-   signal_irq_work(&b->irq_work);
-   local_irq_enable();
+   irq_work_queue(&b->irq_work);
+   irq_work_sync(&b->irq_work);
cond_resched();
}
 }
-- 
2.35.1

[PATCH 2/2] drm/i915: Drop the irqs_disabled() check

2022-03-11 Thread Sebastian Andrzej Siewior

The !irqs_disabled() check triggers on PREEMPT_RT even with
i915_sched_engine::lock acquired. The reason is the lock is transformed
into a sleeping lock on PREEMPT_RT and does not disable interrupts.

There is no need to check for disabled interrupts. The lockdep
annotation below already check if the lock has been acquired by the
caller and will yell if the interrupts are not disabled.

Remove the !irqs_disabled() check.

Reported-by: Maarten Lankhorst 
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/gpu/drm/i915/i915_request.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 76cf5ac91e946..41d7c1071ab52 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -583,7 +583,6 @@ bool __i915_request_submit(struct i915_request *request)
 
RQ_TRACE(request, "\n");
 
-   GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(&engine->sched_engine->lock);
 
/*
@@ -692,7 +691,6 @@ void __i915_request_unsubmit(struct i915_request *request)
 */
RQ_TRACE(request, "\n");
 
-   GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(&engine->sched_engine->lock);
 
/*
-- 
2.35.1

Re: [PATCH v2 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

2022-03-11 Thread Paul Cercueil


Hi Rob,

Le jeu., mars 10 2022 at 16:30:26 -0600, Rob Herring  
a écrit :
On Tue, Mar 08, 2022 at 02:06:43PM +0100, Christophe Branchereau 
wrote:

 Add binding for the leadtek ltk035c5444t, which is a 640x480
 mipi-dbi over spi / 24-bit RGB panel based on the newvision
 NV03052C chipset.

 It is found in the Anbernic RG350M mips handheld.

 Signed-off-by: Christophe Branchereau 
 ---
  .../panel/leadtek,ltk035c5444t-spi.yaml   | 59 
+++

  1 file changed, 59 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t-spi.yaml


We have 18 SPI based panels already:

$ git grep -i 'spi.* {' 
Documentation/devicetree/bindings/display/panel/
Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml:  
  spi {
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml:  
  spi {
Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml:  
  spi {
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml:  
  spi {
Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml:
spi {
Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml:  
  spi0 {
Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml:  
  spi {
Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml: 
   spi {
Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml:  
  spi {

Documentation/devicetree/bindings/display/panel/tpo,td.yaml:spi {
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml:
spi {


Most except for the Samsung ones look like they'd fit in our 
definition

of 'simple panels' which primarily means 1 supply.

So I think it is time for a panel-simple-spi.yaml binding to combine 
all

these. But I'm not going to make the person adding the 19th case to do
that, and this otherwise looks fine:

Reviewed-by: Rob Herring 


I actually thought you sent a patch for this already (I remember you 
talking about it last a binding for a new SPI panel has been added).


I will work on it next week - provided Cristophe's patch has been 
merged before.


Cheers,
-Paul



With one nit fixed below:



 diff --git 
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t-spi.yaml 
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t-spi.yaml

 new file mode 100644
 index ..9b6f1810adab
 --- /dev/null
 +++ 
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t-spi.yaml

 @@ -0,0 +1,59 @@
 +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 +%YAML 1.2
 +---
 +$id: 
http://devicetree.org/schemas/display/panel/leadtek,ltk035c5444t-spi.yaml#

 +$schema: http://devicetree.org/meta-schemas/core.yaml#
 +
 +title: Leadtek ltk035c5444t 3.5" (640x480 pixels) 24-bit IPS LCD 
panel

 +
 +maintainers:
 +  - Paul Cercueil 
 +  - Christophe Branchereau 
 +
 +allOf:
 +  - $ref: panel-common.yaml#
 +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
 +
 +properties:
 +  compatible:
 +const: leadtek,ltk035c5444t-spi


'-spi' is redundant, so drop.


 +
 +  backlight: true
 +  port: true
 +  power-supply: true
 +  reg: true
 +  reset-gpios: true
 +
 +required:
 +  - compatible
 +  - power-supply
 +  - reset-gpios
 +
 +unevaluatedProperties: false
 +
 +examples:
 +  - |
 +#include 
 +
 +spi {
 +#address-cells = <1>;
 +#size-cells = <0>;
 +panel@0 {
 +compatible = "leadtek,ltk035c5444t-spi";


And update the example...


 +reg = <0>;
 +
 +spi-3wire;
 +spi-max-frequency = <3125000>;
 +
 +reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
 +
 +backlight = <&backlight>;
 +power-supply = <&vcc>;
 +
 +port {
 +panel_input: endpoint {
 +remote-endpoint = <&panel_output>;
 +};
 +};
 +};
 +};
 --
 2.34.1

Re: BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_vblanks()

2022-03-11 Thread Maxime Ripard

Hi Dmitry,

On Thu, Mar 10, 2022 at 03:33:07AM +0300, Dmitry Osipenko wrote:
> I was playing/testing SuperTuxKart using VirtIO-GPU driver and spotted a
> UAF bug in drm_atomic_helper_wait_for_vblanks().
> 
> SuperTuxKart can use DRM directly, i.e. you can run game in VT without
> Xorg or Wayland, this is where bugs happens. SuperTuxKart uses a
> non-blocking atomic page flips and UAF happens when a new atomic state
> is committed while there is a previous page flip still in-fly.
> 
> What happens is that the new and old atomic states refer to the same
> CRTC state somehow. Once the older atomic state is destroyed, the CRTC
> state is freed and the newer atomic state continues to use the freed
> CRTC state.

I'm not sure what you mean by "the new and old atomic states refer to
the same CRTC state", are those the same pointers?

> The bug is easily reproducible (at least by me) by playing SuperTuxKart
> for a minute. It presents on latest -next and 5.17-rc7, I haven't
> checked older kernel versions.
> 
> I'm not an expert of the non-blocking code paths in DRM, so asking for
> suggestions about where the root of the problem could be.

Does it occur with other platforms? Can you easily test on something else?

Thanks,
Maxime


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP

Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next drm/drm-next 
next-20220310]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next 
airlied/drm-next v5.17-rc7]
[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/Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-debian-10.3 
(https://download.01.org/0day-ci/archive/20220311/202203112245.edvnthye-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/38985b2e6acdbe67dedb5de8a8aeef917b746453
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
git checkout 38985b2e6acdbe67dedb5de8a8aeef917b746453
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/intel_sseu.c:59:5: warning: no previous prototype 
>> for 'intel_sseu_get_geometry_subslices' [-Wmissing-prototypes]
  59 | u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info 
*sseu)
 | ^


vim +/intel_sseu_get_geometry_subslices +59 drivers/gpu/drm/i915/gt/intel_sseu.c

58  
  > 59  u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
60  {
61  return _intel_sseu_get_subslices(sseu, 
sseu->geometry_subslice_mask, 0);
62  }
63  

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP

Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next drm/drm-next 
next-20220310]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next 
v5.17-rc7]
[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/Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a013 
(https://download.01.org/0day-ci/archive/20220311/202203112234.rtvksbsq-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
276ca87382b8f16a65bddac700202924228982f6)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/38985b2e6acdbe67dedb5de8a8aeef917b746453
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
git checkout 38985b2e6acdbe67dedb5de8a8aeef917b746453
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/ net/core/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/intel_sseu.c:59:5: warning: no previous prototype 
>> for function 'intel_sseu_get_geometry_subslices' [-Wmissing-prototypes]
   u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
   ^
   drivers/gpu/drm/i915/gt/intel_sseu.c:59:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
   u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
   ^
   static 
   1 warning generated.


vim +/intel_sseu_get_geometry_subslices +59 drivers/gpu/drm/i915/gt/intel_sseu.c

58  
  > 59  u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
60  {
61  return _intel_sseu_get_subslices(sseu, 
sseu->geometry_subslice_mask, 0);
62  }
63  

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v8 10/24] dt-bindings: display: rockchip: dw-hdmi: Add additional clock

2022-03-11 Thread Rob Herring

On Fri, 11 Mar 2022 09:33:09 +0100, Sascha Hauer wrote:
> The rk3568 HDMI has an additional clock that needs to be enabled for the
> HDMI controller to work. It is not needed for the HDMI controller
> itself, but to make the SoC internal busses work.
> 
> Signed-off-by: Sascha Hauer 
> ---
> 
> Notes:
> Changes since v7:
> - rename hclk to niu
> 
>  .../bindings/display/rockchip/rockchip,dw-hdmi.yaml| 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring

Re: [PATCH v3 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

2022-03-11 Thread Rob Herring

On Fri, Mar 11, 2022 at 01:04:53PM +0100, Christophe Branchereau wrote:
> Add binding for the leadtek ltk035c5444t, which is a 640x480
> mipi-dbi over spi / 24-bit RGB panel based on the newvision
> NV03052C chipset.
> 
> It is found in the Anbernic RG350M mips handheld.
> 
> Signed-off-by: Christophe Branchereau 
> ---
>  .../display/panel/leadtek,ltk035c5444t.yaml   | 59 +++
>  1 file changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml 
> b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> new file mode 100644
> index ..9e728f8ce0cd
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: GPL-2.0

Why did you change the license? It was correct before.

Rob

Re: [PATCH v2 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

2022-03-11 Thread Rob Herring

On Fri, Mar 11, 2022 at 7:05 AM Paul Cercueil  wrote:
>
> Hi Rob,
>
> Le jeu., mars 10 2022 at 16:30:26 -0600, Rob Herring 
> a écrit :
> > On Tue, Mar 08, 2022 at 02:06:43PM +0100, Christophe Branchereau
> > wrote:
> >>  Add binding for the leadtek ltk035c5444t, which is a 640x480
> >>  mipi-dbi over spi / 24-bit RGB panel based on the newvision
> >>  NV03052C chipset.
> >>
> >>  It is found in the Anbernic RG350M mips handheld.
> >>
> >>  Signed-off-by: Christophe Branchereau 
> >>  ---
> >>   .../panel/leadtek,ltk035c5444t-spi.yaml   | 59
> >> +++
> >>   1 file changed, 59 insertions(+)
> >>   create mode 100644
> >> Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t-spi.yaml
> >
> > We have 18 SPI based panels already:
> >
> > $ git grep -i 'spi.* {'
> > Documentation/devicetree/bindings/display/panel/
> > Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml:
> > spi {
> > Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml:
> >   spi0 {
> > Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml:
> >spi {
> > Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml:
> >   spi {
> > Documentation/devicetree/bindings/display/panel/tpo,td.yaml:spi {
> > Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml:
> > spi {
> >
> > Most except for the Samsung ones look like they'd fit in our
> > definition
> > of 'simple panels' which primarily means 1 supply.
> >
> > So I think it is time for a panel-simple-spi.yaml binding to combine
> > all
> > these. But I'm not going to make the person adding the 19th case to do
> > that, and this otherwise looks fine:
> >
> > Reviewed-by: Rob Herring 
>
> I actually thought you sent a patch for this already (I remember you
> talking about it last a binding for a new SPI panel has been added).

It was just adding spi-peripheral-props.yaml reference that I sent.

> I will work on it next week - provided Cristophe's patch has been
> merged before.

Thanks!

Rob

Re: [PATCH v3 3/3] drm/bridge: ti-sn65dsi86: Support hotplug detection

2022-03-11 Thread Doug Anderson

Hi,

On Thu, Mar 10, 2022 at 9:47 PM Kieran Bingham
 wrote:
>
> > > +static void ti_sn_bridge_hpd_disable(struct drm_bridge *bridge)
> > > +{
> > > +   struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> > > +
> > > +   regmap_write(pdata->regmap, SN_IRQ_HPD_REG, 0);
> > > +   pm_runtime_put_autosuspend(pdata->dev);
> >
> > Before doing the pm_runtime_put_autosuspend() it feels like you should
> > ensure that the interrupt has finished. Otherwise we could be midway
> > through processing an interrupt and the pm_runtime reference could go
> > away, right? Maybe we just disable the irq which I think will wait for
> > anything outstanding to finish?
>
> Should the IRQ handler also call pm_runtime_get/put then?

I thought about that, but I suspect it's cleaner to disable the IRQ
handler (and block waiting for it to finish if it was running). That
will ensure that the core isn't notified about HPD after HPD was
disabled.  Once you do that then there's no need to get/put in the irq
handler since we always hold a pm_runtime reference when the IRQ
handler is enabled.


> > > @@ -1247,9 +1342,29 @@ static int ti_sn_bridge_probe(struct 
> > > auxiliary_device *adev,
> > > pdata->bridge.type = pdata->next_bridge->type == 
> > > DRM_MODE_CONNECTOR_DisplayPort
> > >? DRM_MODE_CONNECTOR_DisplayPort : 
> > > DRM_MODE_CONNECTOR_eDP;
> > >
> > > -   if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
> > > +   if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
> > > pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > >
> > > +   if (!pdata->no_hpd)
> > > +   pdata->bridge.ops |= DRM_BRIDGE_OP_DETECT;
> > > +   }
> > > +
> > > +   if (!pdata->no_hpd && pdata->irq > 0) {
> > > +   dev_err(pdata->dev, "registering IRQ %d\n", pdata->irq);
> > > +
> > > +   ret = devm_request_threaded_irq(pdata->dev, pdata->irq, 
> > > NULL,
> > > +   ti_sn65dsi86_irq_handler,
> > > +   IRQF_ONESHOT, 
> > > "sn65dsi86-irq",
> > > +   pdata);
> > > +   if (ret)
> > > +   return dev_err_probe(pdata->dev, ret,
> > > +"Failed to register DP 
> > > interrupt\n");
> > > +
> > > +   /* Enable IRQ based HPD */
> > > +   regmap_write(pdata->regmap, SN_IRQ_EN_REG, IRQ_EN);
> >
> > Why not put the above regmap_write() in the ti_sn_bridge_hpd_enable() call?
>
> I assumed the IRQ handler may get used by other non-HPD events. Which is
> also why it was originally registered in the main probe(). HPD is just
> one feature of the interrupts. Of course it's only used for HPD now
> though. I guess I could have solved the bridge dependency by splitting
> the IRQ handler to have a dedicated HPD handler function which would
> return if the bridge wasn't initialised, but went with the deferred
> registration of the handler.
>
> I can move this and then leave it to anyone else implementing further
> IRQ features to refactor if needed.

Sounds good. In general the pm_runtime_get reference need to go with
the IRQ enabling, so if someone else finds a non-HPD need then they'll
have to move that too.

Re: [PATCH 1/2] dma-buf: add dma_fence_unwrap

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.17-rc7 next-20220310]
[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/Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
79b00034e9dcd2b065c1665c8b42f62b6b80a9be
config: microblaze-randconfig-r011-20220310 
(https://download.01.org/0day-ci/archive/20220311/202203112305.wceordi2-...@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/088aa14c0f5cad378854823fa661ee145dd2c01b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
git checkout 088aa14c0f5cad378854823fa661ee145dd2c01b
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/dma-buf/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/dma-buf/st-dma-fence-unwrap.c:7:
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_array':
   include/linux/dma-fence-unwrap.h:44:25: error: implicit declaration of 
function 'dma_fence_chain_contained'; did you mean 'dma_fence_chain_init'? 
[-Werror=implicit-function-declaration]
  44 | cursor->array = dma_fence_chain_contained(cursor->chain);
 | ^
 | dma_fence_chain_init
   include/linux/dma-fence-unwrap.h:44:23: warning: assignment to 'struct 
dma_fence *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  44 | cursor->array = dma_fence_chain_contained(cursor->chain);
 |   ^
   include/linux/dma-fence-unwrap.h:46:16: error: implicit declaration of 
function 'dma_fence_array_first'; did you mean 'dma_fence_array_create'? 
[-Werror=implicit-function-declaration]
  46 | return dma_fence_array_first(cursor->array);
 |^
 |dma_fence_array_create
   include/linux/dma-fence-unwrap.h:46:16: warning: returning 'int' from a 
function with return type 'struct dma_fence *' makes pointer from integer 
without a cast [-Wint-conversion]
  46 | return dma_fence_array_first(cursor->array);
 |^~~~
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_next':
   include/linux/dma-fence-unwrap.h:77:15: error: implicit declaration of 
function 'dma_fence_array_next'; did you mean 'dma_fence_unwrap_next'? 
[-Werror=implicit-function-declaration]
  77 | tmp = dma_fence_array_next(cursor->array, cursor->index);
 |   ^~~~
 |   dma_fence_unwrap_next
   include/linux/dma-fence-unwrap.h:77:13: warning: assignment to 'struct 
dma_fence *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  77 | tmp = dma_fence_array_next(cursor->array, cursor->index);
 | ^
   drivers/dma-buf/st-dma-fence-unwrap.c: In function 'unwrap_array':
>> drivers/dma-buf/st-dma-fence-unwrap.c:133:13: warning: variable 'err' set 
>> but not used [-Wunused-but-set-variable]
 133 | int err = 0;
 | ^~~
   drivers/dma-buf/st-dma-fence-unwrap.c: In function 'unwrap_chain':
   drivers/dma-buf/st-dma-fence-unwrap.c:175:13: warning: variable 'err' set 
but not used [-Wunused-but-set-variable]
 175 | int err = 0;
 | ^~~
   drivers/dma-buf/st-dma-fence-unwrap.c: In function 'unwrap_chain_array':
   drivers/dma-buf/st-dma-fence-unwrap.c:217:13: warning: variable 'err' set 
but not used [-Wunused-but-set-variable]
 217 | int err = 0;
 | ^~~
   cc1: some warnings being treated as errors


vim +/err +133 drivers/dma-buf/st-dma-fence-unwrap.c

   128  
   129  static int unwrap_array(void *arg)
   130  {
   131  struct dma_fence *fence, *f1, *f2, *array

Re: [PATCH 2/2] dma-buf/sync-file: fix warning about fence containers

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.17-rc7 next-20220310]
[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/Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
79b00034e9dcd2b065c1665c8b42f62b6b80a9be
config: x86_64-randconfig-m001 
(https://download.01.org/0day-ci/archive/20220312/202203120047.syxpis6h-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
git checkout ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/dma-buf/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/dma-buf/sync_file.c:8:
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_array':
   include/linux/dma-fence-unwrap.h:44:18: error: implicit declaration of 
function 'dma_fence_chain_contained'; did you mean 'dma_fence_chain_init'? 
[-Werror=implicit-function-declaration]
  44 |  cursor->array = dma_fence_chain_contained(cursor->chain);
 |  ^
 |  dma_fence_chain_init
>> include/linux/dma-fence-unwrap.h:44:16: warning: assignment to 'struct 
>> dma_fence *' from 'int' makes pointer from integer without a cast 
>> [-Wint-conversion]
  44 |  cursor->array = dma_fence_chain_contained(cursor->chain);
 |^
   include/linux/dma-fence-unwrap.h:46:9: error: implicit declaration of 
function 'dma_fence_array_first'; did you mean 'dma_fence_array_create'? 
[-Werror=implicit-function-declaration]
  46 |  return dma_fence_array_first(cursor->array);
 | ^
 | dma_fence_array_create
>> include/linux/dma-fence-unwrap.h:46:9: warning: returning 'int' from a 
>> function with return type 'struct dma_fence *' makes pointer from integer 
>> without a cast [-Wint-conversion]
  46 |  return dma_fence_array_first(cursor->array);
 | ^~~~
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_next':
   include/linux/dma-fence-unwrap.h:77:8: error: implicit declaration of 
function 'dma_fence_array_next'; did you mean 'dma_fence_unwrap_next'? 
[-Werror=implicit-function-declaration]
  77 |  tmp = dma_fence_array_next(cursor->array, cursor->index);
 |^~~~
 |dma_fence_unwrap_next
   include/linux/dma-fence-unwrap.h:77:6: warning: assignment to 'struct 
dma_fence *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  77 |  tmp = dma_fence_array_next(cursor->array, cursor->index);
 |  ^
   cc1: some warnings being treated as errors


vim +44 include/linux/dma-fence-unwrap.h

088aa14c0f5cad Christian König 2022-03-11  33  
088aa14c0f5cad Christian König 2022-03-11  34  /**
088aa14c0f5cad Christian König 2022-03-11  35   * dma_fence_unwrap_array - 
helper to unwrap dma_fence_arrays
088aa14c0f5cad Christian König 2022-03-11  36   * @cursor: cursor to initialize
088aa14c0f5cad Christian König 2022-03-11  37   *
088aa14c0f5cad Christian König 2022-03-11  38   * Helper function to unwrap 
dma_fence_array containers, don't touch directly.
088aa14c0f5cad Christian König 2022-03-11  39   * Use 
dma_fence_unwrap_first/next instead.
088aa14c0f5cad Christian König 2022-03-11  40   */
088aa14c0f5cad Christian König 2022-03-11  41  static inline struct dma_fence *
088aa14c0f5cad Christian König 2022-03-11  42  dma_fence_unwrap_array(struct 
dma_fence_unwrap * cursor)
088aa14c0f5cad Christian König 2022-03-11  43  {
088aa14c0f5cad Christian König 2022-03-11 @44   cursor->array = 
dma_fence_chain_contained(cursor->chain);
088aa14c0f5cad Christian König 2022-03-11  45   cursor->index = 0;
088aa14c0f5cad Christian König 2022-03-11 @46   return 
dma_fence_array_first(cursor->array);
088aa14c0f5cad Christian König 2022-03-11  47  }
088aa14c0f5cad Christian König 2022-03-11  48  

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH V3 05/13] drm: bridge: icn6211: Add DSI lane count DT property parsing

2022-03-11 Thread Maxime Ripard

On Fri, Mar 11, 2022 at 11:36:58AM +0100, Marek Vasut wrote:
> On 3/10/22 15:18, Maxime Ripard wrote:
> > On Thu, Mar 10, 2022 at 01:47:13PM +0100, Marek Vasut wrote:
> > > On 3/10/22 11:53, Maxime Ripard wrote:
> > > > On Tue, Mar 08, 2022 at 10:41:05PM +0100, Marek Vasut wrote:
> > > > > On 3/8/22 17:21, Maxime Ripard wrote:
> > > > > > On Tue, Mar 08, 2022 at 03:47:22PM +0100, Marek Vasut wrote:
> > > > > > > On 3/8/22 14:49, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 08, 2022 at 02:27:40PM +0100, Marek Vasut wrote:
> > > > > > > > > On 3/8/22 13:51, Maxime Ripard wrote:
> > > > > > > > > > On Tue, Mar 08, 2022 at 11:29:59AM +0100, Marek Vasut wrote:
> > > > > > > > > > > On 3/8/22 11:07, Jagan Teki wrote:
> > > > > > > > > > > > On Tue, Mar 8, 2022 at 3:19 PM Marek Vasut 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 3/8/22 09:03, Jagan Teki wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [...]
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > > @@ -314,7 +321,9 @@ static const struct 
> > > > > > > > > > > > > > > drm_bridge_funcs chipone_bridge_funcs = {
> > > > > > > > > > > > > > > static int chipone_parse_dt(struct 
> > > > > > > > > > > > > > > chipone *icn)
> > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > >struct device *dev = icn->dev;
> > > > > > > > > > > > > > > +   struct device_node *endpoint;
> > > > > > > > > > > > > > >struct drm_panel *panel;
> > > > > > > > > > > > > > > +   int dsi_lanes;
> > > > > > > > > > > > > > >int ret;
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >icn->vdd1 = 
> > > > > > > > > > > > > > > devm_regulator_get_optional(dev, "vdd1");
> > > > > > > > > > > > > > > @@ -350,15 +359,42 @@ static int 
> > > > > > > > > > > > > > > chipone_parse_dt(struct chipone *icn)
> > > > > > > > > > > > > > >return 
> > > > > > > > > > > > > > > PTR_ERR(icn->enable_gpio);
> > > > > > > > > > > > > > >}
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > +   endpoint = 
> > > > > > > > > > > > > > > of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> > > > > > > > > > > > > > > +   dsi_lanes = 
> > > > > > > > > > > > > > > of_property_count_u32_elems(endpoint, 
> > > > > > > > > > > > > > > "data-lanes");
> > > > > > > > > > > > > > > +   icn->host_node = 
> > > > > > > > > > > > > > > of_graph_get_remote_port_parent(endpoint);
> > > > > > > > > > > > > > > +   of_node_put(endpoint);
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +   if (!icn->host_node)
> > > > > > > > > > > > > > > +   return -ENODEV;
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The non-ports-based OF graph returns a -19 example 
> > > > > > > > > > > > > > on the Allwinner
> > > > > > > > > > > > > > Display pipeline in R16 [1].
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > We need to have a helper to return host_node for 
> > > > > > > > > > > > > > non-ports as I have
> > > > > > > > > > > > > > done it for drm_of_find_bridge.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [1] 
> > > > > > > > > > > > > > https://patchwork.amarulasolutions.com/patch/1805/
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The link points to a patch marked "DO NOT MERGE", 
> > > > > > > > > > > > > maybe that patch is
> > > > > > > > > > > > > missing the DSI host port@0 OF graph link ? Both 
> > > > > > > > > > > > > port@0 and port@1 are
> > > > > > > > > > > > > required, see:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml#n53
> > > > > > > > > > > > > 
> > > > > > > > > > > > > What is "non-ports-based OF graph" ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't see drm_of_find_bridge() in linux-next , what 
> > > > > > > > > > > > > is that ?
> > > > > > > > > > > > 
> > > > > > > > > > > > port@0 is optional as some of the DSI host OF-graph 
> > > > > > > > > > > > represent the
> > > > > > > > > > > > bridge or panel as child nodes instead of ports. (i 
> > > > > > > > > > > > think dt-binding
> > > > > > > > > > > > has to fix it to make port@0 optional)
> > > > > > > > > > > 
> > > > > > > > > > > The current upstream DT binding document says:
> > > > > > > > > > > 
> > > > > > > > > > >  required:
> > > > > > > > > > >- port@0
> > > > > > > > > > >- port@1
> > > > > > > > > > > 
> > > > > > > > > > > So port@0 is mandatory.
> > > > > > > > > > 
> > > > > > > > > > In the binding, sure, but fundamentally the DT excerpt 
> > > > > > > > > > Jagan provided is
> > > > > > > > > > correct. If the bridge supports DCS, there's no reason to 
> > > > > > > > > > use the OF
> >

[Bug 215648] amdgpu: Changing monitor configuration (plug/unplug/wake from DPMS) causes kernel panic

2022-03-11 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=215648

Philipp Riederer (pr_ker...@tum.fail) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |UNREPRODUCIBLE

--- Comment #6 from Philipp Riederer (pr_ker...@tum.fail) ---
I can no longer reproduce this issue with 5.16.14.

Sorry for the noise.

Regards,
Philipp

-- 
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 v3 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

Hi Rob,

Sorry something I can't explain happened with git rebase

v4 on its way

On Fri, Mar 11, 2022 at 3:59 PM Rob Herring  wrote:
>
> On Fri, Mar 11, 2022 at 01:04:53PM +0100, Christophe Branchereau wrote:
> > Add binding for the leadtek ltk035c5444t, which is a 640x480
> > mipi-dbi over spi / 24-bit RGB panel based on the newvision
> > NV03052C chipset.
> >
> > It is found in the Anbernic RG350M mips handheld.
> >
> > Signed-off-by: Christophe Branchereau 
> > ---
> >  .../display/panel/leadtek,ltk035c5444t.yaml   | 59 +++
> >  1 file changed, 59 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml 
> > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> > new file mode 100644
> > index ..9e728f8ce0cd
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
> > @@ -0,0 +1,59 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Why did you change the license? It was correct before.
>
> Rob

[PATCH v4 0/4] Ingenic DRM bridge_atomic_enable proposal

v4: fix the bindings license

KR
Christophe

---

Hello, v3 :

Drop -spi in the compatible string, adjust bindings doc accordingly

KR
Christophe



Hello, this is the v2 for my set of patches :

- use dev_err_probe() instead of dev_err() in the newvision panel
driver probe function

- add bindings documentation for the Leadtek ltk035c5444t

Cheers - Christophe



Hello, this is a set of patches to allow the upstreaming of the
NV3052C panel found in the Anbernic RG350M mips gaming handheld.

It was never upstreamed so far due to a longstanding graphical
bug, which I propose to solve by introducing ingenic_drm_bridge_atomic_enable
in the drm driver so the CRTC can be enabled after the panel itself slept
out, and not before as it used to.

After the drm change, 2 of the existing panels have to be modified accordingly
to introduce missing .enable and .disable in their code.

Christophe Branchereau (4):
  drm/ingenic : add ingenic_drm_bridge_atomic_enable
  drm/panel: Add panel driver for NewVision NV3052C based LCDs
  drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and
.disable
  dt-bindings: display/panel: Add Leadtek ltk035c5444t

 .../display/panel/leadtek,ltk035c5444t.yaml   |  59 +++
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  19 +-
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-abt-y030xx067a.c  |  23 +-
 drivers/gpu/drm/panel/panel-innolux-ej030na.c |  31 +-
 .../gpu/drm/panel/panel-newvision-nv3052c.c   | 497 ++
 7 files changed, 627 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c

-- 
2.35.1

[PATCH v4 1/4] drm/ingenic : add ingenic_drm_bridge_atomic_enable

This allows the CRTC to be enabled after panels have slept out,
and before their display is turned on, solving a graphical bug
on the newvision nv3502c

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821..51512f41263e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -226,6 +226,18 @@ static int ingenic_drm_update_pixclk(struct notifier_block 
*nb,
}
 }
 
+static void ingenic_drm_bridge_atomic_enable(struct drm_bridge *bridge,
+struct drm_bridge_state 
*old_bridge_state)
+{
+   struct ingenic_drm *priv = drm_device_get_priv(bridge->dev);
+
+   regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
+
+   regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
+  JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
+  JZ_LCD_CTRL_ENABLE);
+}
+
 static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
@@ -237,17 +249,11 @@ static void ingenic_drm_crtc_atomic_enable(struct 
drm_crtc *crtc,
if (WARN_ON(IS_ERR(priv_state)))
return;
 
-   regmap_write(priv->map, JZ_REG_LCD_STATE, 0);
-
/* Set addresses of our DMA descriptor chains */
next_id = priv_state->use_palette ? HWDESC_PALETTE : 0;
regmap_write(priv->map, JZ_REG_LCD_DA0, dma_hwdesc_addr(priv, next_id));
regmap_write(priv->map, JZ_REG_LCD_DA1, dma_hwdesc_addr(priv, 1));
 
-   regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
-  JZ_LCD_CTRL_ENABLE | JZ_LCD_CTRL_DISABLE,
-  JZ_LCD_CTRL_ENABLE);
-
drm_crtc_vblank_on(crtc);
 }
 
@@ -968,6 +974,7 @@ static const struct drm_encoder_helper_funcs 
ingenic_drm_encoder_helper_funcs =
 
 static const struct drm_bridge_funcs ingenic_drm_bridge_funcs = {
.attach = ingenic_drm_bridge_attach,
+   .atomic_enable  = ingenic_drm_bridge_atomic_enable,
.atomic_check   = ingenic_drm_bridge_atomic_check,
.atomic_reset   = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
-- 
2.35.1

[PATCH v4 2/4] drm/panel: Add panel driver for NewVision NV3052C based LCDs

This driver supports the NewVision NV3052C based LCDs. Right now, it
only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which
can be found in the Anbernic RG-350M handheld console.

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-newvision-nv3052c.c   | 497 ++
 3 files changed, 507 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-newvision-nv3052c.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bb2e47229c68..40084f709789 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -283,6 +283,15 @@ config DRM_PANEL_NEC_NL8048HL11
  panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
  as a module, choose M here.
 
+config DRM_PANEL_NEWVISION_NV3052C
+   tristate "NewVision NV3052C RGB/SPI panel"
+   depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select DRM_MIPI_DBI
+   help
+ Say Y here if you want to enable support for the panels built
+ around the NewVision NV3052C display controller.
+
 config DRM_PANEL_NOVATEK_NT35510
tristate "Novatek NT35510 RGB panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5740911f637c..42a7ab54234b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += 
panel-leadtek-ltk500hd1829.o
 obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
+obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3052C) += panel-newvision-nv3052c.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += panel-novatek-nt35560.o
 obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c 
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
new file mode 100644
index ..fc31df0dee12
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NevVision NV3052C IPS LCD panel driver
+ *
+ * Copyright (C) 2020, Paul Cercueil 
+ * Copyright (C) 2022, Christophe Branchereau 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct nv3052c_panel_info {
+   const struct drm_display_mode *display_modes;
+   unsigned int num_modes;
+   u16 width_mm, height_mm;
+   u32 bus_format, bus_flags;
+};
+
+struct nv3052c {
+   struct device *dev;
+   struct drm_panel panel;
+   struct mipi_dbi dbi;
+
+   const struct nv3052c_panel_info *panel_info;
+
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+};
+
+struct nv3052c_reg {
+   u8 cmd;
+   u8 val;
+};
+
+static const struct nv3052c_reg nv3052c_panel_regs[] = {
+   { 0xff, 0x30 },
+   { 0xff, 0x52 },
+   { 0xff, 0x01 },
+   { 0xe3, 0x00 },
+   { 0x40, 0x00 },
+   { 0x03, 0x40 },
+   { 0x04, 0x00 },
+   { 0x05, 0x03 },
+   { 0x08, 0x00 },
+   { 0x09, 0x07 },
+   { 0x0a, 0x01 },
+   { 0x0b, 0x32 },
+   { 0x0c, 0x32 },
+   { 0x0d, 0x0b },
+   { 0x0e, 0x00 },
+   { 0x23, 0xa0 },
+
+   { 0x24, 0x0c },
+   { 0x25, 0x06 },
+   { 0x26, 0x14 },
+   { 0x27, 0x14 },
+
+   { 0x38, 0xcc },
+   { 0x39, 0xd7 },
+   { 0x3a, 0x4a },
+
+   { 0x28, 0x40 },
+   { 0x29, 0x01 },
+   { 0x2a, 0xdf },
+   { 0x49, 0x3c },
+   { 0x91, 0x77 },
+   { 0x92, 0x77 },
+   { 0xa0, 0x55 },
+   { 0xa1, 0x50 },
+   { 0xa4, 0x9c },
+   { 0xa7, 0x02 },
+   { 0xa8, 0x01 },
+   { 0xa9, 0x01 },
+   { 0xaa, 0xfc },
+   { 0xab, 0x28 },
+   { 0xac, 0x06 },
+   { 0xad, 0x06 },
+   { 0xae, 0x06 },
+   { 0xaf, 0x03 },
+   { 0xb0, 0x08 },
+   { 0xb1, 0x26 },
+   { 0xb2, 0x28 },
+   { 0xb3, 0x28 },
+   { 0xb4, 0x33 },
+   { 0xb5, 0x08 },
+   { 0xb6, 0x26 },
+   { 0xb7, 0x08 },
+   { 0xb8, 0x26 },
+   { 0xf0, 0x00 },
+   { 0xf6, 0xc0 },
+
+   { 0xff, 0x30 },
+   { 0xff, 0x52 },
+   { 0xff, 0x02 },
+   { 0xb0, 0x0b },
+   { 0xb1, 0x16 },
+   { 0xb2, 0x17 },
+   { 0xb3, 0x2c },
+   { 0xb4, 0x32 },
+   { 0xb5, 0x3b },
+   { 0xb6, 0x29 },
+   { 0xb7, 0x40 },
+   { 0xb8, 0x0d },
+   { 0xb9, 0x05 },
+   { 0xba, 0x12 },
+   { 0xbb, 0x10 },
+   { 0xbc, 0x12 },
+   { 0xbd, 0x15 },
+   { 0xbe, 0x19 },
+   { 0xbf, 0x0e },
+   { 0xc0, 0x16 },
+   { 0xc1, 0x0a },
+   { 0xd0, 0x0c },
+   { 0xd1, 0x17 }

[PATCH v4 3/4] drm/panel : innolux-ej030na and abt-y030xx067a : add .enable and .disable

Following the introduction of bridge_atomic_enable in the ingenic
drm driver, the crtc is enabled between .prepare and .enable, if
it exists.

Add it so the backlight is only enabled after the crtc is, to avoid
graphical issues.

Signed-off-by: Christophe Branchereau 
---
 drivers/gpu/drm/panel/panel-abt-y030xx067a.c  | 23 --
 drivers/gpu/drm/panel/panel-innolux-ej030na.c | 31 ---
 2 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c 
b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
index f043b484055b..b5736344e3ec 100644
--- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
+++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
@@ -183,8 +183,6 @@ static int y030xx067a_prepare(struct drm_panel *panel)
goto err_disable_regulator;
}
 
-   msleep(120);
-
return 0;
 
 err_disable_regulator:
@@ -202,6 +200,25 @@ static int y030xx067a_unprepare(struct drm_panel *panel)
return 0;
 }
 
+static int y030xx067a_enable(struct drm_panel *panel)
+{
+   if (panel->backlight) {
+   /* Wait for the picture to be ready before enabling backlight */
+   msleep(120);
+   }
+
+   return 0;
+}
+
+static int y030xx067a_disable(struct drm_panel *panel)
+{
+   struct y030xx067a *priv = to_y030xx067a(panel);
+
+   regmap_clear_bits(priv->map, 0x06, REG06_XPSAVE);
+
+   return 0;
+}
+
 static int y030xx067a_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
 {
@@ -239,6 +256,8 @@ static int y030xx067a_get_modes(struct drm_panel *panel,
 static const struct drm_panel_funcs y030xx067a_funcs = {
.prepare= y030xx067a_prepare,
.unprepare  = y030xx067a_unprepare,
+   .enable = y030xx067a_enable,
+   .disable= y030xx067a_disable,
.get_modes  = y030xx067a_get_modes,
 };
 
diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c 
b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
index c558de3f99be..6de7370185cd 100644
--- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
+++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
@@ -80,8 +80,6 @@ static const struct reg_sequence ej030na_init_sequence[] = {
{ 0x47, 0x08 },
{ 0x48, 0x0f },
{ 0x49, 0x0f },
-
-   { 0x2b, 0x01 },
 };
 
 static int ej030na_prepare(struct drm_panel *panel)
@@ -109,8 +107,6 @@ static int ej030na_prepare(struct drm_panel *panel)
goto err_disable_regulator;
}
 
-   msleep(120);
-
return 0;
 
 err_disable_regulator:
@@ -128,6 +124,31 @@ static int ej030na_unprepare(struct drm_panel *panel)
return 0;
 }
 
+static int ej030na_enable(struct drm_panel *panel)
+{
+   struct ej030na *priv = to_ej030na(panel);
+
+   /* standby off */
+   regmap_write(priv->map, 0x2b, 0x01);
+
+   if (panel->backlight) {
+   /* Wait for the picture to be ready before enabling backlight */
+   msleep(120);
+   }
+
+   return 0;
+}
+
+static int ej030na_disable(struct drm_panel *panel)
+{
+   struct ej030na *priv = to_ej030na(panel);
+
+   /* standby on */
+   regmap_write(priv->map, 0x2b, 0x00);
+
+   return 0;
+}
+
 static int ej030na_get_modes(struct drm_panel *panel,
 struct drm_connector *connector)
 {
@@ -165,6 +186,8 @@ static int ej030na_get_modes(struct drm_panel *panel,
 static const struct drm_panel_funcs ej030na_funcs = {
.prepare= ej030na_prepare,
.unprepare  = ej030na_unprepare,
+   .enable = ej030na_enable,
+   .disable= ej030na_disable,
.get_modes  = ej030na_get_modes,
 };
 
-- 
2.35.1

[PATCH v4 4/4] dt-bindings: display/panel: Add Leadtek ltk035c5444t

Add binding for the leadtek ltk035c5444t, which is a 640x480
mipi-dbi over spi / 24-bit RGB panel based on the newvision
NV03052C chipset.

It is found in the Anbernic RG350M mips handheld.

Signed-off-by: Christophe Branchereau 
---
 .../display/panel/leadtek,ltk035c5444t.yaml   | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml 
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
new file mode 100644
index ..817a9bed7d5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk035c5444t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek ltk035c5444t 3.5" (640x480 pixels) 24-bit IPS LCD panel
+
+maintainers:
+  - Paul Cercueil 
+  - Christophe Branchereau 
+
+allOf:
+  - $ref: panel-common.yaml#
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+  compatible:
+const: leadtek,ltk035c5444t
+
+  backlight: true
+  port: true
+  power-supply: true
+  reg: true
+  reset-gpios: true
+
+required:
+  - compatible
+  - power-supply
+  - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk035c5444t";
+reg = <0>;
+
+spi-3wire;
+spi-max-frequency = <3125000>;
+
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <&panel_output>;
+};
+};
+};
+};
-- 
2.35.1

[PATCH v2 2/7] drm: mxsfb: Simplify LCDIF IRQ handling

The call to drm_crtc_vblank_off(&lcdif->crtc); disables IRQ generation
from the LCDIF block already and this is called in mxsfb_load() before
request_irq(), so explicitly disabling IRQ using custom function like
mxsfb_irq_disable() is not needed, remove it. The request_irq() call
would return -ENOTCONN if IRQ is IRQ_NOTCONNECTED already, so remove
the unnecessary check. Finally, remove both mxsfb_irq_install() and
mxsfb_irq_uninstall() as well, since they are no longer useful.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 38 +++
 1 file changed, 8 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index c790aeff0a6f0..94cafff7f68d5 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -157,33 +157,6 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static void mxsfb_irq_disable(struct drm_device *drm)
-{
-   struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
-   /* Disable and clear VBLANK IRQ */
-   writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-   writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-}
-
-static int mxsfb_irq_install(struct drm_device *dev, int irq)
-{
-   if (irq == IRQ_NOTCONNECTED)
-   return -ENOTCONN;
-
-   mxsfb_irq_disable(dev);
-
-   return request_irq(irq, mxsfb_irq_handler, 0,  dev->driver->name, dev);
-}
-
-static void mxsfb_irq_uninstall(struct drm_device *dev)
-{
-   struct mxsfb_drm_private *mxsfb = dev->dev_private;
-
-   mxsfb_irq_disable(dev);
-   free_irq(mxsfb->irq, dev);
-}
-
 static int mxsfb_load(struct drm_device *drm,
  const struct mxsfb_devdata *devdata)
 {
@@ -259,7 +232,8 @@ static int mxsfb_load(struct drm_device *drm,
return ret;
mxsfb->irq = ret;
 
-   ret = mxsfb_irq_install(drm, mxsfb->irq);
+   ret = request_irq(mxsfb->irq, mxsfb_irq_handler, 0,
+ drm->driver->name, drm);
if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n");
return ret;
@@ -276,16 +250,20 @@ static int mxsfb_load(struct drm_device *drm,
 
 static void mxsfb_unload(struct drm_device *drm)
 {
+   struct mxsfb_drm_private *mxsfb = drm->dev_private;
+
pm_runtime_get_sync(drm->dev);
 
+   drm_crtc_vblank_off(&mxsfb->crtc);
+
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
 
-   mxsfb_irq_uninstall(drm);
-
pm_runtime_put_sync(drm->dev);
pm_runtime_disable(drm->dev);
 
+   free_irq(mxsfb->irq, drm->dev);
+
drm->dev_private = NULL;
 }
 
-- 
2.34.1

[PATCH v2 6/7] drm: mxsfb: Reorder mxsfb_crtc_mode_set_nofb()

Reorder mxsfb_crtc_mode_set_nofb() such that all functions which perform
register IO are called from one single location in this function. This is
a clean up. No functional change.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 14f5cc590a51b..497603964add8 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -289,13 +289,6 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb,
u32 bus_flags = mxsfb->connector->display_info.bus_flags;
int err;
 
-   /* Mandatory eLCDIF reset as per the Reference Manual */
-   err = mxsfb_reset_block(mxsfb);
-   if (err)
-   return;
-
-   mxsfb_set_formats(mxsfb, bus_format);
-
if (mxsfb->bridge && mxsfb->bridge->timings)
bus_flags = mxsfb->bridge->timings->input_bus_flags;
 
@@ -306,6 +299,13 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb,
 bus_flags);
DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
 
+   /* Mandatory eLCDIF reset as per the Reference Manual */
+   err = mxsfb_reset_block(mxsfb);
+   if (err)
+   return;
+
+   mxsfb_set_formats(mxsfb, bus_format);
+
mxsfb_set_mode(mxsfb, bus_flags);
 }
 
-- 
2.34.1

[PATCH v2 1/7] drm: mxsfb: Simplify LCDIF clock handling

The current clock handling in the LCDIF driver is a convoluted mess.
Implement runtime PM ops which turn the clock ON and OFF and let the
pm_runtime_get_sync()/pm_runtime_put_sync() calls in .atomic_enable
and .atomic_disable callbacks turn the clock ON and OFF at the right
time.

This requires slight reordering in mxsfb_crtc_atomic_enable() and
mxsfb_crtc_atomic_disable(), since all the register accesses must
happen only with clock enabled and clock frequency configuration
must happen with clock disabled.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 104 +-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c |  27 +++-
 2 files changed, 67 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 9d71c55a31c07..c790aeff0a6f0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -73,18 +73,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
},
 };
 
-void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
-   if (mxsfb->clk_axi)
-   clk_prepare_enable(mxsfb->clk_axi);
-}
-
-void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
-   if (mxsfb->clk_axi)
-   clk_disable_unprepare(mxsfb->clk_axi);
-}
-
 static struct drm_framebuffer *
 mxsfb_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -173,13 +161,9 @@ static void mxsfb_irq_disable(struct drm_device *drm)
 {
struct mxsfb_drm_private *mxsfb = drm->dev_private;
 
-   mxsfb_enable_axi_clk(mxsfb);
-
/* Disable and clear VBLANK IRQ */
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-
-   mxsfb_disable_axi_clk(mxsfb);
 }
 
 static int mxsfb_irq_install(struct drm_device *dev, int irq)
@@ -225,43 +209,41 @@ static int mxsfb_load(struct drm_device *drm,
if (IS_ERR(mxsfb->clk))
return PTR_ERR(mxsfb->clk);
 
-   mxsfb->clk_axi = devm_clk_get(drm->dev, "axi");
+   mxsfb->clk_axi = devm_clk_get_optional(drm->dev, "axi");
if (IS_ERR(mxsfb->clk_axi))
-   mxsfb->clk_axi = NULL;
+   return PTR_ERR(mxsfb->clk_axi);
 
-   mxsfb->clk_disp_axi = devm_clk_get(drm->dev, "disp_axi");
+   mxsfb->clk_disp_axi = devm_clk_get_optional(drm->dev, "disp_axi");
if (IS_ERR(mxsfb->clk_disp_axi))
-   mxsfb->clk_disp_axi = NULL;
+   return PTR_ERR(mxsfb->clk_disp_axi);
+
+   platform_set_drvdata(pdev, drm);
 
ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
if (ret)
return ret;
 
-   pm_runtime_enable(drm->dev);
-
/* Modeset init */
drm_mode_config_init(drm);
 
ret = mxsfb_kms_init(mxsfb);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialize KMS pipeline\n");
-   goto err_vblank;
+   return ret;
}
 
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialise vblank\n");
-   goto err_vblank;
+   return ret;
}
 
/* Start with vertical blanking interrupt reporting disabled. */
drm_crtc_vblank_off(&mxsfb->crtc);
 
ret = mxsfb_attach_bridge(mxsfb);
-   if (ret) {
-   dev_err_probe(drm->dev, ret, "Cannot connect bridge\n");
-   goto err_vblank;
-   }
+   if (ret)
+   return dev_err_probe(drm->dev, ret, "Cannot connect bridge\n");
 
drm->mode_config.min_width  = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
@@ -274,44 +256,37 @@ static int mxsfb_load(struct drm_device *drm,
 
ret = platform_get_irq(pdev, 0);
if (ret < 0)
-   goto err_vblank;
+   return ret;
mxsfb->irq = ret;
 
-   pm_runtime_get_sync(drm->dev);
ret = mxsfb_irq_install(drm, mxsfb->irq);
-   pm_runtime_put_sync(drm->dev);
-
if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n");
-   goto err_vblank;
+   return ret;
}
 
drm_kms_helper_poll_init(drm);
 
-   platform_set_drvdata(pdev, drm);
-
drm_helper_hpd_irq_event(drm);
 
-   return 0;
-
-err_vblank:
-   pm_runtime_disable(drm->dev);
+   pm_runtime_enable(drm->dev);
 
-   return ret;
+   return 0;
 }
 
 static void mxsfb_unload(struct drm_device *drm)
 {
+   pm_runtime_get_sync(drm->dev);
+
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
 
-   pm_runtime_get_sync(drm->dev);

[PATCH v2 4/7] drm: mxsfb: Move mxsfb_get_fb_paddr() away from register IO functions

Move mxsfb_get_fb_paddr() out of the way, away from register IO functions.
This is a clean up. No functional change.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 015b289d93a3c..7b0abd0472aae 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -43,6 +43,21 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private 
*mxsfb, u32 val)
mxsfb->devdata->hs_wdth_shift;
 }
 
+static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
+{
+   struct drm_framebuffer *fb = plane->state->fb;
+   struct drm_gem_cma_object *gem;
+
+   if (!fb)
+   return 0;
+
+   gem = drm_fb_cma_get_gem_obj(fb, 0);
+   if (!gem)
+   return 0;
+
+   return gem->paddr;
+}
+
 /*
  * Setup the MXSFB registers for decoding the pixels out of the framebuffer and
  * outputting them on the bus.
@@ -215,21 +230,6 @@ static int mxsfb_reset_block(struct mxsfb_drm_private 
*mxsfb)
return 0;
 }
 
-static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
-{
-   struct drm_framebuffer *fb = plane->state->fb;
-   struct drm_gem_cma_object *gem;
-
-   if (!fb)
-   return 0;
-
-   gem = drm_fb_cma_get_gem_obj(fb, 0);
-   if (!gem)
-   return 0;
-
-   return gem->paddr;
-}
-
 static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb,
 const u32 bus_format)
 {
-- 
2.34.1

[PATCH v2 7/7] drm: mxsfb: Factor out mxsfb_update_buffer()

Pull functionality responsible for programming framebuffer address into
the controller into dedicated function mxsfb_update_buffer(). This is a
clean up. No functional change.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 497603964add8..4baa3db1f3d10 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -58,6 +58,22 @@ static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
return gem->paddr;
 }
 
+static void
+mxsfb_update_buffer(struct mxsfb_drm_private *mxsfb, struct drm_plane *plane,
+   bool both)
+{
+   dma_addr_t paddr;
+
+   paddr = mxsfb_get_fb_paddr(plane);
+   if (!paddr)
+   return;
+
+   if (both)
+   writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+
+   writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+}
+
 /*
  * Setup the MXSFB registers for decoding the pixels out of the framebuffer and
  * outputting them on the bus.
@@ -352,7 +368,6 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_bridge_state *bridge_state;
struct drm_device *drm = mxsfb->drm;
u32 bus_format = 0;
-   dma_addr_t paddr;
 
/* If there is a bridge attached to the LCDIF, use its bus format */
if (mxsfb->bridge) {
@@ -387,11 +402,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
mxsfb_crtc_mode_set_nofb(mxsfb, bus_format);
 
/* Write cur_buf as well to avoid an initial corrupt frame */
-   paddr = mxsfb_get_fb_paddr(crtc->primary);
-   if (paddr) {
-   writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
-   writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
-   }
+   mxsfb_update_buffer(mxsfb, crtc->primary, true);
 
mxsfb_enable_controller(mxsfb);
 
@@ -491,11 +502,8 @@ static void mxsfb_plane_primary_atomic_update(struct 
drm_plane *plane,
  struct drm_atomic_state *state)
 {
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
-   dma_addr_t paddr;
 
-   paddr = mxsfb_get_fb_paddr(plane);
-   if (paddr)
-   writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+   mxsfb_update_buffer(mxsfb, plane, false);
 }
 
 static void mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,
-- 
2.34.1

[PATCH v2 5/7] drm: mxsfb: Factor out mxsfb_set_mode()

Pull mode registers programming from mxsfb_enable_controller() into
dedicated function mxsfb_set_mode(). This is a clean up. No functional
change.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 96 +--
 1 file changed, 52 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 7b0abd0472aae..14f5cc590a51b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -111,6 +111,57 @@ static void mxsfb_set_formats(struct mxsfb_drm_private 
*mxsfb,
writel(ctrl, mxsfb->base + LCDC_CTRL);
 }
 
+static void mxsfb_set_mode(struct mxsfb_drm_private *mxsfb, u32 bus_flags)
+{
+   struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode;
+   u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
+
+   writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
+  TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
+  mxsfb->base + mxsfb->devdata->transfer_count);
+
+   vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
+
+   vdctrl0 = VDCTRL0_ENABLE_PRESENT |  /* Always in DOTCLOCK mode */
+ VDCTRL0_VSYNC_PERIOD_UNIT |
+ VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
+ VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
+   if (m->flags & DRM_MODE_FLAG_PHSYNC)
+   vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
+   if (m->flags & DRM_MODE_FLAG_PVSYNC)
+   vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
+   /* Make sure Data Enable is high active by default */
+   if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
+   vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
+   /*
+* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
+* controllers VDCTRL0_DOTCLK is display centric.
+* Drive on positive edge   -> display samples on falling edge
+* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
+*/
+   if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
+   vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
+
+   writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
+
+   /* Frame length in lines. */
+   writel(m->crtc_vtotal, mxsfb->base + LCDC_VDCTRL1);
+
+   /* Line length in units of clocks or pixels. */
+   hsync_pulse_len = m->crtc_hsync_end - m->crtc_hsync_start;
+   writel(set_hsync_pulse_width(mxsfb, hsync_pulse_len) |
+  VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal),
+  mxsfb->base + LCDC_VDCTRL2);
+
+   writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) |
+  SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
+  mxsfb->base + LCDC_VDCTRL3);
+
+   writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
+  mxsfb->base + LCDC_VDCTRL4);
+
+}
+
 static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
 {
u32 reg;
@@ -236,7 +287,6 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb,
struct drm_device *drm = mxsfb->crtc.dev;
struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode;
u32 bus_flags = mxsfb->connector->display_info.bus_flags;
-   u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
 
/* Mandatory eLCDIF reset as per the Reference Manual */
@@ -256,49 +306,7 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb,
 bus_flags);
DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
 
-   writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
-  TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
-  mxsfb->base + mxsfb->devdata->transfer_count);
-
-   vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
-
-   vdctrl0 = VDCTRL0_ENABLE_PRESENT |  /* Always in DOTCLOCK mode */
- VDCTRL0_VSYNC_PERIOD_UNIT |
- VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
- VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
-   if (m->flags & DRM_MODE_FLAG_PHSYNC)
-   vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
-   if (m->flags & DRM_MODE_FLAG_PVSYNC)
-   vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
-   /* Make sure Data Enable is high active by default */
-   if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
-   vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
-   /*
-* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
-* controllers VDCTRL0_DOTCLK is display centric.
-* Drive on positive edge   -> display samples on falling edge
-* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
-*/
-   if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-   vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
-
-

[PATCH v2 3/7] drm: mxsfb: Wrap FIFO reset and comments into mxsfb_reset_block()

Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up.
No functional change.

Signed-off-by: Marek Vasut 
Cc: Alexander Stein 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Peng Fan 
Cc: Robby Cai 
Cc: Sam Ravnborg 
Cc: Stefan Agner 
---
V2: No change
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 36 +--
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 657b6afbbf1f9..015b289d93a3c 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -183,6 +183,12 @@ static int mxsfb_reset_block(struct mxsfb_drm_private 
*mxsfb)
 {
int ret;
 
+   /*
+* It seems, you can't re-program the controller if it is still
+* running. This may lead to shifted pictures (FIFO issue?), so
+* first stop the controller and drain its FIFOs.
+*/
+
ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_SFTRST);
if (ret)
return ret;
@@ -193,7 +199,20 @@ static int mxsfb_reset_block(struct mxsfb_drm_private 
*mxsfb)
if (ret)
return ret;
 
-   return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+   ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+   if (ret)
+   return ret;
+
+   /* Clear the FIFOs */
+   writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
+   readl(mxsfb->base + LCDC_CTRL1);
+   writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
+   readl(mxsfb->base + LCDC_CTRL1);
+
+   if (mxsfb->devdata->has_overlay)
+   writel(0, mxsfb->base + LCDC_AS_CTRL);
+
+   return 0;
 }
 
 static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
@@ -220,26 +239,11 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb,
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
 
-   /*
-* It seems, you can't re-program the controller if it is still
-* running. This may lead to shifted pictures (FIFO issue?), so
-* first stop the controller and drain its FIFOs.
-*/
-
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb);
if (err)
return;
 
-   /* Clear the FIFOs */
-   writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
-   readl(mxsfb->base + LCDC_CTRL1);
-   writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-   readl(mxsfb->base + LCDC_CTRL1);
-
-   if (mxsfb->devdata->has_overlay)
-   writel(0, mxsfb->base + LCDC_AS_CTRL);
-
mxsfb_set_formats(mxsfb, bus_format);
 
if (mxsfb->bridge && mxsfb->bridge->timings)
-- 
2.34.1

Re: [PATCH v1 1/3] mm: split vm_normal_pages for LRU and non-LRU handling

2022-03-11 Thread Felix Kuehling


On 2022-03-11 04:16, David Hildenbrand wrote:

On 10.03.22 18:26, Alex Sierra wrote:

DEVICE_COHERENT pages introduce a subtle distinction in the way
"normal" pages can be used by various callers throughout the kernel.
They behave like normal pages for purposes of mapping in CPU page
tables, and for COW. But they do not support LRU lists, NUMA
migration or THP. Therefore we split vm_normal_page into two
functions vm_normal_any_page and vm_normal_lru_page. The latter will
only return pages that can be put on an LRU list and that support
NUMA migration, KSM and THP.

We also introduced a FOLL_LRU flag that adds the same behaviour to
follow_page and related APIs, to allow callers to specify that they
expect to put pages on an LRU list.


I still don't see the need for s/vm_normal_page/vm_normal_any_page/. And
as this patch is dominated by that change, I'd suggest (again) to just
drop it as I don't see any value of that renaming. No specifier implies any.


OK. If nobody objects, we can adopts that naming convention.




The general idea of this change LGTM.


I wonder how this interacts with the actual DEVICE_COHERENT coherent
series. Is this a preparation? Should it be part of the DEVICE_COHERENT
series?


Yes, it should be part of that series. Alex developed it on top of the 
series for now. But I think eventually it would need to be spliced into it.


Patch1 would need to go somewhere before the other DEVICE_COHERENT 
patches (with minor modifications). Patch 2 could be squashed into 
"tools: add hmm gup test for long term pinned device pages" or go next 
to it. Patch 3 doesn't have a direct dependency on device-coherent 
pages. It only mentions them in comments.





IOW, should this patch start with

"With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW, they do not support LRU lists, NUMA migration or THP. [...]"


Yes, that makes sense.

Regards,
  Felix




But then, I'm confused by patch 2 and 3, because it feels more like we'd
already have DEVICE_COHERENT then ("hmm_is_coherent_type").

Re: [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector

2022-03-11 Thread Abhinav Kumar


Hi Dmitry and Laurent

On 3/11/2022 12:05 AM, Laurent Pinchart wrote:

On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:

On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar  wrote:


For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.

In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.

To accommodate such vendor drivers and hardware, allow
real encoder to be passed for drm_writeback_connector.

Co-developed-by: Kandpal Suraj 
Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/drm_writeback.c |  8 
  include/drm/drm_writeback.h | 13 +++--
  2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..4dad687 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
 if (IS_ERR(blob))
 return PTR_ERR(blob);

-   drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
-   ret = drm_encoder_init(dev, &wb_connector->encoder,
+   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+   ret = drm_encoder_init(dev, wb_connector->encoder,
&drm_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);


If the encoder is provided by a separate driver, it might use a
different set of encoder funcs.


More than that, if the encoder is provided externally but doesn't have
custom operations, I don't really see the point of having an external
encoder in the first place.

Has this series been tested with a driver that needs to provide an
encoder, to make sure it fits the purpose ?



Yes, I have tested this with the MSM driver which provides an encoder
and yes it absolutely fits the purpose.



I'd suggest checking whether the wb_connector->encoder is NULL here.
If it is, allocate one using drmm_kzalloc and init it.
If it is not NULL, assume that it has been initialized already, so
skip the drm_encoder_init() and just call the drm_encoder_helper_add()


You are both right. We can skip the drm_encoder_init for drivers which 
have already provided an encoder.


The only issue I was facing with that is some of the drivers for example 
the below one, access the "wb_conn->encoder.possible_crtcs" before the 
call to drm_writeback_connector_init().


198 int rcar_du_writeback_init(struct rcar_du_device *rcdu,
199struct rcar_du_crtc *rcrtc)
200 {
201 struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
202
203 wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
204 drm_connector_helper_add(&wb_conn->base,
205  &rcar_du_wb_conn_helper_funcs);
206
207 return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
208 &rcar_du_wb_conn_funcs,
209 &rcar_du_wb_enc_helper_funcs,
210 writeback_formats,
211 ARRAY_SIZE(writeback_formats));

If we allocate the encoder within drm_writeback_connector_init(), do you 
suggest I modify the drivers to move the usage of possible_crtcs after 
the drm_writeback_connector_init() call to avoid NULL ptr crash?






 if (ret)
@@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 goto connector_fail;

 ret = drm_connector_attach_encoder(connector,
-   &wb_connector->encoder);
+   wb_connector->encoder);
 if (ret)
 goto attach_fail;

@@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
  attach_fail:
 drm_connector_cleanup(connector);
  connector_fail:
-   drm_encoder_cleanup(&wb_connector->encoder);
+   drm_encoder_cleanup(wb_connector->encoder);
  fail:
 drm_property_blob_put(blob);
 return ret;
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 9697d27..0ba266e 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -25,13 +25,22 @@ struct drm_writeback_connector {
 struct drm_connector base;

 /**
-* @encoder: Internal encoder used by the connector to fulfill
+* @encoder: handle to drm_encoder used by the connector to fulfill
  * the DRM framework requirements. The users of the
  * @drm_writeback_connector control the behaviour of the @encoder
  * by passing the @enc_funcs parameter to 
drm_writeback_connector_init()
  * function.
+*
+* For some vendor drivers, the hardware resources are shared between
+* writeback encoder a

Re: [PATCH 1/2] dma-buf: add dma_fence_unwrap

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.17-rc7 next-20220310]
[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/Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
79b00034e9dcd2b065c1665c8b42f62b6b80a9be
config: hexagon-randconfig-r045-20220310 
(https://download.01.org/0day-ci/archive/20220312/202203120114.jpyqmshc-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
276ca87382b8f16a65bddac700202924228982f6)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/088aa14c0f5cad378854823fa661ee145dd2c01b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
git checkout 088aa14c0f5cad378854823fa661ee145dd2c01b
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/dma-buf/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/dma-buf/st-dma-fence-unwrap.c:7:
   include/linux/dma-fence-unwrap.h:44:18: error: implicit declaration of 
function 'dma_fence_chain_contained' [-Werror,-Wimplicit-function-declaration]
   cursor->array = dma_fence_chain_contained(cursor->chain);
   ^
   include/linux/dma-fence-unwrap.h:44:18: note: did you mean 
'dma_fence_chain_init'?
   include/linux/dma-fence-chain.h:108:6: note: 'dma_fence_chain_init' declared 
here
   void dma_fence_chain_init(struct dma_fence_chain *chain,
^
   In file included from drivers/dma-buf/st-dma-fence-unwrap.c:7:
>> include/linux/dma-fence-unwrap.h:44:16: warning: incompatible integer to 
>> pointer conversion assigning to 'struct dma_fence *' from 'int' 
>> [-Wint-conversion]
   cursor->array = dma_fence_chain_contained(cursor->chain);
 ^ 
   include/linux/dma-fence-unwrap.h:46:9: error: implicit declaration of 
function 'dma_fence_array_first' [-Werror,-Wimplicit-function-declaration]
   return dma_fence_array_first(cursor->array);
  ^
   include/linux/dma-fence-unwrap.h:46:9: note: did you mean 
'dma_fence_array_create'?
   include/linux/dma-fence-array.h:77:25: note: 'dma_fence_array_create' 
declared here
   struct dma_fence_array *dma_fence_array_create(int num_fences,
   ^
   In file included from drivers/dma-buf/st-dma-fence-unwrap.c:7:
>> include/linux/dma-fence-unwrap.h:46:9: warning: incompatible integer to 
>> pointer conversion returning 'int' from a function with result type 'struct 
>> dma_fence *' [-Wint-conversion]
   return dma_fence_array_first(cursor->array);
  ^~~~
   include/linux/dma-fence-unwrap.h:77:8: error: implicit declaration of 
function 'dma_fence_array_next' [-Werror,-Wimplicit-function-declaration]
   tmp = dma_fence_array_next(cursor->array, cursor->index);
 ^
   include/linux/dma-fence-unwrap.h:77:6: warning: incompatible integer to 
pointer conversion assigning to 'struct dma_fence *' from 'int' 
[-Wint-conversion]
   tmp = dma_fence_array_next(cursor->array, cursor->index);
   ^ ~~
>> drivers/dma-buf/st-dma-fence-unwrap.c:133:6: warning: variable 'err' set but 
>> not used [-Wunused-but-set-variable]
   int err = 0;
   ^
   drivers/dma-buf/st-dma-fence-unwrap.c:175:6: warning: variable 'err' set but 
not used [-Wunused-but-set-variable]
   int err = 0;
   ^
   drivers/dma-buf/st-dma-fence-unwrap.c:217:6: warning: variable 'err' set but 
not used [-Wunused-but-set-variable]
   int err = 0;
   ^
   6 warnings and 3 errors generated.


vim +44 include/linux/dma-fence-unwrap.h

33  
34  /**
35   * dma_fence_unwrap_array - helper to unwrap dma_fence_arrays
36   * @cursor: cursor to initialize
37   *
38   * Helper function to unwrap d

Re: [PATCH 5/6] drm/rcar_du: use drm_encoder pointer for drm_writeback_connector

2022-03-11 Thread Abhinav Kumar


Hi Laurent

On 3/10/2022 11:28 PM, Laurent Pinchart wrote:

Hi Abhinav

Thank you for the patch.

On Thu, Mar 10, 2022 at 05:49:59PM -0800, Abhinav Kumar wrote:

Make changes to rcar_du driver to start using drm_encoder pointer
for drm_writeback_connector.

Co-developed-by: Kandpal Suraj 
Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c 
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d125..03930ad 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,7 +200,8 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
  {
struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
  
-	wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);

+   wb_conn->encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);


Where is this freed ?


You are right, this isnt. Looking more into this, it seems like moving 
the allocation of encoder to drm_writeback.c for cases which dont pass a 
real encoder is much better so that I will not have to add alloc() / 
free() code for all the vendor driver changes which is what I originally 
thought in my RFC but changed my mind because of below.





+   wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);


Do you think we can just move usage of wb_conn->encoder->possible_crtcs 
just right after drm_writeback_connector_init() so that it wont crash?


198 int rcar_du_writeback_init(struct rcar_du_device *rcdu,
199struct rcar_du_crtc *rcrtc)
200 {
201 struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
202
203 wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
204 drm_connector_helper_add(&wb_conn->base,
205  &rcar_du_wb_conn_helper_funcs);
206
207 return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
208 &rcar_du_wb_conn_funcs,
209 &rcar_du_wb_enc_helper_funcs,
210 writeback_formats,
211 ARRAY_SIZE(writeback_formats));
212 }


drm_connector_helper_add(&wb_conn->base,
 &rcar_du_wb_conn_helper_funcs);

Re: [PATCH 2/2] dma-buf/sync-file: fix warning about fence containers

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.17-rc7 next-20220310]
[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/Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
79b00034e9dcd2b065c1665c8b42f62b6b80a9be
config: arm64-randconfig-r014-20220310 
(https://download.01.org/0day-ci/archive/20220312/202203120115.qe4gabiv-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
276ca87382b8f16a65bddac700202924228982f6)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
git checkout ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/dma-buf/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/dma-buf/sync_file.c:8:
   include/linux/dma-fence-unwrap.h:44:18: error: implicit declaration of 
function 'dma_fence_chain_contained' [-Werror,-Wimplicit-function-declaration]
   cursor->array = dma_fence_chain_contained(cursor->chain);
   ^
   include/linux/dma-fence-unwrap.h:44:18: note: did you mean 
'dma_fence_chain_init'?
   include/linux/dma-fence-chain.h:108:6: note: 'dma_fence_chain_init' declared 
here
   void dma_fence_chain_init(struct dma_fence_chain *chain,
^
   In file included from drivers/dma-buf/sync_file.c:8:
>> include/linux/dma-fence-unwrap.h:44:16: warning: incompatible integer to 
>> pointer conversion assigning to 'struct dma_fence *' from 'int' 
>> [-Wint-conversion]
   cursor->array = dma_fence_chain_contained(cursor->chain);
 ^ 
   include/linux/dma-fence-unwrap.h:46:9: error: implicit declaration of 
function 'dma_fence_array_first' [-Werror,-Wimplicit-function-declaration]
   return dma_fence_array_first(cursor->array);
  ^
   include/linux/dma-fence-unwrap.h:46:9: note: did you mean 
'dma_fence_array_create'?
   include/linux/dma-fence-array.h:77:25: note: 'dma_fence_array_create' 
declared here
   struct dma_fence_array *dma_fence_array_create(int num_fences,
   ^
   In file included from drivers/dma-buf/sync_file.c:8:
>> include/linux/dma-fence-unwrap.h:46:9: warning: incompatible integer to 
>> pointer conversion returning 'int' from a function with result type 'struct 
>> dma_fence *' [-Wint-conversion]
   return dma_fence_array_first(cursor->array);
  ^~~~
   include/linux/dma-fence-unwrap.h:77:8: error: implicit declaration of 
function 'dma_fence_array_next' [-Werror,-Wimplicit-function-declaration]
   tmp = dma_fence_array_next(cursor->array, cursor->index);
 ^
   include/linux/dma-fence-unwrap.h:77:6: warning: incompatible integer to 
pointer conversion assigning to 'struct dma_fence *' from 'int' 
[-Wint-conversion]
   tmp = dma_fence_array_next(cursor->array, cursor->index);
   ^ ~~
   3 warnings and 3 errors generated.


vim +44 include/linux/dma-fence-unwrap.h

088aa14c0f5cad Christian König 2022-03-11  33  
088aa14c0f5cad Christian König 2022-03-11  34  /**
088aa14c0f5cad Christian König 2022-03-11  35   * dma_fence_unwrap_array - 
helper to unwrap dma_fence_arrays
088aa14c0f5cad Christian König 2022-03-11  36   * @cursor: cursor to initialize
088aa14c0f5cad Christian König 2022-03-11  37   *
088aa14c0f5cad Christian König 2022-03-11  38   * Helper function to unwrap 
dma_fence_array containers, don't touch directly.
088aa14c0f5cad Christian König 2022-03-11  39   * Use 
dma_fence_unwrap_first/next instead.
088aa14c0f5cad Christian König 2022-03-11  40   */
088aa14c

Re: [PATCH 1/6] drm: allow real encoder to be passed for drm_writeback_connector

2022-03-11 Thread Dmitry Baryshkov

On Fri, 11 Mar 2022 at 20:09, Abhinav Kumar  wrote:
>
> Hi Dmitry and Laurent
>
> On 3/11/2022 12:05 AM, Laurent Pinchart wrote:
> > On Fri, Mar 11, 2022 at 10:46:13AM +0300, Dmitry Baryshkov wrote:
> >> On Fri, 11 Mar 2022 at 04:50, Abhinav Kumar  
> >> wrote:
> >>>
> >>> For some vendor driver implementations, display hardware can
> >>> be shared between the encoder used for writeback and the physical
> >>> display.
> >>>
> >>> In addition resources such as clocks and interrupts can
> >>> also be shared between writeback and the real encoder.
> >>>
> >>> To accommodate such vendor drivers and hardware, allow
> >>> real encoder to be passed for drm_writeback_connector.
> >>>
> >>> Co-developed-by: Kandpal Suraj 
> >>> Signed-off-by: Abhinav Kumar 
> >>> ---
> >>>   drivers/gpu/drm/drm_writeback.c |  8 
> >>>   include/drm/drm_writeback.h | 13 +++--
> >>>   2 files changed, 15 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_writeback.c 
> >>> b/drivers/gpu/drm/drm_writeback.c
> >>> index dccf4504..4dad687 100644
> >>> --- a/drivers/gpu/drm/drm_writeback.c
> >>> +++ b/drivers/gpu/drm/drm_writeback.c
> >>> @@ -189,8 +189,8 @@ int drm_writeback_connector_init(struct drm_device 
> >>> *dev,
> >>>  if (IS_ERR(blob))
> >>>  return PTR_ERR(blob);
> >>>
> >>> -   drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
> >>> -   ret = drm_encoder_init(dev, &wb_connector->encoder,
> >>> +   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> >>> +   ret = drm_encoder_init(dev, wb_connector->encoder,
> >>> &drm_writeback_encoder_funcs,
> >>> DRM_MODE_ENCODER_VIRTUAL, NULL);
> >>
> >> If the encoder is provided by a separate driver, it might use a
> >> different set of encoder funcs.
> >
> > More than that, if the encoder is provided externally but doesn't have
> > custom operations, I don't really see the point of having an external
> > encoder in the first place.
> >
> > Has this series been tested with a driver that needs to provide an
> > encoder, to make sure it fits the purpose ?
> >
>
> Yes, I have tested this with the MSM driver which provides an encoder
> and yes it absolutely fits the purpose.
>
>
> >> I'd suggest checking whether the wb_connector->encoder is NULL here.
> >> If it is, allocate one using drmm_kzalloc and init it.
> >> If it is not NULL, assume that it has been initialized already, so
> >> skip the drm_encoder_init() and just call the drm_encoder_helper_add()
>
> You are both right. We can skip the drm_encoder_init for drivers which
> have already provided an encoder.
>
> The only issue I was facing with that is some of the drivers for example
> the below one, access the "wb_conn->encoder.possible_crtcs" before the
> call to drm_writeback_connector_init().

Yes. please do.

>
> 198 int rcar_du_writeback_init(struct rcar_du_device *rcdu,
> 199struct rcar_du_crtc *rcrtc)
> 200 {
> 201 struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
> 202
> 203 wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
> 204 drm_connector_helper_add(&wb_conn->base,
> 205  &rcar_du_wb_conn_helper_funcs);
> 206
> 207 return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
> 208 &rcar_du_wb_conn_funcs,
> 209 &rcar_du_wb_enc_helper_funcs,
> 210 writeback_formats,
> 211 ARRAY_SIZE(writeback_formats));
>
> If we allocate the encoder within drm_writeback_connector_init(), do you
> suggest I modify the drivers to move the usage of possible_crtcs after
> the drm_writeback_connector_init() call to avoid NULL ptr crash?
>
>
> >>
> >>>  if (ret)
> >>> @@ -204,7 +204,7 @@ int drm_writeback_connector_init(struct drm_device 
> >>> *dev,
> >>>  goto connector_fail;
> >>>
> >>>  ret = drm_connector_attach_encoder(connector,
> >>> -   &wb_connector->encoder);
> >>> +   wb_connector->encoder);
> >>>  if (ret)
> >>>  goto attach_fail;
> >>>
> >>> @@ -233,7 +233,7 @@ int drm_writeback_connector_init(struct drm_device 
> >>> *dev,
> >>>   attach_fail:
> >>>  drm_connector_cleanup(connector);
> >>>   connector_fail:
> >>> -   drm_encoder_cleanup(&wb_connector->encoder);
> >>> +   drm_encoder_cleanup(wb_connector->encoder);
> >>>   fail:
> >>>  drm_property_blob_put(blob);
> >>>  return ret;
> >>> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> >>> index 9697d27..0ba266e 100644
> >>> --- a/include/drm/drm_writeback.h
> >>> +++ b/include/drm/drm_writeback.h
> >>> @@ -25,13 +25,22 @@ struct drm_writeback_connector {
> >>

[PATCH] drm/edid: Update comments for drm_find_edid_extension

2022-03-11 Thread Drew Davenport

In (40d9b043a89e drm/connector: store tile information from displayid (v3))
this function was changed to find EDID extensions by id, but the comments
still are specific to the CEA extension.

Signed-off-by: Drew Davenport 

---

 drivers/gpu/drm/drm_edid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 561f53831e29..1afe73fbf3e0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3326,7 +3326,7 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define EDID_CEA_VCDB_QS   (1 << 6)
 
 /*
- * Search EDID for CEA extension block.
+ * Search EDID for the extension block with id @ext_id.
  */
 const u8 *drm_find_edid_extension(const struct edid *edid,
  int ext_id, int *ext_index)
@@ -3338,7 +3338,7 @@ const u8 *drm_find_edid_extension(const struct edid *edid,
if (edid == NULL || edid->extensions == 0)
return NULL;
 
-   /* Find CEA extension */
+   /* Find extension that matches @ext_id */
for (i = *ext_index; i < edid->extensions; i++) {
edid_ext = (const u8 *)edid + EDID_LENGTH * (i + 1);
if (edid_ext[0] == ext_id)
-- 
2.35.1.723.g4982287a31-goog

Re: [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc


On Tue, Mar 08, 2022 at 10:17:42PM +0530, Balasubramani Vivekanandan wrote:

This patch is continuation of the effort to move all pointers in i915,
which at any point may be pointing to device memory or system memory, to
iosys_map interface.
More details about the need of this change is explained in the patch
series which initiated this task
https://patchwork.freedesktop.org/series/99711/

This patch converts all access to the lrc_desc through iosys_map
interfaces.

Cc: Lucas De Marchi 
Cc: John Harrison 
Cc: Matthew Brost 
Cc: Umesh Nerlige Ramappa 
Signed-off-by: Balasubramani Vivekanandan 
---


...


diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -2245,13 +2256,13 @@ static void prepare_context_registration_info(struct 
intel_context *ce)
GEM_BUG_ON(i915_gem_object_is_lmem(guc->ct.vma->obj) !=
   i915_gem_object_is_lmem(ce->ring->vma->obj));

-   desc = __get_lrc_desc(guc, ctx_id);
-   desc->engine_class = engine_class_to_guc_class(engine->class);
-   desc->engine_submit_mask = engine->logical_mask;
-   desc->hw_context_desc = ce->lrc.lrca;
-   desc->priority = ce->guc_state.prio;
-   desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
-   guc_context_policy_init(engine, desc);
+   memset(&desc, 0, sizeof(desc));


previously we would re-use whatever was left in
guc->lrc_desc_pool_vaddr. Here we are changing it to always zero
everything and set the fields we are interested in.

As I'm not too familiar with this part and I see us traversing child 
guc_process_desc
which may point to the same id, it doesn't _feel_ safe. Did you check if
this is not zero'ing what it shouldn't?

Matt Brost / John / Daniele, could you clarify?

thanks
Lucas De Marchi

Re: [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc


On Tue, Mar 08, 2022 at 10:17:42PM +0530, Balasubramani Vivekanandan wrote:

This patch is continuation of the effort to move all pointers in i915,
which at any point may be pointing to device memory or system memory, to
iosys_map interface.
More details about the need of this change is explained in the patch
series which initiated this task
https://patchwork.freedesktop.org/series/99711/

This patch converts all access to the lrc_desc through iosys_map
interfaces.

Cc: Lucas De Marchi 
Cc: John Harrison 
Cc: Matthew Brost 
Cc: Umesh Nerlige Ramappa 
Signed-off-by: Balasubramani Vivekanandan 
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h|  2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 68 ---
2 files changed, 43 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e439e6c1ac8b..cbbc24dbaf0f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -168,7 +168,7 @@ struct intel_guc {
/** @lrc_desc_pool: object allocated to hold the GuC LRC descriptor 
pool */
struct i915_vma *lrc_desc_pool;
/** @lrc_desc_pool_vaddr: contents of the GuC LRC descriptor pool */
-   void *lrc_desc_pool_vaddr;
+   struct iosys_map lrc_desc_pool_vaddr;


s/_vaddr/_map/ for consistency with intel_guc_ads



/**
 * @context_lookup: used to resolve intel_context from guc_id, if a
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9ec03234d2c2..84b17ded886a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -467,13 +467,14 @@ static u32 *get_wq_pointer(struct guc_process_desc *desc,
return &__get_parent_scratch(ce)->wq[ce->parallel.guc.wqi_tail / 
sizeof(u32)];
}

-static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc *guc, u32 index)
+static void __write_lrc_desc(struct intel_guc *guc, u32 index,
+struct guc_lrc_desc *desc)
{
-   struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr;
+   unsigned int size = sizeof(struct guc_lrc_desc);

GEM_BUG_ON(index >= GUC_MAX_CONTEXT_ID);

-   return &base[index];
+   iosys_map_memcpy_to(&guc->lrc_desc_pool_vaddr, index * size, desc, 
size);


you are not using size anywhere else, so it would be preferred to keep the size
calculation inside this call.

iosys_map_memcpy_to(&guc->lrc_desc_pool_vaddr, index * size, desc, 
sizeof(*desc));

which also avoids accidentally using the wrong struct if we ever change
the type of what we are copying.


}

static inline struct intel_context *__get_context(struct intel_guc *guc, u32 id)
@@ -489,20 +490,28 @@ static int guc_lrc_desc_pool_create(struct intel_guc *guc)
{
u32 size;
int ret;
+   void *addr;


vaddr for consistency



size = PAGE_ALIGN(sizeof(struct guc_lrc_desc) *
  GUC_MAX_CONTEXT_ID);
ret = intel_guc_allocate_and_map_vma(guc, size, &guc->lrc_desc_pool,
-(void 
**)&guc->lrc_desc_pool_vaddr);
+&addr);
+
if (ret)
return ret;

+   if (i915_gem_object_is_lmem(guc->lrc_desc_pool->obj))
+   iosys_map_set_vaddr_iomem(&guc->lrc_desc_pool_vaddr,
+ (void __iomem *)addr);
+   else
+   iosys_map_set_vaddr(&guc->lrc_desc_pool_vaddr, addr);
+
return 0;
}

static void guc_lrc_desc_pool_destroy(struct intel_guc *guc)
{
-   guc->lrc_desc_pool_vaddr = NULL;
+   iosys_map_clear(&guc->lrc_desc_pool_vaddr);
i915_vma_unpin_and_release(&guc->lrc_desc_pool, I915_VMA_RELEASE_MAP);
}

@@ -513,9 +522,11 @@ static inline bool guc_submission_initialized(struct 
intel_guc *guc)

static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
{
-   struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
+   unsigned int size = sizeof(struct guc_lrc_desc);

-   memset(desc, 0, sizeof(*desc));
+   GEM_BUG_ON(id >= GUC_MAX_CONTEXT_ID);
+
+   iosys_map_memset(&guc->lrc_desc_pool_vaddr, id * size, 0, size);


ditto. And maybe move it be close to __write_lrc_desc. I don't really
understand the difference here with 1 underscore vs the 2. Maybe as a
follow up just reconcile them?

The rest I left to another reply to focus on what may be the only
real issue I see in this patch and to get feedback from other people.

thanks
Lucas De Marchi

Re: [PATCH 1/5] dyndbg: fix static_branch manipulation

2022-03-11 Thread Jason Baron




On 3/10/22 23:47, Jim Cromie wrote:
> In 
> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/__;!!GjvTz_vk!HGKKoni4RVdEBgv_V0zPSNSX428bpf02zkCy2WbeQkBdVtp1QJqGX-lJYlRDGg$
>  
> 
> Vincent's patch commented on, and worked around, a bug toggling
> static_branch's, when a 2nd PRINTK-ish flag was added.  The bug
> results in a premature static_branch_disable when the 1st of 2 flags
> was disabled.
> 
> The cited commit computed newflags, but then in the JUMP_LABEL block,
> failed to use that result, instead using just one of the terms in it.
> Using newflags instead made the code work properly.
> 
> This is Vincents test-case, reduced.  It needs the 2nd flag to work
> properly, but it's explanatory here.
> 
> pt_test() {
> echo 5 > /sys/module/dynamic_debug/verbose
> 
> site="module tcp" # just one callsite
> echo " $site =_ " > /proc/dynamic_debug/control # clear it
> 
> # A B ~A ~B
> for flg in +T +p "-T #broke here" -p; do
>   echo " $site $flg " > /proc/dynamic_debug/control
> done;
> 
> # A B ~B ~A
> for flg in +T +p "-p #broke here" -T; do
>   echo " $site $flg " > /proc/dynamic_debug/control
> done
> }
> pt_test
> 
> Fixes: 84da83a6ffc0 dyndbg: combine flags & mask into a struct, simplify with 
> it
> CC: vincent.whitchu...@axis.com
> Signed-off-by: Jim Cromie 
> 
> --
> .drop @stable, no exposed bug.
> ---
>  lib/dynamic_debug.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index dd7f56af9aed..a56c1286ffa4 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -211,10 +211,11 @@ static int ddebug_change(const struct ddebug_query 
> *query,
>   continue;
>  #ifdef CONFIG_JUMP_LABEL
>   if (dp->flags & _DPRINTK_FLAGS_PRINT) {
> - if (!(modifiers->flags & _DPRINTK_FLAGS_PRINT))
> + if (!(newflags & _DPRINTK_FLAGS_PRINT))
>   
> static_branch_disable(&dp->key.dd_key_true);
> - } else if (modifiers->flags & _DPRINTK_FLAGS_PRINT)
> + } else if (newflags & _DPRINTK_FLAGS_PRINT) {
>   static_branch_enable(&dp->key.dd_key_true);
> + }
>  #endif
>   dp->flags = newflags;
>   v4pr_info("changed %s:%d [%s]%s =%s\n",



Hi Jim,

If iiuc this is currently a bug but could be if we add a second 'print' bit
such as for printing to the tracing logs. That said I agree that using 
'newflags'
here makes the code more straightforward/readable. So this one is fine with
me.

Acked-by: Jason Baron 

Thanks,

-Jason

Re: [PATCH 2/2] dma-buf/sync-file: fix warning about fence containers

Hi "Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.17-rc7 next-20220310]
[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/Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
79b00034e9dcd2b065c1665c8b42f62b6b80a9be
config: x86_64-randconfig-m001 
(https://download.01.org/0day-ci/archive/20220312/202203120217.bfa438j9-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_unwrap/20220311-190352
git checkout ca3584ac05c4a450e69b1c6bcb0672b5ab026c7c
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 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/dma-buf/sync_file.c:8:
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_array':
>> include/linux/dma-fence-unwrap.h:44:18: error: implicit declaration of 
>> function 'dma_fence_chain_contained'; did you mean 'dma_fence_chain_init'? 
>> [-Werror=implicit-function-declaration]
  44 |  cursor->array = dma_fence_chain_contained(cursor->chain);
 |  ^
 |  dma_fence_chain_init
   include/linux/dma-fence-unwrap.h:44:16: warning: assignment to 'struct 
dma_fence *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  44 |  cursor->array = dma_fence_chain_contained(cursor->chain);
 |^
>> include/linux/dma-fence-unwrap.h:46:9: error: implicit declaration of 
>> function 'dma_fence_array_first'; did you mean 'dma_fence_array_create'? 
>> [-Werror=implicit-function-declaration]
  46 |  return dma_fence_array_first(cursor->array);
 | ^
 | dma_fence_array_create
   include/linux/dma-fence-unwrap.h:46:9: warning: returning 'int' from a 
function with return type 'struct dma_fence *' makes pointer from integer 
without a cast [-Wint-conversion]
  46 |  return dma_fence_array_first(cursor->array);
 | ^~~~
   include/linux/dma-fence-unwrap.h: In function 'dma_fence_unwrap_next':
>> include/linux/dma-fence-unwrap.h:77:8: error: implicit declaration of 
>> function 'dma_fence_array_next'; did you mean 'dma_fence_unwrap_next'? 
>> [-Werror=implicit-function-declaration]
  77 |  tmp = dma_fence_array_next(cursor->array, cursor->index);
 |^~~~
 |dma_fence_unwrap_next
   include/linux/dma-fence-unwrap.h:77:6: warning: assignment to 'struct 
dma_fence *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
  77 |  tmp = dma_fence_array_next(cursor->array, cursor->index);
 |  ^
   cc1: some warnings being treated as errors


vim +44 include/linux/dma-fence-unwrap.h

088aa14c0f5cad Christian König 2022-03-11  33  
088aa14c0f5cad Christian König 2022-03-11  34  /**
088aa14c0f5cad Christian König 2022-03-11  35   * dma_fence_unwrap_array - 
helper to unwrap dma_fence_arrays
088aa14c0f5cad Christian König 2022-03-11  36   * @cursor: cursor to initialize
088aa14c0f5cad Christian König 2022-03-11  37   *
088aa14c0f5cad Christian König 2022-03-11  38   * Helper function to unwrap 
dma_fence_array containers, don't touch directly.
088aa14c0f5cad Christian König 2022-03-11  39   * Use 
dma_fence_unwrap_first/next instead.
088aa14c0f5cad Christian König 2022-03-11  40   */
088aa14c0f5cad Christian König 2022-03-11  41  static inline struct dma_fence *
088aa14c0f5cad Christian König 2022-03-11  42  dma_fence_unwrap_array(struct 
dma_fence_unwrap * cursor)
088aa14c0f5cad Christian König 2022-03-11  43  {
088aa14c0f5cad Christian König 2022-03-11 @44   cursor->array = 
dma_fence_chain_contained(cursor->chain);
088aa14c0f5cad Christian König 2022-03-11  45   cursor->index = 0;
088aa14c0f5cad Christian König 2022-03-11 @46   return 
dma_fence_array_first(cursor->array);
088aa14c0f5cad Christian König 2022-03-11  47  }
088aa14c0f5cad Christian König 2022-03-11  48  
08

Re: [Intel-gfx] [PATCH 1/2] drm/i915/sseu: Don't overallocate subslice storage


On Thu, Mar 10, 2022 at 10:15:42PM -0800, Matt Roper wrote:

Xe_HP removed "slice" as a first-class unit in the hardware design.
Instead we now have a single pool of subslices (which are now referred
to as "DSS") that different hardware units have different ways of
grouping ("compute slices," "geometry slices," etc.).  For the purposes
of topology representation, we treat Xe_HP-based platforms as having a
single slice that contains all of the platform's DSS.  There's no need
to allocate storage space for (max legacy slices * max dss); let's
update some of our macros to minimize the storage requirement for sseu
topology.  We'll also document some of the constants to make it a little
bit more clear what they represent.

Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/gt/intel_engine_types.h |  2 +-
drivers/gpu/drm/i915/gt/intel_sseu.h | 47 +++-
2 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 4fbf45a74ec0..f9e246004bc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -645,7 +645,7 @@ intel_engine_has_relative_mmio(const struct intel_engine_cs 
* const engine)

#define for_each_instdone_gslice_dss_xehp(dev_priv_, sseu_, iter_, gslice_, 
dss_) \
for ((iter_) = 0, (gslice_) = 0, (dss_) = 0; \
-(iter_) < GEN_MAX_SUBSLICES; \
+(iter_) < GEN_SS_MASK_SIZE; \
 (iter_)++, (gslice_) = (iter_) / GEN_DSS_PER_GSLICE, \
 (dss_) = (iter_) % GEN_DSS_PER_GSLICE) \
for_each_if(intel_sseu_has_subslice((sseu_), 0, (iter_)))
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h 
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 8a79cd8eaab4..4f59eadbb61a 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -15,26 +15,49 @@ struct drm_i915_private;
struct intel_gt;
struct drm_printer;

-#define GEN_MAX_SLICES (3) /* SKL upper bound */
-#define GEN_MAX_SUBSLICES  (32) /* XEHPSDV upper bound */
-#define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
-#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
-#define GEN_MAX_EUS(16) /* TGL upper bound */
-#define GEN_MAX_EU_STRIDE GEN_SSEU_STRIDE(GEN_MAX_EUS)
+/*
+ * Maximum number of legacy slices.  Legacy slices no longer exist starting on
+ * Xe_HP ("gslices," "cslices," etc. on Xe_HP and beyond are a different
+ * concept and are not expressed through fusing).
+ */
+#define GEN_MAX_LEGACY_SLICES  3
+
+/*
+ * Maximum number of subslices that can exist within a legacy slice.  This is
+ * only relevant to pre-Xe_HP platforms (Xe_HP and beyond use the GEN_MAX_DSS
+ * value below).
+ */
+#define GEN_MAX_LEGACY_SUBSLICES   6


instead of calling the old legacy, maybe just add the XEHP_ prefix to
the new ones?


+
+/* Maximum number of DSS on newer platforms (Xe_HP and beyond). */
+#define GEN_MAX_DSS32
+
+/* Maximum number of EUs that can exist within a subslice or DSS. */
+#define GEN_MAX_EUS_PER_SS 16
+
+#define MAX(a, b)  ((a) > (b) ? (a) : (b))


what's worse, include kernel.h in another header file or redefine MAX
everywhere? Re-defining it in headers we risk situations in which the
include order may create warnings about defining it in multiple places.



+
+/* The maximum number of bits needed to express each subslice/DSS 
independently */
+#define GEN_SS_MASK_SIZE   MAX(GEN_MAX_DSS, \
+   GEN_MAX_LEGACY_SLICES * 
GEN_MAX_LEGACY_SUBSLICES)
+
+#define GEN_SSEU_STRIDE(max_entries)   DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
+#define GEN_MAX_SUBSLICE_STRIDE
GEN_SSEU_STRIDE(GEN_SS_MASK_SIZE)
+#define GEN_MAX_EU_STRIDE  GEN_SSEU_STRIDE(GEN_MAX_EUS_PER_SS)

#define GEN_DSS_PER_GSLICE  4
#define GEN_DSS_PER_CSLICE  8
#define GEN_DSS_PER_MSLICE  8

-#define GEN_MAX_GSLICES(GEN_MAX_SUBSLICES / GEN_DSS_PER_GSLICE)
-#define GEN_MAX_CSLICES(GEN_MAX_SUBSLICES / GEN_DSS_PER_CSLICE)
+#define GEN_MAX_GSLICES(GEN_MAX_DSS / GEN_DSS_PER_GSLICE)
+#define GEN_MAX_CSLICES(GEN_MAX_DSS / GEN_DSS_PER_CSLICE)

struct sseu_dev_info {
u8 slice_mask;
-   u8 subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
-   u8 geometry_subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
-   u8 compute_subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
-   u8 eu_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICES * GEN_MAX_EU_STRIDE];
+   u8 subslice_mask[GEN_SS_MASK_SIZE];
+   u8 geometry_subslice_mask[GEN_SS_MASK_SIZE];
+   u8 compute_subslice_mask[GEN_SS_MASK_SIZE];
+   u8 eu_mask[GEN_SS_MASK_SIZE * GEN_MAX_EU_STRIDE];



Aside the minor things above, everything look correct.

Reviewed-by: Lucas

Re: [PATCH 2/5] dyndbg: add class_id field and query support

2022-03-11 Thread Jason Baron




On 3/10/22 23:47, Jim Cromie wrote:
> DRM defines/uses 10 enum drm_debug_category's to create exclusive
> classes of debug messages.  To support this directly in dynamic-debug,
> add the following:
> 
> - struct _ddebug.class_id:4 - 4 bits is enough
> - define _DPRINTK_SITE_UNCLASSED 15 - see below
> 
> and the query support:
> - struct _ddebug_query.class_id
> - ddebug_parse_query  - looks for "class" keyword, then calls..
> - parse_class - accepts uint: 0-15, sets query.class_id and marker
> - vpr_info_dq - displays new field
> - ddebug_proc_show- append column with "cls:%d" if !UNCLASSED
> 
> With the patch, one can enable current/unclassed callsites by:
> 
>   #> echo drm class 15 +p > /proc/dynamic_debug/control
> 

To me, this is hard to read, what the heck is '15'? I have to go look it
up in the control file and it's not descriptive. I think that using
classes/categories makes sense but I'm wondering if it can be a bit more
user friendly? Perhaps, we can pass an array of strings that is indexed
by the class id to each pr_debug() site that wants to use class. So
something like:

enum levels {
LOW,
MEDIUM,
HIGH
};

static const char * const level_to_strings[] = {
[LOW] = "low",
[MEDIUM] = "medium",
[HIGH] = "high",
};

And then you'd have a wrapper macros in your driver:

#define module_foo_pr_debug_class(level, fmt, args...)
pr_debug_class(level, level_to_strings, fmt, args);

Such that call sites look like:

module_foo_pr_debug_class(LOW, fmt, args...);

Such that you're not always passing the strings array around. Now, this
does mean another pointer for struct _ddebug and most wouldn't have it.
Maybe we could just add another linker section for these so as to save
space.

> parse_class() accepts 0 .. _DPRINTK_SITE_UNCLASSED, which allows the
>> control interface to explicitly manipulate unclassed callsites.
> 
> After parsing keywords, ddebug_parse_query() sets .class_id=15, iff it
> wasnt explicitly set.  This allows future classed/categorized
> callsites to be untouched by legacy (class unaware) queries.
> 
> DEFINE_DYNAMIC_DEBUG_METADATA gets _CLS(cls,) suffix and arg, and
> initializes the new .class_id=cls field.  The old name gets the default.
> 
> Then, these _CLS(cls,...) modifications are repeated up through the
> stack of *dynamic_func_call* macros that use the METADATA initializer,
> so as to actually supply the category into it.
> 
> NOTES:
> 
> _DPRINTK_SITE_UNCLASSED: this symbol is used to initialize all
> existing/unclassed pr-debug callsites.  Normally, the default would be
> zero, but DRM_UT_CORE "uses" that value, in the sense that 0 is
> exposed as a bit position in drm.debug.  Using 15 allows identity
> mapping from category to class, avoiding fiddly offsets.
> 
> Default .class_id = 15 means that ``echo +p > control`` no longer
> toggles ALL the callsites, only the unclassed ones.  This was only
> useful for static-branch toggle load testing anyway.
> 

I think that # echo +p > control should continue to work as is, why
should the introduction of classes change that ?

> RFC:
> 
> The new _CLS macro flavor gets a warning from DRM/dri-devel's CI,
> but not from checkpatch (on this subject).
> 
> a8f6c71f283e dyndbg: add class_id field and query support
> -:141: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible 
> side-effects?
> +#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do {\
> + DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
> + if (DYNAMIC_DEBUG_BRANCH(id))   \
> + func(&id, ##__VA_ARGS__);   \
>  } while (0)
> 
> I couldn't fix it with a ``typeof(id) _id = id`` construct.  I haven't
> seen the warning myself, on the _CLS extended macro, nor the original.
> 
> CC: Rasmus Villemoes 
> Signed-off-by: Jim Cromie 
> ---
>  .../admin-guide/dynamic-debug-howto.rst   |  7 +++
>  include/linux/dynamic_debug.h | 54 ++-
>  lib/dynamic_debug.c   | 48 ++---
>  3 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
> b/Documentation/admin-guide/dynamic-debug-howto.rst
> index a89cfa083155..8ef8d7dcd140 100644
> --- a/Documentation/admin-guide/dynamic-debug-howto.rst
> +++ b/Documentation/admin-guide/dynamic-debug-howto.rst
> @@ -35,6 +35,7 @@ Dynamic debug has even more useful features:
> - line number (including ranges of line numbers)
> - module name
> - format string
> +   - class number:0-15
>  
>   * Provides a debugfs control file: ``/dynamic_debug/control``
> which can be read to display the complete list of known debug
> @@ -143,6 +144,7 @@ against.  Possible keywords are:::
>'module' string |
>'format' string |
>'line' line-range
> +  'class' integer:[0-15]
>  
>line-range ::= linen

Re: [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP

Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next drm/drm-next 
next-20220310]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next 
airlied/drm-next v5.17-rc7]
[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/Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-rhel-8.3-kselftests 
(https://download.01.org/0day-ci/archive/20220312/202203120322.okxcdfs7-...@intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
# 
https://github.com/0day-ci/linux/commit/38985b2e6acdbe67dedb5de8a8aeef917b746453
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Matt-Roper/drm-i915-sseu-Don-t-overallocate-subslice-storage/20220311-141705
git checkout 38985b2e6acdbe67dedb5de8a8aeef917b746453
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir 
ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gt/intel_sseu.c:59:5: sparse: sparse: symbol 
>> 'intel_sseu_get_geometry_subslices' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[RFC PATCH] drm/i915/xehp: intel_sseu_get_geometry_subslices() can be static

drivers/gpu/drm/i915/gt/intel_sseu.c:59:5: warning: symbol 
'intel_sseu_get_geometry_subslices' was not declared. Should it be static?

Reported-by: kernel test robot 
Signed-off-by: kernel test robot 
---
 drivers/gpu/drm/i915/gt/intel_sseu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 4d28458ab768d..99e31dcf3db06 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -56,7 +56,7 @@ u32 intel_sseu_get_subslices(const struct sseu_dev_info 
*sseu, u8 slice)
return _intel_sseu_get_subslices(sseu, sseu->subslice_mask, slice);
 }
 
-u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
+static u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)
 {
return _intel_sseu_get_subslices(sseu, sseu->geometry_subslice_mask, 0);
 }

Re: [Intel-gfx] [PATCH 2/2] drm/i915/xehp: Update topology dumps for Xe_HP


On Thu, Mar 10, 2022 at 10:15:43PM -0800, Matt Roper wrote:

When running on Xe_HP or beyond, let's use an updated format for
describing topology in our error state dumps and debugfs to give a
more accurate view of the hardware:

- Just report DSS directly without the legacy "slice0" output that's no
  longer meaningful.
- Indicate whether each DSS is accessible for geometry and/or compute.
- Rename "rcs_topology" to "sseu_topology" since the information
  reported is common to both RCS and CCS engines now.

Signed-off-by: Matt Roper 
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 48 +---
drivers/gpu/drm/i915/gt/intel_sseu.h |  3 +-
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c |  8 ++--
drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
4 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 614915ffbd37..4d28458ab768 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -10,6 +10,8 @@
#include "intel_gt_regs.h"
#include "intel_sseu.h"

+#include "linux/string_helpers.h"
+
void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
 u8 max_subslices, u8 max_eus_per_subslice)
{
@@ -54,6 +56,11 @@ u32 intel_sseu_get_subslices(const struct sseu_dev_info 
*sseu, u8 slice)
return _intel_sseu_get_subslices(sseu, sseu->subslice_mask, slice);


this func with a single underscore is the one inconsistent with the rest of the 
file.
Just rename it while touching this part of the code?


}

+u32 intel_sseu_get_geometry_subslices(const struct sseu_dev_info *sseu)


since it's only local to this compilation unit, make it static and
remove the intel_ prefix?


+{
+   return _intel_sseu_get_subslices(sseu, sseu->geometry_subslice_mask, 0);
+}
+
u32 intel_sseu_get_compute_subslices(const struct sseu_dev_info *sseu)
{
return _intel_sseu_get_subslices(sseu, sseu->compute_subslice_mask, 0);
@@ -720,16 +727,11 @@ void intel_sseu_dump(const struct sseu_dev_info *sseu, 
struct drm_printer *p)
   str_yes_no(sseu->has_eu_pg));
}

-void intel_sseu_print_topology(const struct sseu_dev_info *sseu,
-  struct drm_printer *p)
+static void intel_sseu_print_legacy_topology(const struct sseu_dev_info *sseu,


removing the intel_ prefix would make it consistent with the rest of the file 
too


+struct drm_printer *p)
{
int s, ss;

-   if (sseu->max_slices == 0) {
-   drm_printf(p, "Unavailable\n");
-   return;
-   }
-
for (s = 0; s < sseu->max_slices; s++) {
drm_printf(p, "slice%d: %u subslice(s) (0x%08x):\n",
   s, intel_sseu_subslices_per_slice(sseu, s),
@@ -744,6 +746,38 @@ void intel_sseu_print_topology(const struct sseu_dev_info 
*sseu,
}
}

+static void intel_sseu_print_xehp_topology(const struct sseu_dev_info *sseu,
+  struct drm_printer *p)


ditto


+{
+   u32 g_dss_mask = intel_sseu_get_geometry_subslices(sseu);
+   u32 c_dss_mask = intel_sseu_get_compute_subslices(sseu);
+   int dss;
+
+   for (dss = 0; dss < sseu->max_subslices; dss++) {
+   u16 enabled_eus = sseu_get_eus(sseu, 0, dss);
+
+   drm_printf(p, "DSS%02d: G:%3s C:%3s, %2u EUs (0x%04hx)\n", dss,
+  str_yes_no(g_dss_mask & BIT(dss)),
+  str_yes_no(c_dss_mask & BIT(dss)),
+  hweight16(enabled_eus), enabled_eus);
+   }
+}
+
+
+void intel_sseu_print_topology(struct drm_i915_private *i915,
+  const struct sseu_dev_info *sseu,
+  struct drm_printer *p)
+{
+   if (sseu->max_slices == 0) {
+   drm_printf(p, "Unavailable\n");
+   return;


either make this an early return, or remove the return

other than coding style nits metioned above,


Reviewed-by: Lucas De Marchi 

Lucas De Marchi

Re: [PATCH V3 05/13] drm: bridge: icn6211: Add DSI lane count DT property parsing