[PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

This is v9 of the VOP2 series. Biggest change this time is that I marked
the hclk_vo as critical instead of enabling it in the HDMI driver. Also
a little bugfix is included for a bug in setting up the layer mixer,
reported by Andy Yan.

Note that this series depends on these patches:

clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock
clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop*
clk: rockchip: rk3568: Add more PLL rates

These are not included in this series as they are already applied by
Heiko. They haven't hit mainline yet, you can pick them from v4 of this
series.

Sascha


Changes since v8:
- make hclk_vo a critical clock instead of enabling it in the hdmi driver
- Fix vop2_setup_layer_mixer(), reported by Andy Yan
- Limit planes possible_crtcs to actually existing crtcs
- simplify vop2_create_crtc() a bit

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 (17):
  clk: rk3568: Mark hclk_vo as critical
  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
  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    |   46 +-
 .../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/clk/rockchip/clk-rk3568.c             |    1 +
 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   |  276 +-
 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  | 2688 +++++++++++++++++
 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 +
 27 files changed, 4167 insertions(+), 195 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
 create mode 100644 include/dt-bindings/soc/rockchip,vop2.h

-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 01/23] clk: rk3568: Mark hclk_vo as critical

[Sascha Hauer]

Whenever pclk_vo is enabled hclk_vo must be enabled as well. This is
described in the Reference Manual as:

| 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 doesn't offer a way to enable clock B whenever clock A is
enabled, at least not when B is not an ancestor of A. Workaround this by
marking hclk_vo as critical so it is never disabled. This is suboptimal in
terms of power consumption, but a stop gap solution until the clock framework
has a way to deal with this.

We have this clock tree:

|      aclk_vo                  2        2        0   300000000          0     0  50000         Y
|         aclk_hdcp             0        0        0   300000000          0     0  50000         N
|         pclk_vo               2        3        0    75000000          0     0  50000         Y
|            pclk_edp_ctrl      0        0        0    75000000          0     0  50000         N
|            pclk_dsitx_1       0        0        0    75000000          0     0  50000         N
|            pclk_dsitx_0       1        2        0    75000000          0     0  50000         Y
|            pclk_hdmi_host     1        2        0    75000000          0     0  50000         Y
|            pclk_hdcp          0        0        0    75000000          0     0  50000         N
|         hclk_vo               2        5        0   150000000          0     0  50000         Y
|            hclk_hdcp          0        0        0   150000000          0     0  50000         N
|            hclk_vop           0        2        0   150000000          0     0  50000         N

Without this patch the edp, dsitx, hdmi and hdcp driver would enable their
clocks which then enables pclk_vo, but hclk_vo stays disabled and register
accesses just hang. hclk_vo is enabled by the VOP2 driver, so reproducibility
of this issue depends on the probe order.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

Notes:
    Changes since v8:
    - new patch

 drivers/clk/rockchip/clk-rk3568.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
index 63dfbeeeb06d9..62694d95173ab 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -1591,6 +1591,7 @@ static const char *const rk3568_cru_critical_clocks[] __initconst = {
 	"hclk_php",
 	"pclk_php",
 	"hclk_usb",
+	"hclk_vo",
 };
 
 static const char *const rk3568_pmucru_critical_clocks[] __initconst = {
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 01/23] clk: rk3568: Mark hclk_vo as critical

[Dmitry Osipenko]

On 3/28/22 18:10, Sascha Hauer wrote:
> Whenever pclk_vo is enabled hclk_vo must be enabled as well. This is
> described in the Reference Manual as:
> 
> | 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 doesn't offer a way to enable clock B whenever clock A is
> enabled, at least not when B is not an ancestor of A. Workaround this by
> marking hclk_vo as critical so it is never disabled. This is suboptimal in
> terms of power consumption, but a stop gap solution until the clock framework
> has a way to deal with this.
> 
> We have this clock tree:
> 
> |      aclk_vo                  2        2        0   300000000          0     0  50000         Y
> |         aclk_hdcp             0        0        0   300000000          0     0  50000         N
> |         pclk_vo               2        3        0    75000000          0     0  50000         Y
> |            pclk_edp_ctrl      0        0        0    75000000          0     0  50000         N
> |            pclk_dsitx_1       0        0        0    75000000          0     0  50000         N
> |            pclk_dsitx_0       1        2        0    75000000          0     0  50000         Y
> |            pclk_hdmi_host     1        2        0    75000000          0     0  50000         Y
> |            pclk_hdcp          0        0        0    75000000          0     0  50000         N
> |         hclk_vo               2        5        0   150000000          0     0  50000         Y
> |            hclk_hdcp          0        0        0   150000000          0     0  50000         N
> |            hclk_vop           0        2        0   150000000          0     0  50000         N
> 
> Without this patch the edp, dsitx, hdmi and hdcp driver would enable their
> clocks which then enables pclk_vo, but hclk_vo stays disabled and register
> accesses just hang. hclk_vo is enabled by the VOP2 driver, so reproducibility
> of this issue depends on the probe order.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> 
> Notes:
>     Changes since v8:
>     - new patch
> 
>  drivers/clk/rockchip/clk-rk3568.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
> index 63dfbeeeb06d9..62694d95173ab 100644
> --- a/drivers/clk/rockchip/clk-rk3568.c
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -1591,6 +1591,7 @@ static const char *const rk3568_cru_critical_clocks[] __initconst = {
>  	"hclk_php",
>  	"pclk_php",
>  	"hclk_usb",
> +	"hclk_vo",
>  };
>  
>  static const char *const rk3568_pmucru_critical_clocks[] __initconst = {

Nice! That's much better than the DT hacks, IMO, thank you.

Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 01/23] clk: rk3568: Mark hclk_vo as critical

[Robin Murphy]

On 2022-03-28 16:10, Sascha Hauer wrote:
> Whenever pclk_vo is enabled hclk_vo must be enabled as well. This is
> described in the Reference Manual as:
> 
> | 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 doesn't offer a way to enable clock B whenever clock A is
> enabled, at least not when B is not an ancestor of A. Workaround this by
> marking hclk_vo as critical so it is never disabled. This is suboptimal in
> terms of power consumption, but a stop gap solution until the clock framework
> has a way to deal with this.
> 
> We have this clock tree:
> 
> |      aclk_vo                  2        2        0   300000000          0     0  50000         Y
> |         aclk_hdcp             0        0        0   300000000          0     0  50000         N
> |         pclk_vo               2        3        0    75000000          0     0  50000         Y
> |            pclk_edp_ctrl      0        0        0    75000000          0     0  50000         N
> |            pclk_dsitx_1       0        0        0    75000000          0     0  50000         N
> |            pclk_dsitx_0       1        2        0    75000000          0     0  50000         Y
> |            pclk_hdmi_host     1        2        0    75000000          0     0  50000         Y
> |            pclk_hdcp          0        0        0    75000000          0     0  50000         N
> |         hclk_vo               2        5        0   150000000          0     0  50000         Y
> |            hclk_hdcp          0        0        0   150000000          0     0  50000         N
> |            hclk_vop           0        2        0   150000000          0     0  50000         N
> 
> Without this patch the edp, dsitx, hdmi and hdcp driver would enable their
> clocks which then enables pclk_vo, but hclk_vo stays disabled and register
> accesses just hang. hclk_vo is enabled by the VOP2 driver, so reproducibility
> of this issue depends on the probe order.

FWIW,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> 
> Notes:
>      Changes since v8:
>      - new patch
> 
>   drivers/clk/rockchip/clk-rk3568.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
> index 63dfbeeeb06d9..62694d95173ab 100644
> --- a/drivers/clk/rockchip/clk-rk3568.c
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -1591,6 +1591,7 @@ static const char *const rk3568_cru_critical_clocks[] __initconst = {
>   	"hclk_php",
>   	"pclk_php",
>   	"hclk_usb",
> +	"hclk_vo",
>   };
>   
>   static const char *const rk3568_pmucru_critical_clocks[] __initconst = {

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 02/23] drm/rockchip: Embed drm_encoder into rockchip_decoder

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
---

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 c82901d9a9ccd..28fcc8efa33db 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(dp->adp, drm_dev);
 	if (ret)
@@ -341,7 +351,7 @@ static int rockchip_dp_bind(struct device *dev, struct device *master,
 
 	return 0;
 err_cleanup_encoder:
-	dp->encoder.funcs->destroy(&dp->encoder);
+	dp->encoder.encoder.funcs->destroy(&dp->encoder.encoder);
 	return ret;
 }
 
@@ -351,7 +361,7 @@ static void rockchip_dp_unbind(struct device *dev, struct device *master,
 	struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
 	analogix_dp_unbind(dp->adp);
-	dp->encoder.funcs->destroy(&dp->encoder);
+	dp->encoder.encoder.funcs->destroy(&dp->encoder.encoder);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index d3e6c93739bf6..8584e19792be2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -26,11 +26,17 @@
 #include "cdn-dp-reg.h"
 #include "rockchip_drm_vop.h"
 
-#define connector_to_dp(c) \
-		container_of(c, struct cdn_dp_device, connector)
+static inline struct cdn_dp_device *connector_to_dp(struct drm_connector *connector)
+{
+	return container_of(connector, struct cdn_dp_device, connector);
+}
 
-#define encoder_to_dp(c) \
-		container_of(c, struct cdn_dp_device, encoder)
+static inline struct cdn_dp_device *encoder_to_dp(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct cdn_dp_device, encoder);
+}
 
 #define GRF_SOC_CON9		0x6224
 #define DP_SEL_VOP_LIT		BIT(12)
@@ -1050,7 +1056,7 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
 
 	INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
 
-	encoder = &dp->encoder;
+	encoder = &dp->encoder.encoder;
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
 							     dev->of_node);
@@ -1115,7 +1121,7 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
 static void cdn_dp_unbind(struct device *dev, struct device *master, void *data)
 {
 	struct cdn_dp_device *dp = dev_get_drvdata(dev);
-	struct drm_encoder *encoder = &dp->encoder;
+	struct drm_encoder *encoder = &dp->encoder.encoder;
 	struct drm_connector *connector = &dp->connector;
 
 	cancel_work_sync(&dp->event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 6d0c5032ef3ad..f7d4cecb46ba4 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -66,7 +66,7 @@ struct cdn_dp_device {
 	struct device *dev;
 	struct drm_device *drm_dev;
 	struct drm_connector connector;
-	struct drm_encoder encoder;
+	struct rockchip_encoder encoder;
 	struct drm_display_mode mode;
 	struct platform_device *audio_pdev;
 	struct work_struct event_work;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 4ed7a68681978..110e83aad9bb4 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -181,8 +181,6 @@
 
 #define HIWORD_UPDATE(val, mask)	(val | (mask) << 16)
 
-#define to_dsi(nm)	container_of(nm, struct dw_mipi_dsi_rockchip, nm)
-
 enum {
 	DW_DSI_USAGE_IDLE,
 	DW_DSI_USAGE_DSI,
@@ -236,7 +234,7 @@ struct rockchip_dw_dsi_chip_data {
 
 struct dw_mipi_dsi_rockchip {
 	struct device *dev;
-	struct drm_encoder encoder;
+	struct rockchip_encoder encoder;
 	void __iomem *base;
 
 	struct regmap *grf_regmap;
@@ -271,6 +269,13 @@ struct dw_mipi_dsi_rockchip {
 	bool dsi_bound;
 };
 
+static struct dw_mipi_dsi_rockchip *to_dsi(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct dw_mipi_dsi_rockchip, encoder);
+}
+
 struct dphy_pll_parameter_map {
 	unsigned int max_mbps;
 	u8 hsfreqrange;
@@ -770,7 +775,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
 	int ret, mux;
 
 	mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node,
-						&dsi->encoder);
+						&dsi->encoder.encoder);
 	if (mux < 0)
 		return;
 
@@ -801,7 +806,7 @@ dw_mipi_dsi_encoder_helper_funcs = {
 static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
 					   struct drm_device *drm_dev)
 {
-	struct drm_encoder *encoder = &dsi->encoder;
+	struct drm_encoder *encoder = &dsi->encoder.encoder;
 	int ret;
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
@@ -959,7 +964,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
 		goto out_pll_clk;
 	}
 
-	ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
+	ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder.encoder);
 	if (ret) {
 		DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
 		goto out_pll_clk;
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8677c82716784..06c9ddef6f362 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -67,7 +67,7 @@ struct rockchip_hdmi_chip_data {
 struct rockchip_hdmi {
 	struct device *dev;
 	struct regmap *regmap;
-	struct drm_encoder encoder;
+	struct rockchip_encoder encoder;
 	const struct rockchip_hdmi_chip_data *chip_data;
 	struct clk *vpll_clk;
 	struct clk *grf_clk;
@@ -75,7 +75,12 @@ struct rockchip_hdmi {
 	struct phy *phy;
 };
 
-#define to_rockchip_hdmi(x)	container_of(x, struct rockchip_hdmi, x)
+static struct rockchip_hdmi *to_rockchip_hdmi(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct rockchip_hdmi, encoder);
+}
 
 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
 	{
@@ -511,7 +516,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	hdmi->dev = &pdev->dev;
 	hdmi->chip_data = plat_data->phy_data;
 	plat_data->phy_data = hdmi;
-	encoder = &hdmi->encoder;
+	encoder = &hdmi->encoder.encoder;
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
 	/*
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 046e8ec2a71c5..0a4f72021d6af 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -26,8 +26,6 @@
 
 #include "inno_hdmi.h"
 
-#define to_inno_hdmi(x)	container_of(x, struct inno_hdmi, x)
-
 struct hdmi_data_info {
 	int vic;
 	bool sink_is_hdmi;
@@ -56,7 +54,7 @@ struct inno_hdmi {
 	void __iomem *regs;
 
 	struct drm_connector	connector;
-	struct drm_encoder	encoder;
+	struct rockchip_encoder	encoder;
 
 	struct inno_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
@@ -67,6 +65,18 @@ struct inno_hdmi {
 	struct drm_display_mode previous_mode;
 };
 
+static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct inno_hdmi, encoder);
+}
+
+static struct inno_hdmi *connector_to_inno_hdmi(struct drm_connector *connector)
+{
+	return container_of(connector, struct inno_hdmi, connector);
+}
+
 enum {
 	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
 	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
@@ -483,7 +493,7 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 				       struct drm_display_mode *mode,
 				       struct drm_display_mode *adj_mode)
 {
-	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_setup(hdmi, adj_mode);
 
@@ -493,14 +503,14 @@ static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 
 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
 {
-	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
 }
 
 static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
 {
-	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
 
 	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
 }
@@ -536,7 +546,7 @@ static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
 static enum drm_connector_status
 inno_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
-	struct inno_hdmi *hdmi = to_inno_hdmi(connector);
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
 
 	return (hdmi_readb(hdmi, HDMI_STATUS) & m_HOTPLUG) ?
 		connector_status_connected : connector_status_disconnected;
@@ -544,7 +554,7 @@ inno_hdmi_connector_detect(struct drm_connector *connector, bool force)
 
 static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
 {
-	struct inno_hdmi *hdmi = to_inno_hdmi(connector);
+	struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
 	struct edid *edid;
 	int ret = 0;
 
@@ -599,7 +609,7 @@ static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
 
 static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)
 {
-	struct drm_encoder *encoder = &hdmi->encoder;
+	struct drm_encoder *encoder = &hdmi->encoder.encoder;
 	struct device *dev = hdmi->dev;
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
@@ -879,7 +889,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master,
 	return 0;
 err_cleanup_hdmi:
 	hdmi->connector.funcs->destroy(&hdmi->connector);
-	hdmi->encoder.funcs->destroy(&hdmi->encoder);
+	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 err_put_adapter:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_clk:
@@ -893,7 +903,7 @@ static void inno_hdmi_unbind(struct device *dev, struct device *master,
 	struct inno_hdmi *hdmi = dev_get_drvdata(dev);
 
 	hdmi->connector.funcs->destroy(&hdmi->connector);
-	hdmi->encoder.funcs->destroy(&hdmi->encoder);
+	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
 	clk_disable_unprepare(hdmi->pclk);
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1c546c3a89984..319240c33dcc0 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -47,7 +47,7 @@ struct rk3066_hdmi {
 	void __iomem *regs;
 
 	struct drm_connector connector;
-	struct drm_encoder encoder;
+	struct rockchip_encoder encoder;
 
 	struct rk3066_hdmi_i2c *i2c;
 	struct i2c_adapter *ddc;
@@ -58,7 +58,17 @@ struct rk3066_hdmi {
 	struct drm_display_mode previous_mode;
 };
 
-#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+static struct rk3066_hdmi *encoder_to_rk3066_hdmi(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct rk3066_hdmi, encoder);
+}
+
+static struct rk3066_hdmi *connector_to_rk3066_hdmi(struct drm_connector *connector)
+{
+	return container_of(connector, struct rk3066_hdmi, connector);
+}
 
 static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
 {
@@ -380,7 +390,7 @@ rk3066_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 			     struct drm_display_mode *mode,
 			     struct drm_display_mode *adj_mode)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(encoder);
+	struct rk3066_hdmi *hdmi = encoder_to_rk3066_hdmi(encoder);
 
 	/* Store the display mode for plugin/DPMS poweron events. */
 	memcpy(&hdmi->previous_mode, adj_mode, sizeof(hdmi->previous_mode));
@@ -388,7 +398,7 @@ rk3066_hdmi_encoder_mode_set(struct drm_encoder *encoder,
 
 static void rk3066_hdmi_encoder_enable(struct drm_encoder *encoder)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(encoder);
+	struct rk3066_hdmi *hdmi = encoder_to_rk3066_hdmi(encoder);
 	int mux, val;
 
 	mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
@@ -407,7 +417,7 @@ static void rk3066_hdmi_encoder_enable(struct drm_encoder *encoder)
 
 static void rk3066_hdmi_encoder_disable(struct drm_encoder *encoder)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(encoder);
+	struct rk3066_hdmi *hdmi = encoder_to_rk3066_hdmi(encoder);
 
 	DRM_DEV_DEBUG(hdmi->dev, "hdmi encoder disable\n");
 
@@ -455,7 +465,7 @@ struct drm_encoder_helper_funcs rk3066_hdmi_encoder_helper_funcs = {
 static enum drm_connector_status
 rk3066_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
+	struct rk3066_hdmi *hdmi = connector_to_rk3066_hdmi(connector);
 
 	return (hdmi_readb(hdmi, HDMI_HPG_MENS_STA) & HDMI_HPG_IN_STATUS_HIGH) ?
 		connector_status_connected : connector_status_disconnected;
@@ -463,7 +473,7 @@ rk3066_hdmi_connector_detect(struct drm_connector *connector, bool force)
 
 static int rk3066_hdmi_connector_get_modes(struct drm_connector *connector)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
+	struct rk3066_hdmi *hdmi = connector_to_rk3066_hdmi(connector);
 	struct edid *edid;
 	int ret = 0;
 
@@ -496,9 +506,9 @@ rk3066_hdmi_connector_mode_valid(struct drm_connector *connector,
 static struct drm_encoder *
 rk3066_hdmi_connector_best_encoder(struct drm_connector *connector)
 {
-	struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
+	struct rk3066_hdmi *hdmi = connector_to_rk3066_hdmi(connector);
 
-	return &hdmi->encoder;
+	return &hdmi->encoder.encoder;
 }
 
 static int
@@ -538,7 +548,7 @@ struct drm_connector_helper_funcs rk3066_hdmi_connector_helper_funcs = {
 static int
 rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi)
 {
-	struct drm_encoder *encoder = &hdmi->encoder;
+	struct drm_encoder *encoder = &hdmi->encoder.encoder;
 	struct device *dev = hdmi->dev;
 
 	encoder->possible_crtcs =
@@ -816,7 +826,7 @@ static int rk3066_hdmi_bind(struct device *dev, struct device *master,
 
 err_cleanup_hdmi:
 	hdmi->connector.funcs->destroy(&hdmi->connector);
-	hdmi->encoder.funcs->destroy(&hdmi->encoder);
+	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 err_disable_i2c:
 	i2c_put_adapter(hdmi->ddc);
 err_disable_hclk:
@@ -831,7 +841,7 @@ static void rk3066_hdmi_unbind(struct device *dev, struct device *master,
 	struct rk3066_hdmi *hdmi = dev_get_drvdata(dev);
 
 	hdmi->connector.funcs->destroy(&hdmi->connector);
-	hdmi->encoder.funcs->destroy(&hdmi->encoder);
+	hdmi->encoder.encoder.funcs->destroy(&hdmi->encoder.encoder);
 
 	i2c_put_adapter(hdmi->ddc);
 	clk_disable_unprepare(hdmi->hclk);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 143a48330f849..686f687a76a37 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -48,6 +48,10 @@ struct rockchip_drm_private {
 	struct drm_mm mm;
 };
 
+struct rockchip_encoder {
+	struct drm_encoder encoder;
+};
+
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
 				   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
@@ -63,4 +67,10 @@ extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
 extern struct platform_driver vop_platform_driver;
 extern struct platform_driver rk3066_hdmi_driver;
+
+static inline struct rockchip_encoder *to_rockchip_encoder(struct drm_encoder *encoder)
+{
+	return container_of(encoder, struct rockchip_encoder, encoder);
+}
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 0b972418067e8..25d8c24ef7729 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -36,12 +36,6 @@
 
 struct rockchip_lvds;
 
-#define connector_to_lvds(c) \
-		container_of(c, struct rockchip_lvds, connector)
-
-#define encoder_to_lvds(c) \
-		container_of(c, struct rockchip_lvds, encoder)
-
 /**
  * struct rockchip_lvds_soc_data - rockchip lvds Soc private data
  * @probe: LVDS platform probe function
@@ -65,10 +59,22 @@ struct rockchip_lvds {
 	struct drm_panel *panel;
 	struct drm_bridge *bridge;
 	struct drm_connector connector;
-	struct drm_encoder encoder;
+	struct rockchip_encoder encoder;
 	struct dev_pin_info *pins;
 };
 
+static inline struct rockchip_lvds *connector_to_lvds(struct drm_connector *connector)
+{
+	return container_of(connector, struct rockchip_lvds, connector);
+}
+
+static inline struct rockchip_lvds *encoder_to_lvds(struct drm_encoder *encoder)
+{
+	struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
+
+	return container_of(rkencoder, struct rockchip_lvds, encoder);
+}
+
 static inline void rk3288_writel(struct rockchip_lvds *lvds, u32 offset,
 				 u32 val)
 {
@@ -599,7 +605,7 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
 		goto err_put_remote;
 	}
 
-	encoder = &lvds->encoder;
+	encoder = &lvds->encoder.encoder;
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
 							     dev->of_node);
 
@@ -674,10 +680,10 @@ static void rockchip_lvds_unbind(struct device *dev, struct device *master,
 	const struct drm_encoder_helper_funcs *encoder_funcs;
 
 	encoder_funcs = lvds->soc_data->helper_funcs;
-	encoder_funcs->disable(&lvds->encoder);
+	encoder_funcs->disable(&lvds->encoder.encoder);
 	pm_runtime_disable(dev);
 	drm_connector_cleanup(&lvds->connector);
-	drm_encoder_cleanup(&lvds->encoder);
+	drm_encoder_cleanup(&lvds->encoder.encoder);
 }
 
 static const struct component_ops rockchip_lvds_component_ops = {
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 03/23] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
---

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 ac190e2b1f7aa..214214190fef1 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 04/23] drm/rockchip: dw_hdmi: rename vpll clock to reference clock

[Sascha Hauer]

"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 <s.hauer@pengutronix.de>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 05/23] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name

[Sascha Hauer]

"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 <s.hauer@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 06/23] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
---
 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@ff940000 {
 			 <&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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 07/23] drm/rockchip: dw_hdmi: add rk3568 support

[Sascha Hauer]

Add a new dw_hdmi_plat_data struct and new compatible for rk3568.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 08/23] dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI

[Sascha Hauer]

From: Benjamin Gaignard <benjamin.gaignard@collabora.com>

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 <benjamin.gaignard@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 .../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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 09/23] drm/rockchip: dw_hdmi: add regulator support

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 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 <linux/platform_device.h>
 #include <linux/phy/phy.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 
 #include <drm/bridge/dw_hdmi.h>
 #include <drm/drm_edid.h>
@@ -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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 10/23] dt-bindings: display: rockchip: dw-hdmi: Add regulator support

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---

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 e6b8437a1e2d1..38ebb69830287 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 11/23] drm/rockchip: dw_hdmi: Use auto-generated tables

[Sascha Hauer]

From: Douglas Anderson <dianders@chromium.org>

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 <https://crrev.com/c/285855> 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 <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

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 fe4f9556239ac..cb43e7b47157d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -91,80 +91,88 @@ static struct rockchip_hdmi *to_rockchip_hdmi(struct drm_encoder *encoder)
 
 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
 	{
-		27000000, {
-			{ 0x00b3, 0x0000},
-			{ 0x2153, 0x0000},
-			{ 0x40f3, 0x0000}
+		30666000, {
+			{ 0x00b3, 0x0000 },
+			{ 0x2153, 0x0000 },
+			{ 0x40f3, 0x0000 },
 		},
-	}, {
-		36000000, {
-			{ 0x00b3, 0x0000},
-			{ 0x2153, 0x0000},
-			{ 0x40f3, 0x0000}
+	},  {
+		36800000, {
+			{ 0x00b3, 0x0000 },
+			{ 0x2153, 0x0000 },
+			{ 0x40a2, 0x0001 },
 		},
-	}, {
-		40000000, {
-			{ 0x00b3, 0x0000},
-			{ 0x2153, 0x0000},
-			{ 0x40f3, 0x0000}
+	},  {
+		46000000, {
+			{ 0x00b3, 0x0000 },
+			{ 0x2142, 0x0001 },
+			{ 0x40a2, 0x0001 },
 		},
-	}, {
-		54000000, {
-			{ 0x0072, 0x0001},
-			{ 0x2142, 0x0001},
-			{ 0x40a2, 0x0001},
+	},  {
+		61333000, {
+			{ 0x0072, 0x0001 },
+			{ 0x2142, 0x0001 },
+			{ 0x40a2, 0x0001 },
 		},
-	}, {
-		65000000, {
-			{ 0x0072, 0x0001},
-			{ 0x2142, 0x0001},
-			{ 0x40a2, 0x0001},
+	},  {
+		73600000, {
+			{ 0x0072, 0x0001 },
+			{ 0x2142, 0x0001 },
+			{ 0x4061, 0x0002 },
 		},
-	}, {
-		66000000, {
-			{ 0x013e, 0x0003},
-			{ 0x217e, 0x0002},
-			{ 0x4061, 0x0002}
+	},  {
+		92000000, {
+			{ 0x0072, 0x0001 },
+			{ 0x2145, 0x0002 },
+			{ 0x4061, 0x0002 },
 		},
-	}, {
-		74250000, {
-			{ 0x0072, 0x0001},
-			{ 0x2145, 0x0002},
-			{ 0x4061, 0x0002}
+	},  {
+		122666000, {
+			{ 0x0051, 0x0002 },
+			{ 0x2145, 0x0002 },
+			{ 0x4061, 0x0002 },
 		},
-	}, {
-		83500000, {
-			{ 0x0072, 0x0001},
+	},  {
+		147200000, {
+			{ 0x0051, 0x0002 },
+			{ 0x2145, 0x0002 },
+			{ 0x4064, 0x0003 },
 		},
-	}, {
-		108000000, {
-			{ 0x0051, 0x0002},
-			{ 0x2145, 0x0002},
-			{ 0x4061, 0x0002}
+	},  {
+		184000000, {
+			{ 0x0051, 0x0002 },
+			{ 0x214c, 0x0003 },
+			{ 0x4064, 0x0003 },
 		},
-	}, {
-		106500000, {
-			{ 0x0051, 0x0002},
-			{ 0x2145, 0x0002},
-			{ 0x4061, 0x0002}
+	},  {
+		226666000, {
+			{ 0x0040, 0x0003 },
+			{ 0x214c, 0x0003 },
+			{ 0x4064, 0x0003 },
 		},
-	}, {
-		146250000, {
-			{ 0x0051, 0x0002},
-			{ 0x2145, 0x0002},
-			{ 0x4061, 0x0002}
+	},  {
+		272000000, {
+			{ 0x0040, 0x0003 },
+			{ 0x214c, 0x0003 },
+			{ 0x5a64, 0x0003 },
 		},
-	}, {
-		148500000, {
-			{ 0x0051, 0x0003},
-			{ 0x214c, 0x0003},
-			{ 0x4064, 0x0003}
+	},  {
+		340000000, {
+			{ 0x0040, 0x0003 },
+			{ 0x3b4c, 0x0003 },
+			{ 0x5a64, 0x0003 },
 		},
-	}, {
+	},  {
+		600000000, {
+			{ 0x1a40, 0x0003 },
+			{ 0x3b4c, 0x0003 },
+			{ 0x5a64, 0x0003 },
+		},
+	},  {
 		~0UL, {
-			{ 0x00a0, 0x000a },
-			{ 0x2001, 0x000f },
-			{ 0x4002, 0x000f },
+			{ 0x0000, 0x0000 },
+			{ 0x0000, 0x0000 },
+			{ 0x0000, 0x0000 },
 		},
 	}
 };
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 12/23] drm/rockchip: dw_hdmi: drop mode_valid hook

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
---

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 cb43e7b47157d..008ab20f39ee6 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -248,26 +248,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)
 {
 }
@@ -433,7 +413,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,
@@ -450,7 +429,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,
@@ -470,7 +448,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,
@@ -488,7 +465,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,
@@ -501,7 +477,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 13/23] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

[Sascha Hauer]

From: Douglas Anderson <dianders@chromium.org>

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 <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

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 008ab20f39ee6..5be5d1d4963cd 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -180,20 +180,8 @@ static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
 static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
 	/*      pixelclk    bpp8    bpp10   bpp12 */
 	{
-		40000000,  { 0x0018, 0x0018, 0x0018 },
-	}, {
-		65000000,  { 0x0028, 0x0028, 0x0028 },
-	}, {
-		66000000,  { 0x0038, 0x0038, 0x0038 },
-	}, {
-		74250000,  { 0x0028, 0x0038, 0x0038 },
-	}, {
-		83500000,  { 0x0028, 0x0038, 0x0038 },
-	}, {
-		146250000, { 0x0038, 0x0038, 0x0038 },
-	}, {
-		148500000, { 0x0000, 0x0038, 0x0038 },
-	}, {
+		600000000, { 0x0000, 0x0000, 0x0000 },
+	},  {
 		~0UL,      { 0x0000, 0x0000, 0x0000},
 	}
 };
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 14/23] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

[Sascha Hauer]

From: Nickey Yang <nickey.yang@rock-chips.com>

add 594Mhz configuration parameters in rockchip_phy_config

Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

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 5be5d1d4963cd..7e6dc851a9c8b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -191,6 +191,7 @@ static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
 	{ 74250000,  0x8009, 0x0004, 0x0272},
 	{ 148500000, 0x802b, 0x0004, 0x028d},
 	{ 297000000, 0x8039, 0x0005, 0x028d},
+	{ 594000000, 0x8039, 0x0000, 0x019d},
 	{ ~0UL,	     0x0000, 0x0000, 0x0000}
 };
 
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 15/23] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional

[Sascha Hauer]

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

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---

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 38ebb69830287..d7cb2b2be60e8 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -89,6 +89,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 16/23] arm64: dts: rockchip: rk356x: Add VOP2 nodes

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---

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 5b0f528d68180..4deab90e83834 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -114,3 +114,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 7cdef800cb3ce..fdb7a9a6ca743 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -129,6 +129,11 @@ opp-1800000000 {
 		};
 	};
 
+	display_subsystem: display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+	};
+
 	firmware {
 		scmi: scmi {
 			compatible = "arm,scmi-smc";
@@ -569,6 +574,52 @@ gmac1_mtl_tx_setup: tx-queues-config {
 		};
 	};
 
+	vop: vop@fe040000 {
+		reg = <0x0 0xfe040000 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+		reg-names = "regs", "gamma_lut";
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+		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 = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+		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 0000000000000..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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 17/23] arm64: dts: rockchip: rk356x: Add HDMI nodes

[Sascha Hauer]

Add support for the HDMI port found on RK3568.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

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 fdb7a9a6ca743..1a359bbf65300 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -620,6 +620,38 @@ vop_mmu: iommu@fe043e00 {
 		status = "disabled";
 	};
 
+	hdmi: hdmi@fe0a0000 {
+		compatible = "rockchip,rk3568-dw-hdmi";
+		reg = <0x0 0xfe0a0000 0x0 0x20000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		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";
+		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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 18/23] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
---

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 a794a0ea5c701..096b66d7697e2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -8,6 +8,7 @@
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
 #include "rk3568.dtsi"
 
 / {
@@ -34,6 +35,17 @@ dc_12v: dc-12v {
 		regulator-max-microvolt = <12000000>;
 	};
 
+	hdmi-con {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
 	leds {
 		compatible = "gpio-leds";
 
@@ -189,6 +201,24 @@ &gpu {
 	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";
 
@@ -589,3 +619,20 @@ &usb2phy1_otg {
 	phy-supply = <&vcc5v0_usb_host>;
 	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 = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 19/23] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

[Sascha Hauer]

From: Michael Riesch <michael.riesch@wolfvision.net>

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

Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

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 dd7f4b9b686b8..6504f7ab3ea77 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 <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
 #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";
 
@@ -248,6 +260,24 @@ &gpu {
 	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";
 
@@ -685,3 +715,20 @@ &usb2phy1_otg {
 	phy-supply = <&vcc5v0_usb20_host>;
 	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 = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi_in_vp0>;
+	};
+};
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 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 fa5cfda4e90e3..7d22e2997a571 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -23,8 +23,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 214214190fef1..7cf8b9665e5cf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -494,7 +494,7 @@ static int __init rockchip_drm_init(void)
 		return -ENODEV;
 
 	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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi Sascha:

On 3/28/22 23:11, Sascha Hauer wrote:
> With upcoming VOP2 support VOP won't be the only choice anymore, so make
> the VOP driver optional.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>   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 fa5cfda4e90e3..7d22e2997a571 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -23,8 +23,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


Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588 .


>   	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 214214190fef1..7cf8b9665e5cf 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -494,7 +494,7 @@ static int __init rockchip_drm_init(void)
>   		return -ENODEV;
>   
>   	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,

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

Hi Andy,

On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 3/28/22 23:11, Sascha Hauer wrote:
> > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > the VOP driver optional.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> >   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 fa5cfda4e90e3..7d22e2997a571 100644
> > --- a/drivers/gpu/drm/rockchip/Kconfig
> > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > @@ -23,8 +23,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.

That reminds me that I wanted to rephrase this. Will change in next
round.

> > +
> >   config ROCKCHIP_ANALOGIX_DP
> >   	bool "Rockchip specific extensions for Analogix DP driver"
> > +	depends on ROCKCHIP_VOP
> 
> 
> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588 .

I added the dependency because analogix_dp-rockchip.c calls
rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
so this driver currenty can't work with the VOP2 driver and can't
be linked without the VOP driver being present.
I'll add a few words to the commit message.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi Sascha:

On 3/30/22 14:39, Sascha Hauer wrote:
> Hi Andy,
>
> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>> Hi Sascha:
>>
>> On 3/28/22 23:11, Sascha Hauer wrote:
>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>> the VOP driver optional.
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>> ---
>>>    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 fa5cfda4e90e3..7d22e2997a571 100644
>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>> @@ -23,8 +23,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.
> That reminds me that I wanted to rephrase this. Will change in next
> round.
>
>>> +
>>>    config ROCKCHIP_ANALOGIX_DP
>>>    	bool "Rockchip specific extensions for Analogix DP driver"
>>> +	depends on ROCKCHIP_VOP
>>
>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588 .
> I added the dependency because analogix_dp-rockchip.c calls
> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> so this driver currenty can't work with the VOP2 driver and can't
> be linked without the VOP driver being present.
> I'll add a few words to the commit message.


Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP 
driver to rockchip_drm_drv.c

int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int 
mstimeout)
{
         struct rockchip_drm_private *priv;
         int pipe, ret = 0;

         if (!crtc)
                 return -ENODEV;

         if (mstimeout <= 0)
                 return -EINVAL;

         priv = crtc->dev->dev_private;
         pipe = drm_crtc_index(crtc);

         if (priv->crtc_funcs[pipe] && 
priv->crtc_funcs[pipe]->wait_vact_end)
                 ret = priv->crtc_funcs[pipe]->wait_vact_end(crtc, 
mstimeout);

         return ret;
}
EXPORT_SYMBOL(rockchip_drm_wait_vact_end);

> Sascha
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 3/30/22 14:39, Sascha Hauer wrote:
> > Hi Andy,
> > 
> > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > the VOP driver optional.
> > > > 
> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > ---
> > > >    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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > @@ -23,8 +23,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.
> > That reminds me that I wanted to rephrase this. Will change in next
> > round.
> > 
> > > > +
> > > >    config ROCKCHIP_ANALOGIX_DP
> > > >    	bool "Rockchip specific extensions for Analogix DP driver"
> > > > +	depends on ROCKCHIP_VOP
> > > 
> > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.

BTW I just looked at the downstream driver. Here we have the same
situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
which is implemented in the VOP driver, so when the analogix dp driver
is actually used on a VOP2 SoC then it is either used in a way that
rockchip_drm_wait_vact_end() will never be called or it explodes in all
colours.

> > I added the dependency because analogix_dp-rockchip.c calls
> > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > so this driver currenty can't work with the VOP2 driver and can't
> > be linked without the VOP driver being present.
> > I'll add a few words to the commit message.
> 
> 
> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> driver to rockchip_drm_drv.c

I am not sure if that's really worth it. Yes, the direction might be the
right one, but I would really prefer when somebody does the change who
can test and confirm that the analogix dp really works with VOP2 in the
end.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi Sascha:

On 3/31/22 15:06, Sascha Hauer wrote:
> On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
>> Hi Sascha:
>>
>> On 3/30/22 14:39, Sascha Hauer wrote:
>>> Hi Andy,
>>>
>>> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>>>> Hi Sascha:
>>>>
>>>> On 3/28/22 23:11, Sascha Hauer wrote:
>>>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>>>> the VOP driver optional.
>>>>>
>>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>>> ---
>>>>>     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 fa5cfda4e90e3..7d22e2997a571 100644
>>>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>>>> @@ -23,8 +23,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.
>>> That reminds me that I wanted to rephrase this. Will change in next
>>> round.
>>>
>>>>> +
>>>>>     config ROCKCHIP_ANALOGIX_DP
>>>>>     	bool "Rockchip specific extensions for Analogix DP driver"
>>>>> +	depends on ROCKCHIP_VOP
>>>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> BTW I just looked at the downstream driver. Here we have the same
> situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> which is implemented in the VOP driver, so when the analogix dp driver
> is actually used on a VOP2 SoC then it is either used in a way that
> rockchip_drm_wait_vact_end() will never be called or it explodes in all
> colours.
>
>>> I added the dependency because analogix_dp-rockchip.c calls
>>> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
>>> so this driver currenty can't work with the VOP2 driver and can't
>>> be linked without the VOP driver being present.
>>> I'll add a few words to the commit message.
>>
>> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
>> driver to rockchip_drm_drv.c
> I am not sure if that's really worth it. Yes, the direction might be the
> right one, but I would really prefer when somebody does the change who
> can test and confirm that the analogix dp really works with VOP2 in the
> end.

If follow this point, the current DW_MIPI also has not been tested for 
confirm that it

can really work with VOP2, so you should also make it depends on 
ROCKCHIP_VOP.

I think the current solution is just a workaround to make your patch 
pass the kernel compile

but not reflect the real situation.

> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 3/31/22 15:06, Sascha Hauer wrote:
> > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > Hi Andy,
> > > > 
> > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > Hi Sascha:
> > > > > 
> > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > the VOP driver optional.
> > > > > > 
> > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > ---
> > > > > >     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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > @@ -23,8 +23,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.
> > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > round.
> > > > 
> > > > > > +
> > > > > >     config ROCKCHIP_ANALOGIX_DP
> > > > > >     	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > +	depends on ROCKCHIP_VOP
> > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > BTW I just looked at the downstream driver. Here we have the same
> > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > which is implemented in the VOP driver, so when the analogix dp driver
> > is actually used on a VOP2 SoC then it is either used in a way that
> > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > colours.
> > 
> > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > be linked without the VOP driver being present.
> > > > I'll add a few words to the commit message.
> > > 
> > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > driver to rockchip_drm_drv.c
> > I am not sure if that's really worth it. Yes, the direction might be the
> > right one, but I would really prefer when somebody does the change who
> > can test and confirm that the analogix dp really works with VOP2 in the
> > end.
> 
> If follow this point, the current DW_MIPI also has not been tested for
> confirm that it
> 
> can really work with VOP2, so you should also make it depends on
> ROCKCHIP_VOP.

Well at least I have patches here which make DW_MIPI work with VOP2 ;)

What about the others, like LVDS and RGB?
> 
> I think the current solution is just a workaround to make your patch pass
> the kernel compile

Indeed.

I agree that it would be good to add a note somewhere which outputs
work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
dependencies is the right place for it, because only people who deliberately
disable VOP support will see this information.
Maybe we should rather add it to the Kconfig help text?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi:

On 3/31/22 16:18, Sascha Hauer wrote:
> On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
>> Hi Sascha:
>>
>> On 3/31/22 15:06, Sascha Hauer wrote:
>>> On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
>>>> Hi Sascha:
>>>>
>>>> On 3/30/22 14:39, Sascha Hauer wrote:
>>>>> Hi Andy,
>>>>>
>>>>> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>>>>>> Hi Sascha:
>>>>>>
>>>>>> On 3/28/22 23:11, Sascha Hauer wrote:
>>>>>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>>>>>> the VOP driver optional.
>>>>>>>
>>>>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>>>>> ---
>>>>>>>      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 fa5cfda4e90e3..7d22e2997a571 100644
>>>>>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>>>>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>>>>>> @@ -23,8 +23,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.
>>>>> That reminds me that I wanted to rephrase this. Will change in next
>>>>> round.
>>>>>
>>>>>>> +
>>>>>>>      config ROCKCHIP_ANALOGIX_DP
>>>>>>>      	bool "Rockchip specific extensions for Analogix DP driver"
>>>>>>> +	depends on ROCKCHIP_VOP
>>>>>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
>>> BTW I just looked at the downstream driver. Here we have the same
>>> situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
>>> which is implemented in the VOP driver, so when the analogix dp driver
>>> is actually used on a VOP2 SoC then it is either used in a way that
>>> rockchip_drm_wait_vact_end() will never be called or it explodes in all
>>> colours.
>>>
>>>>> I added the dependency because analogix_dp-rockchip.c calls
>>>>> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
>>>>> so this driver currenty can't work with the VOP2 driver and can't
>>>>> be linked without the VOP driver being present.
>>>>> I'll add a few words to the commit message.
>>>> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
>>>> driver to rockchip_drm_drv.c
>>> I am not sure if that's really worth it. Yes, the direction might be the
>>> right one, but I would really prefer when somebody does the change who
>>> can test and confirm that the analogix dp really works with VOP2 in the
>>> end.
>> If follow this point, the current DW_MIPI also has not been tested for
>> confirm that it
>>
>> can really work with VOP2, so you should also make it depends on
>> ROCKCHIP_VOP.
> Well at least I have patches here which make DW_MIPI work with VOP2 ;)


But you DW_MIPI patches for rk356x didn't come. So this is not keep 
consistency with this point.

>
> What about the others, like LVDS and RGB?


Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, 
RK3588 has BT1120/BT656, no LVDS or RGB.

>> I think the current solution is just a workaround to make your patch pass
>> the kernel compile
> Indeed.
>
> I agree that it would be good to add a note somewhere which outputs
> work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> dependencies is the right place for it, because only people who deliberately
> disable VOP support will see this information.
> Maybe we should rather add it to the Kconfig help text?


If a device is supported for this soc, we will add dt node at the dtsi file.

A Kconfig dependencies don't seems a good idea.


>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> Hi:
> 
> On 3/31/22 16:18, Sascha Hauer wrote:
> > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > Hi Sascha:
> > > > > 
> > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > Hi Andy,
> > > > > > 
> > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > the VOP driver optional.
> > > > > > > > 
> > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > ---
> > > > > > > >      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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > @@ -23,8 +23,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.
> > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > round.
> > > > > > 
> > > > > > > > +
> > > > > > > >      config ROCKCHIP_ANALOGIX_DP
> > > > > > > >      	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > BTW I just looked at the downstream driver. Here we have the same
> > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > colours.
> > > > 
> > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > be linked without the VOP driver being present.
> > > > > > I'll add a few words to the commit message.
> > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > driver to rockchip_drm_drv.c
> > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > right one, but I would really prefer when somebody does the change who
> > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > end.
> > > If follow this point, the current DW_MIPI also has not been tested for
> > > confirm that it
> > > 
> > > can really work with VOP2, so you should also make it depends on
> > > ROCKCHIP_VOP.
> > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> 
> 
> But you DW_MIPI patches for rk356x didn't come. So this is not keep
> consistency with this point.
> 
> > 
> > What about the others, like LVDS and RGB?
> 
> 
> Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> has BT1120/BT656, no LVDS or RGB.
> 
> > > I think the current solution is just a workaround to make your patch pass
> > > the kernel compile
> > Indeed.
> > 
> > I agree that it would be good to add a note somewhere which outputs
> > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > dependencies is the right place for it, because only people who deliberately
> > disable VOP support will see this information.
> > Maybe we should rather add it to the Kconfig help text?
> 
> 
> If a device is supported for this soc, we will add dt node at the dtsi file.
> 
> A Kconfig dependencies don't seems a good idea.

Ok, this means we can keep my current approach with just letting
ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
buildable kernel.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi Sascha:

On 4/1/22 20:55, Sascha Hauer wrote:
> On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
>> Hi:
>>
>> On 3/31/22 16:18, Sascha Hauer wrote:
>>> On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
>>>> Hi Sascha:
>>>>
>>>> On 3/31/22 15:06, Sascha Hauer wrote:
>>>>> On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
>>>>>> Hi Sascha:
>>>>>>
>>>>>> On 3/30/22 14:39, Sascha Hauer wrote:
>>>>>>> Hi Andy,
>>>>>>>
>>>>>>> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>>>>>>>> Hi Sascha:
>>>>>>>>
>>>>>>>> On 3/28/22 23:11, Sascha Hauer wrote:
>>>>>>>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>>>>>>>> the VOP driver optional.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>>>>>>> ---
>>>>>>>>>       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 fa5cfda4e90e3..7d22e2997a571 100644
>>>>>>>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>> @@ -23,8 +23,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.
>>>>>>> That reminds me that I wanted to rephrase this. Will change in next
>>>>>>> round.
>>>>>>>
>>>>>>>>> +
>>>>>>>>>       config ROCKCHIP_ANALOGIX_DP
>>>>>>>>>       	bool "Rockchip specific extensions for Analogix DP driver"
>>>>>>>>> +	depends on ROCKCHIP_VOP
>>>>>>>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
>>>>> BTW I just looked at the downstream driver. Here we have the same
>>>>> situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
>>>>> which is implemented in the VOP driver, so when the analogix dp driver
>>>>> is actually used on a VOP2 SoC then it is either used in a way that
>>>>> rockchip_drm_wait_vact_end() will never be called or it explodes in all
>>>>> colours.
>>>>>
>>>>>>> I added the dependency because analogix_dp-rockchip.c calls
>>>>>>> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
>>>>>>> so this driver currenty can't work with the VOP2 driver and can't
>>>>>>> be linked without the VOP driver being present.
>>>>>>> I'll add a few words to the commit message.
>>>>>> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
>>>>>> driver to rockchip_drm_drv.c
>>>>> I am not sure if that's really worth it. Yes, the direction might be the
>>>>> right one, but I would really prefer when somebody does the change who
>>>>> can test and confirm that the analogix dp really works with VOP2 in the
>>>>> end.
>>>> If follow this point, the current DW_MIPI also has not been tested for
>>>> confirm that it
>>>>
>>>> can really work with VOP2, so you should also make it depends on
>>>> ROCKCHIP_VOP.
>>> Well at least I have patches here which make DW_MIPI work with VOP2 ;)
>>
>> But you DW_MIPI patches for rk356x didn't come. So this is not keep
>> consistency with this point.
>>
>>> What about the others, like LVDS and RGB?
>>
>> Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
>> has BT1120/BT656, no LVDS or RGB.
>>
>>>> I think the current solution is just a workaround to make your patch pass
>>>> the kernel compile
>>> Indeed.
>>>
>>> I agree that it would be good to add a note somewhere which outputs
>>> work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
>>> dependencies is the right place for it, because only people who deliberately
>>> disable VOP support will see this information.
>>> Maybe we should rather add it to the Kconfig help text?
>>
>> If a device is supported for this soc, we will add dt node at the dtsi file.
>>
>> A Kconfig dependencies don't seems a good idea.
> Ok, this means we can keep my current approach with just letting
> ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non

Excuse me? How do you get this conclusion ?

I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.

If this patch will cause the compile error, please do a real fix, not a

workaround that may deliver misleading information.

> buildable kernel.
>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 4/1/22 20:55, Sascha Hauer wrote:
> > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > Hi:
> > > 
> > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > Hi Sascha:
> > > > > 
> > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > Hi Andy,
> > > > > > > > 
> > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > the VOP driver optional.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > ---
> > > > > > > > > >       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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > @@ -23,8 +23,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.
> > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > round.
> > > > > > > > 
> > > > > > > > > > +
> > > > > > > > > >       config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > >       	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > colours.
> > > > > > 
> > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > be linked without the VOP driver being present.
> > > > > > > > I'll add a few words to the commit message.
> > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > driver to rockchip_drm_drv.c
> > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > end.
> > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > confirm that it
> > > > > 
> > > > > can really work with VOP2, so you should also make it depends on
> > > > > ROCKCHIP_VOP.

Here you are suggesting to add even more Kconfig dependencies.

> > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > 
> > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > consistency with this point.
> > > 
> > > > What about the others, like LVDS and RGB?
> > > 
> > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > has BT1120/BT656, no LVDS or RGB.
> > > 
> > > > > I think the current solution is just a workaround to make your patch pass
> > > > > the kernel compile
> > > > Indeed.
> > > > 
> > > > I agree that it would be good to add a note somewhere which outputs
> > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > dependencies is the right place for it, because only people who deliberately
> > > > disable VOP support will see this information.
> > > > Maybe we should rather add it to the Kconfig help text?
> > > 
> > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > 
> > > A Kconfig dependencies don't seems a good idea.

Here you say Kconfig dependencies are no good idea.

> > Ok, this means we can keep my current approach with just letting
> > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> 
> Excuse me? How do you get this conclusion ?

Given that you say that you want to have both more and less Kconfig
dependencies I came to the conclusion that I only add one where it's
necessary to compile the driver.

> 
> I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.

Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
Rockchip downstream kernel, so I wonder how relevant this usecase really
is.

> 
> If this patch will cause the compile error, please do a real fix, not a

I can't, because I don't have any hardware to test the Analogix DP on a
VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
not even supported in the downstream Kernel I am not sure if it's really
worth doing that.

Moving rockchip_drm_wait_vact_end() to rockchip_drm_drv.c doesn't work
with mainline currently, we first would have to add a struct crtc_funcs
to struct rockchip_drm_private. Yes, that could be done.

> 
> workaround that may deliver misleading information.

The Kconfig dependency quite clearly says that the Analogix DP currently
doesn't work with the VOP2. Anyone who wants to change that can use that
information as a starting point and implement whatever is necessary and
likely has the hardware to verify the work. I don't want to solve
problems that *might* arise in the future, and in this case it's not a
direction decision that we might regret in the future.

Sascha



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi Sacha:

On 4/5/22 17:05, Sascha Hauer wrote:
> On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
>> Hi Sascha:
>>
>> On 4/1/22 20:55, Sascha Hauer wrote:
>>> On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
>>>> Hi:
>>>>
>>>> On 3/31/22 16:18, Sascha Hauer wrote:
>>>>> On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
>>>>>> Hi Sascha:
>>>>>>
>>>>>> On 3/31/22 15:06, Sascha Hauer wrote:
>>>>>>> On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
>>>>>>>> Hi Sascha:
>>>>>>>>
>>>>>>>> On 3/30/22 14:39, Sascha Hauer wrote:
>>>>>>>>> Hi Andy,
>>>>>>>>>
>>>>>>>>> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>>>>>>>>>> Hi Sascha:
>>>>>>>>>>
>>>>>>>>>> On 3/28/22 23:11, Sascha Hauer wrote:
>>>>>>>>>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>>>>>>>>>> the VOP driver optional.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>>>>>>>>> ---
>>>>>>>>>>>        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 fa5cfda4e90e3..7d22e2997a571 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>>>> @@ -23,8 +23,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.
>>>>>>>>> That reminds me that I wanted to rephrase this. Will change in next
>>>>>>>>> round.
>>>>>>>>>
>>>>>>>>>>> +
>>>>>>>>>>>        config ROCKCHIP_ANALOGIX_DP
>>>>>>>>>>>        	bool "Rockchip specific extensions for Analogix DP driver"
>>>>>>>>>>> +	depends on ROCKCHIP_VOP
>>>>>>>>>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
>>>>>>> BTW I just looked at the downstream driver. Here we have the same
>>>>>>> situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
>>>>>>> which is implemented in the VOP driver, so when the analogix dp driver
>>>>>>> is actually used on a VOP2 SoC then it is either used in a way that
>>>>>>> rockchip_drm_wait_vact_end() will never be called or it explodes in all
>>>>>>> colours.
>>>>>>>
>>>>>>>>> I added the dependency because analogix_dp-rockchip.c calls
>>>>>>>>> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
>>>>>>>>> so this driver currenty can't work with the VOP2 driver and can't
>>>>>>>>> be linked without the VOP driver being present.
>>>>>>>>> I'll add a few words to the commit message.
>>>>>>>> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
>>>>>>>> driver to rockchip_drm_drv.c
>>>>>>> I am not sure if that's really worth it. Yes, the direction might be the
>>>>>>> right one, but I would really prefer when somebody does the change who
>>>>>>> can test and confirm that the analogix dp really works with VOP2 in the
>>>>>>> end.
>>>>>> If follow this point, the current DW_MIPI also has not been tested for
>>>>>> confirm that it
>>>>>>
>>>>>> can really work with VOP2, so you should also make it depends on
>>>>>> ROCKCHIP_VOP.
> Here you are suggesting to add even more Kconfig dependencies.
>
>>>>> Well at least I have patches here which make DW_MIPI work with VOP2 ;)
>>>> But you DW_MIPI patches for rk356x didn't come. So this is not keep
>>>> consistency with this point.
>>>>
>>>>> What about the others, like LVDS and RGB?
>>>> Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
>>>> has BT1120/BT656, no LVDS or RGB.
>>>>
>>>>>> I think the current solution is just a workaround to make your patch pass
>>>>>> the kernel compile
>>>>> Indeed.
>>>>>
>>>>> I agree that it would be good to add a note somewhere which outputs
>>>>> work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
>>>>> dependencies is the right place for it, because only people who deliberately
>>>>> disable VOP support will see this information.
>>>>> Maybe we should rather add it to the Kconfig help text?
>>>> If a device is supported for this soc, we will add dt node at the dtsi file.
>>>>
>>>> A Kconfig dependencies don't seems a good idea.
> Here you say Kconfig dependencies are no good idea.


Yes. It's not a good idea. So I don't want to see you use a Kcofig 
dependence

to disable a module to avoid compile which introduced by your patch.

>
>>> Ok, this means we can keep my current approach with just letting
>>> ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
>> Excuse me? How do you get this conclusion ?
> Given that you say that you want to have both more and less Kconfig
> dependencies I came to the conclusion that I only add one where it's
> necessary to compile the driver.
>
>> I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> Rockchip downstream kernel, so I wonder how relevant this usecase really
> is.


No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the

vendor kernel. We have many rk356x based products shipped with edp.

Even the VGA output interface on RK3568_EVB1 is drived by

ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert

chip.


So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with

the Rockchip downstream kernel? Is it because you can't make the DP work on

your board? If it is, please contact the supplier who gave you the board.


Do you have a RK3568_EVB1 that has a VGA output interface on board?

If you have it, I can offer you image to verify the DP.


>> If this patch will cause the compile error, please do a real fix, not a
> I can't, because I don't have any hardware to test the Analogix DP on a
> VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> not even supported in the downstream Kernel I am not sure if it's really
> worth doing that.


Again, this is not the truth, see above.

I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just

want you can give a better solution when you patch cause the compile error.

Disable a module when it conflict with your patch is too rough.

>
> Moving rockchip_drm_wait_vact_end() to rockchip_drm_drv.c doesn't work
> with mainline currently, we first would have to add a struct crtc_funcs
> to struct rockchip_drm_private. Yes, that could be done.
>
>> workaround that may deliver misleading information.
> The Kconfig dependency quite clearly says that the Analogix DP currently
> doesn't work with the VOP2. Anyone who wants to change that can use that
> information as a starting point and implement whatever is necessary and
> likely has the hardware to verify the work. I don't want to solve
> problems that *might* arise in the future, and in this case it's not a
> direction decision that we might regret in the future.
>
> Sascha
>
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/5/22 17:05, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > Hi:
> > > > > 
> > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > Hi Andy,
> > > > > > > > > > 
> > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > >        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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > @@ -23,8 +23,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.
> > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > round.
> > > > > > > > > > 
> > > > > > > > > > > > +
> > > > > > > > > > > >        config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > >        	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > colours.
> > > > > > > > 
> > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > end.
> > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > confirm that it
> > > > > > > 
> > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > ROCKCHIP_VOP.
> > Here you are suggesting to add even more Kconfig dependencies.
> > 
> > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > consistency with this point.
> > > > > 
> > > > > > What about the others, like LVDS and RGB?
> > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > 
> > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > the kernel compile
> > > > > > Indeed.
> > > > > > 
> > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > disable VOP support will see this information.
> > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > 
> > > > > A Kconfig dependencies don't seems a good idea.
> > Here you say Kconfig dependencies are no good idea.
> 
> 
> Yes. It's not a good idea. So I don't want to see you use a Kcofig
> dependence
> 
> to disable a module to avoid compile which introduced by your patch.
> 
> > 
> > > > Ok, this means we can keep my current approach with just letting
> > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > Excuse me? How do you get this conclusion ?
> > Given that you say that you want to have both more and less Kconfig
> > dependencies I came to the conclusion that I only add one where it's
> > necessary to compile the driver.
> > 
> > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > is.
> 
> 
> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> vendor kernel. We have many rk356x based products shipped with edp.
> Even the VGA output interface on RK3568_EVB1 is drived by
> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> chip.
> 
> 
> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> the Rockchip downstream kernel? Is it because you can't make the DP work on
> your board? If it is, please contact the supplier who gave you the board.

In the downstream kernel I have available (which is a 5.10.66)
analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
implemented in rockchip_drm_vop.c and assumes that the passed struct
drm_crtc * can be converted to a struct vop *. Basically it's the same
situation we have right now with the mainline kernel, just that the
linker issues won't show up because the VOP driver can't be disabled
in the downstream kernel.

> 
> 
> Do you have a RK3568_EVB1 that has a VGA output interface on board?
> 
> If you have it, I can offer you image to verify the DP.
> 
> 
> > > If this patch will cause the compile error, please do a real fix, not a
> > I can't, because I don't have any hardware to test the Analogix DP on a
> > VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> > not even supported in the downstream Kernel I am not sure if it's really
> > worth doing that.
> 
> 
> Again, this is not the truth, see above.
> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
> want you can give a better solution when you patch cause the compile error.
> Disable a module when it conflict with your patch is too rough.

It does not conflict with my patch. The dependency only means that you can't
enable the Analogix DP driver when the VOP driver is disabled. That
doesn't hurt, because currently you can't do anything with the Analogix
DP driver without the VOP driver. With the added dependency the Analogix DP
driver can still be used with the VOP driver, even when the VOP2 driver
is enabled. I really can't see a problem with that.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Andy Yan]

Hi:

On 4/6/22 15:04, Sascha Hauer wrote:
> On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
>> Hi Sacha:
>>
>> On 4/5/22 17:05, Sascha Hauer wrote:
>>> On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
>>>> Hi Sascha:
>>>>
>>>> On 4/1/22 20:55, Sascha Hauer wrote:
>>>>> On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
>>>>>> Hi:
>>>>>>
>>>>>> On 3/31/22 16:18, Sascha Hauer wrote:
>>>>>>> On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
>>>>>>>> Hi Sascha:
>>>>>>>>
>>>>>>>> On 3/31/22 15:06, Sascha Hauer wrote:
>>>>>>>>> On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
>>>>>>>>>> Hi Sascha:
>>>>>>>>>>
>>>>>>>>>> On 3/30/22 14:39, Sascha Hauer wrote:
>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
>>>>>>>>>>>> Hi Sascha:
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/28/22 23:11, Sascha Hauer wrote:
>>>>>>>>>>>>> With upcoming VOP2 support VOP won't be the only choice anymore, so make
>>>>>>>>>>>>> the VOP driver optional.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>         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 fa5cfda4e90e3..7d22e2997a571 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>>>>>>>>>>>>> @@ -23,8 +23,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.
>>>>>>>>>>> That reminds me that I wanted to rephrase this. Will change in next
>>>>>>>>>>> round.
>>>>>>>>>>>
>>>>>>>>>>>>> +
>>>>>>>>>>>>>         config ROCKCHIP_ANALOGIX_DP
>>>>>>>>>>>>>         	bool "Rockchip specific extensions for Analogix DP driver"
>>>>>>>>>>>>> +	depends on ROCKCHIP_VOP
>>>>>>>>>>>> Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
>>>>>>>>> BTW I just looked at the downstream driver. Here we have the same
>>>>>>>>> situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
>>>>>>>>> which is implemented in the VOP driver, so when the analogix dp driver
>>>>>>>>> is actually used on a VOP2 SoC then it is either used in a way that
>>>>>>>>> rockchip_drm_wait_vact_end() will never be called or it explodes in all
>>>>>>>>> colours.
>>>>>>>>>
>>>>>>>>>>> I added the dependency because analogix_dp-rockchip.c calls
>>>>>>>>>>> rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
>>>>>>>>>>> so this driver currenty can't work with the VOP2 driver and can't
>>>>>>>>>>> be linked without the VOP driver being present.
>>>>>>>>>>> I'll add a few words to the commit message.
>>>>>>>>>> Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
>>>>>>>>>> driver to rockchip_drm_drv.c
>>>>>>>>> I am not sure if that's really worth it. Yes, the direction might be the
>>>>>>>>> right one, but I would really prefer when somebody does the change who
>>>>>>>>> can test and confirm that the analogix dp really works with VOP2 in the
>>>>>>>>> end.
>>>>>>>> If follow this point, the current DW_MIPI also has not been tested for
>>>>>>>> confirm that it
>>>>>>>>
>>>>>>>> can really work with VOP2, so you should also make it depends on
>>>>>>>> ROCKCHIP_VOP.
>>> Here you are suggesting to add even more Kconfig dependencies.
>>>
>>>>>>> Well at least I have patches here which make DW_MIPI work with VOP2 ;)
>>>>>> But you DW_MIPI patches for rk356x didn't come. So this is not keep
>>>>>> consistency with this point.
>>>>>>
>>>>>>> What about the others, like LVDS and RGB?
>>>>>> Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
>>>>>> has BT1120/BT656, no LVDS or RGB.
>>>>>>
>>>>>>>> I think the current solution is just a workaround to make your patch pass
>>>>>>>> the kernel compile
>>>>>>> Indeed.
>>>>>>>
>>>>>>> I agree that it would be good to add a note somewhere which outputs
>>>>>>> work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
>>>>>>> dependencies is the right place for it, because only people who deliberately
>>>>>>> disable VOP support will see this information.
>>>>>>> Maybe we should rather add it to the Kconfig help text?
>>>>>> If a device is supported for this soc, we will add dt node at the dtsi file.
>>>>>>
>>>>>> A Kconfig dependencies don't seems a good idea.
>>> Here you say Kconfig dependencies are no good idea.
>>
>> Yes. It's not a good idea. So I don't want to see you use a Kcofig
>> dependence
>>
>> to disable a module to avoid compile which introduced by your patch.
>>
>>>>> Ok, this means we can keep my current approach with just letting
>>>>> ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
>>>> Excuse me? How do you get this conclusion ?
>>> Given that you say that you want to have both more and less Kconfig
>>> dependencies I came to the conclusion that I only add one where it's
>>> necessary to compile the driver.
>>>
>>>> I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
>>> Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
>>> Rockchip downstream kernel, so I wonder how relevant this usecase really
>>> is.
>>
>> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
>> vendor kernel. We have many rk356x based products shipped with edp.
>> Even the VGA output interface on RK3568_EVB1 is drived by
>> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
>> chip.
>>
>>
>> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
>> the Rockchip downstream kernel? Is it because you can't make the DP work on
>> your board? If it is, please contact the supplier who gave you the board.
> In the downstream kernel I have available (which is a 5.10.66)
> analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
> implemented in rockchip_drm_vop.c and assumes that the passed struct
> drm_crtc * can be converted to a struct vop *. Basically it's the same
> situation we have right now with the mainline kernel, just that the
> linker issues won't show up because the VOP driver can't be disabled
> in the downstream kernel.


So you judge ROCKCHIP_ANALOGIX_DP can't work by this(as vop2 doesn't has 
rockchip_drm_wait_vact_end interface)?

No, you may not know clearly about this function, this function is used 
for eDP PSR, which is a

optional function, that means not every eDP panel has PSR function(this 
function usually parsed from edid).

This really not means than ROCKCHIP_ANALOGIX_DP can't work.


And your 5.10 downstream kernel seems out of dated. We have already move 
this function out from rockchip_drm_vop to rockchip_drm_drv.


>>
>> Do you have a RK3568_EVB1 that has a VGA output interface on board?
>>
>> If you have it, I can offer you image to verify the DP.
>>
>>
>>>> If this patch will cause the compile error, please do a real fix, not a
>>> I can't, because I don't have any hardware to test the Analogix DP on a
>>> VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
>>> not even supported in the downstream Kernel I am not sure if it's really
>>> worth doing that.
>>
>> Again, this is not the truth, see above.
>> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
>> want you can give a better solution when you patch cause the compile error.
>> Disable a module when it conflict with your patch is too rough.
> It does not conflict with my patch. The dependency only means that you can't
> enable the Analogix DP driver when the VOP driver is disabled. That
> doesn't hurt, because currently you can't do anything with the Analogix
> DP driver without the VOP driver. With the added dependency the Analogix DP
> driver can still be used with the VOP driver, even when the VOP2 driver
> is enabled. I really can't see a problem with that.
>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Wed, Apr 06, 2022 at 03:47:18PM +0800, Andy Yan wrote:
> Hi:
> 
> On 4/6/22 15:04, Sascha Hauer wrote:
> > On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> > > Hi Sacha:
> > > 
> > > On 4/5/22 17:05, Sascha Hauer wrote:
> > > > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > > > Hi Sascha:
> > > > > 
> > > > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > > > Hi:
> > > > > > > 
> > > > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > > > Hi Andy,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >         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 fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > > > @@ -23,8 +23,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.
> > > > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > > > round.
> > > > > > > > > > > > 
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > >         config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > > > >         	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > > > colours.
> > > > > > > > > > 
> > > > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > > > end.
> > > > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > > > confirm that it
> > > > > > > > > 
> > > > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > > > ROCKCHIP_VOP.
> > > > Here you are suggesting to add even more Kconfig dependencies.
> > > > 
> > > > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > > > consistency with this point.
> > > > > > > 
> > > > > > > > What about the others, like LVDS and RGB?
> > > > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > > > 
> > > > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > > > the kernel compile
> > > > > > > > Indeed.
> > > > > > > > 
> > > > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > > > disable VOP support will see this information.
> > > > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > > > 
> > > > > > > A Kconfig dependencies don't seems a good idea.
> > > > Here you say Kconfig dependencies are no good idea.
> > > 
> > > Yes. It's not a good idea. So I don't want to see you use a Kcofig
> > > dependence
> > > 
> > > to disable a module to avoid compile which introduced by your patch.
> > > 
> > > > > > Ok, this means we can keep my current approach with just letting
> > > > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > > > Excuse me? How do you get this conclusion ?
> > > > Given that you say that you want to have both more and less Kconfig
> > > > dependencies I came to the conclusion that I only add one where it's
> > > > necessary to compile the driver.
> > > > 
> > > > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > > > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > > > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > > > is.
> > > 
> > > No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> > > vendor kernel. We have many rk356x based products shipped with edp.
> > > Even the VGA output interface on RK3568_EVB1 is drived by
> > > ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> > > chip.
> > > 
> > > 
> > > So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> > > the Rockchip downstream kernel? Is it because you can't make the DP work on
> > > your board? If it is, please contact the supplier who gave you the board.
> > In the downstream kernel I have available (which is a 5.10.66)
> > analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
> > implemented in rockchip_drm_vop.c and assumes that the passed struct
> > drm_crtc * can be converted to a struct vop *. Basically it's the same
> > situation we have right now with the mainline kernel, just that the
> > linker issues won't show up because the VOP driver can't be disabled
> > in the downstream kernel.
> 
> 
> So you judge ROCKCHIP_ANALOGIX_DP can't work by this(as vop2 doesn't has
> rockchip_drm_wait_vact_end interface)?
> 
> No, you may not know clearly about this function, this function is used for
> eDP PSR, which is a
> 
> optional function, that means not every eDP panel has PSR function(this
> function usually parsed from edid).
> 
> This really not means than ROCKCHIP_ANALOGIX_DP can't work.
> 
> 
> And your 5.10 downstream kernel seems out of dated. We have already move
> this function out from rockchip_drm_vop to rockchip_drm_drv.

I guessed that. Well we can do the same once we are there, but currently
we are not. My patch doesn't break any existing features and we can add
Analogix DP support later. I know the VOP2 driver is not feature
complete and it doesn't aim to be.

Please let's stop arguing about this topic. Once somebody wants to add
Analogix DP support with VOP2 we can discuss the right way at length and
until then my patch won't do any harm.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 22/23] dt-bindings: display: rockchip: Add binding for VOP2

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---

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 0000000000000..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 <hjc@rock-chips.com>
+  - Heiko Stuebner <heiko@sntech.de>
+
+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 <dt-bindings/clock/rk3568-cru.h>
+        #include <dt-bindings/interrupt-controller/arm-gic.h>
+        #include <dt-bindings/power/rk3568-power.h>
+        bus {
+            #address-cells = <2>;
+            #size-cells = <2>;
+            vop: vop@fe040000 {
+                compatible = "rockchip,rk3568-vop";
+                reg = <0x0 0xfe040000 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+                interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+                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>;
+                    };
+                };
+            };
+        };
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 23/23] dt-bindings: display: rockchip: dw-hdmi: fix ports description

[Sascha Hauer]

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 <s.hauer@pengutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---

Notes:
    Changes since v6:
    - Add Reviewed-by: Rob Herring <robh@kernel.org>
    Changes since v5:
    - new patch

 .../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 d7cb2b2be60e8..7e59dee15a5f4 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -97,27 +97,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10:
> 
> 
> Changes since v8:
> - make hclk_vo a critical clock instead of enabling it in the hdmi driver
> - Fix vop2_setup_layer_mixer(), reported by Andy Yan
> - Limit planes possible_crtcs to actually existing crtcs
> 
> 

Sascha,

FYI:
I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane.
It look issue is still present :-(

You can easily reproduce with modetest utility:

modetest -P 43@67:1920x1080@NV12 

gives green screen.

however if you do:

modetest #43 (green screen)
modetest #49  (ok)

then

modetest #43 

gives expected result ("rainbow" picture on screen)

let me know if i can do any extra tests helping you to fix issue
 
br



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

Hi Piotr,

On Tue, Mar 29, 2022 at 09:31:01AM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10:
> > 
> > 
> > Changes since v8:
> > - make hclk_vo a critical clock instead of enabling it in the hdmi driver
> > - Fix vop2_setup_layer_mixer(), reported by Andy Yan
> > - Limit planes possible_crtcs to actually existing crtcs
> > 
> > 
> 
> Sascha,
> 
> FYI:
> I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane.
> It look issue is still present :-(
> 
> You can easily reproduce with modetest utility:
> 
> modetest -P 43@67:1920x1080@NV12

This only sets the overlay, but how did you get something on the screen
initially?

I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
expected, I can't reproduce any green screen issue here.

I found another problem though which might or might not be related with
your issue. I saw that the overlay is not exactly centered as it ought
to be. This goes down to wrong delay settings for the overlay, the
following patch fixes this.

Sascha

---------------------------------8<-------------------------------

From f9a92401344e8aa3203fca2236dd4a40cc8690f6 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Wed, 30 Mar 2022 09:22:26 +0200
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 69e9870d5f2dc..7dba7b9b63dc6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1979,10 +1979,10 @@ static void vop2_setup_dly_for_windows(struct vop2 *vop2)
 			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__ESMART1, dly);
 			break;
 		case ROCKCHIP_VOP2_SMART0:
-			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
+			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
 			break;
 		case ROCKCHIP_VOP2_SMART1:
-			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
+			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
 			break;
 		}
 	}
-- 
2.30.2

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[piotro.oniszczuk@google.com]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 09:28:
> 
>> 
>> You can easily reproduce with modetest utility:
>> 
>> modetest -P 43@67:1920x1080@NV12
> 
> This only sets the overlay, but how did you get something on the screen
> initially?
> 

I'm not sure that above command only sets plane.
On other SoCs i’m testing it gives expected results: diagonal colored stripes.
There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   

> I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
> expected, I can't reproduce any green screen issue here.

I see you are using plane #69.
Why not #43?
Is plane #43 working ok for you?

I’m using plane #43 because: application (player) - at start -  queries all planes and selects first plane offering format being within offered formats by provider (video decoder; NV12 from rk356x hantro video decoder).

pls look on app log regarding planes discovery and election: https://pastebin.com/edAhbcvU

Now - looking what VOP2 reports: https://pastebin.com/8ujkaV9n
is see first plane accepting NV12 is #43 - so my app is electing this plane to use for displaying video.

This strategy works well for all 13 platforms i’m supporting (only 13 i have in my testbed).

If this approach is - by Yours VOP2 patches goal - is not supported - then OK.
I understand this :-)

But - if You want to support DRM features in the same way like other SOC are doing (and working well with KODI/MythTV/mpv/etc) - then i think:

1\ DRM plane #43 not supports NV12 - but code wrongly reports NV12 format is supported, or
2\ DRM plane #43 is supported - but code has bug resulting with green screen.

Pls let me know what you think!


> 
> I found another problem though which might or might not be related with
> your issue. I saw that the overlay is not exactly centered as it ought
> to be. This goes down to wrong delay settings for the overlay, the
> following patch fixes this.
> 
> Sascha
> 
> ---------------------------------8<-------------------------------
> 
> From f9a92401344e8aa3203fca2236dd4a40cc8690f6 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Wed, 30 Mar 2022 09:22:26 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 69e9870d5f2dc..7dba7b9b63dc6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1979,10 +1979,10 @@ static void vop2_setup_dly_for_windows(struct vop2 *vop2)
> 			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__ESMART1, dly);
> 			break;
> 		case ROCKCHIP_VOP2_SMART0:
> -			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
> +			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
> 			break;
> 		case ROCKCHIP_VOP2_SMART1:
> -			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART0, dly);
> +			sdly |= FIELD_PREP(RK3568_SMART_DLY_NUM__SMART1, dly);
> 			break;
> 		}
> 	}
> -- 
> 2.30.2
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 09:28:
> > 
> >> 
> >> You can easily reproduce with modetest utility:
> >> 
> >> modetest -P 43@67:1920x1080@NV12
> > 
> > This only sets the overlay, but how did you get something on the screen
> > initially?

Let me rephrase this: The above sets a plane, but it doesn't set a mode
on the crtc. When my system boots up then the output of modetest looks
like this:

Encoders:
id      crtc    type    possible crtcs  possible clones
68      0       TMDS    0x00000001      0x00000001
Connectors:
id      encoder status          name            size (mm)       modes  encoders
69      0       connected       HDMI-A-1        530x300         9      68
CRTCs:
id      fb      pos     size
67      0       (0,0)   (0x0)
  #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 

No mode is set on the CRTC and the encoder/connector/crtc are not bound
to each other, consequently the screen is in standby. "modetest -P
43@67:1920x1080@NV12" doesn't change this, still no mode set. Hence my
question: How did you set a mode initially?

> > 
> 
> I'm not sure that above command only sets plane.
> On other SoCs i’m testing it gives expected results: diagonal colored stripes.
> There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   
> 
> > I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
> > expected, I can't reproduce any green screen issue here.
> 
> I see you are using plane #69.
> Why not #43?

I used "modetest -s 69@67:1920x1080 -d" to set a mode. The '69' is the
connector id, not a plane.

> Is plane #43 working ok for you?

Yes.

> 
> I’m using plane #43 because: application (player) - at start -  queries all planes and selects first plane offering format being within offered formats by provider (video decoder; NV12 from rk356x hantro video decoder).
> 
> pls look on app log regarding planes discovery and election: https://pastebin.com/edAhbcvU
> 
> Now - looking what VOP2 reports: https://pastebin.com/8ujkaV9n
> is see first plane accepting NV12 is #43 - so my app is electing this plane to use for displaying video.
> 
> This strategy works well for all 13 platforms i’m supporting (only 13 i have in my testbed).
> 
> If this approach is - by Yours VOP2 patches goal - is not supported - then OK.
> I understand this :-)
> 
> But - if You want to support DRM features in the same way like other SOC are doing (and working well with KODI/MythTV/mpv/etc) - then i think:
> 
> 1\ DRM plane #43 not supports NV12 - but code wrongly reports NV12 format is supported, or
> 2\ DRM plane #43 is supported - but code has bug resulting with green screen.

plane #43 should support NV12 and it seems to work fine here.

I believe you that there's a problem, but I can't reproduce it here and
I might need further assistence to reproduce it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[piotro.oniszczuk@google.com]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 11:45:
> 
> On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com wrote:
> 
> Let me rephrase this: The above sets a plane, but it doesn't set a mode
> on the crtc. When my system boots up then the output of modetest looks
> like this:
> 
> Encoders:
> id      crtc    type    possible crtcs  possible clones
> 68      0       TMDS    0x00000001      0x00000001
> Connectors:
> id      encoder status          name            size (mm)       modes  encoders
> 69      0       connected       HDMI-A-1        530x300         9      68
> CRTCs:
> id      fb      pos     size
> 67      0       (0,0)   (0x0)
>  #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 
> 
> No mode is set on the CRTC and the encoder/connector/crtc are not bound
> to each other, consequently the screen is in standby. "modetest -P
> 43@67:1920x1080@NV12" doesn't change this, still no mode set. Hence my
> question: How did you set a mode initially?

Ah ok. I see your point.
mode is set by app (player). 

Sequence was like this:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)

> 
>>> 
>> 
>> I'm not sure that above command only sets plane.
>> On other SoCs i’m testing it gives expected results: diagonal colored stripes.
>> There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   
>> 
>>> I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
>>> expected, I can't reproduce any green screen issue here.
>> 
>> I see you are using plane #69.
>> Why not #43?
> 
> I used "modetest -s 69@67:1920x1080 -d" to set a mode. The '69' is the
> connector id, not a plane.

ack.
typo from my side.

it was
modetest -P 49@67:1920x1080@NV12


> 
>> Is plane #43 working ok for you?
> 
> Yes.

So it looks your testing method of #43 is not meaningful for verifying issue we are discussing here.

In my case:
12 SOC (except rk356x VOP2) gives me:
-boot board
-start app
-on UI select playback
-playback is ok
-exit app
-run modetest -P XX@YY:1920x1080@NV12 (diagonal stripes)

(XX/YY are plane/connector elected by app: plane@conector with format matching provider format) 

rk356x with vop2 v9:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Mar 30, 2022 at 12:01:05PM +0200, piotro.oniszczuk@google.com wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 11:45:
> > 
> > On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com wrote:
> > 
> > Let me rephrase this: The above sets a plane, but it doesn't set a mode
> > on the crtc. When my system boots up then the output of modetest looks
> > like this:
> > 
> > Encoders:
> > id      crtc    type    possible crtcs  possible clones
> > 68      0       TMDS    0x00000001      0x00000001
> > Connectors:
> > id      encoder status          name            size (mm)       modes  encoders
> > 69      0       connected       HDMI-A-1        530x300         9      68
> > CRTCs:
> > id      fb      pos     size
> > 67      0       (0,0)   (0x0)
> >  #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 
> > 
> > No mode is set on the CRTC and the encoder/connector/crtc are not bound
> > to each other, consequently the screen is in standby. "modetest -P
> > 43@67:1920x1080@NV12" doesn't change this, still no mode set. Hence my
> > question: How did you set a mode initially?
> 
> Ah ok. I see your point.
> mode is set by app (player). 
> 
> Sequence was like this:
> -boot board
> -start app
> -on UI select playback
> -playback has green screen
> -exit app
> -run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
> -run modetest -P 49@67:1920x1080@NV12 (works ok)
> -run modetest -P 43@67:1920x1080@NV12 (now works ok)
> 
> > 
> >>> 
> >> 
> >> I'm not sure that above command only sets plane.
> >> On other SoCs i’m testing it gives expected results: diagonal colored stripes.
> >> There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   
> >> 
> >>> I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
> >>> expected, I can't reproduce any green screen issue here.
> >> 
> >> I see you are using plane #69.
> >> Why not #43?
> > 
> > I used "modetest -s 69@67:1920x1080 -d" to set a mode. The '69' is the
> > connector id, not a plane.
> 
> ack.
> typo from my side.
> 
> it was
> modetest -P 49@67:1920x1080@NV12
> 
> 
> > 
> >> Is plane #43 working ok for you?
> > 
> > Yes.
> 
> So it looks your testing method of #43 is not meaningful for verifying issue we are discussing here.
> 
> In my case:
> 12 SOC (except rk356x VOP2) gives me:
> -boot board
> -start app
> -on UI select playback
> -playback is ok
> -exit app
> -run modetest -P XX@YY:1920x1080@NV12 (diagonal stripes)
> 
> (XX/YY are plane/connector elected by app: plane@conector with format matching provider format) 
> 
> rk356x with vop2 v9:
> -boot board
> -start app
> -on UI select playback
> -playback has green screen
> -exit app
> -run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
> -run modetest -P 49@67:1920x1080@NV12 (works ok)
> -run modetest -P 43@67:1920x1080@NV12 (now works ok)

Does it change anything if you do a "modetest -s 69@67:1920x1080" before
starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
before starting the app? Or other combinations thereof?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20:
> 
> Does it change anything if you do a "modetest -s 69@67:1920x1080" before
> starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
> before starting the app? Or other combinations thereof?

So i tried following combinations

1.
-boot
-start app
-stop app
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 43@67:1920x1080@NV12 -> green screen

2.
-boot
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 43@67:1920x1080@NV12 -> green screen

3.
-boot
-modetest -s 69@67:1920x1080 -> ok
-start app
-playback in app -> green screen
-stop app
-modetest -P 43@67:1920x1080@NV12 -> green screen

4.
-boot
-modetest -s 69@67:1920x1080 -> ok
-start app
-playback in app -> green screen
-stop app
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 43@67:1920x1080@NV12 -> green screen

br




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20:
> > 
> > Does it change anything if you do a "modetest -s 69@67:1920x1080" before
> > starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
> > before starting the app? Or other combinations thereof?
> 
> So i tried following combinations
> 
> -boot
> -modetest -s 69@67:1920x1080 -> ok
> -modetest -P 43@67:1920x1080@NV12 -> green screen

I have no idea what is going on here. There same commands work for me.
You could provide me your kernel config and upstream commitish you are
working on, maybe that gets me closer to your setup.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 21:20:
> 
>> So i tried following combinations
>> 
>> -boot
>> -modetest -s 69@67:1920x1080 -> ok
>> -modetest -P 43@67:1920x1080@NV12 -> green screen
> 
> I have no idea what is going on here. There same commands work for me.
> You could provide me your kernel config and upstream commitish you are
> working on, maybe that gets me closer to your setup.

Sascha

May you try with my kernel config?
https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.17/files/linux-5.17-arm64-armv8.config

If this config will work for you then:

i'll try to build vanilla 5.17 + minimal possible set of patches allowing me to get video decoder working on rk3566.
This may help us to find why:
-you have it working
-I have it not working




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Mar 30, 2022 at 09:35:17PM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 21:20:
> > 
> >> So i tried following combinations
> >> 
> >> -boot
> >> -modetest -s 69@67:1920x1080 -> ok
> >> -modetest -P 43@67:1920x1080@NV12 -> green screen
> > 
> > I have no idea what is going on here. There same commands work for me.
> > You could provide me your kernel config and upstream commitish you are
> > working on, maybe that gets me closer to your setup.
> 
> Sascha
> 
> May you try with my kernel config?
> https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.17/files/linux-5.17-arm64-armv8.config

This works for me as well.

> 
> If this config will work for you then:
> 
> i'll try to build vanilla 5.17 + minimal possible set of patches allowing me to get video decoder working on rk3566.

You shouldn't need a video decoder for this test.

For your convenience I pushed the branch I just tested to:

git://git.pengutronix.de/sha/linux rockchip-vop2-v9

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Andy Yan]

Hi Piotr:

On 3/31/22 03:20, Sascha Hauer wrote:
> On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
>>
>>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20:
>>>
>>> Does it change anything if you do a "modetest -s 69@67:1920x1080" before
>>> starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
>>> before starting the app? Or other combinations thereof?
>> So i tried following combinations
>>
>> -boot
>> -modetest -s 69@67:1920x1080 -> ok
>> -modetest -P 43@67:1920x1080@NV12 -> green screen
> I have no idea what is going on here. There same commands work for me.
> You could provide me your kernel config and upstream commitish you are
> working on, maybe that gets me closer to your setup.


It's a little strange, I can't reproduce this issue neither.

But I have problem with this two step command sequence.

step 1:  modetest -s 69@67:1920x1080 -> ok

step 2:  modetest -P 43@67:1920x1080@NV12,

I got the failed message:  "failed to enable plane: Permission denied"

Because the drm core will stop step2 by drm_ioctrl_permit as 
DRM_IOCTL_SETPLANE need a master,

but the current master is the modetest run by step1.

static int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
{

         /* ROOT_ONLY is only for CAP_SYS_ADMIN */
         if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) {
                 printk("DRM_ROOT_ONLY\n");
                 return -EACCES;
         }

         /* AUTH is only for authenticated or render client */
         if (unlikely((flags & DRM_AUTH) && 
!drm_is_render_client(file_priv) &&
                      !file_priv->authenticated)) {
                 printk("DRM_AUTH\n");
                 return -EACCES;
         }

         /* MASTER is only for master or control clients */
         if (unlikely((flags & DRM_MASTER) &&
                      !drm_is_current_master(file_priv))) {
                 printk("DRM_MASTER\n");
                 return -EACCES;
         }

         /* Render clients must be explicitly allowed */
         if (unlikely(!(flags & DRM_RENDER_ALLOW) &&
                      drm_is_render_client(file_priv))) {
                 printk("DRM_RENDER_NOT_ALLOW\n");
                 return -EACCES;
         }

         return 0;
}


After bypass the permission check, I can run step 2 , but the display on 
the screen will have a shift as the wrong dly configuration.

So how you two got step two run success?

Piotr:

What soc is on you board? rk3566 or rk3568?

I have a scripts[0]  use io[1] command to dump the VOP2 register you can 
use it dump the register configuration when you meet a display failure,

then send the dump to me, maybe I can figure out something.

[0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh

[1] https://github.com/andyshrk/io

>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Thu, Mar 31, 2022 at 08:13:09PM +0800, Andy Yan wrote:
> Hi Piotr:
> 
> On 3/31/22 03:20, Sascha Hauer wrote:
> > On Wed, Mar 30, 2022 at 04:52:22PM +0200, Piotr Oniszczuk wrote:
> > > 
> > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 30.03.2022, o godz. 12:20:
> > > > 
> > > > Does it change anything if you do a "modetest -s 69@67:1920x1080" before
> > > > starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
> > > > before starting the app? Or other combinations thereof?
> > > So i tried following combinations
> > > 
> > > -boot
> > > -modetest -s 69@67:1920x1080 -> ok
> > > -modetest -P 43@67:1920x1080@NV12 -> green screen
> > I have no idea what is going on here. There same commands work for me.
> > You could provide me your kernel config and upstream commitish you are
> > working on, maybe that gets me closer to your setup.
> 
> 
> It's a little strange, I can't reproduce this issue neither.
> 
> But I have problem with this two step command sequence.
> 
> step 1:  modetest -s 69@67:1920x1080 -> ok
> 
> step 2:  modetest -P 43@67:1920x1080@NV12,
> 
> I got the failed message:  "failed to enable plane: Permission denied"
> 
> Because the drm core will stop step2 by drm_ioctrl_permit as
> DRM_IOCTL_SETPLANE need a master,
> 
> but the current master is the modetest run by step1.
>

[...]

> 
> So how you two got step two run success?

You have to stop the first modetest by hitting return. Alternatively you
could pass the -d option to the first modetest.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13:
> 
> 
> Piotr:
> 
> What soc is on you board? rk3566 or rk3568?

it is rk3566 in x96-x6 tvbox


> 
> I have a scripts[0]  use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure,
> 
> then send the dump to me, maybe I can figure out something.
> 
> [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh
> 
> [1] https://github.com/andyshrk/io

Andy

Pls see https://pastebin.com/CHmu9s22

I put dumps for following scenarios:

1.
-boot
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 43@67:1920x1080@NV12 -> green screen


2.
-boot
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width)
(setting palne#49 fixes plane #43. Here i set plane #49 but not yet setting #43)


3.
-boot
-modetest -s 69@67:1920x1080 -> ok
-modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width)
-modetest -P 43@67:1920x1080@NV12 -> now ok (but shifted horizontally by about 5% of screen width)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Thu, Mar 31, 2022 at 04:53:05PM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13:
> > 
> > 
> > Piotr:
> > 
> > What soc is on you board? rk3566 or rk3568?
> 
> it is rk3566 in x96-x6 tvbox
> 
> 
> > 
> > I have a scripts[0]  use io[1] command to dump the VOP2 register you can use it dump the register configuration when you meet a display failure,
> > 
> > then send the dump to me, maybe I can figure out something.
> > 
> > [0]https://github.com/andyshrk/buildroot/blob/2022/board/andyshrk/rootfs_overlay/usr/bin/vop2_dump.sh
> > 
> > [1] https://github.com/andyshrk/io
> 
> Andy
> 
> Pls see https://pastebin.com/CHmu9s22
> 
> I put dumps for following scenarios:
> 
> 1.
> -boot
> -modetest -s 69@67:1920x1080 -> ok
> -modetest -P 43@67:1920x1080@NV12 -> green screen
> 
> 
> 2.
> -boot
> -modetest -s 69@67:1920x1080 -> ok
> -modetest -P 49@67:1920x1080@NV12 -> ok (but shifted horizontally by about 5% of screen width)

Have you applied the bugfix I shared with you here:

https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 31.03.2022, o godz. 17:00:
> 
> 
> Have you applied the bugfix I shared with you here:
> 
> https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/
> 

oooops

noooooo
didn't noticed :-(

let me try with it!


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 31.03.2022, o godz. 17:06:
> 
> 
> 
>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 31.03.2022, o godz. 17:00:
>> 
>> 
>> Have you applied the bugfix I shared with you here:
>> 
>> https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/
>> 
> 
> oooops
> 
> noooooo
> didn't noticed :-(
> 
> let me try with it!
> 

ok - i tried.
unfortunately no any difference :-(





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Fri, Apr 01, 2022 at 09:52:01AM +0800, Andy Yan wrote:
>    Hi Piotr:
> 
>    On 3/31/22 22:53, Piotr Oniszczuk wrote:
> 
> 
> 
>  Wiadomość napisana przez Andy Yan [1]<andy.yan@rock-chips.com> w dniu 31.03.2022, o godz. 14:13:
> 
> 
>  Piotr:
> 
>  What soc is on you board? rk3566 or rk3568?
> 
>  it is rk3566 in x96-x6 tvbox
> 
>    RK3566?  Maybe that is the problem.

Likely, yes.

> 
>    plane[43]: Esmart1-win0
>    crtc=(null)
>    fb=0
>    crtc-pos=0x0+0+0
>    src-pos=0.000000x0.000000+0.000000+0.000000
>    rotation=1
>    normalized-zpos=1
>    color-encoding=ITU-R BT.601 YCbCr
>    color-range=YCbCr limited range
> 
>    From your dri/state dump, Plane 43 is Esmart1.
> 
>    Cluster1, Esmart1, Smart1 are special on rk3566, they are
> 
>    mirror window of Cluster0, Esmart0, Esmart0. That means
> 
>    the software can't program  a independent framebuffer for
> 
>    these three windows. They can only share the fb address set
> 
>    in Cluster0, Esmart0, Smart0.

Downstream Kernel has this:

static bool vop2_is_mirror_win(struct vop2_win *win)
{
        return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
}

static int vop2_create_crtc(struct vop2 *vop2)
{
	...

        for (j = 0; j < vop2->registered_num_wins; j++) {
                win = &vop2->win[j];

                if (win->type != DRM_PLANE_TYPE_OVERLAY)
                        continue;
                /*
                 * Only dual display on rk3568(which need two crtcs) need mirror win
                 */
                if (registered_num_crtcs < 2 && vop2_is_mirror_win(win))
                        continue;

		...

                ret = vop2_plane_init(vop2, win, possible_crtcs);
	}

	...
}

"Smart1-win0" and "Esmart1-win0" have this WIN_FEATURE_MIRROR bit set. It
seems we just should just don't register these windows for rk3566.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Andy Yan <andy.yan@rock-chips.com> w dniu 01.04.2022, o godz. 14:04:
> 
> Hi Piotr:
> 
> On 4/1/22 09:52, Andy Yan wrote:
> 
> Pls update the new vop2_dump.sh scripts from github. The
> 
> previous scripts I gave you has some bug. sorry.
> 

Andy,

Sure. np.
Pls find dump with current vop2_dump.sh
https://pastebin.com/CwVj0kuX

btw: this is with latest patch from Sascha:
https://lore.kernel.org/linux-arm-kernel/20220330072822.GX12181@pengutronix.de/



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

Hi Piotr,

On Tue, Mar 29, 2022 at 09:31:01AM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 28.03.2022, o godz. 17:10:
> > 
> > 
> > Changes since v8:
> > - make hclk_vo a critical clock instead of enabling it in the hdmi driver
> > - Fix vop2_setup_layer_mixer(), reported by Andy Yan
> > - Limit planes possible_crtcs to actually existing crtcs
> > 
> > 
> 
> Sascha,
> 
> FYI:
> I was hoping v9 will fix green screen issue i see when video player wants to draw to nv12 capable drm plane.
> It look issue is still present :-(

Based on the discussion with Andy please try the following patch, it
should fix your green screen issue. Note that with this patch the
CRTC and plane ids will change, so the modetest commands need to be
adjusted accordingly.

Sascha

-------------------------8<---------------------------

-- 
From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 1 Apr 2022 14:48:49 +0200
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 7dba7b9b63dc6..1421bf2f133f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
 			}
 		}
 
+		if (vop2->data->soc_id == 3566) {
+			/*
+			 * On RK3566 these windows don't have an independent
+			 * framebuffer. They share the framebuffer with smart0,
+			 * esmart0 and cluster0 respectively.
+			 */
+			switch (win->data->phys_id) {
+			case ROCKCHIP_VOP2_SMART1:
+			case ROCKCHIP_VOP2_ESMART1:
+			case ROCKCHIP_VOP2_CLUSTER1:
+				continue;
+			}
+		}
+
 		if (win->type == DRM_PLANE_TYPE_OVERLAY)
 			possible_crtcs = (1 << nvps) - 1;
 
-- 
2.30.2

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52:
> 
> Based on the discussion with Andy please try the following patch, it
> should fix your green screen issue. Note that with this patch the
> CRTC and plane ids will change, so the modetest commands need to be
> adjusted accordingly.
> 
> Sascha
> 
> -------------------------8<---------------------------
> 
> -- 
> From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Fri, 1 Apr 2022 14:48:49 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 7dba7b9b63dc6..1421bf2f133f1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> 			}
> 		}
> 
> +		if (vop2->data->soc_id == 3566) {
> +			/*
> +			 * On RK3566 these windows don't have an independent
> +			 * framebuffer. They share the framebuffer with smart0,
> +			 * esmart0 and cluster0 respectively.
> +			 */
> +			switch (win->data->phys_id) {
> +			case ROCKCHIP_VOP2_SMART1:
> +			case ROCKCHIP_VOP2_ESMART1:
> +			case ROCKCHIP_VOP2_CLUSTER1:
> +				continue;
> +			}
> +		}
> +
> 		if (win->type == DRM_PLANE_TYPE_OVERLAY)
> 			possible_crtcs = (1 << nvps) - 1;
> 
> -- 
> 2.30.2
> 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Sascha

Now works perfectly!
(hd playback with 3.5...5.5% cpu while rendering to drm plane)

Fantastic work of You!



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05:
> 
> 
> 
>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52:
>> 
>> Based on the discussion with Andy please try the following patch, it
>> should fix your green screen issue. Note that with this patch the
>> CRTC and plane ids will change, so the modetest commands need to be
>> adjusted accordingly.
>> 
>> Sascha
>> 
>> -------------------------8<---------------------------
>> 
>> -- 
>> From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
>> From: Sascha Hauer <s.hauer@pengutronix.de>
>> Date: Fri, 1 Apr 2022 14:48:49 +0200
>> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>> 
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> index 7dba7b9b63dc6..1421bf2f133f1 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
>> 			}
>> 		}
>> 
>> +		if (vop2->data->soc_id == 3566) {
>> +			/*
>> +			 * On RK3566 these windows don't have an independent
>> +			 * framebuffer. They share the framebuffer with smart0,
>> +			 * esmart0 and cluster0 respectively.
>> +			 */
>> +			switch (win->data->phys_id) {
>> +			case ROCKCHIP_VOP2_SMART1:
>> +			case ROCKCHIP_VOP2_ESMART1:
>> +			case ROCKCHIP_VOP2_CLUSTER1:
>> +				continue;
>> +			}
>> +		}
>> +
>> 		if (win->type == DRM_PLANE_TYPE_OVERLAY)
>> 			possible_crtcs = (1 << nvps) - 1;
>> 
>> -- 
>> 2.30.2
>> 
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> Sascha
> 
> Now works perfectly!
> (hd playback with 3.5...5.5% cpu while rendering to drm plane)
> 
> Fantastic work of You!

Sascha,

Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 

context: player draws video on plane #X and osd on overlay plane #Y
When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)

This works well on all platforms i have  - except rk3566 

For me it looks like z-order vop2 issue or alpha blending issue.
As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.

what you think?



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05:
> > 
> > 
> > 
> >> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 01.04.2022, o godz. 14:52:
> >> 
> >> Based on the discussion with Andy please try the following patch, it
> >> should fix your green screen issue. Note that with this patch the
> >> CRTC and plane ids will change, so the modetest commands need to be
> >> adjusted accordingly.
> >> 
> >> Sascha
> >> 
> >> -------------------------8<---------------------------
> >> 
> >> -- 
> >> From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> >> From: Sascha Hauer <s.hauer@pengutronix.de>
> >> Date: Fri, 1 Apr 2022 14:48:49 +0200
> >> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> >> 
> >> ---
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> index 7dba7b9b63dc6..1421bf2f133f1 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> >> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> >> 			}
> >> 		}
> >> 
> >> +		if (vop2->data->soc_id == 3566) {
> >> +			/*
> >> +			 * On RK3566 these windows don't have an independent
> >> +			 * framebuffer. They share the framebuffer with smart0,
> >> +			 * esmart0 and cluster0 respectively.
> >> +			 */
> >> +			switch (win->data->phys_id) {
> >> +			case ROCKCHIP_VOP2_SMART1:
> >> +			case ROCKCHIP_VOP2_ESMART1:
> >> +			case ROCKCHIP_VOP2_CLUSTER1:
> >> +				continue;
> >> +			}
> >> +		}
> >> +
> >> 		if (win->type == DRM_PLANE_TYPE_OVERLAY)
> >> 			possible_crtcs = (1 << nvps) - 1;
> >> 
> >> -- 
> >> 2.30.2
> >> 
> >> Pengutronix e.K.                           |                             |
> >> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> >> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> >> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> > 
> > Sascha
> > 
> > Now works perfectly!
> > (hd playback with 3.5...5.5% cpu while rendering to drm plane)
> > 
> > Fantastic work of You!
> 
> Sascha,
> 
> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 
> 
> context: player draws video on plane #X and osd on overlay plane #Y
> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)
> 
> This works well on all platforms i have  - except rk3566 
> 
> For me it looks like z-order vop2 issue or alpha blending issue.
> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.

During my testing I haven't seen any z-order issues, but that doesn't
mean much. With Weston I can currently only use the AFBC enabled cluster
windows and with modetest I can only use the non-cluster windows. Are
you able to find out which window is used for the OSD?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 06.04.2022, o godz. 16:58:
> 
> On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
>> 
>> 
>> Sascha,
>> 
>> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 
>> 
>> context: player draws video on plane #X and osd on overlay plane #Y
>> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)
>> 
>> This works well on all platforms i have  - except rk3566 
>> 
>> For me it looks like z-order vop2 issue or alpha blending issue.
>> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.
> 
> During my testing I haven't seen any z-order issues, but that doesn't
> mean much. With Weston I can currently only use the AFBC enabled cluster
> windows and with modetest I can only use the non-cluster windows. Are
> you able to find out which window is used for the OSD?
> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

WiIl this answer to your Q?

player:

2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm
2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated
2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video
2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt
2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1

so:
plane #37 is where video is drawing
plane #43 is GUI/OSD


dri state:

root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
plane[31]: Smart0-win0
        crtc=video_port0
        fb=58
                allocated by = mythfrontend
                refcount=2
                format=XR24 little-endian (0x34325258)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=7680
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=4
                                start=00000000
                                size=8294400
                                imported=no
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[37]: Esmart0-win0
        crtc=(null)
        fb=0
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[43]: Cluster0-win0
        crtc=(null)
        fb=0
        crtc-pos=0x0+0+0
        src-pos=0.000000x0.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
crtc[49]: video_port0
        enable=1
        active=1
        self_refresh_active=0
        planes_changed=1
        mode_changed=0
        active_changed=0
        connectors_changed=0
        color_mgmt_changed=0
        plane_mask=1
        connector_mask=1
        encoder_mask=1
        mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
connector[51]: HDMI-A-1
        crtc=video_port0
        self_refresh_aware=0
 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Apr 06, 2022 at 06:00:00PM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 06.04.2022, o godz. 16:58:
> > 
> > On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
> >> 
> >> 
> >> Sascha,
> >> 
> >> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 
> >> 
> >> context: player draws video on plane #X and osd on overlay plane #Y
> >> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)
> >> 
> >> This works well on all platforms i have  - except rk3566 
> >> 
> >> For me it looks like z-order vop2 issue or alpha blending issue.
> >> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.
> > 
> > During my testing I haven't seen any z-order issues, but that doesn't
> > mean much. With Weston I can currently only use the AFBC enabled cluster
> > windows and with modetest I can only use the non-cluster windows. Are
> > you able to find out which window is used for the OSD?
> > 
> > Sascha
> > 
> > -- 
> > Pengutronix e.K.                           |                             |
> > Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> > 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> WiIl this answer to your Q?

Yes, and it raises a few more ;)

> 
> player:
> 
> 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm
> 2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
> 2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated
> 2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> 2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video
> 2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
> 2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
> 2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt
> 2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
> 
> so:
> plane #37 is where video is drawing
> plane #43 is GUI/OSD
> 
> 
> dri state:
> 
> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
> plane[31]: Smart0-win0
>         crtc=video_port0
>         fb=58
>                 allocated by = mythfrontend
>                 refcount=2
>                 format=XR24 little-endian (0x34325258)
>                 modifier=0x0
>                 size=1920x1080
>                 layers:
>                         size[0]=1920x1080
>                         pitch[0]=7680
>                         offset[0]=0
>                         obj[0]:
>                                 name=0
>                                 refcount=4
>                                 start=00000000
>                                 size=8294400
>                                 imported=no
>         crtc-pos=1920x1080+0+0
>         src-pos=1920.000000x1080.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range

Ok, this seems to be the base plane.

> plane[37]: Esmart0-win0
>         crtc=(null)

crtc=null? Did you capture the state without a video playing? Otherwise
I would expect a crtc associated here.

>         fb=0
>         crtc-pos=1920x1080+0+0
>         src-pos=1920.000000x1080.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range
> plane[43]: Cluster0-win0
>         crtc=(null)

This plane is selected for OSD by your application. The cluster windows
can't show a regular linear framebuffer, they can only do AFBC. You'll
see that in modetest:

	in_formats blob decoded:
                 XR24:  ARM_BLOCK_SIZE=16x16,
			 ARM_BLOCK_SIZE=16x16,MODE=SPARSE
			 ARM_BLOCK_SIZE=16x16,MODE=YTR
			 ARM_BLOCK_SIZE=16x16,MODE=CBR
			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE
			 ARM_BLOCK_SIZE=16x16,MODE=SPARSE|CBR
			 ARM_BLOCK_SIZE=16x16,MODE=YTR|CBR
			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE|CBR
			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPLIT|SPARSE
		...

The other windows show "XR24: LINEAR" here. Does your application use
the GPU to render the OSD? Otherwise I doubt your application can
handle this format, so it should not use this layer.

>         fb=0
>         crtc-pos=0x0+0+0
>         src-pos=0.000000x0.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0

I would be interested in this output when the player is actually playing
something. This normalized-zpos puzzles me a bit. Normally it should be
unique over all enabled planes for a CRTC. Maybe 0 is ok here because
it's currently not associated to any CRTC.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 07.04.2022, o godz. 12:16:
> 
> 
> Yes, and it raises a few more ;)

pls see at end of email: DRI state with playback

> 
>> 
>> player:
>> 
>> 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt): 930mmx530mm
>> 2022-04-06 17:52:26.424922 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
>> 2022-04-06 17:52:26.425061 I /dev/dri/card0: Authenticated
>> 2022-04-06 17:52:26.534362 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
>> 2022-04-06 17:52:26.534384 I /dev/dri/card0: Selected Plane #37 Overlay for video
>> 2022-04-06 17:52:26.534430 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
>> 2022-04-06 17:52:26.534437 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
>> 2022-04-06 17:52:26.534480 I /dev/dri/card0: DRM device retrieved from Qt
>> 2022-04-06 17:52:26.534489 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
>> 
>> so:
>> plane #37 is where video is drawing
>> plane #43 is GUI/OSD
>> 
>> 
>> dri state:
>> 
>> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
>> plane[31]: Smart0-win0
>>        crtc=video_port0
>>        fb=58
>>                allocated by = mythfrontend
>>                refcount=2
>>                format=XR24 little-endian (0x34325258)
>>                modifier=0x0
>>                size=1920x1080
>>                layers:
>>                        size[0]=1920x1080
>>                        pitch[0]=7680
>>                        offset[0]=0
>>                        obj[0]:
>>                                name=0
>>                                refcount=4
>>                                start=00000000
>>                                size=8294400
>>                                imported=no
>>        crtc-pos=1920x1080+0+0
>>        src-pos=1920.000000x1080.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=0
>>        color-encoding=ITU-R BT.601 YCbCr
>>        color-range=YCbCr limited range
> 
> Ok, this seems to be the base plane.
> 
>> plane[37]: Esmart0-win0
>>        crtc=(null)
> 
> crtc=null? Did you capture the state without a video playing? Otherwise
> I would expect a crtc associated here.

Indeed. This was from player sitting in UI (no playback).
Pls see at bottom of email state with video playback
(it has crtc=video_port0)  

> 
>>        fb=0
>>        crtc-pos=1920x1080+0+0
>>        src-pos=1920.000000x1080.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=0
>>        color-encoding=ITU-R BT.601 YCbCr
>>        color-range=YCbCr limited range
>> plane[43]: Cluster0-win0
>>        crtc=(null)
> 
> This plane is selected for OSD by your application. The cluster windows
> can't show a regular linear framebuffer, they can only do AFBC. You'll
> see that in modetest:
> 
> 	in_formats blob decoded:
>                 XR24:  ARM_BLOCK_SIZE=16x16,
> 			 ARM_BLOCK_SIZE=16x16,MODE=SPARSE
> 			 ARM_BLOCK_SIZE=16x16,MODE=YTR
> 			 ARM_BLOCK_SIZE=16x16,MODE=CBR
> 			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE
> 			 ARM_BLOCK_SIZE=16x16,MODE=SPARSE|CBR
> 			 ARM_BLOCK_SIZE=16x16,MODE=YTR|CBR
> 			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE|CBR
> 			 ARM_BLOCK_SIZE=16x16,MODE=YTR|SPLIT|SPARSE
> 		...
> 
> The other windows show "XR24: LINEAR" here. Does your application use
> the GPU to render the OSD?

Yes.

> Otherwise I doubt your application can
> handle this format, so it should not use this layer.
> 
>>        fb=0
>>        crtc-pos=0x0+0+0
>>        src-pos=0.000000x0.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=0
> 
> I would be interested in this output when the player is actually playing
> something.

Pls see at bottom.

> This normalized-zpos puzzles me a bit.

I'm not surprised :-).
You are puzzled probably because rk35xx current VOP2 code requires - from me - to force Z-position = 0 in Qt if I want to have GUI visible on screen.
Without this screen is black. 
This seems to be i think - another issue to resolve (no any other SoC requires this....).
I'm not sure where issue is - but as i need to do this only on VOP2 - i think there is somewhere something not right in VOP2 code.        

> Normally it should be
> unique over all enabled planes for a CRTC. Maybe 0 is ok here because
> it's currently not associated to any CRTC.

It is because of me setting it to 0 (see explanations above)  

> 
> 

DRI state with video playback:

root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
plane[31]: Smart0-win0
        crtc=video_port0
        fb=55
                allocated by = mythfrontend
                refcount=2
                format=XR24 little-endian (0x34325258)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=7680
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=4
                                start=00000000
                                size=8294400
                                imported=no
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=1
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[37]: Esmart0-win0
        crtc=video_port0
        fb=65
                allocated by = mythfrontend
                refcount=2
                format=NV12 little-endian (0x3231564e)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=1920
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=3
                                start=00000000
                                size=3657728
                                imported=yes
                        size[1]=960x540
                        pitch[1]=1920
                        offset[1]=2088960
                        obj[1]:
                                name=0
                                refcount=3
                                start=00000000
                                size=3657728
                                imported=yes
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[43]: Cluster0-win0
        crtc=(null)
        fb=0
        crtc-pos=0x0+0+0
        src-pos=0.000000x0.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
crtc[49]: video_port0
        enable=1
        active=1
        self_refresh_active=0
        planes_changed=1
        mode_changed=0
        active_changed=0
        connectors_changed=0
        color_mgmt_changed=0
        plane_mask=3
        connector_mask=1
        encoder_mask=1
        mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
connector[51]: HDMI-A-1
        crtc=video_port0
        self_refresh_aware=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05:
> > Sascha
> > 
> > Now works perfectly!
> > (hd playback with 3.5...5.5% cpu while rendering to drm plane)
> > 
> > Fantastic work of You!
> 
> Sascha,
> 
> Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 
> 
> context: player draws video on plane #X and osd on overlay plane #Y
> When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)
> 
> This works well on all platforms i have  - except rk3566 
> 
> For me it looks like z-order vop2 issue or alpha blending issue.
> As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.

That turned out to be simpler than I thought it would be. The zpos
values were never actually written to the hardware. Please try the
following fixup, it should fix this issue.

Thanks for your valuable testing feedback so far :)

Sascha

----------------------------8<------------------------

From d5a102ff1d3010320f492a6ebac6710276fc641f Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 8 Apr 2022 09:45:24 +0200
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 54208b20a5a7e..8d1323a47f822 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1943,8 +1943,10 @@ static void vop2_setup_layer_mixer(struct vop2_video_port *vp)
 			break;
 		}
 
-		layer_sel &= ~RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, 0x7);
-		layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(nlayer + ofs, win->data->layer_sel_id);
+		layer_sel &= ~RK3568_OVL_LAYER_SEL__LAYER(plane->state->normalized_zpos + ofs,
+							  0x7);
+		layer_sel |= RK3568_OVL_LAYER_SEL__LAYER(plane->state->normalized_zpos + ofs,
+							 win->data->layer_sel_id);
 		nlayer++;
 	}
 
-- 
2.30.2


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Fri, Apr 08, 2022 at 10:07:48AM +0200, Sascha Hauer wrote:
> On Wed, Apr 06, 2022 at 11:47:22AM +0200, Piotr Oniszczuk wrote:
> > 
> > 
> > > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 01.04.2022, o godz. 15:05:
> > > Sascha
> > > 
> > > Now works perfectly!
> > > (hd playback with 3.5...5.5% cpu while rendering to drm plane)
> > > 
> > > Fantastic work of You!
> > 
> > Sascha,
> > 
> > Having vop2 finally working with drm planes rendering i discovered another issue: overlay osd is invisible at playback. 
> > 
> > context: player draws video on plane #X and osd on overlay plane #Y
> > When user do i.e. seek at playback - app uses overlay OSD plane to display OSD to user. This approach is used by majority of players (KODI, etc.)
> > 
> > This works well on all platforms i have  - except rk3566 
> > 
> > For me it looks like z-order vop2 issue or alpha blending issue.
> > As this is only on rk3566 and only on drm-planes mode - issue is vop2 related imho.
> 
> That turned out to be simpler than I thought it would be. The zpos
> values were never actually written to the hardware. Please try the
> following fixup, it should fix this issue.

Or better try v10 which I have just sent.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 08.04.2022, o godz. 14:00:
> 
>> That turned out to be simpler than I thought it would be. The zpos
>> values were never actually written to the hardware. Please try the
>> following fixup, it should fix this issue.
> 
> Or better try v10 which I have just sent.
> 

Sascha,

I applied v10 on 5.17.2 and...can't see difference.
I still need to play with zpos to get ui screen.
if i have playback - no OSD.
If I have OSD - no playback.

Maybe fix needs some adjustments for 3566? 

Here is short summary of playings with zpos and kms plane in Qt:

QT_QPA_EGLFS_KMS_ZPOS, QT_QPA_EGLFS_KMS_PLANE_INDEX

0,0 - GUI=ok, playback=ok, OSD=nok
1,0 - GUI=ok, playback=nok, OSD=ok
2,0 - GUI=ok, playback=nok, OSD=ok

0,1 - GUI=ok, playback=nok, OSD=ok
1,1 - GUI=ok, playback=nok, OSD=ok
2,1 - GUI=ok, playback=nok, OSD=ok

0,2 - GUI=nok, playback=n/a, OSD=n/a
1,2 - GUI=nok, playback=n/a, OSD=n/a
2,2 - GUI=nok, playback=n/a, OSD=n/a


player launch:
.......
2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
.......


playback:
.....
2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video
.....


DRI state with zpos=0, kms_id=0 and ongoing playback:

root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
plane[31]: Smart0-win0
        crtc=video_port0
        fb=58
                allocated by = mythfrontend
                refcount=2
                format=XR24 little-endian (0x34325258)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=7680
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=4
                                start=00000000
                                size=8294400
                                imported=no
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[37]: Esmart0-win0
        crtc=video_port0
        fb=65
                allocated by = mythfrontend
                refcount=2
                format=NV12 little-endian (0x3231564e)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=1920
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=3
                                start=00000000
                                size=3657728
                                imported=yes
                        size[1]=960x540
                        pitch[1]=1920
                        offset[1]=2088960
                        obj[1]:
                                name=0
                                refcount=3
                                start=00000000
                                size=3657728
                                imported=yes
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=1
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[43]: Cluster0-win0
        crtc=(null)
        fb=0
        crtc-pos=0x0+0+0
        src-pos=0.000000x0.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
crtc[49]: video_port0
        enable=1
        active=1
        self_refresh_active=0
        planes_changed=1
        mode_changed=0
        active_changed=0
        connectors_changed=0
        color_mgmt_changed=0
        plane_mask=3
        connector_mask=1
        encoder_mask=1
        mode: "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
connector[51]: HDMI-A-1
        crtc=video_port0
        self_refresh_aware=0
root@Myth-Frontend-06c7e973c2f1:~ #




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Fri, Apr 08, 2022 at 05:54:24PM +0200, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 08.04.2022, o godz. 14:00:
> > 
> >> That turned out to be simpler than I thought it would be. The zpos
> >> values were never actually written to the hardware. Please try the
> >> following fixup, it should fix this issue.
> > 
> > Or better try v10 which I have just sent.
> > 
> 
> Sascha,
> 
> I applied v10 on 5.17.2 and...can't see difference.
> I still need to play with zpos to get ui screen.
> if i have playback - no OSD.
> If I have OSD - no playback.
> 
> Maybe fix needs some adjustments for 3566?

I don't think so.

> player launch:
> .......
> 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
> 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
> 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
> 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
> 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1

Ok, so #37 for video, #43 for GUI.

Where is the OSD rendered? Is it rendered on the GUI layer?

> .......
> 
> 
> playback:
> .....
> 2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video
> .....
> 
> DRI state with zpos=0, kms_id=0 and ongoing playback:
> 
> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
> plane[31]: Smart0-win0
>         crtc=video_port0
>         fb=58
>                 allocated by = mythfrontend
>                 refcount=2
>                 format=XR24 little-endian (0x34325258)
>                 modifier=0x0
>                 size=1920x1080
>                 layers:
>                         size[0]=1920x1080
>                         pitch[0]=7680
>                         offset[0]=0
>                         obj[0]:
>                                 name=0
>                                 refcount=4
>                                 start=00000000
>                                 size=8294400
>                                 imported=no
>         crtc-pos=1920x1080+0+0
>         src-pos=1920.000000x1080.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range

Base plane.

> plane[37]: Esmart0-win0
>         crtc=video_port0
>         fb=65
>                 allocated by = mythfrontend
>                 refcount=2
>                 format=NV12 little-endian (0x3231564e)
>                 modifier=0x0
>                 size=1920x1080
>                 layers:
>                         size[0]=1920x1080
>                         pitch[0]=1920
>                         offset[0]=0
>                         obj[0]:
>                                 name=0
>                                 refcount=3
>                                 start=00000000
>                                 size=3657728
>                                 imported=yes
>                         size[1]=960x540
>                         pitch[1]=1920
>                         offset[1]=2088960
>                         obj[1]:
>                                 name=0
>                                 refcount=3
>                                 start=00000000
>                                 size=3657728
>                                 imported=yes
>         crtc-pos=1920x1080+0+0
>         src-pos=1920.000000x1080.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=1
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range

Video plane, rendered full screen above the base plane without alpha.

> plane[43]: Cluster0-win0
>         crtc=(null)
>         fb=0
>         crtc-pos=0x0+0+0
>         src-pos=0.000000x0.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range

Here should be the GUI, but this plane is not active.

With this state I would expect to see a full screen video without
anything on it. Is that the case? If yes, then fine.

Could you post a state where you expect something else than is actually
seen?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 11.04.2022, o godz. 11:08:
> 
> Ok, so #37 for video, #43 for GUI.
> 
> Where is the OSD rendered? Is it rendered on the GUI layer?

Yes

> 
>> .......
>> 
>> 
>> playback:
>> .....
>> 2022-04-08 17:48:55.457823 I DRMVideo: Using Plane #37 for video
>> .....
>> 
>> DRI state with zpos=0, kms_id=0 and ongoing playback:
>> 
>> root@Myth-Frontend-06c7e973c2f1:~ # cat /sys/kernel/debug/dri/0/state
>> plane[31]: Smart0-win0
>>        crtc=video_port0
>>        fb=58
>>                allocated by = mythfrontend
>>                refcount=2
>>                format=XR24 little-endian (0x34325258)
>>                modifier=0x0
>>                size=1920x1080
>>                layers:
>>                        size[0]=1920x1080
>>                        pitch[0]=7680
>>                        offset[0]=0
>>                        obj[0]:
>>                                name=0
>>                                refcount=4
>>                                start=00000000
>>                                size=8294400
>>                                imported=no
>>        crtc-pos=1920x1080+0+0
>>        src-pos=1920.000000x1080.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=0
>>        color-encoding=ITU-R BT.601 YCbCr
>>        color-range=YCbCr limited range
> 
> Base plane.
> 
>> plane[37]: Esmart0-win0
>>        crtc=video_port0
>>        fb=65
>>                allocated by = mythfrontend
>>                refcount=2
>>                format=NV12 little-endian (0x3231564e)
>>                modifier=0x0
>>                size=1920x1080
>>                layers:
>>                        size[0]=1920x1080
>>                        pitch[0]=1920
>>                        offset[0]=0
>>                        obj[0]:
>>                                name=0
>>                                refcount=3
>>                                start=00000000
>>                                size=3657728
>>                                imported=yes
>>                        size[1]=960x540
>>                        pitch[1]=1920
>>                        offset[1]=2088960
>>                        obj[1]:
>>                                name=0
>>                                refcount=3
>>                                start=00000000
>>                                size=3657728
>>                                imported=yes
>>        crtc-pos=1920x1080+0+0
>>        src-pos=1920.000000x1080.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=1
>>        color-encoding=ITU-R BT.601 YCbCr
>>        color-range=YCbCr limited range
> 
> Video plane, rendered full screen above the base plane without alpha.
> 
>> plane[43]: Cluster0-win0
>>        crtc=(null)
>>        fb=0
>>        crtc-pos=0x0+0+0
>>        src-pos=0.000000x0.000000+0.000000+0.000000
>>        rotation=1
>>        normalized-zpos=0
>>        color-encoding=ITU-R BT.601 YCbCr
>>        color-range=YCbCr limited range
> 
> Here should be the GUI, but this plane is not active.

I suspect this is because above DRI state report was with user-forced Qt vars.
This was because to get UI non-black screen.
I done this by request to provide DRI state with video playback. (to get playback I need UI to navigate)
By this DRI state report might misleading as i'm manually forcing Qt KMS_Index/Zpos. 

> 
> With this state I would expect to see a full screen video without
> anything on it. Is that the case? If yes, then fine.

yes. this is a case.
so this is fine.

So I think non-visible OSD issue is side effect of other, root cause issue: issue causing user to force Qt vars to get UI on VOP2

Context: (my view):

We have stack of 3 components interacting:
1.player (draws video to DRM plane)
2.Qt (draws UI to GL to DRM plane)
3.DRM (mixing planes+displaying) 

Stack coperation:
a. DRM reports available planes+attributes to player
b. player - accordingly to above report - sets Qt (KMS/Zpos, etc).
c. user starting player. player uses Qt for drawing UI 
d. user asks for playback
e. player draws (by Qt) OSD  and directly video (accordingly to Qt setup in (b)

With VOP2 i have issue at (c): screen is black.
Above procedure works fully automated on all other platforms i have/supporting. 

For me most probable hypothesis:

1\
- In steep (b) Qt is set (or configured to use DRM) in way that UI resulting with black screen
- this is because in (a) player receives (wrong?) DRM report - and by this Qt is wrongly set
This may explain we have issue at (c)

2\
- In steep (b) Qt is set & using DRM in way that UI should work ok
- but VOP2 draws black screen (by some reason)
This may explain we have issue at (c)


Alternative hypothesis:
DRM properly realises (a)
Player wrongly realises (b)
This hypothesis is way less probable (for me) because:
1. procedure (a)...(e) works well on all other SoC. No need from user to overwrite automatically detected/set of Qt vars.
2. vop2 is single requiring from user overwrite of autodetected Qt vars. to get non-black screen UI.

I'm a bit out of ideas how to progress with this.

As (a)...(e) concept works ok (and afaik also is used by other players exploiting DRM planes rendering) - i'm not sure should I play with (b) because of VOP2 black-screen?


   
BTW:
this is DRI state when there is no any Qt.vars overwrites.
(so all is autodetected/setup like in other  working SoCs; VOP2 gives here black screen UI):

2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1

plane[31]: Smart0-win0
        crtc=video_port0
        fb=53
                allocated by = [fbcon]
                refcount=2
                format=XR24 little-endian (0x34325258)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=7680
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=3
                                start=00000000
                                size=8294400
                                imported=no
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[37]: Esmart0-win0
        crtc=(null)
        fb=0
        crtc-pos=0x0+0+0
        src-pos=0.000000x0.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
plane[43]: Cluster0-win0
        crtc=video_port0
        fb=58
                allocated by = mythfrontend
                refcount=2
                format=AR24 little-endian (0x34325241)
                modifier=0x0
                size=1920x1080
                layers:
                        size[0]=1920x1080
                        pitch[0]=7680
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=4
                                start=00000000
                                size=8294400
                                imported=no
        crtc-pos=1920x1080+0+0
        src-pos=1920.000000x1080.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=1
        color-encoding=ITU-R BT.601 YCbCr
        color-range=YCbCr limited range
crtc[49]: video_port0
        enable=1
        active=1
        self_refresh_active=0
        planes_changed=1
        mode_changed=0
        active_changed=0
        connectors_changed=0
        color_mgmt_changed=0
        plane_mask=5
        connector_mask=1
        encoder_mask=1
        mode: "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
connector[51]: HDMI-A-1
        crtc=video_port0
        self_refresh_aware=0  




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> this is DRI state when there is no any Qt.vars overwrites.
> (so all is autodetected/setup like in other  working SoCs; VOP2 gives here black screen UI):
> 
> 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
> 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
> 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
> 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
> 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
> 
> plane[31]: Smart0-win0
>         crtc=video_port0
>         fb=53
>                 allocated by = [fbcon]
>                 refcount=2
>                 format=XR24 little-endian (0x34325258)
>                 modifier=0x0
>                 size=1920x1080
>                 layers:
>                         size[0]=1920x1080
>                         pitch[0]=7680
>                         offset[0]=0
>                         obj[0]:
>                                 name=0
>                                 refcount=3
>                                 start=00000000
>                                 size=8294400
>                                 imported=no
>         crtc-pos=1920x1080+0+0
>         src-pos=1920.000000x1080.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range
> plane[37]: Esmart0-win0
>         crtc=(null)
>         fb=0
>         crtc-pos=0x0+0+0
>         src-pos=0.000000x0.000000+0.000000+0.000000
>         rotation=1
>         normalized-zpos=0
>         color-encoding=ITU-R BT.601 YCbCr
>         color-range=YCbCr limited range
> plane[43]: Cluster0-win0
>         crtc=video_port0
>         fb=58
>                 allocated by = mythfrontend
>                 refcount=2
>                 format=AR24 little-endian (0x34325241)

Here is your problem. The cluster windows only allow AFBC compressed
formats. AR24 is supported by the cluster windows, but not by the GPU,
see panfrost_afbc_format() in Mesa:

> enum pipe_format
> panfrost_afbc_format(const struct panfrost_device *dev, enum pipe_format format)
> {
>         /* Don't allow swizzled formats on v7 */
>         switch (format) {
>         case PIPE_FORMAT_B8G8R8A8_UNORM:
>         case PIPE_FORMAT_B8G8R8X8_UNORM:
>         case PIPE_FORMAT_A8R8G8B8_UNORM:
>         case PIPE_FORMAT_X8R8G8B8_UNORM:
>         case PIPE_FORMAT_X8B8G8R8_UNORM:
>         case PIPE_FORMAT_A8B8G8R8_UNORM:
>         case PIPE_FORMAT_B8G8R8_UNORM:
>         case PIPE_FORMAT_B5G6R5_UNORM:
>                 if (dev->arch >= 7)
>                         return PIPE_FORMAT_NONE;
> 
>                 break;
>         default:
>                 break;
>         }
> 

Somehow negotiation of the format goes wrong. Applications shouldn't
pick these formats when the GPU is used for rendering. I don't know how
and where this should be fixed properly, but your application should use
DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.

Could you try the following patch? It removed the formats in question
from the list of supported formats in the hope that your application
then picks one of the supported formats.

Sascha

-----------------------8<-----------------------------

From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 12 Apr 2022 09:42:32 +0200
Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver

The cluster windows only allow AFBC compressed formats. Not all of the
offered formats are supported by the GPU though. Applications pick one
of the formats and assume that this is also supported by the GPU they
use to render on them, but this is not the case for all formats.
Particularly DRM_FORMAT_XRGB8888 and DRM_FORMAT_ARGB8888 are not
supported by the GPU and choosing them results in a black screen.
Drop these formats for now.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 9bf0637bf8e26..38412766e3659 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -16,8 +16,6 @@
 #include "rockchip_drm_vop2.h"
 
 static const uint32_t formats_win_full_10bit[] = {
-	DRM_FORMAT_XRGB8888,
-	DRM_FORMAT_ARGB8888,
 	DRM_FORMAT_XBGR8888,
 	DRM_FORMAT_ABGR8888,
 	DRM_FORMAT_RGB888,
-- 
2.30.2


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Lucas Stach]

Am Dienstag, dem 12.04.2022 um 09:50 +0200 schrieb Sascha Hauer:
> On Mon, Apr 11, 2022 at 01:07:56PM +0200, Piotr Oniszczuk wrote:
> > this is DRI state when there is no any Qt.vars overwrites.
> > (so all is autodetected/setup like in other  working SoCs; VOP2 gives here black screen UI):
> > 
> > 2022-04-08 17:47:57.035668 I /dev/dri/card0 Qt EGLFS/KMS Fd:5 Crtc id:49 Connector id:51 Atomic: 1
> > 2022-04-08 17:47:57.035806 I /dev/dri/card0: Authenticated
> > 2022-04-08 17:47:57.145447 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
> > 2022-04-08 17:47:57.145469 I /dev/dri/card0: Selected Plane #37 Overlay for video
> > 2022-04-08 17:47:57.145515 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
> > 2022-04-08 17:47:57.145523 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
> > 2022-04-08 17:47:57.145567 I /dev/dri/card0: DRM device retrieved from Qt
> > 2022-04-08 17:47:57.145574 I /dev/dri/card0: Multi-plane setup: Requested: 1 Setup: 1
> > 
> > plane[31]: Smart0-win0
> >         crtc=video_port0
> >         fb=53
> >                 allocated by = [fbcon]
> >                 refcount=2
> >                 format=XR24 little-endian (0x34325258)
> >                 modifier=0x0
> >                 size=1920x1080
> >                 layers:
> >                         size[0]=1920x1080
> >                         pitch[0]=7680
> >                         offset[0]=0
> >                         obj[0]:
> >                                 name=0
> >                                 refcount=3
> >                                 start=00000000
> >                                 size=8294400
> >                                 imported=no
> >         crtc-pos=1920x1080+0+0
> >         src-pos=1920.000000x1080.000000+0.000000+0.000000
> >         rotation=1
> >         normalized-zpos=0
> >         color-encoding=ITU-R BT.601 YCbCr
> >         color-range=YCbCr limited range
> > plane[37]: Esmart0-win0
> >         crtc=(null)
> >         fb=0
> >         crtc-pos=0x0+0+0
> >         src-pos=0.000000x0.000000+0.000000+0.000000
> >         rotation=1
> >         normalized-zpos=0
> >         color-encoding=ITU-R BT.601 YCbCr
> >         color-range=YCbCr limited range
> > plane[43]: Cluster0-win0
> >         crtc=video_port0
> >         fb=58
> >                 allocated by = mythfrontend
> >                 refcount=2
> >                 format=AR24 little-endian (0x34325241)
> 
> Here is your problem. The cluster windows only allow AFBC compressed
> formats. AR24 is supported by the cluster windows, but not by the GPU,
> see panfrost_afbc_format() in Mesa:
> 
> > enum pipe_format
> > panfrost_afbc_format(const struct panfrost_device *dev, enum pipe_format format)
> > {
> >         /* Don't allow swizzled formats on v7 */
> >         switch (format) {
> >         case PIPE_FORMAT_B8G8R8A8_UNORM:
> >         case PIPE_FORMAT_B8G8R8X8_UNORM:
> >         case PIPE_FORMAT_A8R8G8B8_UNORM:
> >         case PIPE_FORMAT_X8R8G8B8_UNORM:
> >         case PIPE_FORMAT_X8B8G8R8_UNORM:
> >         case PIPE_FORMAT_A8B8G8R8_UNORM:
> >         case PIPE_FORMAT_B8G8R8_UNORM:
> >         case PIPE_FORMAT_B5G6R5_UNORM:
> >                 if (dev->arch >= 7)
> >                         return PIPE_FORMAT_NONE;
> > 
> >                 break;
> >         default:
> >                 break;
> >         }
> > 
> 
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
> 
This could be both a Mesa/Panfrost or application issue. The
application is supposed to try to allocate with a arbitrary chosen
format and the valid modifiers queried from the plane it wants to put
the surface on. However I'm not sure if all applications have a
fallback path in place to try another format swizzling if the surface
allocation fails. Now there are two possible failures here:

1. The application feeds a wrong modifier list to the GBM
implementation, as it may have queried another plane in the assumption
that supported modifiers are uniform across all planes.

2. The GBM implementation (Panfrost) actually allocates a surface
instead of failing the allocation, even if it does not support any
combination of the provided format and modifier list.

Regards,
Lucas

> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
> 
> Sascha
> 
> -----------------------8<-----------------------------
> 
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> The cluster windows only allow AFBC compressed formats. Not all of the
> offered formats are supported by the GPU though. Applications pick one
> of the formats and assume that this is also supported by the GPU they
> use to render on them, but this is not the case for all formats.
> Particularly DRM_FORMAT_XRGB8888 and DRM_FORMAT_ARGB8888 are not
> supported by the GPU and choosing them results in a black screen.
> Drop these formats for now.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 9bf0637bf8e26..38412766e3659 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,8 +16,6 @@
>  #include "rockchip_drm_vop2.h"
>  
>  static const uint32_t formats_win_full_10bit[] = {
> -	DRM_FORMAT_XRGB8888,
> -	DRM_FORMAT_ARGB8888,
>  	DRM_FORMAT_XBGR8888,
>  	DRM_FORMAT_ABGR8888,
>  	DRM_FORMAT_RGB888,
> -- 
> 2.30.2
> 
> 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Lucas Stach <l.stach@pengutronix.de> w dniu 12.04.2022, o godz. 10:10:
> 
> This could be both a Mesa/Panfrost or application issue. The
> application is supposed to try to allocate with a arbitrary chosen
> format and the valid modifiers queried from the plane it wants to put
> the surface on. However I'm not sure if all applications have a
> fallback path in place to try another format swizzling if the surface
> allocation fails.

This is good remark imho.
I think we have this fallback.
I'll try verify this.

Generalising a bit - I think we my consider following cases:

a\ format is correctly negotiated and signalled to consumer/provider but we don't see expected results (=correct screen seen by user)
b\ format was correctly negotiated but consumer/provider failed using signalled format (i.e. due bug in implementation)
c\ consumer or provider advertising - in reality unsupported format (false positive) - so negotiation resulting with signalling efficiently non-working format
  
Sascha says (in today's email):

"Here is your problem. The cluster windows only allow AFBC compressed
formats. AR24 is supported by the cluster windows, but not by the GPU,
see panfrost_afbc_format() in Mesa:"

I'm reading this as case c\ as Sascha said "negotiated format is not supported by GPU" ....but this format was negotiated.

......but for sure Sascha is much better than me here in subject - so i'm might be wrong here
    

> Now there are two possible failures here:
> 
> 1. The application feeds a wrong modifier list to the GBM
> implementation, as it may have queried another plane in the assumption
> that supported modifiers are uniform across all planes.
> 

This will be cardinal design error.
(keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM planes)
  

> 2. The GBM implementation (Panfrost) actually allocates a surface
> instead of failing the allocation, even if it does not support any
> combination of the provided format and modifier list.
> 

Testing Sacha patch (see today's email from Sascha) i'm getting

Qt: EGL Error : Could not create the egl surface: error = 0x3009

i'm reading this as: Qt tries allocate EGL surface and EGL returns error.

or i'm wrong?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Daniel Stone]

On Tue, 12 Apr 2022 at 11:14, Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Lucas Stach <l.stach@pengutronix.de> w dniu 12.04.2022, o godz. 10:10:
> > 1. The application feeds a wrong modifier list to the GBM
> > implementation, as it may have queried another plane in the assumption
> > that supported modifiers are uniform across all planes.
>
> This will be cardinal design error.
> (keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM planes)
>
>
> > 2. The GBM implementation (Panfrost) actually allocates a surface
> > instead of failing the allocation, even if it does not support any
> > combination of the provided format and modifier list.
>
> Testing Sacha patch (see today's email from Sascha) i'm getting
>
> Qt: EGL Error : Could not create the egl surface: error = 0x3009
>
> i'm reading this as: Qt tries allocate EGL surface and EGL returns error.
> or i'm wrong?

Correct, that's EGL_BAD_MATCH. There are very few ways that can
happen; by far the most likely is that Qt has chosen an EGLConfig
which does not correctly correspond to the format. (If it was an
impossible format/modifier combination, then this would be already
caught when allocating the gbm_surface.)

Either way, it seems quite clear that the VOP2 driver is totally fine
here, and that you have a Qt (likely) or Mesa (tbh less likely) issue
to debug to get the app working.

Cheers,
Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Daniel Stone <daniel@fooishbar.org> w dniu 12.04.2022, o godz. 13:30:
> 
>> Testing Sacha patch (see today's email from Sascha) i'm getting
>> 
>> Qt: EGL Error : Could not create the egl surface: error = 0x3009
>> 
>> i'm reading this as: Qt tries allocate EGL surface and EGL returns error.
>> or i'm wrong?
> 
> Correct, that's EGL_BAD_MATCH. There are very few ways that can
> happen; by far the most likely is that Qt has chosen an EGLConfig
> which does not correctly correspond to the format. (If it was an
> impossible format/modifier combination, then this would be already
> caught when allocating the gbm_surface.)
> 
> Either way, it seems quite clear that the VOP2 driver is totally fine
> here, and that you have a Qt (likely) or Mesa (tbh less likely) issue
> to debug to get the app working.
> 
> Cheers,
> Daniel

Thx Daniel!

Indeed - this is probably another case where I see: writing DRM planes rendering mediaplayer with help of Qt is (too)corner case for Qt....


@all

Looking on Qt sources it looks to me this format should be supported:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/kmsconvenience/qkmsdevice.cpp?h=5.15.2#n380

Interesting that with custom Qt config1: "format": "argb8888",
DRI state shows: format=AR24 little-endian (0x34325241)

UI is OK, playback is OK. OSD not visible (*)

custom config2: "format": "abgr8888" 
Qt crashes with EGL_BAD_MATCH

So it looks forcing some Qt formats works while other - not. 

Looking why this:

Qt logging says nothing.
export MESA_DEBUG=1 gives no any message. I'm a lost here a bit...



But from a bit more distant perspective:

1. Sascha concludes in (*) that issue is most probably in format negotiation by app.

2. imho app probably correctly negotiates accordingly to inputs it gets from providers (DRM) and clients (mesa). 
Test with patch excluding
DRM_FORMAT_XRGB8888,
DRM_FORMAT_ARGB8888,
shows imho proper app reaction on this (new format elected; but Qt fails with this format). Indirectly i conclude app logic is ok....

3. Sum of p1 & p2 tells me:
i need to add extra logic in format election to specifically deal with constrains of rk356x (see explanation in (*))
    
4. Even if i implement p3 - then user world - (this using Qt) - will be not happy as:
- majority users are using pre-build Qt
- I don't believe Trolltech will fix this soon

So i see following path:
  
we will verify is issue of Qt with abgr8888 an Qt root cause issue,

If Yes - then:
	- Investigate is there reasonable way to workaround with this outside of Qt?
If not - then:
	- conclude: vop2 - due Qt bug - will not work ok with Qt until Qt will be fixed.

 
If you think this make sense - i need some help with: verify is issue of Qt with abgr8888 an Qt root cause issue

let me know what you think



(*)
Sascha mentioned:
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Daniel Stone]

Hi Piotr,

On Fri, 15 Apr 2022 at 12:11, Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote:
> Looking on Qt sources it looks to me this format should be supported:
>
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/kmsconvenience/qkmsdevice.cpp?h=5.15.2#n380
>
> Interesting that with custom Qt config1: "format": "argb8888",
> DRI state shows: format=AR24 little-endian (0x34325241)
>
> UI is OK, playback is OK. OSD not visible (*)
>
> custom config2: "format": "abgr8888"
> Qt crashes with EGL_BAD_MATCH
>
> So it looks forcing some Qt formats works while other - not.
>
> Looking why this:
>
> Qt logging says nothing.
> export MESA_DEBUG=1 gives no any message. I'm a lost here a bit...

I bet if you dumped the gbm_surface format (passed by Qt as a
parameter to gbm_surface_create_with_modifiers or gbm_surface_create)
and the EGLConfig's EGL_NATIVE_VISUAL_ID (from eglQueryConfig), you
would see that the format tokens are different. Which is a Qt coding
error.

> But from a bit more distant perspective:
>
> 1. Sascha concludes in (*) that issue is most probably in format negotiation by app.
>
> 2. imho app probably correctly negotiates accordingly to inputs it gets from providers (DRM) and clients (mesa).
> Test with patch excluding
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> shows imho proper app reaction on this (new format elected; but Qt fails with this format). Indirectly i conclude app logic is ok....
>
> 3. Sum of p1 & p2 tells me:
> i need to add extra logic in format election to specifically deal with constrains of rk356x (see explanation in (*))

I disagree. I looked at a clone of Qt, and I could not see a coherent
path that ensured that the gbm_surface format chosen by Qt matched the
EGLConfig format used on that EGLSurface. A mismatch is an error.

There are some workarounds allowing you to specify a format, however
those only work by coincidence sometimes. Even with the explicit
format specification, Qt never makes any attempt to match gbm_surface
and EGLConfig formats; it just hopes that they will match by
coincidence.

There is no additional complexity or strangeness that RK356x is
introducing here. It only works by pure luck on other platforms.

> 4. Even if i implement p3 - then user world - (this using Qt) - will be not happy as:
> - majority users are using pre-build Qt
> - I don't believe Trolltech will fix this soon
>
> So i see following path:
>
> we will verify is issue of Qt with abgr8888 an Qt root cause issue,
>
> If Yes - then:
>         - Investigate is there reasonable way to workaround with this outside of Qt?
> If not - then:
>         - conclude: vop2 - due Qt bug - will not work ok with Qt until Qt will be fixed.
>
>
> If you think this make sense - i need some help with: verify is issue of Qt with abgr8888 an Qt root cause issue

Unfortunately there is no reasonable workaround outside of Qt. Looking
at the Qt/QPA source tree, it looks like the usual way of 'fixing'
this is to hack platform specific configuration into the Qt backend.
If Qt won't be fixed to use generic APIs correctly, then I guess your
best option is to just hack up yet another platform-specific backend.
Which is a shame, but there is no reasonable workaround we can do in
low-level code for toolkits doing the wrong thing and hoping it works.

Cheers,
Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Piotr Oniszczuk]

> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 12.04.2022, o godz. 09:50:
> 
> 
> Somehow negotiation of the format goes wrong. Applications shouldn't
> pick these formats when the GPU is used for rendering. I don't know how
> and where this should be fixed properly, but your application should use
> DRM_FORMAT_ABGR8888 aka AB24 aka PIPE_FORMAT_R8G8B8A8_UNORM instead of
> DRM_FORMAT_ARGB8888 aka AR24 aka PIPE_FORMAT_B8G8R8A8_UNORM.
> 
Applied :-)
Results: pls see below

> Could you try the following patch? It removed the formats in question
> from the list of supported formats in the hope that your application
> then picks one of the supported formats.
> 
> Sascha
> 
> -----------------------8<-----------------------------
> 
> From 7427109cfd16803902b55cd5536b9212abd09665 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Tue, 12 Apr 2022 09:42:32 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> 
> The cluster windows only allow AFBC compressed formats. Not all of the
> offered formats are supported by the GPU though. Applications pick one
> of the formats and assume that this is also supported by the GPU they
> use to render on them, but this is not the case for all formats.
> Particularly DRM_FORMAT_XRGB8888 and DRM_FORMAT_ARGB8888 are not
> supported by the GPU and choosing them results in a black screen.
> Drop these formats for now.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 9bf0637bf8e26..38412766e3659 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,8 +16,6 @@
> #include "rockchip_drm_vop2.h"
> 
> static const uint32_t formats_win_full_10bit[] = {
> -	DRM_FORMAT_XRGB8888,
> -	DRM_FORMAT_ARGB8888,
> 	DRM_FORMAT_XBGR8888,
> 	DRM_FORMAT_ABGR8888,
> 	DRM_FORMAT_RGB888,
> -- 
> 

With above patch app select expected format (i think):

1970-01-01 01:00:31.074643 I /dev/dri/card0: Authenticated
1970-01-01 01:00:31.189420 I /dev/dri/card0: Found 3 planes; 3 for this CRTC
1970-01-01 01:00:31.189444 I /dev/dri/card0: Selected Plane #37 Overlay for video
1970-01-01 01:00:31.189528 I /dev/dri/card0: Supported DRM video formats: NV12,NV16,NV24,YVYU,VYUY
1970-01-01 01:00:31.189536 I /dev/dri/card0: Selected Plane #43 Overlay for GUI
1970-01-01 01:00:31.190279 I Wrote /home/minimyth/.mythtv/eglfs_kms_config.json: 
{
"device": "/dev/dri/card0",
"outputs": [ { "name": "HDMI1", "format": "abgr8888", "mode": "current" } ]
}

(file eglfs_kms_config.json is generated by app to configure Qt; it is steep (b) in yesterday's email) 
I see format abgr8888 is now selected by app (this is expected t think)



but later Qt says:

1970-01-01 01:00:34.985215 I Qt: EGL Error : Could not create the egl surface: error = 0x3009
Handling Aborted
Aborted
 
I suspect Qt tries with this format talk to GLES provider - but it wasn't somehow accepted by underlying EGL provider (mesa GLES)?



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Andy Yan]

Hi Sacha:

On 4/1/22 20:52, Sascha Hauer wrote:
> -- 
> >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer<s.hauer@pengutronix.de>
> Date: Fri, 1 Apr 2022 14:48:49 +0200
> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 7dba7b9b63dc6..1421bf2f133f1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
>   			}
>   		}
>   
> +		if (vop2->data->soc_id == 3566) {
> +			/*
> +			 * On RK3566 these windows don't have an independent
> +			 * framebuffer. They share the framebuffer with smart0,
> +			 * esmart0 and cluster0 respectively.
> +			 */
> +			switch (win->data->phys_id) {
> +			case ROCKCHIP_VOP2_SMART1:
> +			case ROCKCHIP_VOP2_ESMART1:
> +			case ROCKCHIP_VOP2_CLUSTER1:
> +				continue;
> +			}


Think about this , there maybe other upcoming vop2 base soc, they may 
only have

mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.

I think this should add WIN_FEATURE at the platform description file 
rockchip_vop2_reg.c, then

check the FEATURE to decide whether the driver should give this window a 
special treatment.

this can make one code run for different soc with different platform 
description. or we should add

the same code logic for different soc again and again.

> +		}
> +
>   		if (win->type == DRM_PLANE_TYPE_OVERLAY)
>   			possible_crtcs = (1 << nvps) - 1;
>   

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/1/22 20:52, Sascha Hauer wrote:
> > -- 
> > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> > From: Sascha Hauer<s.hauer@pengutronix.de>
> > Date: Fri, 1 Apr 2022 14:48:49 +0200
> > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> > 
> > ---
> >   drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> >   1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index 7dba7b9b63dc6..1421bf2f133f1 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> >   			}
> >   		}
> > +		if (vop2->data->soc_id == 3566) {
> > +			/*
> > +			 * On RK3566 these windows don't have an independent
> > +			 * framebuffer. They share the framebuffer with smart0,
> > +			 * esmart0 and cluster0 respectively.
> > +			 */
> > +			switch (win->data->phys_id) {
> > +			case ROCKCHIP_VOP2_SMART1:
> > +			case ROCKCHIP_VOP2_ESMART1:
> > +			case ROCKCHIP_VOP2_CLUSTER1:
> > +				continue;
> > +			}
> 
> 
> Think about this , there maybe other upcoming vop2 base soc, they may only
> have
> 
> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
> 
> I think this should add WIN_FEATURE at the platform description file
> rockchip_vop2_reg.c, then
> 
> check the FEATURE to decide whether the driver should give this window a
> special treatment.
> 
> this can make one code run for different soc with different platform
> description. or we should add
> 
> the same code logic for different soc again and again.

You mean like done in the downstream Kernel? Here indeed we have a
WIN_FEATURE_MIRROR flag added to the platform description. This is then
evaluated with:

static bool vop2_is_mirror_win(struct vop2_win *win)
{
        return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
}

So a flag is added and afterwards its evaluation is SoC specific. That
doesn't help at all and only obfuscates things.

Besides, experience shows that you can't predict a good abstraction for
future hardware revisions, the hardware guys are just too creative in
creating hardware that breaks existing abstractions.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Andy Yan]

Hi:

On 4/5/22 17:37, Sascha Hauer wrote:
> On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
>> Hi Sacha:
>>
>> On 4/1/22 20:52, Sascha Hauer wrote:
>>> -- 
>>> >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
>>> From: Sascha Hauer<s.hauer@pengutronix.de>
>>> Date: Fri, 1 Apr 2022 14:48:49 +0200
>>> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>>>
>>> ---
>>>    drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
>>>    1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>> index 7dba7b9b63dc6..1421bf2f133f1 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
>>>    			}
>>>    		}
>>> +		if (vop2->data->soc_id == 3566) {
>>> +			/*
>>> +			 * On RK3566 these windows don't have an independent
>>> +			 * framebuffer. They share the framebuffer with smart0,
>>> +			 * esmart0 and cluster0 respectively.
>>> +			 */
>>> +			switch (win->data->phys_id) {
>>> +			case ROCKCHIP_VOP2_SMART1:
>>> +			case ROCKCHIP_VOP2_ESMART1:
>>> +			case ROCKCHIP_VOP2_CLUSTER1:
>>> +				continue;
>>> +			}
>>
>> Think about this , there maybe other upcoming vop2 base soc, they may only
>> have
>>
>> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
>>
>> I think this should add WIN_FEATURE at the platform description file
>> rockchip_vop2_reg.c, then
>>
>> check the FEATURE to decide whether the driver should give this window a
>> special treatment.
>>
>> this can make one code run for different soc with different platform
>> description. or we should add
>>
>> the same code logic for different soc again and again.
> You mean like done in the downstream Kernel? Here indeed we have a
> WIN_FEATURE_MIRROR flag added to the platform description. This is then
> evaluated with:
>
> static bool vop2_is_mirror_win(struct vop2_win *win)
> {
>          return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
> }
>
> So a flag is added and afterwards its evaluation is SoC specific. That
> doesn't help at all and only obfuscates things.
>
> Besides, experience shows that you can't predict a good abstraction for

This is not a  predict,  this is an IP feature, so it will appeared on 
upcoming SOC.

We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and

also have a entry level soc which only have 4 windows, they both have 
this feature.

> future hardware revisions, the hardware guys are just too creative in
> creating hardware that breaks existing abstractions.
>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote:
> Hi:
> 
> On 4/5/22 17:37, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
> > > Hi Sacha:
> > > 
> > > On 4/1/22 20:52, Sascha Hauer wrote:
> > > > -- 
> > > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> > > > From: Sascha Hauer<s.hauer@pengutronix.de>
> > > > Date: Fri, 1 Apr 2022 14:48:49 +0200
> > > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> > > > 
> > > > ---
> > > >    drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> > > >    1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > index 7dba7b9b63dc6..1421bf2f133f1 100644
> > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> > > >    			}
> > > >    		}
> > > > +		if (vop2->data->soc_id == 3566) {
> > > > +			/*
> > > > +			 * On RK3566 these windows don't have an independent
> > > > +			 * framebuffer. They share the framebuffer with smart0,
> > > > +			 * esmart0 and cluster0 respectively.
> > > > +			 */
> > > > +			switch (win->data->phys_id) {
> > > > +			case ROCKCHIP_VOP2_SMART1:
> > > > +			case ROCKCHIP_VOP2_ESMART1:
> > > > +			case ROCKCHIP_VOP2_CLUSTER1:
> > > > +				continue;
> > > > +			}
> > > 
> > > Think about this , there maybe other upcoming vop2 base soc, they may only
> > > have
> > > 
> > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
> > > 
> > > I think this should add WIN_FEATURE at the platform description file
> > > rockchip_vop2_reg.c, then
> > > 
> > > check the FEATURE to decide whether the driver should give this window a
> > > special treatment.
> > > 
> > > this can make one code run for different soc with different platform
> > > description. or we should add
> > > 
> > > the same code logic for different soc again and again.
> > You mean like done in the downstream Kernel? Here indeed we have a
> > WIN_FEATURE_MIRROR flag added to the platform description. This is then
> > evaluated with:
> > 
> > static bool vop2_is_mirror_win(struct vop2_win *win)
> > {
> >          return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
> > }
> > 
> > So a flag is added and afterwards its evaluation is SoC specific. That
> > doesn't help at all and only obfuscates things.
> > 
> > Besides, experience shows that you can't predict a good abstraction for
> 
> This is not a  predict,  this is an IP feature, so it will appeared on
> upcoming SOC.
> 
> We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and
> 
> also have a entry level soc which only have 4 windows, they both have this
> feature.

Same as with the other discussion: Please let's solve this once we are
there.
For now my addition is the easiest way out. Once other SoCs shall be
supported we can re-evaluate that and find better suitable ways for SoC
abstractions. This may result in just your suggestion (in which case you
can say told-you-so) or completely different.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Andy Yan]

Hi:

On 4/6/22 16:13, Sascha Hauer wrote:
> On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote:
>> Hi:
>>
>> On 4/5/22 17:37, Sascha Hauer wrote:
>>> On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
>>>> Hi Sacha:
>>>>
>>>> On 4/1/22 20:52, Sascha Hauer wrote:
>>>>> -- 
>>>>> >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
>>>>> From: Sascha Hauer<s.hauer@pengutronix.de>
>>>>> Date: Fri, 1 Apr 2022 14:48:49 +0200
>>>>> Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
>>>>>
>>>>> ---
>>>>>     drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
>>>>>     1 file changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>>>> index 7dba7b9b63dc6..1421bf2f133f1 100644
>>>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>>>>> @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
>>>>>     			}
>>>>>     		}
>>>>> +		if (vop2->data->soc_id == 3566) {
>>>>> +			/*
>>>>> +			 * On RK3566 these windows don't have an independent
>>>>> +			 * framebuffer. They share the framebuffer with smart0,
>>>>> +			 * esmart0 and cluster0 respectively.
>>>>> +			 */
>>>>> +			switch (win->data->phys_id) {
>>>>> +			case ROCKCHIP_VOP2_SMART1:
>>>>> +			case ROCKCHIP_VOP2_ESMART1:
>>>>> +			case ROCKCHIP_VOP2_CLUSTER1:
>>>>> +				continue;
>>>>> +			}
>>>> Think about this , there maybe other upcoming vop2 base soc, they may only
>>>> have
>>>>
>>>> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
>>>>
>>>> I think this should add WIN_FEATURE at the platform description file
>>>> rockchip_vop2_reg.c, then
>>>>
>>>> check the FEATURE to decide whether the driver should give this window a
>>>> special treatment.
>>>>
>>>> this can make one code run for different soc with different platform
>>>> description. or we should add
>>>>
>>>> the same code logic for different soc again and again.
>>> You mean like done in the downstream Kernel? Here indeed we have a
>>> WIN_FEATURE_MIRROR flag added to the platform description. This is then
>>> evaluated with:
>>>
>>> static bool vop2_is_mirror_win(struct vop2_win *win)
>>> {
>>>           return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
>>> }
>>>
>>> So a flag is added and afterwards its evaluation is SoC specific. That
>>> doesn't help at all and only obfuscates things.
>>>
>>> Besides, experience shows that you can't predict a good abstraction for
>> This is not a  predict,  this is an IP feature, so it will appeared on
>> upcoming SOC.
>>
>> We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and
>>
>> also have a entry level soc which only have 4 windows, they both have this
>> feature.
> Same as with the other discussion: Please let's solve this once we are
> there.


I am not sure if this is the suitable way for upstream, this sound like

just solve the issue appeared at the front of eyes and not think any

thing about make this driver easy to support new hardware in the future.

> For now my addition is the easiest way out. Once other SoCs shall be
> supported we can re-evaluate that and find better suitable ways for SoC
> abstractions. This may result in just your suggestion (in which case you
> can say told-you-so) or completely different.
>
> Sascha
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Wed, Apr 06, 2022 at 04:36:42PM +0800, Andy Yan wrote:
> Hi:
> 
> On 4/6/22 16:13, Sascha Hauer wrote:
> > On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote:
> > > Hi:
> > > 
> > > On 4/5/22 17:37, Sascha Hauer wrote:
> > > > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
> > > > > Hi Sacha:
> > > > > 
> > > > > On 4/1/22 20:52, Sascha Hauer wrote:
> > > > > > -- 
> > > > > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> > > > > > From: Sascha Hauer<s.hauer@pengutronix.de>
> > > > > > Date: Fri, 1 Apr 2022 14:48:49 +0200
> > > > > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> > > > > > 
> > > > > > ---
> > > > > >     drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> > > > > >     1 file changed, 14 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > index 7dba7b9b63dc6..1421bf2f133f1 100644
> > > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> > > > > >     			}
> > > > > >     		}
> > > > > > +		if (vop2->data->soc_id == 3566) {
> > > > > > +			/*
> > > > > > +			 * On RK3566 these windows don't have an independent
> > > > > > +			 * framebuffer. They share the framebuffer with smart0,
> > > > > > +			 * esmart0 and cluster0 respectively.
> > > > > > +			 */
> > > > > > +			switch (win->data->phys_id) {
> > > > > > +			case ROCKCHIP_VOP2_SMART1:
> > > > > > +			case ROCKCHIP_VOP2_ESMART1:
> > > > > > +			case ROCKCHIP_VOP2_CLUSTER1:
> > > > > > +				continue;
> > > > > > +			}
> > > > > Think about this , there maybe other upcoming vop2 base soc, they may only
> > > > > have
> > > > > 
> > > > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
> > > > > 
> > > > > I think this should add WIN_FEATURE at the platform description file
> > > > > rockchip_vop2_reg.c, then
> > > > > 
> > > > > check the FEATURE to decide whether the driver should give this window a
> > > > > special treatment.
> > > > > 
> > > > > this can make one code run for different soc with different platform
> > > > > description. or we should add
> > > > > 
> > > > > the same code logic for different soc again and again.
> > > > You mean like done in the downstream Kernel? Here indeed we have a
> > > > WIN_FEATURE_MIRROR flag added to the platform description. This is then
> > > > evaluated with:
> > > > 
> > > > static bool vop2_is_mirror_win(struct vop2_win *win)
> > > > {
> > > >           return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
> > > > }
> > > > 
> > > > So a flag is added and afterwards its evaluation is SoC specific. That
> > > > doesn't help at all and only obfuscates things.
> > > > 
> > > > Besides, experience shows that you can't predict a good abstraction for
> > > This is not a  predict,  this is an IP feature, so it will appeared on
> > > upcoming SOC.
> > > 
> > > We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and
> > > 
> > > also have a entry level soc which only have 4 windows, they both have this
> > > feature.
> > Same as with the other discussion: Please let's solve this once we are
> > there.
> 
> 
> I am not sure if this is the suitable way for upstream, this sound like
> 
> just solve the issue appeared at the front of eyes and not think any
> 
> thing about make this driver easy to support new hardware in the future.

Oh come on, we are not talking about any major design decisions here,
this is merely a small implementation detail that can be refactored
anytime.

I would change it when all it takes is to add a feature (or better:
nonfeature) flag to the window data, but the combination of the flag
*and* testing on which SoC the flag shall be honoured makes me feel
that the feature flag is still not the best abstraction.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel