* [PATCH RESEND v2 01/12] drm/bridge: move ANA78xx driver to analogix subdirectory
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick, Laurent Pinchart
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
---
drivers/gpu/drm/bridge/Kconfig | 10 ----------
drivers/gpu/drm/bridge/Makefile | 4 ++--
drivers/gpu/drm/bridge/analogix/Kconfig | 10 ++++++++++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h | 0
6 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..4922c1ceffef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,16 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_ANALOGIX_ANX78XX
- tristate "Analogix ANX78XX bridge"
- select DRM_KMS_HELPER
- select REGMAP_I2C
- ---help---
- ANX78XX is an ultra-low Full-HD SlimPort transmitter
- designed for portable devices. The ANX78XX transforms
- the HDMI output of an application processor to MyDP
- or DisplayPort.
-
config DRM_CDNS_DSI
tristate "Cadence DPI/DSI bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..a6c7dd7727ea 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
@@ -12,8 +11,9 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index 80f286fa3a69..c4d343a2f04d 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,13 @@
+config DRM_ANALOGIX_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX78XX is an ultra-low Full-HD SlimPort transmitter
+ designed for portable devices. The ANX78XX transforms
+ the HDMI output of an application processor to MyDP
+ or DisplayPort.
+
config DRM_ANALOGIX_DP
tristate
depends on DRM
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index cd4010ba6890..ce1687e60975 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,2 +1,3 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 01/12] drm/bridge: move ANA78xx driver to analogix subdirectory
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
Cc: Laurent Pinchart
From: Icenowy Zheng <icenowy@aosc.io>
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/Kconfig | 10 ----------
drivers/gpu/drm/bridge/Makefile | 4 ++--
drivers/gpu/drm/bridge/analogix/Kconfig | 10 ++++++++++
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
.../gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h | 0
6 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (100%)
rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.h (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..4922c1ceffef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,16 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_ANALOGIX_ANX78XX
- tristate "Analogix ANX78XX bridge"
- select DRM_KMS_HELPER
- select REGMAP_I2C
- ---help---
- ANX78XX is an ultra-low Full-HD SlimPort transmitter
- designed for portable devices. The ANX78XX transforms
- the HDMI output of an application processor to MyDP
- or DisplayPort.
-
config DRM_CDNS_DSI
tristate "Cadence DPI/DSI bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..a6c7dd7727ea 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
@@ -12,8 +11,9 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index 80f286fa3a69..c4d343a2f04d 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,13 @@
+config DRM_ANALOGIX_ANX78XX
+ tristate "Analogix ANX78XX bridge"
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX78XX is an ultra-low Full-HD SlimPort transmitter
+ designed for portable devices. The ANX78XX transforms
+ the HDMI output of an application processor to MyDP
+ or DisplayPort.
+
config DRM_ANALOGIX_DP
tristate
depends on DRM
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index cd4010ba6890..ce1687e60975 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,2 +1,3 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.c
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
similarity index 100%
rename from drivers/gpu/drm/bridge/analogix-anx78xx.h
rename to drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 02/12] drm/bridge: split some definitions of ANX78xx to dedicated headers
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Some definitions currently in analogix-anx78xx.h are not restricted to
the ANX78xx series, but also applicable to other DisplayPort
transmitters by Analogix.
Split out them to dedicated headers, and make analogix-anx78xx.h include
them.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../drm/bridge/analogix/analogix-anx78xx.h | 464 +-----------------
.../drm/bridge/analogix/analogix-i2c-dptx.h | 248 ++++++++++
.../bridge/analogix/analogix-i2c-txcommon.h | 237 +++++++++
3 files changed, 490 insertions(+), 459 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
index 38753c870137..8aa1eca306d3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
@@ -15,9 +15,12 @@
#ifndef __ANX78xx_H
#define __ANX78xx_H
-#define TX_P0 0x70
+#include "analogix-i2c-dptx.h"
+#include "analogix-i2c-txcommon.h"
+
+#define TX_P0 ANALOGIX_I2C_DPTX
#define TX_P1 0x7a
-#define TX_P2 0x72
+#define TX_P2 ANALOGIX_I2C_TXCOMMON
#define RX_P0 0x7e
#define RX_P1 0x80
@@ -225,463 +228,6 @@
#define SP_CLEAR_AVMUTE BIT(4)
#define SP_SET_AVMUTE BIT(0)
-/***************************************************************/
-/* Register definition of device address 0x70 */
-/***************************************************************/
-
-/* HDCP Status Register */
-#define SP_TX_HDCP_STATUS_REG 0x00
-#define SP_AUTH_FAIL BIT(5)
-#define SP_AUTHEN_PASS BIT(1)
-
-/* HDCP Control Register 0 */
-#define SP_HDCP_CTRL0_REG 0x01
-#define SP_RX_REPEATER BIT(6)
-#define SP_RE_AUTH BIT(5)
-#define SP_SW_AUTH_OK BIT(4)
-#define SP_HARD_AUTH_EN BIT(3)
-#define SP_HDCP_ENC_EN BIT(2)
-#define SP_BKSV_SRM_PASS BIT(1)
-#define SP_KSVLIST_VLD BIT(0)
-/* HDCP Function Enabled */
-#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3))
-
-/* HDCP Receiver BSTATUS Register 0 */
-#define SP_HDCP_RX_BSTATUS0_REG 0x1b
-/* HDCP Receiver BSTATUS Register 1 */
-#define SP_HDCP_RX_BSTATUS1_REG 0x1c
-
-/* HDCP Embedded "Blue Screen" Content Registers */
-#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c
-#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d
-#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e
-
-/* HDCP Wait R0 Timing Register */
-#define SP_HDCP_WAIT_R0_TIME_REG 0x40
-
-/* HDCP Link Integrity Check Timer Register */
-#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41
-
-/* HDCP Repeater Ready Wait Timer Register */
-#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42
-
-/* HDCP Auto Timer Register */
-#define SP_HDCP_AUTO_TIMER_REG 0x51
-
-/* HDCP Key Status Register */
-#define SP_HDCP_KEY_STATUS_REG 0x5e
-
-/* HDCP Key Command Register */
-#define SP_HDCP_KEY_COMMAND_REG 0x5f
-#define SP_DISABLE_SYNC_HDCP BIT(2)
-
-/* OTP Memory Key Protection Registers */
-#define SP_OTP_KEY_PROTECT1_REG 0x60
-#define SP_OTP_KEY_PROTECT2_REG 0x61
-#define SP_OTP_KEY_PROTECT3_REG 0x62
-#define SP_OTP_PSW1 0xa2
-#define SP_OTP_PSW2 0x7e
-#define SP_OTP_PSW3 0xc6
-
-/* DP System Control Registers */
-#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1)
-/* Bits for DP System Control Register 2 */
-#define SP_CHA_STA BIT(2)
-/* Bits for DP System Control Register 3 */
-#define SP_HPD_STATUS BIT(6)
-#define SP_STRM_VALID BIT(2)
-/* Bits for DP System Control Register 4 */
-#define SP_ENHANCED_MODE BIT(3)
-
-/* DP Video Control Register */
-#define SP_DP_VIDEO_CTRL_REG 0x84
-#define SP_COLOR_F_MASK 0x06
-#define SP_COLOR_F_SHIFT 1
-#define SP_BPC_MASK 0xe0
-#define SP_BPC_SHIFT 5
-# define SP_BPC_6BITS 0x00
-# define SP_BPC_8BITS 0x01
-# define SP_BPC_10BITS 0x02
-# define SP_BPC_12BITS 0x03
-
-/* DP Audio Control Register */
-#define SP_DP_AUDIO_CTRL_REG 0x87
-#define SP_AUD_EN BIT(0)
-
-/* 10us Pulse Generate Timer Registers */
-#define SP_I2C_GEN_10US_TIMER0_REG 0x88
-#define SP_I2C_GEN_10US_TIMER1_REG 0x89
-
-/* Packet Send Control Register */
-#define SP_PACKET_SEND_CTRL_REG 0x90
-#define SP_AUD_IF_UP BIT(7)
-#define SP_AVI_IF_UD BIT(6)
-#define SP_MPEG_IF_UD BIT(5)
-#define SP_SPD_IF_UD BIT(4)
-#define SP_AUD_IF_EN BIT(3)
-#define SP_AVI_IF_EN BIT(2)
-#define SP_MPEG_IF_EN BIT(1)
-#define SP_SPD_IF_EN BIT(0)
-
-/* DP HDCP Control Register */
-#define SP_DP_HDCP_CTRL_REG 0x92
-#define SP_AUTO_EN BIT(7)
-#define SP_AUTO_START BIT(5)
-#define SP_LINK_POLLING BIT(1)
-
-/* DP Main Link Bandwidth Setting Register */
-#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0
-#define SP_LINK_BW_SET_MASK 0x1f
-#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
-
-/* DP Training Pattern Set Register */
-#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
-
-/* DP Lane 0 Link Training Control Register */
-#define SP_DP_LANE0_LT_CTRL_REG 0xa3
-#define SP_TX_SW_SET_MASK 0x1b
-#define SP_MAX_PRE_REACH BIT(5)
-#define SP_MAX_DRIVE_REACH BIT(4)
-#define SP_PRE_EMP_LEVEL1 BIT(3)
-#define SP_DRVIE_CURRENT_LEVEL1 BIT(0)
-
-/* DP Link Training Control Register */
-#define SP_DP_LT_CTRL_REG 0xa8
-#define SP_LT_ERROR_TYPE_MASK 0x70
-# define SP_LT_NO_ERROR 0x00
-# define SP_LT_AUX_WRITE_ERROR 0x01
-# define SP_LT_MAX_DRIVE_REACHED 0x02
-# define SP_LT_WRONG_LANE_COUNT_SET 0x03
-# define SP_LT_LOOP_SAME_5_TIME 0x04
-# define SP_LT_CR_FAIL_IN_EQ 0x05
-# define SP_LT_EQ_LOOP_5_TIME 0x06
-#define SP_LT_EN BIT(0)
-
-/* DP CEP Training Control Registers */
-#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9
-#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa
-
-/* DP Debug Register 1 */
-#define SP_DP_DEBUG1_REG 0xb0
-#define SP_DEBUG_PLL_LOCK BIT(4)
-#define SP_POLLING_EN BIT(1)
-
-/* DP Polling Control Register */
-#define SP_DP_POLLING_CTRL_REG 0xb4
-#define SP_AUTO_POLLING_DISABLE BIT(0)
-
-/* DP Link Debug Control Register */
-#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8
-#define SP_M_VID_DEBUG BIT(5)
-#define SP_NEW_PRBS7 BIT(4)
-#define SP_INSERT_ER BIT(1)
-#define SP_PRBS31_EN BIT(0)
-
-/* AUX Misc control Register */
-#define SP_AUX_MISC_CTRL_REG 0xbf
-
-/* DP PLL control Register */
-#define SP_DP_PLL_CTRL_REG 0xc7
-#define SP_PLL_RST BIT(6)
-
-/* DP Analog Power Down Register */
-#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8
-#define SP_CH0_PD BIT(0)
-
-/* DP Misc Control Register */
-#define SP_DP_MISC_CTRL_REG 0xcd
-#define SP_EQ_TRAINING_LOOP BIT(6)
-
-/* DP Extra I2C Device Address Register */
-#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce
-#define SP_I2C_STRETCH_DISABLE BIT(7)
-
-#define SP_I2C_EXTRA_ADDR 0x50
-
-/* DP Downspread Control Register 1 */
-#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0
-
-/* DP M Value Calculation Control Register */
-#define SP_DP_M_CALCULATION_CTRL_REG 0xd9
-#define SP_M_GEN_CLK_SEL BIT(0)
-
-/* AUX Channel Access Status Register */
-#define SP_AUX_CH_STATUS_REG 0xe0
-#define SP_AUX_STATUS 0x0f
-
-/* AUX Channel DEFER Control Register */
-#define SP_AUX_DEFER_CTRL_REG 0xe2
-#define SP_DEFER_CTRL_EN BIT(7)
-
-/* DP Buffer Data Count Register */
-#define SP_BUF_DATA_COUNT_REG 0xe4
-#define SP_BUF_DATA_COUNT_MASK 0x1f
-#define SP_BUF_CLR BIT(7)
-
-/* DP AUX Channel Control Register 1 */
-#define SP_DP_AUX_CH_CTRL1_REG 0xe5
-#define SP_AUX_TX_COMM_MASK 0x0f
-#define SP_AUX_LENGTH_MASK 0xf0
-#define SP_AUX_LENGTH_SHIFT 4
-
-/* DP AUX CH Address Register 0 */
-#define SP_AUX_ADDR_7_0_REG 0xe6
-
-/* DP AUX CH Address Register 1 */
-#define SP_AUX_ADDR_15_8_REG 0xe7
-
-/* DP AUX CH Address Register 2 */
-#define SP_AUX_ADDR_19_16_REG 0xe8
-#define SP_AUX_ADDR_19_16_MASK 0x0f
-
-/* DP AUX Channel Control Register 2 */
-#define SP_DP_AUX_CH_CTRL2_REG 0xe9
-#define SP_AUX_SEL_RXCM BIT(6)
-#define SP_AUX_CHSEL BIT(3)
-#define SP_AUX_PN_INV BIT(2)
-#define SP_ADDR_ONLY BIT(1)
-#define SP_AUX_EN BIT(0)
-
-/* DP Video Stream Control InfoFrame Register */
-#define SP_DP_3D_VSC_CTRL_REG 0xea
-#define SP_INFO_FRAME_VSC_EN BIT(0)
-
-/* DP Video Stream Data Byte 1 Register */
-#define SP_DP_VSC_DB1_REG 0xeb
-
-/* DP AUX Channel Control Register 3 */
-#define SP_DP_AUX_CH_CTRL3_REG 0xec
-#define SP_WAIT_COUNTER_7_0_MASK 0xff
-
-/* DP AUX Channel Control Register 4 */
-#define SP_DP_AUX_CH_CTRL4_REG 0xed
-
-/* DP AUX Buffer Data Registers */
-#define SP_DP_BUF_DATA0_REG 0xf0
-
-/***************************************************************/
-/* Register definition of device address 0x72 */
-/***************************************************************/
-
-/*
- * Core Register Definitions
- */
-
-/* Device ID Low Byte Register */
-#define SP_DEVICE_IDL_REG 0x02
-
-/* Device ID High Byte Register */
-#define SP_DEVICE_IDH_REG 0x03
-
-/* Device version register */
-#define SP_DEVICE_VERSION_REG 0x04
-
-/* Power Down Control Register */
-#define SP_POWERDOWN_CTRL_REG 0x05
-#define SP_REGISTER_PD BIT(7)
-#define SP_HDCP_PD BIT(5)
-#define SP_AUDIO_PD BIT(4)
-#define SP_VIDEO_PD BIT(3)
-#define SP_LINK_PD BIT(2)
-#define SP_TOTAL_PD BIT(1)
-
-/* Reset Control Register 1 */
-#define SP_RESET_CTRL1_REG 0x06
-#define SP_MISC_RST BIT(7)
-#define SP_VIDCAP_RST BIT(6)
-#define SP_VIDFIF_RST BIT(5)
-#define SP_AUDFIF_RST BIT(4)
-#define SP_AUDCAP_RST BIT(3)
-#define SP_HDCP_RST BIT(2)
-#define SP_SW_RST BIT(1)
-#define SP_HW_RST BIT(0)
-
-/* Reset Control Register 2 */
-#define SP_RESET_CTRL2_REG 0x07
-#define SP_AUX_RST BIT(2)
-#define SP_SERDES_FIFO_RST BIT(1)
-#define SP_I2C_REG_RST BIT(0)
-
-/* Video Control Register 1 */
-#define SP_VID_CTRL1_REG 0x08
-#define SP_VIDEO_EN BIT(7)
-#define SP_VIDEO_MUTE BIT(2)
-#define SP_DE_GEN BIT(1)
-#define SP_DEMUX BIT(0)
-
-/* Video Control Register 2 */
-#define SP_VID_CTRL2_REG 0x09
-#define SP_IN_COLOR_F_MASK 0x03
-#define SP_IN_YC_BIT_SEL BIT(2)
-#define SP_IN_BPC_MASK 0x70
-#define SP_IN_BPC_SHIFT 4
-# define SP_IN_BPC_12BIT 0x03
-# define SP_IN_BPC_10BIT 0x02
-# define SP_IN_BPC_8BIT 0x01
-# define SP_IN_BPC_6BIT 0x00
-#define SP_IN_D_RANGE BIT(7)
-
-/* Video Control Register 3 */
-#define SP_VID_CTRL3_REG 0x0a
-#define SP_HPD_OUT BIT(6)
-
-/* Video Control Register 5 */
-#define SP_VID_CTRL5_REG 0x0c
-#define SP_CSC_STD_SEL BIT(7)
-#define SP_XVYCC_RNG_LMT BIT(6)
-#define SP_RANGE_Y2R BIT(5)
-#define SP_CSPACE_Y2R BIT(4)
-#define SP_RGB_RNG_LMT BIT(3)
-#define SP_Y_RNG_LMT BIT(2)
-#define SP_RANGE_R2Y BIT(1)
-#define SP_CSPACE_R2Y BIT(0)
-
-/* Video Control Register 6 */
-#define SP_VID_CTRL6_REG 0x0d
-#define SP_TEST_PATTERN_EN BIT(7)
-#define SP_VIDEO_PROCESS_EN BIT(6)
-#define SP_VID_US_MODE BIT(3)
-#define SP_VID_DS_MODE BIT(2)
-#define SP_UP_SAMPLE BIT(1)
-#define SP_DOWN_SAMPLE BIT(0)
-
-/* Video Control Register 8 */
-#define SP_VID_CTRL8_REG 0x0f
-#define SP_VID_VRES_TH BIT(0)
-
-/* Total Line Status Low Byte Register */
-#define SP_TOTAL_LINE_STAL_REG 0x24
-
-/* Total Line Status High Byte Register */
-#define SP_TOTAL_LINE_STAH_REG 0x25
-
-/* Active Line Status Low Byte Register */
-#define SP_ACT_LINE_STAL_REG 0x26
-
-/* Active Line Status High Byte Register */
-#define SP_ACT_LINE_STAH_REG 0x27
-
-/* Vertical Front Porch Status Register */
-#define SP_V_F_PORCH_STA_REG 0x28
-
-/* Vertical SYNC Width Status Register */
-#define SP_V_SYNC_STA_REG 0x29
-
-/* Vertical Back Porch Status Register */
-#define SP_V_B_PORCH_STA_REG 0x2a
-
-/* Total Pixel Status Low Byte Register */
-#define SP_TOTAL_PIXEL_STAL_REG 0x2b
-
-/* Total Pixel Status High Byte Register */
-#define SP_TOTAL_PIXEL_STAH_REG 0x2c
-
-/* Active Pixel Status Low Byte Register */
-#define SP_ACT_PIXEL_STAL_REG 0x2d
-
-/* Active Pixel Status High Byte Register */
-#define SP_ACT_PIXEL_STAH_REG 0x2e
-
-/* Horizontal Front Porch Status Low Byte Register */
-#define SP_H_F_PORCH_STAL_REG 0x2f
-
-/* Horizontal Front Porch Statys High Byte Register */
-#define SP_H_F_PORCH_STAH_REG 0x30
-
-/* Horizontal SYNC Width Status Low Byte Register */
-#define SP_H_SYNC_STAL_REG 0x31
-
-/* Horizontal SYNC Width Status High Byte Register */
-#define SP_H_SYNC_STAH_REG 0x32
-
-/* Horizontal Back Porch Status Low Byte Register */
-#define SP_H_B_PORCH_STAL_REG 0x33
-
-/* Horizontal Back Porch Status High Byte Register */
-#define SP_H_B_PORCH_STAH_REG 0x34
-
-/* InfoFrame AVI Packet DB1 Register */
-#define SP_INFOFRAME_AVI_DB1_REG 0x70
-
-/* Bit Control Specific Register */
-#define SP_BIT_CTRL_SPECIFIC_REG 0x80
-#define SP_BIT_CTRL_SELECT_SHIFT 1
-#define SP_ENABLE_BIT_CTRL BIT(0)
-
-/* InfoFrame Audio Packet DB1 Register */
-#define SP_INFOFRAME_AUD_DB1_REG 0x83
-
-/* InfoFrame MPEG Packet DB1 Register */
-#define SP_INFOFRAME_MPEG_DB1_REG 0xb0
-
-/* Audio Channel Status Registers */
-#define SP_AUD_CH_STATUS_BASE 0xd0
-
-/* Audio Channel Num Register 5 */
-#define SP_I2S_CHANNEL_NUM_MASK 0xe0
-# define SP_I2S_CH_NUM_1 (0x00 << 5)
-# define SP_I2S_CH_NUM_2 (0x01 << 5)
-# define SP_I2S_CH_NUM_3 (0x02 << 5)
-# define SP_I2S_CH_NUM_4 (0x03 << 5)
-# define SP_I2S_CH_NUM_5 (0x04 << 5)
-# define SP_I2S_CH_NUM_6 (0x05 << 5)
-# define SP_I2S_CH_NUM_7 (0x06 << 5)
-# define SP_I2S_CH_NUM_8 (0x07 << 5)
-#define SP_EXT_VUCP BIT(2)
-#define SP_VBIT BIT(1)
-#define SP_AUDIO_LAYOUT BIT(0)
-
-/* Analog Debug Register 2 */
-#define SP_ANALOG_DEBUG2_REG 0xdd
-#define SP_FORCE_SW_OFF_BYPASS 0x20
-#define SP_XTAL_FRQ 0x1c
-# define SP_XTAL_FRQ_19M2 (0x00 << 2)
-# define SP_XTAL_FRQ_24M (0x01 << 2)
-# define SP_XTAL_FRQ_25M (0x02 << 2)
-# define SP_XTAL_FRQ_26M (0x03 << 2)
-# define SP_XTAL_FRQ_27M (0x04 << 2)
-# define SP_XTAL_FRQ_38M4 (0x05 << 2)
-# define SP_XTAL_FRQ_52M (0x06 << 2)
-#define SP_POWERON_TIME_1P5MS 0x03
-
-/* Analog Control 0 Register */
-#define SP_ANALOG_CTRL0_REG 0xe1
-
-/* Common Interrupt Status Register 1 */
-#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1)
-#define SP_PLL_LOCK_CHG 0x40
-
-/* Common Interrupt Status Register 2 */
-#define SP_COMMON_INT_STATUS2 0xf2
-#define SP_HDCP_AUTH_CHG BIT(1)
-#define SP_HDCP_AUTH_DONE BIT(0)
-
-#define SP_HDCP_LINK_CHECK_FAIL BIT(0)
-
-/* Common Interrupt Status Register 4 */
-#define SP_COMMON_INT_STATUS4_REG 0xf4
-#define SP_HPD_IRQ BIT(6)
-#define SP_HPD_ESYNC_ERR BIT(4)
-#define SP_HPD_CHG BIT(2)
-#define SP_HPD_LOST BIT(1)
-#define SP_HPD_PLUG BIT(0)
-
-/* DP Interrupt Status Register */
-#define SP_DP_INT_STATUS1_REG 0xf7
-#define SP_TRAINING_FINISH BIT(5)
-#define SP_POLLING_ERR BIT(4)
-
-/* Common Interrupt Mask Register */
-#define SP_COMMON_INT_MASK_BASE (0xf8 - 1)
-
-#define SP_COMMON_INT_MASK4_REG 0xfb
-
-/* DP Interrupts Mask Register */
-#define SP_DP_INT_MASK1_REG 0xfe
-
-/* Interrupt Control Register */
-#define SP_INT_CTRL_REG 0xff
-
/***************************************************************/
/* Register definition of device address 0x7a */
/***************************************************************/
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
new file mode 100644
index 000000000000..bc0831b127bf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -0,0 +1,248 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
+ *
+ * Based on analogix-anx78xx.h, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#ifndef _ANALOGIX_I2C_DPTX_H_
+#define _ANALOGIX_I2C_DPTX_H_
+
+#define ANALOGIX_I2C_DPTX 0x70
+
+/***************************************************************/
+/* Register definition of device address 0x70 */
+/***************************************************************/
+
+/* HDCP Status Register */
+#define SP_TX_HDCP_STATUS_REG 0x00
+#define SP_AUTH_FAIL BIT(5)
+#define SP_AUTHEN_PASS BIT(1)
+
+/* HDCP Control Register 0 */
+#define SP_HDCP_CTRL0_REG 0x01
+#define SP_RX_REPEATER BIT(6)
+#define SP_RE_AUTH BIT(5)
+#define SP_SW_AUTH_OK BIT(4)
+#define SP_HARD_AUTH_EN BIT(3)
+#define SP_HDCP_ENC_EN BIT(2)
+#define SP_BKSV_SRM_PASS BIT(1)
+#define SP_KSVLIST_VLD BIT(0)
+/* HDCP Function Enabled */
+#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3))
+
+/* HDCP Receiver BSTATUS Register 0 */
+#define SP_HDCP_RX_BSTATUS0_REG 0x1b
+/* HDCP Receiver BSTATUS Register 1 */
+#define SP_HDCP_RX_BSTATUS1_REG 0x1c
+
+/* HDCP Embedded "Blue Screen" Content Registers */
+#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c
+#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d
+#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e
+
+/* HDCP Wait R0 Timing Register */
+#define SP_HDCP_WAIT_R0_TIME_REG 0x40
+
+/* HDCP Link Integrity Check Timer Register */
+#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41
+
+/* HDCP Repeater Ready Wait Timer Register */
+#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42
+
+/* HDCP Auto Timer Register */
+#define SP_HDCP_AUTO_TIMER_REG 0x51
+
+/* HDCP Key Status Register */
+#define SP_HDCP_KEY_STATUS_REG 0x5e
+
+/* HDCP Key Command Register */
+#define SP_HDCP_KEY_COMMAND_REG 0x5f
+#define SP_DISABLE_SYNC_HDCP BIT(2)
+
+/* OTP Memory Key Protection Registers */
+#define SP_OTP_KEY_PROTECT1_REG 0x60
+#define SP_OTP_KEY_PROTECT2_REG 0x61
+#define SP_OTP_KEY_PROTECT3_REG 0x62
+#define SP_OTP_PSW1 0xa2
+#define SP_OTP_PSW2 0x7e
+#define SP_OTP_PSW3 0xc6
+
+/* DP System Control Registers */
+#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1)
+/* Bits for DP System Control Register 2 */
+#define SP_CHA_STA BIT(2)
+/* Bits for DP System Control Register 3 */
+#define SP_HPD_STATUS BIT(6)
+#define SP_STRM_VALID BIT(2)
+/* Bits for DP System Control Register 4 */
+#define SP_ENHANCED_MODE BIT(3)
+
+/* DP Video Control Register */
+#define SP_DP_VIDEO_CTRL_REG 0x84
+#define SP_COLOR_F_MASK 0x06
+#define SP_COLOR_F_SHIFT 1
+#define SP_BPC_MASK 0xe0
+#define SP_BPC_SHIFT 5
+# define SP_BPC_6BITS 0x00
+# define SP_BPC_8BITS 0x01
+# define SP_BPC_10BITS 0x02
+# define SP_BPC_12BITS 0x03
+
+/* DP Audio Control Register */
+#define SP_DP_AUDIO_CTRL_REG 0x87
+#define SP_AUD_EN BIT(0)
+
+/* 10us Pulse Generate Timer Registers */
+#define SP_I2C_GEN_10US_TIMER0_REG 0x88
+#define SP_I2C_GEN_10US_TIMER1_REG 0x89
+
+/* Packet Send Control Register */
+#define SP_PACKET_SEND_CTRL_REG 0x90
+#define SP_AUD_IF_UP BIT(7)
+#define SP_AVI_IF_UD BIT(6)
+#define SP_MPEG_IF_UD BIT(5)
+#define SP_SPD_IF_UD BIT(4)
+#define SP_AUD_IF_EN BIT(3)
+#define SP_AVI_IF_EN BIT(2)
+#define SP_MPEG_IF_EN BIT(1)
+#define SP_SPD_IF_EN BIT(0)
+
+/* DP HDCP Control Register */
+#define SP_DP_HDCP_CTRL_REG 0x92
+#define SP_AUTO_EN BIT(7)
+#define SP_AUTO_START BIT(5)
+#define SP_LINK_POLLING BIT(1)
+
+/* DP Main Link Bandwidth Setting Register */
+#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0
+#define SP_LINK_BW_SET_MASK 0x1f
+#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
+
+/* DP Training Pattern Set Register */
+#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
+
+/* DP Lane 0 Link Training Control Register */
+#define SP_DP_LANE0_LT_CTRL_REG 0xa3
+#define SP_TX_SW_SET_MASK 0x1b
+#define SP_MAX_PRE_REACH BIT(5)
+#define SP_MAX_DRIVE_REACH BIT(4)
+#define SP_PRE_EMP_LEVEL1 BIT(3)
+#define SP_DRVIE_CURRENT_LEVEL1 BIT(0)
+
+/* DP Link Training Control Register */
+#define SP_DP_LT_CTRL_REG 0xa8
+#define SP_LT_ERROR_TYPE_MASK 0x70
+# define SP_LT_NO_ERROR 0x00
+# define SP_LT_AUX_WRITE_ERROR 0x01
+# define SP_LT_MAX_DRIVE_REACHED 0x02
+# define SP_LT_WRONG_LANE_COUNT_SET 0x03
+# define SP_LT_LOOP_SAME_5_TIME 0x04
+# define SP_LT_CR_FAIL_IN_EQ 0x05
+# define SP_LT_EQ_LOOP_5_TIME 0x06
+#define SP_LT_EN BIT(0)
+
+/* DP CEP Training Control Registers */
+#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9
+#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa
+
+/* DP Debug Register 1 */
+#define SP_DP_DEBUG1_REG 0xb0
+#define SP_DEBUG_PLL_LOCK BIT(4)
+#define SP_POLLING_EN BIT(1)
+
+/* DP Polling Control Register */
+#define SP_DP_POLLING_CTRL_REG 0xb4
+#define SP_AUTO_POLLING_DISABLE BIT(0)
+
+/* DP Link Debug Control Register */
+#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8
+#define SP_M_VID_DEBUG BIT(5)
+#define SP_NEW_PRBS7 BIT(4)
+#define SP_INSERT_ER BIT(1)
+#define SP_PRBS31_EN BIT(0)
+
+/* AUX Misc control Register */
+#define SP_AUX_MISC_CTRL_REG 0xbf
+
+/* DP PLL control Register */
+#define SP_DP_PLL_CTRL_REG 0xc7
+#define SP_PLL_RST BIT(6)
+
+/* DP Analog Power Down Register */
+#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8
+#define SP_CH0_PD BIT(0)
+
+/* DP Misc Control Register */
+#define SP_DP_MISC_CTRL_REG 0xcd
+#define SP_EQ_TRAINING_LOOP BIT(6)
+
+/* DP Extra I2C Device Address Register */
+#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce
+#define SP_I2C_STRETCH_DISABLE BIT(7)
+
+#define SP_I2C_EXTRA_ADDR 0x50
+
+/* DP Downspread Control Register 1 */
+#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0
+
+/* DP M Value Calculation Control Register */
+#define SP_DP_M_CALCULATION_CTRL_REG 0xd9
+#define SP_M_GEN_CLK_SEL BIT(0)
+
+/* AUX Channel Access Status Register */
+#define SP_AUX_CH_STATUS_REG 0xe0
+#define SP_AUX_STATUS 0x0f
+
+/* AUX Channel DEFER Control Register */
+#define SP_AUX_DEFER_CTRL_REG 0xe2
+#define SP_DEFER_CTRL_EN BIT(7)
+
+/* DP Buffer Data Count Register */
+#define SP_BUF_DATA_COUNT_REG 0xe4
+#define SP_BUF_DATA_COUNT_MASK 0x1f
+#define SP_BUF_CLR BIT(7)
+
+/* DP AUX Channel Control Register 1 */
+#define SP_DP_AUX_CH_CTRL1_REG 0xe5
+#define SP_AUX_TX_COMM_MASK 0x0f
+#define SP_AUX_LENGTH_MASK 0xf0
+#define SP_AUX_LENGTH_SHIFT 4
+
+/* DP AUX CH Address Register 0 */
+#define SP_AUX_ADDR_7_0_REG 0xe6
+
+/* DP AUX CH Address Register 1 */
+#define SP_AUX_ADDR_15_8_REG 0xe7
+
+/* DP AUX CH Address Register 2 */
+#define SP_AUX_ADDR_19_16_REG 0xe8
+#define SP_AUX_ADDR_19_16_MASK 0x0f
+
+/* DP AUX Channel Control Register 2 */
+#define SP_DP_AUX_CH_CTRL2_REG 0xe9
+#define SP_AUX_SEL_RXCM BIT(6)
+#define SP_AUX_CHSEL BIT(3)
+#define SP_AUX_PN_INV BIT(2)
+#define SP_ADDR_ONLY BIT(1)
+#define SP_AUX_EN BIT(0)
+
+/* DP Video Stream Control InfoFrame Register */
+#define SP_DP_3D_VSC_CTRL_REG 0xea
+#define SP_INFO_FRAME_VSC_EN BIT(0)
+
+/* DP Video Stream Data Byte 1 Register */
+#define SP_DP_VSC_DB1_REG 0xeb
+
+/* DP AUX Channel Control Register 3 */
+#define SP_DP_AUX_CH_CTRL3_REG 0xec
+#define SP_WAIT_COUNTER_7_0_MASK 0xff
+
+/* DP AUX Channel Control Register 4 */
+#define SP_DP_AUX_CH_CTRL4_REG 0xed
+
+/* DP AUX Buffer Data Registers */
+#define SP_DP_BUF_DATA0_REG 0xf0
+
+#endif
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
new file mode 100644
index 000000000000..7d683573e970
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -0,0 +1,237 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
+ *
+ * Based on analogix-anx78xx.h, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#ifndef _ANALOGIX_I2C_TXCOMMON_H_
+#define _ANALOGIX_I2C_TXCOMMON_H_
+
+#define ANALOGIX_I2C_TXCOMMON 0x72
+
+/***************************************************************/
+/* Register definition of device address 0x72 */
+/***************************************************************/
+
+/*
+ * Core Register Definitions
+ */
+
+/* Device ID Low Byte Register */
+#define SP_DEVICE_IDL_REG 0x02
+
+/* Device ID High Byte Register */
+#define SP_DEVICE_IDH_REG 0x03
+
+/* Device version register */
+#define SP_DEVICE_VERSION_REG 0x04
+
+/* Power Down Control Register */
+#define SP_POWERDOWN_CTRL_REG 0x05
+#define SP_REGISTER_PD BIT(7)
+#define SP_HDCP_PD BIT(5)
+#define SP_AUDIO_PD BIT(4)
+#define SP_VIDEO_PD BIT(3)
+#define SP_LINK_PD BIT(2)
+#define SP_TOTAL_PD BIT(1)
+
+/* Reset Control Register 1 */
+#define SP_RESET_CTRL1_REG 0x06
+#define SP_MISC_RST BIT(7)
+#define SP_VIDCAP_RST BIT(6)
+#define SP_VIDFIF_RST BIT(5)
+#define SP_AUDFIF_RST BIT(4)
+#define SP_AUDCAP_RST BIT(3)
+#define SP_HDCP_RST BIT(2)
+#define SP_SW_RST BIT(1)
+#define SP_HW_RST BIT(0)
+
+/* Reset Control Register 2 */
+#define SP_RESET_CTRL2_REG 0x07
+#define SP_AUX_RST BIT(2)
+#define SP_SERDES_FIFO_RST BIT(1)
+#define SP_I2C_REG_RST BIT(0)
+
+/* Video Control Register 1 */
+#define SP_VID_CTRL1_REG 0x08
+#define SP_VIDEO_EN BIT(7)
+#define SP_VIDEO_MUTE BIT(2)
+#define SP_DE_GEN BIT(1)
+#define SP_DEMUX BIT(0)
+
+/* Video Control Register 2 */
+#define SP_VID_CTRL2_REG 0x09
+#define SP_IN_COLOR_F_MASK 0x03
+#define SP_IN_YC_BIT_SEL BIT(2)
+#define SP_IN_BPC_MASK 0x70
+#define SP_IN_BPC_SHIFT 4
+# define SP_IN_BPC_12BIT 0x03
+# define SP_IN_BPC_10BIT 0x02
+# define SP_IN_BPC_8BIT 0x01
+# define SP_IN_BPC_6BIT 0x00
+#define SP_IN_D_RANGE BIT(7)
+
+/* Video Control Register 3 */
+#define SP_VID_CTRL3_REG 0x0a
+#define SP_HPD_OUT BIT(6)
+
+/* Video Control Register 5 */
+#define SP_VID_CTRL5_REG 0x0c
+#define SP_CSC_STD_SEL BIT(7)
+#define SP_XVYCC_RNG_LMT BIT(6)
+#define SP_RANGE_Y2R BIT(5)
+#define SP_CSPACE_Y2R BIT(4)
+#define SP_RGB_RNG_LMT BIT(3)
+#define SP_Y_RNG_LMT BIT(2)
+#define SP_RANGE_R2Y BIT(1)
+#define SP_CSPACE_R2Y BIT(0)
+
+/* Video Control Register 6 */
+#define SP_VID_CTRL6_REG 0x0d
+#define SP_TEST_PATTERN_EN BIT(7)
+#define SP_VIDEO_PROCESS_EN BIT(6)
+#define SP_VID_US_MODE BIT(3)
+#define SP_VID_DS_MODE BIT(2)
+#define SP_UP_SAMPLE BIT(1)
+#define SP_DOWN_SAMPLE BIT(0)
+
+/* Video Control Register 8 */
+#define SP_VID_CTRL8_REG 0x0f
+#define SP_VID_VRES_TH BIT(0)
+
+/* Total Line Status Low Byte Register */
+#define SP_TOTAL_LINE_STAL_REG 0x24
+
+/* Total Line Status High Byte Register */
+#define SP_TOTAL_LINE_STAH_REG 0x25
+
+/* Active Line Status Low Byte Register */
+#define SP_ACT_LINE_STAL_REG 0x26
+
+/* Active Line Status High Byte Register */
+#define SP_ACT_LINE_STAH_REG 0x27
+
+/* Vertical Front Porch Status Register */
+#define SP_V_F_PORCH_STA_REG 0x28
+
+/* Vertical SYNC Width Status Register */
+#define SP_V_SYNC_STA_REG 0x29
+
+/* Vertical Back Porch Status Register */
+#define SP_V_B_PORCH_STA_REG 0x2a
+
+/* Total Pixel Status Low Byte Register */
+#define SP_TOTAL_PIXEL_STAL_REG 0x2b
+
+/* Total Pixel Status High Byte Register */
+#define SP_TOTAL_PIXEL_STAH_REG 0x2c
+
+/* Active Pixel Status Low Byte Register */
+#define SP_ACT_PIXEL_STAL_REG 0x2d
+
+/* Active Pixel Status High Byte Register */
+#define SP_ACT_PIXEL_STAH_REG 0x2e
+
+/* Horizontal Front Porch Status Low Byte Register */
+#define SP_H_F_PORCH_STAL_REG 0x2f
+
+/* Horizontal Front Porch Statys High Byte Register */
+#define SP_H_F_PORCH_STAH_REG 0x30
+
+/* Horizontal SYNC Width Status Low Byte Register */
+#define SP_H_SYNC_STAL_REG 0x31
+
+/* Horizontal SYNC Width Status High Byte Register */
+#define SP_H_SYNC_STAH_REG 0x32
+
+/* Horizontal Back Porch Status Low Byte Register */
+#define SP_H_B_PORCH_STAL_REG 0x33
+
+/* Horizontal Back Porch Status High Byte Register */
+#define SP_H_B_PORCH_STAH_REG 0x34
+
+/* InfoFrame AVI Packet DB1 Register */
+#define SP_INFOFRAME_AVI_DB1_REG 0x70
+
+/* Bit Control Specific Register */
+#define SP_BIT_CTRL_SPECIFIC_REG 0x80
+#define SP_BIT_CTRL_SELECT_SHIFT 1
+#define SP_ENABLE_BIT_CTRL BIT(0)
+
+/* InfoFrame Audio Packet DB1 Register */
+#define SP_INFOFRAME_AUD_DB1_REG 0x83
+
+/* InfoFrame MPEG Packet DB1 Register */
+#define SP_INFOFRAME_MPEG_DB1_REG 0xb0
+
+/* Audio Channel Status Registers */
+#define SP_AUD_CH_STATUS_BASE 0xd0
+
+/* Audio Channel Num Register 5 */
+#define SP_I2S_CHANNEL_NUM_MASK 0xe0
+# define SP_I2S_CH_NUM_1 (0x00 << 5)
+# define SP_I2S_CH_NUM_2 (0x01 << 5)
+# define SP_I2S_CH_NUM_3 (0x02 << 5)
+# define SP_I2S_CH_NUM_4 (0x03 << 5)
+# define SP_I2S_CH_NUM_5 (0x04 << 5)
+# define SP_I2S_CH_NUM_6 (0x05 << 5)
+# define SP_I2S_CH_NUM_7 (0x06 << 5)
+# define SP_I2S_CH_NUM_8 (0x07 << 5)
+#define SP_EXT_VUCP BIT(2)
+#define SP_VBIT BIT(1)
+#define SP_AUDIO_LAYOUT BIT(0)
+
+/* Analog Debug Register 2 */
+#define SP_ANALOG_DEBUG2_REG 0xdd
+#define SP_FORCE_SW_OFF_BYPASS 0x20
+#define SP_XTAL_FRQ 0x1c
+# define SP_XTAL_FRQ_19M2 (0x00 << 2)
+# define SP_XTAL_FRQ_24M (0x01 << 2)
+# define SP_XTAL_FRQ_25M (0x02 << 2)
+# define SP_XTAL_FRQ_26M (0x03 << 2)
+# define SP_XTAL_FRQ_27M (0x04 << 2)
+# define SP_XTAL_FRQ_38M4 (0x05 << 2)
+# define SP_XTAL_FRQ_52M (0x06 << 2)
+#define SP_POWERON_TIME_1P5MS 0x03
+
+/* Analog Control 0 Register */
+#define SP_ANALOG_CTRL0_REG 0xe1
+
+/* Common Interrupt Status Register 1 */
+#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1)
+#define SP_PLL_LOCK_CHG 0x40
+
+/* Common Interrupt Status Register 2 */
+#define SP_COMMON_INT_STATUS2 0xf2
+#define SP_HDCP_AUTH_CHG BIT(1)
+#define SP_HDCP_AUTH_DONE BIT(0)
+
+#define SP_HDCP_LINK_CHECK_FAIL BIT(0)
+
+/* Common Interrupt Status Register 4 */
+#define SP_COMMON_INT_STATUS4_REG 0xf4
+#define SP_HPD_IRQ BIT(6)
+#define SP_HPD_ESYNC_ERR BIT(4)
+#define SP_HPD_CHG BIT(2)
+#define SP_HPD_LOST BIT(1)
+#define SP_HPD_PLUG BIT(0)
+
+/* DP Interrupt Status Register */
+#define SP_DP_INT_STATUS1_REG 0xf7
+#define SP_TRAINING_FINISH BIT(5)
+#define SP_POLLING_ERR BIT(4)
+
+/* Common Interrupt Mask Register */
+#define SP_COMMON_INT_MASK_BASE (0xf8 - 1)
+
+#define SP_COMMON_INT_MASK4_REG 0xfb
+
+/* DP Interrupts Mask Register */
+#define SP_DP_INT_MASK1_REG 0xfe
+
+/* Interrupt Control Register */
+#define SP_INT_CTRL_REG 0xff
+
+#endif /* _ANALOGIX_I2C_TXCOMMON_H_ */
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 02/12] drm/bridge: split some definitions of ANX78xx to dedicated headers
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
Some definitions currently in analogix-anx78xx.h are not restricted to
the ANX78xx series, but also applicable to other DisplayPort
transmitters by Analogix.
Split out them to dedicated headers, and make analogix-anx78xx.h include
them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
.../drm/bridge/analogix/analogix-anx78xx.h | 464 +-----------------
.../drm/bridge/analogix/analogix-i2c-dptx.h | 248 ++++++++++
.../bridge/analogix/analogix-i2c-txcommon.h | 237 +++++++++
3 files changed, 490 insertions(+), 459 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
index 38753c870137..8aa1eca306d3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
@@ -15,9 +15,12 @@
#ifndef __ANX78xx_H
#define __ANX78xx_H
-#define TX_P0 0x70
+#include "analogix-i2c-dptx.h"
+#include "analogix-i2c-txcommon.h"
+
+#define TX_P0 ANALOGIX_I2C_DPTX
#define TX_P1 0x7a
-#define TX_P2 0x72
+#define TX_P2 ANALOGIX_I2C_TXCOMMON
#define RX_P0 0x7e
#define RX_P1 0x80
@@ -225,463 +228,6 @@
#define SP_CLEAR_AVMUTE BIT(4)
#define SP_SET_AVMUTE BIT(0)
-/***************************************************************/
-/* Register definition of device address 0x70 */
-/***************************************************************/
-
-/* HDCP Status Register */
-#define SP_TX_HDCP_STATUS_REG 0x00
-#define SP_AUTH_FAIL BIT(5)
-#define SP_AUTHEN_PASS BIT(1)
-
-/* HDCP Control Register 0 */
-#define SP_HDCP_CTRL0_REG 0x01
-#define SP_RX_REPEATER BIT(6)
-#define SP_RE_AUTH BIT(5)
-#define SP_SW_AUTH_OK BIT(4)
-#define SP_HARD_AUTH_EN BIT(3)
-#define SP_HDCP_ENC_EN BIT(2)
-#define SP_BKSV_SRM_PASS BIT(1)
-#define SP_KSVLIST_VLD BIT(0)
-/* HDCP Function Enabled */
-#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3))
-
-/* HDCP Receiver BSTATUS Register 0 */
-#define SP_HDCP_RX_BSTATUS0_REG 0x1b
-/* HDCP Receiver BSTATUS Register 1 */
-#define SP_HDCP_RX_BSTATUS1_REG 0x1c
-
-/* HDCP Embedded "Blue Screen" Content Registers */
-#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c
-#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d
-#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e
-
-/* HDCP Wait R0 Timing Register */
-#define SP_HDCP_WAIT_R0_TIME_REG 0x40
-
-/* HDCP Link Integrity Check Timer Register */
-#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41
-
-/* HDCP Repeater Ready Wait Timer Register */
-#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42
-
-/* HDCP Auto Timer Register */
-#define SP_HDCP_AUTO_TIMER_REG 0x51
-
-/* HDCP Key Status Register */
-#define SP_HDCP_KEY_STATUS_REG 0x5e
-
-/* HDCP Key Command Register */
-#define SP_HDCP_KEY_COMMAND_REG 0x5f
-#define SP_DISABLE_SYNC_HDCP BIT(2)
-
-/* OTP Memory Key Protection Registers */
-#define SP_OTP_KEY_PROTECT1_REG 0x60
-#define SP_OTP_KEY_PROTECT2_REG 0x61
-#define SP_OTP_KEY_PROTECT3_REG 0x62
-#define SP_OTP_PSW1 0xa2
-#define SP_OTP_PSW2 0x7e
-#define SP_OTP_PSW3 0xc6
-
-/* DP System Control Registers */
-#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1)
-/* Bits for DP System Control Register 2 */
-#define SP_CHA_STA BIT(2)
-/* Bits for DP System Control Register 3 */
-#define SP_HPD_STATUS BIT(6)
-#define SP_STRM_VALID BIT(2)
-/* Bits for DP System Control Register 4 */
-#define SP_ENHANCED_MODE BIT(3)
-
-/* DP Video Control Register */
-#define SP_DP_VIDEO_CTRL_REG 0x84
-#define SP_COLOR_F_MASK 0x06
-#define SP_COLOR_F_SHIFT 1
-#define SP_BPC_MASK 0xe0
-#define SP_BPC_SHIFT 5
-# define SP_BPC_6BITS 0x00
-# define SP_BPC_8BITS 0x01
-# define SP_BPC_10BITS 0x02
-# define SP_BPC_12BITS 0x03
-
-/* DP Audio Control Register */
-#define SP_DP_AUDIO_CTRL_REG 0x87
-#define SP_AUD_EN BIT(0)
-
-/* 10us Pulse Generate Timer Registers */
-#define SP_I2C_GEN_10US_TIMER0_REG 0x88
-#define SP_I2C_GEN_10US_TIMER1_REG 0x89
-
-/* Packet Send Control Register */
-#define SP_PACKET_SEND_CTRL_REG 0x90
-#define SP_AUD_IF_UP BIT(7)
-#define SP_AVI_IF_UD BIT(6)
-#define SP_MPEG_IF_UD BIT(5)
-#define SP_SPD_IF_UD BIT(4)
-#define SP_AUD_IF_EN BIT(3)
-#define SP_AVI_IF_EN BIT(2)
-#define SP_MPEG_IF_EN BIT(1)
-#define SP_SPD_IF_EN BIT(0)
-
-/* DP HDCP Control Register */
-#define SP_DP_HDCP_CTRL_REG 0x92
-#define SP_AUTO_EN BIT(7)
-#define SP_AUTO_START BIT(5)
-#define SP_LINK_POLLING BIT(1)
-
-/* DP Main Link Bandwidth Setting Register */
-#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0
-#define SP_LINK_BW_SET_MASK 0x1f
-#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
-
-/* DP Training Pattern Set Register */
-#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
-
-/* DP Lane 0 Link Training Control Register */
-#define SP_DP_LANE0_LT_CTRL_REG 0xa3
-#define SP_TX_SW_SET_MASK 0x1b
-#define SP_MAX_PRE_REACH BIT(5)
-#define SP_MAX_DRIVE_REACH BIT(4)
-#define SP_PRE_EMP_LEVEL1 BIT(3)
-#define SP_DRVIE_CURRENT_LEVEL1 BIT(0)
-
-/* DP Link Training Control Register */
-#define SP_DP_LT_CTRL_REG 0xa8
-#define SP_LT_ERROR_TYPE_MASK 0x70
-# define SP_LT_NO_ERROR 0x00
-# define SP_LT_AUX_WRITE_ERROR 0x01
-# define SP_LT_MAX_DRIVE_REACHED 0x02
-# define SP_LT_WRONG_LANE_COUNT_SET 0x03
-# define SP_LT_LOOP_SAME_5_TIME 0x04
-# define SP_LT_CR_FAIL_IN_EQ 0x05
-# define SP_LT_EQ_LOOP_5_TIME 0x06
-#define SP_LT_EN BIT(0)
-
-/* DP CEP Training Control Registers */
-#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9
-#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa
-
-/* DP Debug Register 1 */
-#define SP_DP_DEBUG1_REG 0xb0
-#define SP_DEBUG_PLL_LOCK BIT(4)
-#define SP_POLLING_EN BIT(1)
-
-/* DP Polling Control Register */
-#define SP_DP_POLLING_CTRL_REG 0xb4
-#define SP_AUTO_POLLING_DISABLE BIT(0)
-
-/* DP Link Debug Control Register */
-#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8
-#define SP_M_VID_DEBUG BIT(5)
-#define SP_NEW_PRBS7 BIT(4)
-#define SP_INSERT_ER BIT(1)
-#define SP_PRBS31_EN BIT(0)
-
-/* AUX Misc control Register */
-#define SP_AUX_MISC_CTRL_REG 0xbf
-
-/* DP PLL control Register */
-#define SP_DP_PLL_CTRL_REG 0xc7
-#define SP_PLL_RST BIT(6)
-
-/* DP Analog Power Down Register */
-#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8
-#define SP_CH0_PD BIT(0)
-
-/* DP Misc Control Register */
-#define SP_DP_MISC_CTRL_REG 0xcd
-#define SP_EQ_TRAINING_LOOP BIT(6)
-
-/* DP Extra I2C Device Address Register */
-#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce
-#define SP_I2C_STRETCH_DISABLE BIT(7)
-
-#define SP_I2C_EXTRA_ADDR 0x50
-
-/* DP Downspread Control Register 1 */
-#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0
-
-/* DP M Value Calculation Control Register */
-#define SP_DP_M_CALCULATION_CTRL_REG 0xd9
-#define SP_M_GEN_CLK_SEL BIT(0)
-
-/* AUX Channel Access Status Register */
-#define SP_AUX_CH_STATUS_REG 0xe0
-#define SP_AUX_STATUS 0x0f
-
-/* AUX Channel DEFER Control Register */
-#define SP_AUX_DEFER_CTRL_REG 0xe2
-#define SP_DEFER_CTRL_EN BIT(7)
-
-/* DP Buffer Data Count Register */
-#define SP_BUF_DATA_COUNT_REG 0xe4
-#define SP_BUF_DATA_COUNT_MASK 0x1f
-#define SP_BUF_CLR BIT(7)
-
-/* DP AUX Channel Control Register 1 */
-#define SP_DP_AUX_CH_CTRL1_REG 0xe5
-#define SP_AUX_TX_COMM_MASK 0x0f
-#define SP_AUX_LENGTH_MASK 0xf0
-#define SP_AUX_LENGTH_SHIFT 4
-
-/* DP AUX CH Address Register 0 */
-#define SP_AUX_ADDR_7_0_REG 0xe6
-
-/* DP AUX CH Address Register 1 */
-#define SP_AUX_ADDR_15_8_REG 0xe7
-
-/* DP AUX CH Address Register 2 */
-#define SP_AUX_ADDR_19_16_REG 0xe8
-#define SP_AUX_ADDR_19_16_MASK 0x0f
-
-/* DP AUX Channel Control Register 2 */
-#define SP_DP_AUX_CH_CTRL2_REG 0xe9
-#define SP_AUX_SEL_RXCM BIT(6)
-#define SP_AUX_CHSEL BIT(3)
-#define SP_AUX_PN_INV BIT(2)
-#define SP_ADDR_ONLY BIT(1)
-#define SP_AUX_EN BIT(0)
-
-/* DP Video Stream Control InfoFrame Register */
-#define SP_DP_3D_VSC_CTRL_REG 0xea
-#define SP_INFO_FRAME_VSC_EN BIT(0)
-
-/* DP Video Stream Data Byte 1 Register */
-#define SP_DP_VSC_DB1_REG 0xeb
-
-/* DP AUX Channel Control Register 3 */
-#define SP_DP_AUX_CH_CTRL3_REG 0xec
-#define SP_WAIT_COUNTER_7_0_MASK 0xff
-
-/* DP AUX Channel Control Register 4 */
-#define SP_DP_AUX_CH_CTRL4_REG 0xed
-
-/* DP AUX Buffer Data Registers */
-#define SP_DP_BUF_DATA0_REG 0xf0
-
-/***************************************************************/
-/* Register definition of device address 0x72 */
-/***************************************************************/
-
-/*
- * Core Register Definitions
- */
-
-/* Device ID Low Byte Register */
-#define SP_DEVICE_IDL_REG 0x02
-
-/* Device ID High Byte Register */
-#define SP_DEVICE_IDH_REG 0x03
-
-/* Device version register */
-#define SP_DEVICE_VERSION_REG 0x04
-
-/* Power Down Control Register */
-#define SP_POWERDOWN_CTRL_REG 0x05
-#define SP_REGISTER_PD BIT(7)
-#define SP_HDCP_PD BIT(5)
-#define SP_AUDIO_PD BIT(4)
-#define SP_VIDEO_PD BIT(3)
-#define SP_LINK_PD BIT(2)
-#define SP_TOTAL_PD BIT(1)
-
-/* Reset Control Register 1 */
-#define SP_RESET_CTRL1_REG 0x06
-#define SP_MISC_RST BIT(7)
-#define SP_VIDCAP_RST BIT(6)
-#define SP_VIDFIF_RST BIT(5)
-#define SP_AUDFIF_RST BIT(4)
-#define SP_AUDCAP_RST BIT(3)
-#define SP_HDCP_RST BIT(2)
-#define SP_SW_RST BIT(1)
-#define SP_HW_RST BIT(0)
-
-/* Reset Control Register 2 */
-#define SP_RESET_CTRL2_REG 0x07
-#define SP_AUX_RST BIT(2)
-#define SP_SERDES_FIFO_RST BIT(1)
-#define SP_I2C_REG_RST BIT(0)
-
-/* Video Control Register 1 */
-#define SP_VID_CTRL1_REG 0x08
-#define SP_VIDEO_EN BIT(7)
-#define SP_VIDEO_MUTE BIT(2)
-#define SP_DE_GEN BIT(1)
-#define SP_DEMUX BIT(0)
-
-/* Video Control Register 2 */
-#define SP_VID_CTRL2_REG 0x09
-#define SP_IN_COLOR_F_MASK 0x03
-#define SP_IN_YC_BIT_SEL BIT(2)
-#define SP_IN_BPC_MASK 0x70
-#define SP_IN_BPC_SHIFT 4
-# define SP_IN_BPC_12BIT 0x03
-# define SP_IN_BPC_10BIT 0x02
-# define SP_IN_BPC_8BIT 0x01
-# define SP_IN_BPC_6BIT 0x00
-#define SP_IN_D_RANGE BIT(7)
-
-/* Video Control Register 3 */
-#define SP_VID_CTRL3_REG 0x0a
-#define SP_HPD_OUT BIT(6)
-
-/* Video Control Register 5 */
-#define SP_VID_CTRL5_REG 0x0c
-#define SP_CSC_STD_SEL BIT(7)
-#define SP_XVYCC_RNG_LMT BIT(6)
-#define SP_RANGE_Y2R BIT(5)
-#define SP_CSPACE_Y2R BIT(4)
-#define SP_RGB_RNG_LMT BIT(3)
-#define SP_Y_RNG_LMT BIT(2)
-#define SP_RANGE_R2Y BIT(1)
-#define SP_CSPACE_R2Y BIT(0)
-
-/* Video Control Register 6 */
-#define SP_VID_CTRL6_REG 0x0d
-#define SP_TEST_PATTERN_EN BIT(7)
-#define SP_VIDEO_PROCESS_EN BIT(6)
-#define SP_VID_US_MODE BIT(3)
-#define SP_VID_DS_MODE BIT(2)
-#define SP_UP_SAMPLE BIT(1)
-#define SP_DOWN_SAMPLE BIT(0)
-
-/* Video Control Register 8 */
-#define SP_VID_CTRL8_REG 0x0f
-#define SP_VID_VRES_TH BIT(0)
-
-/* Total Line Status Low Byte Register */
-#define SP_TOTAL_LINE_STAL_REG 0x24
-
-/* Total Line Status High Byte Register */
-#define SP_TOTAL_LINE_STAH_REG 0x25
-
-/* Active Line Status Low Byte Register */
-#define SP_ACT_LINE_STAL_REG 0x26
-
-/* Active Line Status High Byte Register */
-#define SP_ACT_LINE_STAH_REG 0x27
-
-/* Vertical Front Porch Status Register */
-#define SP_V_F_PORCH_STA_REG 0x28
-
-/* Vertical SYNC Width Status Register */
-#define SP_V_SYNC_STA_REG 0x29
-
-/* Vertical Back Porch Status Register */
-#define SP_V_B_PORCH_STA_REG 0x2a
-
-/* Total Pixel Status Low Byte Register */
-#define SP_TOTAL_PIXEL_STAL_REG 0x2b
-
-/* Total Pixel Status High Byte Register */
-#define SP_TOTAL_PIXEL_STAH_REG 0x2c
-
-/* Active Pixel Status Low Byte Register */
-#define SP_ACT_PIXEL_STAL_REG 0x2d
-
-/* Active Pixel Status High Byte Register */
-#define SP_ACT_PIXEL_STAH_REG 0x2e
-
-/* Horizontal Front Porch Status Low Byte Register */
-#define SP_H_F_PORCH_STAL_REG 0x2f
-
-/* Horizontal Front Porch Statys High Byte Register */
-#define SP_H_F_PORCH_STAH_REG 0x30
-
-/* Horizontal SYNC Width Status Low Byte Register */
-#define SP_H_SYNC_STAL_REG 0x31
-
-/* Horizontal SYNC Width Status High Byte Register */
-#define SP_H_SYNC_STAH_REG 0x32
-
-/* Horizontal Back Porch Status Low Byte Register */
-#define SP_H_B_PORCH_STAL_REG 0x33
-
-/* Horizontal Back Porch Status High Byte Register */
-#define SP_H_B_PORCH_STAH_REG 0x34
-
-/* InfoFrame AVI Packet DB1 Register */
-#define SP_INFOFRAME_AVI_DB1_REG 0x70
-
-/* Bit Control Specific Register */
-#define SP_BIT_CTRL_SPECIFIC_REG 0x80
-#define SP_BIT_CTRL_SELECT_SHIFT 1
-#define SP_ENABLE_BIT_CTRL BIT(0)
-
-/* InfoFrame Audio Packet DB1 Register */
-#define SP_INFOFRAME_AUD_DB1_REG 0x83
-
-/* InfoFrame MPEG Packet DB1 Register */
-#define SP_INFOFRAME_MPEG_DB1_REG 0xb0
-
-/* Audio Channel Status Registers */
-#define SP_AUD_CH_STATUS_BASE 0xd0
-
-/* Audio Channel Num Register 5 */
-#define SP_I2S_CHANNEL_NUM_MASK 0xe0
-# define SP_I2S_CH_NUM_1 (0x00 << 5)
-# define SP_I2S_CH_NUM_2 (0x01 << 5)
-# define SP_I2S_CH_NUM_3 (0x02 << 5)
-# define SP_I2S_CH_NUM_4 (0x03 << 5)
-# define SP_I2S_CH_NUM_5 (0x04 << 5)
-# define SP_I2S_CH_NUM_6 (0x05 << 5)
-# define SP_I2S_CH_NUM_7 (0x06 << 5)
-# define SP_I2S_CH_NUM_8 (0x07 << 5)
-#define SP_EXT_VUCP BIT(2)
-#define SP_VBIT BIT(1)
-#define SP_AUDIO_LAYOUT BIT(0)
-
-/* Analog Debug Register 2 */
-#define SP_ANALOG_DEBUG2_REG 0xdd
-#define SP_FORCE_SW_OFF_BYPASS 0x20
-#define SP_XTAL_FRQ 0x1c
-# define SP_XTAL_FRQ_19M2 (0x00 << 2)
-# define SP_XTAL_FRQ_24M (0x01 << 2)
-# define SP_XTAL_FRQ_25M (0x02 << 2)
-# define SP_XTAL_FRQ_26M (0x03 << 2)
-# define SP_XTAL_FRQ_27M (0x04 << 2)
-# define SP_XTAL_FRQ_38M4 (0x05 << 2)
-# define SP_XTAL_FRQ_52M (0x06 << 2)
-#define SP_POWERON_TIME_1P5MS 0x03
-
-/* Analog Control 0 Register */
-#define SP_ANALOG_CTRL0_REG 0xe1
-
-/* Common Interrupt Status Register 1 */
-#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1)
-#define SP_PLL_LOCK_CHG 0x40
-
-/* Common Interrupt Status Register 2 */
-#define SP_COMMON_INT_STATUS2 0xf2
-#define SP_HDCP_AUTH_CHG BIT(1)
-#define SP_HDCP_AUTH_DONE BIT(0)
-
-#define SP_HDCP_LINK_CHECK_FAIL BIT(0)
-
-/* Common Interrupt Status Register 4 */
-#define SP_COMMON_INT_STATUS4_REG 0xf4
-#define SP_HPD_IRQ BIT(6)
-#define SP_HPD_ESYNC_ERR BIT(4)
-#define SP_HPD_CHG BIT(2)
-#define SP_HPD_LOST BIT(1)
-#define SP_HPD_PLUG BIT(0)
-
-/* DP Interrupt Status Register */
-#define SP_DP_INT_STATUS1_REG 0xf7
-#define SP_TRAINING_FINISH BIT(5)
-#define SP_POLLING_ERR BIT(4)
-
-/* Common Interrupt Mask Register */
-#define SP_COMMON_INT_MASK_BASE (0xf8 - 1)
-
-#define SP_COMMON_INT_MASK4_REG 0xfb
-
-/* DP Interrupts Mask Register */
-#define SP_DP_INT_MASK1_REG 0xfe
-
-/* Interrupt Control Register */
-#define SP_INT_CTRL_REG 0xff
-
/***************************************************************/
/* Register definition of device address 0x7a */
/***************************************************************/
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
new file mode 100644
index 000000000000..bc0831b127bf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -0,0 +1,248 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * Based on analogix-anx78xx.h, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#ifndef _ANALOGIX_I2C_DPTX_H_
+#define _ANALOGIX_I2C_DPTX_H_
+
+#define ANALOGIX_I2C_DPTX 0x70
+
+/***************************************************************/
+/* Register definition of device address 0x70 */
+/***************************************************************/
+
+/* HDCP Status Register */
+#define SP_TX_HDCP_STATUS_REG 0x00
+#define SP_AUTH_FAIL BIT(5)
+#define SP_AUTHEN_PASS BIT(1)
+
+/* HDCP Control Register 0 */
+#define SP_HDCP_CTRL0_REG 0x01
+#define SP_RX_REPEATER BIT(6)
+#define SP_RE_AUTH BIT(5)
+#define SP_SW_AUTH_OK BIT(4)
+#define SP_HARD_AUTH_EN BIT(3)
+#define SP_HDCP_ENC_EN BIT(2)
+#define SP_BKSV_SRM_PASS BIT(1)
+#define SP_KSVLIST_VLD BIT(0)
+/* HDCP Function Enabled */
+#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3))
+
+/* HDCP Receiver BSTATUS Register 0 */
+#define SP_HDCP_RX_BSTATUS0_REG 0x1b
+/* HDCP Receiver BSTATUS Register 1 */
+#define SP_HDCP_RX_BSTATUS1_REG 0x1c
+
+/* HDCP Embedded "Blue Screen" Content Registers */
+#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c
+#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d
+#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e
+
+/* HDCP Wait R0 Timing Register */
+#define SP_HDCP_WAIT_R0_TIME_REG 0x40
+
+/* HDCP Link Integrity Check Timer Register */
+#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41
+
+/* HDCP Repeater Ready Wait Timer Register */
+#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42
+
+/* HDCP Auto Timer Register */
+#define SP_HDCP_AUTO_TIMER_REG 0x51
+
+/* HDCP Key Status Register */
+#define SP_HDCP_KEY_STATUS_REG 0x5e
+
+/* HDCP Key Command Register */
+#define SP_HDCP_KEY_COMMAND_REG 0x5f
+#define SP_DISABLE_SYNC_HDCP BIT(2)
+
+/* OTP Memory Key Protection Registers */
+#define SP_OTP_KEY_PROTECT1_REG 0x60
+#define SP_OTP_KEY_PROTECT2_REG 0x61
+#define SP_OTP_KEY_PROTECT3_REG 0x62
+#define SP_OTP_PSW1 0xa2
+#define SP_OTP_PSW2 0x7e
+#define SP_OTP_PSW3 0xc6
+
+/* DP System Control Registers */
+#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1)
+/* Bits for DP System Control Register 2 */
+#define SP_CHA_STA BIT(2)
+/* Bits for DP System Control Register 3 */
+#define SP_HPD_STATUS BIT(6)
+#define SP_STRM_VALID BIT(2)
+/* Bits for DP System Control Register 4 */
+#define SP_ENHANCED_MODE BIT(3)
+
+/* DP Video Control Register */
+#define SP_DP_VIDEO_CTRL_REG 0x84
+#define SP_COLOR_F_MASK 0x06
+#define SP_COLOR_F_SHIFT 1
+#define SP_BPC_MASK 0xe0
+#define SP_BPC_SHIFT 5
+# define SP_BPC_6BITS 0x00
+# define SP_BPC_8BITS 0x01
+# define SP_BPC_10BITS 0x02
+# define SP_BPC_12BITS 0x03
+
+/* DP Audio Control Register */
+#define SP_DP_AUDIO_CTRL_REG 0x87
+#define SP_AUD_EN BIT(0)
+
+/* 10us Pulse Generate Timer Registers */
+#define SP_I2C_GEN_10US_TIMER0_REG 0x88
+#define SP_I2C_GEN_10US_TIMER1_REG 0x89
+
+/* Packet Send Control Register */
+#define SP_PACKET_SEND_CTRL_REG 0x90
+#define SP_AUD_IF_UP BIT(7)
+#define SP_AVI_IF_UD BIT(6)
+#define SP_MPEG_IF_UD BIT(5)
+#define SP_SPD_IF_UD BIT(4)
+#define SP_AUD_IF_EN BIT(3)
+#define SP_AVI_IF_EN BIT(2)
+#define SP_MPEG_IF_EN BIT(1)
+#define SP_SPD_IF_EN BIT(0)
+
+/* DP HDCP Control Register */
+#define SP_DP_HDCP_CTRL_REG 0x92
+#define SP_AUTO_EN BIT(7)
+#define SP_AUTO_START BIT(5)
+#define SP_LINK_POLLING BIT(1)
+
+/* DP Main Link Bandwidth Setting Register */
+#define SP_DP_MAIN_LINK_BW_SET_REG 0xa0
+#define SP_LINK_BW_SET_MASK 0x1f
+#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
+
+/* DP Training Pattern Set Register */
+#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
+
+/* DP Lane 0 Link Training Control Register */
+#define SP_DP_LANE0_LT_CTRL_REG 0xa3
+#define SP_TX_SW_SET_MASK 0x1b
+#define SP_MAX_PRE_REACH BIT(5)
+#define SP_MAX_DRIVE_REACH BIT(4)
+#define SP_PRE_EMP_LEVEL1 BIT(3)
+#define SP_DRVIE_CURRENT_LEVEL1 BIT(0)
+
+/* DP Link Training Control Register */
+#define SP_DP_LT_CTRL_REG 0xa8
+#define SP_LT_ERROR_TYPE_MASK 0x70
+# define SP_LT_NO_ERROR 0x00
+# define SP_LT_AUX_WRITE_ERROR 0x01
+# define SP_LT_MAX_DRIVE_REACHED 0x02
+# define SP_LT_WRONG_LANE_COUNT_SET 0x03
+# define SP_LT_LOOP_SAME_5_TIME 0x04
+# define SP_LT_CR_FAIL_IN_EQ 0x05
+# define SP_LT_EQ_LOOP_5_TIME 0x06
+#define SP_LT_EN BIT(0)
+
+/* DP CEP Training Control Registers */
+#define SP_DP_CEP_TRAINING_CTRL0_REG 0xa9
+#define SP_DP_CEP_TRAINING_CTRL1_REG 0xaa
+
+/* DP Debug Register 1 */
+#define SP_DP_DEBUG1_REG 0xb0
+#define SP_DEBUG_PLL_LOCK BIT(4)
+#define SP_POLLING_EN BIT(1)
+
+/* DP Polling Control Register */
+#define SP_DP_POLLING_CTRL_REG 0xb4
+#define SP_AUTO_POLLING_DISABLE BIT(0)
+
+/* DP Link Debug Control Register */
+#define SP_DP_LINK_DEBUG_CTRL_REG 0xb8
+#define SP_M_VID_DEBUG BIT(5)
+#define SP_NEW_PRBS7 BIT(4)
+#define SP_INSERT_ER BIT(1)
+#define SP_PRBS31_EN BIT(0)
+
+/* AUX Misc control Register */
+#define SP_AUX_MISC_CTRL_REG 0xbf
+
+/* DP PLL control Register */
+#define SP_DP_PLL_CTRL_REG 0xc7
+#define SP_PLL_RST BIT(6)
+
+/* DP Analog Power Down Register */
+#define SP_DP_ANALOG_POWER_DOWN_REG 0xc8
+#define SP_CH0_PD BIT(0)
+
+/* DP Misc Control Register */
+#define SP_DP_MISC_CTRL_REG 0xcd
+#define SP_EQ_TRAINING_LOOP BIT(6)
+
+/* DP Extra I2C Device Address Register */
+#define SP_DP_EXTRA_I2C_DEV_ADDR_REG 0xce
+#define SP_I2C_STRETCH_DISABLE BIT(7)
+
+#define SP_I2C_EXTRA_ADDR 0x50
+
+/* DP Downspread Control Register 1 */
+#define SP_DP_DOWNSPREAD_CTRL1_REG 0xd0
+
+/* DP M Value Calculation Control Register */
+#define SP_DP_M_CALCULATION_CTRL_REG 0xd9
+#define SP_M_GEN_CLK_SEL BIT(0)
+
+/* AUX Channel Access Status Register */
+#define SP_AUX_CH_STATUS_REG 0xe0
+#define SP_AUX_STATUS 0x0f
+
+/* AUX Channel DEFER Control Register */
+#define SP_AUX_DEFER_CTRL_REG 0xe2
+#define SP_DEFER_CTRL_EN BIT(7)
+
+/* DP Buffer Data Count Register */
+#define SP_BUF_DATA_COUNT_REG 0xe4
+#define SP_BUF_DATA_COUNT_MASK 0x1f
+#define SP_BUF_CLR BIT(7)
+
+/* DP AUX Channel Control Register 1 */
+#define SP_DP_AUX_CH_CTRL1_REG 0xe5
+#define SP_AUX_TX_COMM_MASK 0x0f
+#define SP_AUX_LENGTH_MASK 0xf0
+#define SP_AUX_LENGTH_SHIFT 4
+
+/* DP AUX CH Address Register 0 */
+#define SP_AUX_ADDR_7_0_REG 0xe6
+
+/* DP AUX CH Address Register 1 */
+#define SP_AUX_ADDR_15_8_REG 0xe7
+
+/* DP AUX CH Address Register 2 */
+#define SP_AUX_ADDR_19_16_REG 0xe8
+#define SP_AUX_ADDR_19_16_MASK 0x0f
+
+/* DP AUX Channel Control Register 2 */
+#define SP_DP_AUX_CH_CTRL2_REG 0xe9
+#define SP_AUX_SEL_RXCM BIT(6)
+#define SP_AUX_CHSEL BIT(3)
+#define SP_AUX_PN_INV BIT(2)
+#define SP_ADDR_ONLY BIT(1)
+#define SP_AUX_EN BIT(0)
+
+/* DP Video Stream Control InfoFrame Register */
+#define SP_DP_3D_VSC_CTRL_REG 0xea
+#define SP_INFO_FRAME_VSC_EN BIT(0)
+
+/* DP Video Stream Data Byte 1 Register */
+#define SP_DP_VSC_DB1_REG 0xeb
+
+/* DP AUX Channel Control Register 3 */
+#define SP_DP_AUX_CH_CTRL3_REG 0xec
+#define SP_WAIT_COUNTER_7_0_MASK 0xff
+
+/* DP AUX Channel Control Register 4 */
+#define SP_DP_AUX_CH_CTRL4_REG 0xed
+
+/* DP AUX Buffer Data Registers */
+#define SP_DP_BUF_DATA0_REG 0xf0
+
+#endif
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
new file mode 100644
index 000000000000..7d683573e970
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -0,0 +1,237 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * Based on analogix-anx78xx.h, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#ifndef _ANALOGIX_I2C_TXCOMMON_H_
+#define _ANALOGIX_I2C_TXCOMMON_H_
+
+#define ANALOGIX_I2C_TXCOMMON 0x72
+
+/***************************************************************/
+/* Register definition of device address 0x72 */
+/***************************************************************/
+
+/*
+ * Core Register Definitions
+ */
+
+/* Device ID Low Byte Register */
+#define SP_DEVICE_IDL_REG 0x02
+
+/* Device ID High Byte Register */
+#define SP_DEVICE_IDH_REG 0x03
+
+/* Device version register */
+#define SP_DEVICE_VERSION_REG 0x04
+
+/* Power Down Control Register */
+#define SP_POWERDOWN_CTRL_REG 0x05
+#define SP_REGISTER_PD BIT(7)
+#define SP_HDCP_PD BIT(5)
+#define SP_AUDIO_PD BIT(4)
+#define SP_VIDEO_PD BIT(3)
+#define SP_LINK_PD BIT(2)
+#define SP_TOTAL_PD BIT(1)
+
+/* Reset Control Register 1 */
+#define SP_RESET_CTRL1_REG 0x06
+#define SP_MISC_RST BIT(7)
+#define SP_VIDCAP_RST BIT(6)
+#define SP_VIDFIF_RST BIT(5)
+#define SP_AUDFIF_RST BIT(4)
+#define SP_AUDCAP_RST BIT(3)
+#define SP_HDCP_RST BIT(2)
+#define SP_SW_RST BIT(1)
+#define SP_HW_RST BIT(0)
+
+/* Reset Control Register 2 */
+#define SP_RESET_CTRL2_REG 0x07
+#define SP_AUX_RST BIT(2)
+#define SP_SERDES_FIFO_RST BIT(1)
+#define SP_I2C_REG_RST BIT(0)
+
+/* Video Control Register 1 */
+#define SP_VID_CTRL1_REG 0x08
+#define SP_VIDEO_EN BIT(7)
+#define SP_VIDEO_MUTE BIT(2)
+#define SP_DE_GEN BIT(1)
+#define SP_DEMUX BIT(0)
+
+/* Video Control Register 2 */
+#define SP_VID_CTRL2_REG 0x09
+#define SP_IN_COLOR_F_MASK 0x03
+#define SP_IN_YC_BIT_SEL BIT(2)
+#define SP_IN_BPC_MASK 0x70
+#define SP_IN_BPC_SHIFT 4
+# define SP_IN_BPC_12BIT 0x03
+# define SP_IN_BPC_10BIT 0x02
+# define SP_IN_BPC_8BIT 0x01
+# define SP_IN_BPC_6BIT 0x00
+#define SP_IN_D_RANGE BIT(7)
+
+/* Video Control Register 3 */
+#define SP_VID_CTRL3_REG 0x0a
+#define SP_HPD_OUT BIT(6)
+
+/* Video Control Register 5 */
+#define SP_VID_CTRL5_REG 0x0c
+#define SP_CSC_STD_SEL BIT(7)
+#define SP_XVYCC_RNG_LMT BIT(6)
+#define SP_RANGE_Y2R BIT(5)
+#define SP_CSPACE_Y2R BIT(4)
+#define SP_RGB_RNG_LMT BIT(3)
+#define SP_Y_RNG_LMT BIT(2)
+#define SP_RANGE_R2Y BIT(1)
+#define SP_CSPACE_R2Y BIT(0)
+
+/* Video Control Register 6 */
+#define SP_VID_CTRL6_REG 0x0d
+#define SP_TEST_PATTERN_EN BIT(7)
+#define SP_VIDEO_PROCESS_EN BIT(6)
+#define SP_VID_US_MODE BIT(3)
+#define SP_VID_DS_MODE BIT(2)
+#define SP_UP_SAMPLE BIT(1)
+#define SP_DOWN_SAMPLE BIT(0)
+
+/* Video Control Register 8 */
+#define SP_VID_CTRL8_REG 0x0f
+#define SP_VID_VRES_TH BIT(0)
+
+/* Total Line Status Low Byte Register */
+#define SP_TOTAL_LINE_STAL_REG 0x24
+
+/* Total Line Status High Byte Register */
+#define SP_TOTAL_LINE_STAH_REG 0x25
+
+/* Active Line Status Low Byte Register */
+#define SP_ACT_LINE_STAL_REG 0x26
+
+/* Active Line Status High Byte Register */
+#define SP_ACT_LINE_STAH_REG 0x27
+
+/* Vertical Front Porch Status Register */
+#define SP_V_F_PORCH_STA_REG 0x28
+
+/* Vertical SYNC Width Status Register */
+#define SP_V_SYNC_STA_REG 0x29
+
+/* Vertical Back Porch Status Register */
+#define SP_V_B_PORCH_STA_REG 0x2a
+
+/* Total Pixel Status Low Byte Register */
+#define SP_TOTAL_PIXEL_STAL_REG 0x2b
+
+/* Total Pixel Status High Byte Register */
+#define SP_TOTAL_PIXEL_STAH_REG 0x2c
+
+/* Active Pixel Status Low Byte Register */
+#define SP_ACT_PIXEL_STAL_REG 0x2d
+
+/* Active Pixel Status High Byte Register */
+#define SP_ACT_PIXEL_STAH_REG 0x2e
+
+/* Horizontal Front Porch Status Low Byte Register */
+#define SP_H_F_PORCH_STAL_REG 0x2f
+
+/* Horizontal Front Porch Statys High Byte Register */
+#define SP_H_F_PORCH_STAH_REG 0x30
+
+/* Horizontal SYNC Width Status Low Byte Register */
+#define SP_H_SYNC_STAL_REG 0x31
+
+/* Horizontal SYNC Width Status High Byte Register */
+#define SP_H_SYNC_STAH_REG 0x32
+
+/* Horizontal Back Porch Status Low Byte Register */
+#define SP_H_B_PORCH_STAL_REG 0x33
+
+/* Horizontal Back Porch Status High Byte Register */
+#define SP_H_B_PORCH_STAH_REG 0x34
+
+/* InfoFrame AVI Packet DB1 Register */
+#define SP_INFOFRAME_AVI_DB1_REG 0x70
+
+/* Bit Control Specific Register */
+#define SP_BIT_CTRL_SPECIFIC_REG 0x80
+#define SP_BIT_CTRL_SELECT_SHIFT 1
+#define SP_ENABLE_BIT_CTRL BIT(0)
+
+/* InfoFrame Audio Packet DB1 Register */
+#define SP_INFOFRAME_AUD_DB1_REG 0x83
+
+/* InfoFrame MPEG Packet DB1 Register */
+#define SP_INFOFRAME_MPEG_DB1_REG 0xb0
+
+/* Audio Channel Status Registers */
+#define SP_AUD_CH_STATUS_BASE 0xd0
+
+/* Audio Channel Num Register 5 */
+#define SP_I2S_CHANNEL_NUM_MASK 0xe0
+# define SP_I2S_CH_NUM_1 (0x00 << 5)
+# define SP_I2S_CH_NUM_2 (0x01 << 5)
+# define SP_I2S_CH_NUM_3 (0x02 << 5)
+# define SP_I2S_CH_NUM_4 (0x03 << 5)
+# define SP_I2S_CH_NUM_5 (0x04 << 5)
+# define SP_I2S_CH_NUM_6 (0x05 << 5)
+# define SP_I2S_CH_NUM_7 (0x06 << 5)
+# define SP_I2S_CH_NUM_8 (0x07 << 5)
+#define SP_EXT_VUCP BIT(2)
+#define SP_VBIT BIT(1)
+#define SP_AUDIO_LAYOUT BIT(0)
+
+/* Analog Debug Register 2 */
+#define SP_ANALOG_DEBUG2_REG 0xdd
+#define SP_FORCE_SW_OFF_BYPASS 0x20
+#define SP_XTAL_FRQ 0x1c
+# define SP_XTAL_FRQ_19M2 (0x00 << 2)
+# define SP_XTAL_FRQ_24M (0x01 << 2)
+# define SP_XTAL_FRQ_25M (0x02 << 2)
+# define SP_XTAL_FRQ_26M (0x03 << 2)
+# define SP_XTAL_FRQ_27M (0x04 << 2)
+# define SP_XTAL_FRQ_38M4 (0x05 << 2)
+# define SP_XTAL_FRQ_52M (0x06 << 2)
+#define SP_POWERON_TIME_1P5MS 0x03
+
+/* Analog Control 0 Register */
+#define SP_ANALOG_CTRL0_REG 0xe1
+
+/* Common Interrupt Status Register 1 */
+#define SP_COMMON_INT_STATUS_BASE (0xf1 - 1)
+#define SP_PLL_LOCK_CHG 0x40
+
+/* Common Interrupt Status Register 2 */
+#define SP_COMMON_INT_STATUS2 0xf2
+#define SP_HDCP_AUTH_CHG BIT(1)
+#define SP_HDCP_AUTH_DONE BIT(0)
+
+#define SP_HDCP_LINK_CHECK_FAIL BIT(0)
+
+/* Common Interrupt Status Register 4 */
+#define SP_COMMON_INT_STATUS4_REG 0xf4
+#define SP_HPD_IRQ BIT(6)
+#define SP_HPD_ESYNC_ERR BIT(4)
+#define SP_HPD_CHG BIT(2)
+#define SP_HPD_LOST BIT(1)
+#define SP_HPD_PLUG BIT(0)
+
+/* DP Interrupt Status Register */
+#define SP_DP_INT_STATUS1_REG 0xf7
+#define SP_TRAINING_FINISH BIT(5)
+#define SP_POLLING_ERR BIT(4)
+
+/* Common Interrupt Mask Register */
+#define SP_COMMON_INT_MASK_BASE (0xf8 - 1)
+
+#define SP_COMMON_INT_MASK4_REG 0xfb
+
+/* DP Interrupts Mask Register */
+#define SP_DP_INT_MASK1_REG 0xfe
+
+/* Interrupt Control Register */
+#define SP_INT_CTRL_REG 0xff
+
+#endif /* _ANALOGIX_I2C_TXCOMMON_H_ */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 03/12] drm/bridge: extract some Analogix I2C DP common code
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Some code can be shared within different DP bridges by Analogix.
Extract them to a new module.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 4 +
drivers/gpu/drm/bridge/analogix/Makefile | 2 +
.../drm/bridge/analogix/analogix-anx78xx.c | 146 +--------------
.../drm/bridge/analogix/analogix-i2c-dptx.c | 169 ++++++++++++++++++
.../drm/bridge/analogix/analogix-i2c-dptx.h | 2 +
5 files changed, 178 insertions(+), 145 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index c4d343a2f04d..ed2d05c12546 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,5 +1,6 @@
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
+ select DRM_ANALOGIX_DP_I2C
select DRM_KMS_HELPER
select REGMAP_I2C
help
@@ -11,3 +12,6 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_DP_I2C
+ tristate
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index ce1687e60975..2d523b67487d 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,5 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+analogix_dp_i2c-objs := analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
+obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index f8433c93f463..bf8291d0ddd0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -45,8 +45,6 @@
#define I2C_IDX_RX_P1 4
#define XTAL_CLK 270 /* 27M */
-#define AUX_CH_BUFFER_SIZE 16
-#define AUX_WAIT_TIMEOUT_MS 15
static const u8 anx78xx_i2c_addresses[] = {
[I2C_IDX_TX_P0] = TX_P0,
@@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8 reg, u8 mask)
return regmap_update_bits(map, reg, mask, 0);
}
-static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx)
-{
- unsigned int value;
- int err;
-
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG,
- &value);
- if (err < 0)
- return false;
-
- return (value & SP_AUX_EN) == 0;
-}
-
-static int anx78xx_aux_wait(struct anx78xx *anx78xx)
-{
- unsigned long timeout;
- unsigned int status;
- int err;
-
- timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
-
- while (!anx78xx_aux_op_finished(anx78xx)) {
- if (time_after(jiffies, timeout)) {
- if (!anx78xx_aux_op_finished(anx78xx)) {
- DRM_ERROR("Timed out waiting AUX to finish\n");
- return -ETIMEDOUT;
- }
-
- break;
- }
-
- usleep_range(1000, 2000);
- }
-
- /* Read the AUX channel access status */
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG,
- &status);
- if (err < 0) {
- DRM_ERROR("Failed to read from AUX channel: %d\n", err);
- return err;
- }
-
- if (status & SP_AUX_STATUS) {
- DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
- status);
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr)
-{
- int err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG,
- addr & 0xff);
- if (err)
- return err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG,
- (addr & 0xff00) >> 8);
- if (err)
- return err;
-
- /*
- * DP AUX CH Address Register #2, only update bits[3:0]
- * [7:4] RESERVED
- * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
- */
- err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_AUX_ADDR_19_16_REG,
- SP_AUX_ADDR_19_16_MASK,
- (addr & 0xf0000) >> 16);
-
- if (err)
- return err;
-
- return 0;
-}
-
static ssize_t anx78xx_aux_transfer(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
{
struct anx78xx *anx78xx = container_of(aux, struct anx78xx, aux);
- u8 ctrl1 = msg->request;
- u8 ctrl2 = SP_AUX_EN;
- u8 *buffer = msg->buffer;
- int err;
-
- /* The DP AUX transmit and receive buffer has 16 bytes. */
- if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE))
- return -E2BIG;
-
- /* Zero-sized messages specify address-only transactions. */
- if (msg->size < 1)
- ctrl2 |= SP_ADDR_ONLY;
- else /* For non-zero-sized set the length field. */
- ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
-
- if ((msg->request & DP_AUX_I2C_READ) == 0) {
- /* When WRITE | MOT write values to data buffer */
- err = regmap_bulk_write(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_BUF_DATA0_REG, buffer,
- msg->size);
- if (err)
- return err;
- }
-
- /* Write address and request */
- err = anx78xx_aux_address(anx78xx, msg->address);
- if (err)
- return err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL1_REG,
- ctrl1);
- if (err)
- return err;
-
- /* Start transaction */
- err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY |
- SP_AUX_EN, ctrl2);
- if (err)
- return err;
-
- err = anx78xx_aux_wait(anx78xx);
- if (err)
- return err;
-
- msg->reply = DP_AUX_I2C_REPLY_ACK;
-
- if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) {
- /* Read values from data buffer */
- err = regmap_bulk_read(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_BUF_DATA0_REG, buffer,
- msg->size);
- if (err)
- return err;
- }
-
- err = anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY);
- if (err)
- return err;
-
- return msg->size;
+ return anx_aux_transfer(anx78xx->map[I2C_IDX_TX_P0], msg);
}
static int anx78xx_set_hpd(struct anx78xx *anx78xx)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
new file mode 100644
index 000000000000..9cb30962032e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
+ *
+ * Based on analogix-anx78xx.c, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#include <drm/drm.h>
+#include <drm/drmP.h>
+#include <drm/drm_dp_helper.h>
+
+#include "analogix-i2c-dptx.h"
+
+#define AUX_WAIT_TIMEOUT_MS 15
+#define AUX_CH_BUFFER_SIZE 16
+
+static int anx_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static bool anx_aux_op_finished(struct regmap *map_dptx)
+{
+ unsigned int value;
+ int err;
+
+ err = regmap_read(map_dptx, SP_DP_AUX_CH_CTRL2_REG, &value);
+ if (err < 0)
+ return false;
+
+ return (value & SP_AUX_EN) == 0;
+}
+
+static int anx_aux_wait(struct regmap *map_dptx)
+{
+ unsigned long timeout;
+ unsigned int status;
+ int err;
+
+ timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
+
+ while (!anx_aux_op_finished(map_dptx)) {
+ if (time_after(jiffies, timeout)) {
+ if (!anx_aux_op_finished(map_dptx)) {
+ DRM_ERROR("Timed out waiting AUX to finish\n");
+ return -ETIMEDOUT;
+ }
+
+ break;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ /* Read the AUX channel access status */
+ err = regmap_read(map_dptx, SP_AUX_CH_STATUS_REG, &status);
+ if (err < 0) {
+ DRM_ERROR("Failed to read from AUX channel: %d\n", err);
+ return err;
+ }
+
+ if (status & SP_AUX_STATUS) {
+ DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
+ status);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int anx_aux_address(struct regmap *map_dptx, unsigned int addr)
+{
+ int err;
+
+ err = regmap_write(map_dptx, SP_AUX_ADDR_7_0_REG, addr & 0xff);
+ if (err)
+ return err;
+
+ err = regmap_write(map_dptx, SP_AUX_ADDR_15_8_REG,
+ (addr & 0xff00) >> 8);
+ if (err)
+ return err;
+
+ /*
+ * DP AUX CH Address Register #2, only update bits[3:0]
+ * [7:4] RESERVED
+ * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
+ */
+ err = regmap_update_bits(map_dptx, SP_AUX_ADDR_19_16_REG,
+ SP_AUX_ADDR_19_16_MASK,
+ (addr & 0xf0000) >> 16);
+
+ if (err)
+ return err;
+
+ return 0;
+}
+
+ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg)
+{
+ u8 ctrl1 = msg->request;
+ u8 ctrl2 = SP_AUX_EN;
+ u8 *buffer = msg->buffer;
+ int err;
+
+ /* The DP AUX transmit and receive buffer has 16 bytes. */
+ if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE))
+ return -E2BIG;
+
+ /* Zero-sized messages specify address-only transactions. */
+ if (msg->size < 1)
+ ctrl2 |= SP_ADDR_ONLY;
+ else /* For non-zero-sized set the length field. */
+ ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
+
+ if ((msg->request & DP_AUX_I2C_READ) == 0) {
+ /* When WRITE | MOT write values to data buffer */
+ err = regmap_bulk_write(map_dptx,
+ SP_DP_BUF_DATA0_REG, buffer,
+ msg->size);
+ if (err)
+ return err;
+ }
+
+ /* Write address and request */
+ err = anx_aux_address(map_dptx, msg->address);
+ if (err)
+ return err;
+
+ err = regmap_write(map_dptx, SP_DP_AUX_CH_CTRL1_REG, ctrl1);
+ if (err)
+ return err;
+
+ /* Start transaction */
+ err = regmap_update_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
+ SP_ADDR_ONLY | SP_AUX_EN, ctrl2);
+ if (err)
+ return err;
+
+ err = anx_aux_wait(map_dptx);
+ if (err)
+ return err;
+
+ msg->reply = DP_AUX_I2C_REPLY_ACK;
+
+ if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) {
+ /* Read values from data buffer */
+ err = regmap_bulk_read(map_dptx,
+ SP_DP_BUF_DATA0_REG, buffer,
+ msg->size);
+ if (err)
+ return err;
+ }
+
+ err = anx_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY);
+ if (err)
+ return err;
+
+ return msg->size;
+}
+EXPORT_SYMBOL(anx_aux_transfer);
+
+MODULE_DESCRIPTION("Analogix DisplayPort Transmitter common code");
+MODULE_AUTHOR("Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index bc0831b127bf..c2ca854613a0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -245,4 +245,6 @@
/* DP AUX Buffer Data Registers */
#define SP_DP_BUF_DATA0_REG 0xf0
+ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg);
+
#endif
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 03/12] drm/bridge: extract some Analogix I2C DP common code
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
Some code can be shared within different DP bridges by Analogix.
Extract them to a new module.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 4 +
drivers/gpu/drm/bridge/analogix/Makefile | 2 +
.../drm/bridge/analogix/analogix-anx78xx.c | 146 +--------------
.../drm/bridge/analogix/analogix-i2c-dptx.c | 169 ++++++++++++++++++
.../drm/bridge/analogix/analogix-i2c-dptx.h | 2 +
5 files changed, 178 insertions(+), 145 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index c4d343a2f04d..ed2d05c12546 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,5 +1,6 @@
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
+ select DRM_ANALOGIX_DP_I2C
select DRM_KMS_HELPER
select REGMAP_I2C
help
@@ -11,3 +12,6 @@ config DRM_ANALOGIX_ANX78XX
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_DP_I2C
+ tristate
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index ce1687e60975..2d523b67487d 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,5 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+analogix_dp_i2c-objs := analogix-i2c-dptx.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
+obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index f8433c93f463..bf8291d0ddd0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -45,8 +45,6 @@
#define I2C_IDX_RX_P1 4
#define XTAL_CLK 270 /* 27M */
-#define AUX_CH_BUFFER_SIZE 16
-#define AUX_WAIT_TIMEOUT_MS 15
static const u8 anx78xx_i2c_addresses[] = {
[I2C_IDX_TX_P0] = TX_P0,
@@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8 reg, u8 mask)
return regmap_update_bits(map, reg, mask, 0);
}
-static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx)
-{
- unsigned int value;
- int err;
-
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG,
- &value);
- if (err < 0)
- return false;
-
- return (value & SP_AUX_EN) == 0;
-}
-
-static int anx78xx_aux_wait(struct anx78xx *anx78xx)
-{
- unsigned long timeout;
- unsigned int status;
- int err;
-
- timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
-
- while (!anx78xx_aux_op_finished(anx78xx)) {
- if (time_after(jiffies, timeout)) {
- if (!anx78xx_aux_op_finished(anx78xx)) {
- DRM_ERROR("Timed out waiting AUX to finish\n");
- return -ETIMEDOUT;
- }
-
- break;
- }
-
- usleep_range(1000, 2000);
- }
-
- /* Read the AUX channel access status */
- err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG,
- &status);
- if (err < 0) {
- DRM_ERROR("Failed to read from AUX channel: %d\n", err);
- return err;
- }
-
- if (status & SP_AUX_STATUS) {
- DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
- status);
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr)
-{
- int err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG,
- addr & 0xff);
- if (err)
- return err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG,
- (addr & 0xff00) >> 8);
- if (err)
- return err;
-
- /*
- * DP AUX CH Address Register #2, only update bits[3:0]
- * [7:4] RESERVED
- * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
- */
- err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_AUX_ADDR_19_16_REG,
- SP_AUX_ADDR_19_16_MASK,
- (addr & 0xf0000) >> 16);
-
- if (err)
- return err;
-
- return 0;
-}
-
static ssize_t anx78xx_aux_transfer(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
{
struct anx78xx *anx78xx = container_of(aux, struct anx78xx, aux);
- u8 ctrl1 = msg->request;
- u8 ctrl2 = SP_AUX_EN;
- u8 *buffer = msg->buffer;
- int err;
-
- /* The DP AUX transmit and receive buffer has 16 bytes. */
- if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE))
- return -E2BIG;
-
- /* Zero-sized messages specify address-only transactions. */
- if (msg->size < 1)
- ctrl2 |= SP_ADDR_ONLY;
- else /* For non-zero-sized set the length field. */
- ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
-
- if ((msg->request & DP_AUX_I2C_READ) == 0) {
- /* When WRITE | MOT write values to data buffer */
- err = regmap_bulk_write(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_BUF_DATA0_REG, buffer,
- msg->size);
- if (err)
- return err;
- }
-
- /* Write address and request */
- err = anx78xx_aux_address(anx78xx, msg->address);
- if (err)
- return err;
-
- err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL1_REG,
- ctrl1);
- if (err)
- return err;
-
- /* Start transaction */
- err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY |
- SP_AUX_EN, ctrl2);
- if (err)
- return err;
-
- err = anx78xx_aux_wait(anx78xx);
- if (err)
- return err;
-
- msg->reply = DP_AUX_I2C_REPLY_ACK;
-
- if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) {
- /* Read values from data buffer */
- err = regmap_bulk_read(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_BUF_DATA0_REG, buffer,
- msg->size);
- if (err)
- return err;
- }
-
- err = anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY);
- if (err)
- return err;
-
- return msg->size;
+ return anx_aux_transfer(anx78xx->map[I2C_IDX_TX_P0], msg);
}
static int anx78xx_set_hpd(struct anx78xx *anx78xx)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
new file mode 100644
index 000000000000..9cb30962032e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2017 Icenowy Zheng <icenowy@aosc.io>
+ *
+ * Based on analogix-anx78xx.c, which is:
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ */
+
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#include <drm/drm.h>
+#include <drm/drmP.h>
+#include <drm/drm_dp_helper.h>
+
+#include "analogix-i2c-dptx.h"
+
+#define AUX_WAIT_TIMEOUT_MS 15
+#define AUX_CH_BUFFER_SIZE 16
+
+static int anx_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static bool anx_aux_op_finished(struct regmap *map_dptx)
+{
+ unsigned int value;
+ int err;
+
+ err = regmap_read(map_dptx, SP_DP_AUX_CH_CTRL2_REG, &value);
+ if (err < 0)
+ return false;
+
+ return (value & SP_AUX_EN) == 0;
+}
+
+static int anx_aux_wait(struct regmap *map_dptx)
+{
+ unsigned long timeout;
+ unsigned int status;
+ int err;
+
+ timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
+
+ while (!anx_aux_op_finished(map_dptx)) {
+ if (time_after(jiffies, timeout)) {
+ if (!anx_aux_op_finished(map_dptx)) {
+ DRM_ERROR("Timed out waiting AUX to finish\n");
+ return -ETIMEDOUT;
+ }
+
+ break;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ /* Read the AUX channel access status */
+ err = regmap_read(map_dptx, SP_AUX_CH_STATUS_REG, &status);
+ if (err < 0) {
+ DRM_ERROR("Failed to read from AUX channel: %d\n", err);
+ return err;
+ }
+
+ if (status & SP_AUX_STATUS) {
+ DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
+ status);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int anx_aux_address(struct regmap *map_dptx, unsigned int addr)
+{
+ int err;
+
+ err = regmap_write(map_dptx, SP_AUX_ADDR_7_0_REG, addr & 0xff);
+ if (err)
+ return err;
+
+ err = regmap_write(map_dptx, SP_AUX_ADDR_15_8_REG,
+ (addr & 0xff00) >> 8);
+ if (err)
+ return err;
+
+ /*
+ * DP AUX CH Address Register #2, only update bits[3:0]
+ * [7:4] RESERVED
+ * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
+ */
+ err = regmap_update_bits(map_dptx, SP_AUX_ADDR_19_16_REG,
+ SP_AUX_ADDR_19_16_MASK,
+ (addr & 0xf0000) >> 16);
+
+ if (err)
+ return err;
+
+ return 0;
+}
+
+ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg)
+{
+ u8 ctrl1 = msg->request;
+ u8 ctrl2 = SP_AUX_EN;
+ u8 *buffer = msg->buffer;
+ int err;
+
+ /* The DP AUX transmit and receive buffer has 16 bytes. */
+ if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE))
+ return -E2BIG;
+
+ /* Zero-sized messages specify address-only transactions. */
+ if (msg->size < 1)
+ ctrl2 |= SP_ADDR_ONLY;
+ else /* For non-zero-sized set the length field. */
+ ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
+
+ if ((msg->request & DP_AUX_I2C_READ) == 0) {
+ /* When WRITE | MOT write values to data buffer */
+ err = regmap_bulk_write(map_dptx,
+ SP_DP_BUF_DATA0_REG, buffer,
+ msg->size);
+ if (err)
+ return err;
+ }
+
+ /* Write address and request */
+ err = anx_aux_address(map_dptx, msg->address);
+ if (err)
+ return err;
+
+ err = regmap_write(map_dptx, SP_DP_AUX_CH_CTRL1_REG, ctrl1);
+ if (err)
+ return err;
+
+ /* Start transaction */
+ err = regmap_update_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
+ SP_ADDR_ONLY | SP_AUX_EN, ctrl2);
+ if (err)
+ return err;
+
+ err = anx_aux_wait(map_dptx);
+ if (err)
+ return err;
+
+ msg->reply = DP_AUX_I2C_REPLY_ACK;
+
+ if ((msg->size > 0) && (msg->request & DP_AUX_I2C_READ)) {
+ /* Read values from data buffer */
+ err = regmap_bulk_read(map_dptx,
+ SP_DP_BUF_DATA0_REG, buffer,
+ msg->size);
+ if (err)
+ return err;
+ }
+
+ err = anx_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG, SP_ADDR_ONLY);
+ if (err)
+ return err;
+
+ return msg->size;
+}
+EXPORT_SYMBOL(anx_aux_transfer);
+
+MODULE_DESCRIPTION("Analogix DisplayPort Transmitter common code");
+MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.io>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index bc0831b127bf..c2ca854613a0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -245,4 +245,6 @@
/* DP AUX Buffer Data Registers */
#define SP_DP_BUF_DATA0_REG 0xf0
+ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg);
+
#endif
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 04/12] dt-bindings: Add ANX6345 DP/eDP transmitter binding
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../bindings/display/bridge/anx6345.txt | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
new file mode 100644
index 000000000000..e79a11348d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,56 @@
+Analogix ANX6345 eDP Transmitter
+--------------------------------
+
+The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
+portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx6345"
+ - reg : I2C address of the device
+ - reset-gpios : Which GPIO to use for reset
+
+Optional properties:
+
+ - dvdd12-supply : Regulator for 1.2V digital core power.
+ - dvdd25-supply : Regulator for 2.5V digital core power.
+ - Video ports for RGB input and eDP output using the DT bindings
+ defined in [1]
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_fldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+};
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 04/12] dt-bindings: Add ANX6345 DP/eDP transmitter binding
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
.../bindings/display/bridge/anx6345.txt | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
new file mode 100644
index 000000000000..e79a11348d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,56 @@
+Analogix ANX6345 eDP Transmitter
+--------------------------------
+
+The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
+portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx6345"
+ - reg : I2C address of the device
+ - reset-gpios : Which GPIO to use for reset
+
+Optional properties:
+
+ - dvdd12-supply : Regulator for 1.2V digital core power.
+ - dvdd25-supply : Regulator for 2.5V digital core power.
+ - Video ports for RGB input and eDP output using the DT bindings
+ defined in [1]
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_fldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 05/12] drm/bridge: Add Analogix anx6345 support
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 11 +
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../drm/bridge/analogix/analogix-anx6345.c | 845 ++++++++++++++++++
.../drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
.../drm/bridge/analogix/analogix-i2c-dptx.h | 8 +
.../bridge/analogix/analogix-i2c-txcommon.h | 3 +
6 files changed, 869 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index ed2d05c12546..3c6ec535d361 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,14 @@
+config DRM_ANALOGIX_ANX6345
+ tristate "Analogix ANX6345 bridge"
+ select DRM_ANALOGIX_DP_I2C
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX6345 is an ultra-low Full-HD DisplayPort/eDP
+ transmitter designed for portable devices. The
+ ANX6345 transforms the LVTTL RGB output of an
+ application processor to eDP or DisplayPort.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP_I2C
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 2d523b67487d..12fed7b04e1e 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
analogix_dp_i2c-objs := analogix-i2c-dptx.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
new file mode 100644
index 000000000000..e275f5c9e8c4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -0,0 +1,845 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
+ * Based on analogix-anx6345.c, which is:
+ * Copyright(c) 2016, Analogix Semiconductor.
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_dp_helper.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+
+#include "analogix-i2c-dptx.h"
+#include "analogix-i2c-txcommon.h"
+
+#define I2C_NUM_ADDRESSES 2
+#define I2C_IDX_DPTX 0
+#define I2C_IDX_TXCOM 1
+
+#define XTAL_CLK 270 /* 27M */
+
+#define POLL_DELAY 50000 /* us */
+#define POLL_TIMEOUT 5000000 /* us */
+
+static const u8 anx6345_i2c_addresses[] = {
+ [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX,
+ [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
+};
+
+struct anx6345_platform_data {
+ struct regulator *dvdd12;
+ struct regulator *dvdd25;
+ struct gpio_desc *gpiod_reset;
+};
+
+struct anx6345 {
+ struct drm_dp_aux aux;
+ struct drm_bridge bridge;
+ struct i2c_client *client;
+ struct edid *edid;
+ struct drm_connector connector;
+ struct drm_dp_link link;
+ struct drm_panel *panel;
+ struct anx6345_platform_data pdata;
+ struct mutex lock;
+
+ /*
+ * I2C Slave addresses of ANX6345 are mapped as DPTX and SYS
+ */
+ struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
+ struct regmap *map[I2C_NUM_ADDRESSES];
+
+ u16 chipid;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
+
+ bool powered;
+};
+
+static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
+{
+ return container_of(c, struct anx6345, connector);
+}
+
+static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx6345, bridge);
+}
+
+static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, mask);
+}
+
+static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux);
+
+ return anx_aux_transfer(anx6345->map[I2C_IDX_DPTX], msg);
+}
+
+static int anx6345_dp_link_training(struct anx6345 *anx6345)
+{
+ unsigned int value;
+ u8 dp_bw;
+ int err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_POWERDOWN_CTRL_REG,
+ SP_TOTAL_PD);
+ if (err)
+ return err;
+
+ err = drm_dp_dpcd_readb(&anx6345->aux, DP_MAX_LINK_RATE, &dp_bw);
+ if (err < 0)
+ return err;
+
+ switch (dp_bw) {
+ case DP_LINK_BW_1_62:
+ case DP_LINK_BW_2_7:
+ break;
+
+ default:
+ DRM_DEBUG_KMS("DP bandwidth (%#02x) not supported\n", dp_bw);
+ return -EINVAL;
+ }
+
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_MUTE);
+ if (err)
+ return err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_VID_CTRL1_REG, SP_VIDEO_EN);
+ if (err)
+ return err;
+
+ /* Get DPCD info */
+ err = drm_dp_dpcd_read(&anx6345->aux, DP_DPCD_REV,
+ &anx6345->dpcd, DP_RECEIVER_CAP_SIZE);
+ if (err < 0) {
+ DRM_ERROR("Failed to read DPCD: %d\n", err);
+ return err;
+ }
+
+ /* Clear channel x SERDES power down */
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_ANALOG_POWER_DOWN_REG, SP_CH0_PD);
+ if (err)
+ return err;
+
+ /* Check link capabilities */
+ err = drm_dp_link_probe(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to probe link capabilities: %d\n", err);
+ return err;
+ }
+
+ /* Power up the sink */
+ err = drm_dp_link_power_up(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to power up DisplayPort link: %d\n", err);
+ return err;
+ }
+
+ /* Possibly enable downspread on the sink */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_DOWNSPREAD_CTRL1_REG, 0);
+ if (err)
+ return err;
+
+ if (anx6345->dpcd[DP_MAX_DOWNSPREAD] & DP_MAX_DOWNSPREAD_0_5) {
+ DRM_DEBUG("Enable downspread on the sink\n");
+ /* 4000PPM */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_DOWNSPREAD_CTRL1_REG, 8);
+ if (err)
+ return err;
+
+ err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL,
+ DP_SPREAD_AMP_0_5);
+ if (err < 0)
+ return err;
+ } else {
+ err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL, 0);
+ if (err < 0)
+ return err;
+ }
+
+ /* Set the lane count and the link rate on the sink */
+ if (drm_dp_enhanced_frame_cap(anx6345->dpcd))
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 4,
+ SP_ENHANCED_MODE);
+ else
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 4,
+ SP_ENHANCED_MODE);
+ if (err)
+ return err;
+
+ value = drm_dp_link_rate_to_bw_code(anx6345->link.rate);
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_MAIN_LINK_BW_SET_REG, value);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LANE_COUNT_SET_REG, anx6345->link.num_lanes);
+ if (err)
+ return err;
+
+ err = drm_dp_link_configure(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to configure DisplayPort link: %d\n", err);
+ return err;
+ }
+
+ /* Start training on the source */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_LT_CTRL_REG,
+ SP_LT_EN);
+ if (err)
+ return err;
+
+ err = regmap_read_poll_timeout(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LT_CTRL_REG,
+ value, !(value & SP_DP_LT_INPROGRESS),
+ POLL_DELAY, POLL_TIMEOUT);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int anx6345_tx_initialization(struct anx6345 *anx6345)
+{
+ int err, i;
+
+ /* FIXME: hardcode color depth now */
+ err = regmap_write(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL2_REG,
+ SP_IN_BPC_6BIT << SP_IN_BPC_SHIFT);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_PLL_CTRL_REG, 0);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_TXCOM],
+ SP_ANALOG_DEBUG1_REG, 0);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LINK_DEBUG_CTRL_REG,
+ SP_NEW_PRBS7 | SP_M_VID_DEBUG);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_ANALOG_POWER_DOWN_REG, 0);
+ if (err)
+ return err;
+
+ /* Force HPD */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 3,
+ SP_HPD_FORCE | SP_HPD_CTRL);
+ if (err)
+ return err;
+
+ for (i = 0; i < 4; i++) {
+ /* 4 lanes */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LANE0_LT_CTRL_REG + i, 0);
+ if (err)
+ return err;
+ }
+
+ /* Reset AUX */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_RESET_CTRL2_REG, SP_AUX_RST);
+ if (err)
+ return err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_RESET_CTRL2_REG, SP_AUX_RST);
+ if (err)
+ return err;
+
+ err = anx6345_dp_link_training(anx6345);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static void anx6345_poweron(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ int err;
+
+ if (WARN_ON(anx6345->powered))
+ return;
+
+ if (pdata->dvdd12) {
+ err = regulator_enable(pdata->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to enable DVDD12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ if (pdata->dvdd25) {
+ err = regulator_enable(pdata->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to enable DVDD25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+ }
+
+ if (anx6345->panel)
+ drm_panel_prepare(anx6345->panel);
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
+ usleep_range(1000, 2000);
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
+
+ /* Power on registers module */
+ anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
+ anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_REGISTER_PD | SP_TOTAL_PD);
+
+ anx6345->powered = true;
+}
+
+static void anx6345_poweroff(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ int err;
+
+ if (WARN_ON(!anx6345->powered))
+ return;
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ if (anx6345->panel)
+ drm_panel_unprepare(anx6345->panel);
+
+ if (pdata->dvdd25) {
+ err = regulator_disable(pdata->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to disable DVDD25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+ }
+
+ if (pdata->dvdd12) {
+ err = regulator_disable(pdata->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to disable DVDD12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ anx6345->powered = false;
+}
+
+static int anx6345_start(struct anx6345 *anx6345)
+{
+ int err;
+
+ if (!anx6345->powered)
+ anx6345_poweron(anx6345);
+
+ /* Power on needed modules */
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_POWERDOWN_CTRL_REG,
+ SP_VIDEO_PD | SP_LINK_PD);
+
+ err = anx6345_tx_initialization(anx6345);
+ if (err) {
+ DRM_ERROR("Failed transmitter initialization: %d\n", err);
+ goto err_poweroff;
+ }
+
+ /*
+ * This delay seems to help keep the hardware in a good state. Without
+ * it, there are times where it fails silently.
+ */
+ usleep_range(10000, 15000);
+
+ return 0;
+
+err_poweroff:
+ DRM_ERROR("Failed DisplayPort transmitter initialization: %d\n", err);
+ anx6345_poweroff(anx6345);
+
+ return err;
+}
+
+static int anx6345_init_pdata(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ struct device *dev = &anx6345->client->dev;
+
+ /* 1.2V digital core power regulator */
+ pdata->dvdd12 = devm_regulator_get(dev, "dvdd12");
+ if (IS_ERR(pdata->dvdd12)) {
+ DRM_ERROR("DVDD12 regulator not found\n");
+ return PTR_ERR(pdata->dvdd12);
+ }
+
+ /* 2.5V digital core power regulator */
+ pdata->dvdd25 = devm_regulator_get(dev, "dvdd25");
+ if (IS_ERR(pdata->dvdd25)) {
+ DRM_ERROR("DVDD25 regulator not found\n");
+ return PTR_ERR(pdata->dvdd25);
+ }
+
+ /* GPIO for chip reset */
+ pdata->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+
+ return PTR_ERR_OR_ZERO(pdata->gpiod_reset);
+}
+
+static int anx6345_config_dp_output(struct anx6345 *anx6345)
+{
+ int err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_MUTE);
+ if (err)
+ return err;
+
+ /* Enable DP output */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_EN);
+ if (err)
+ return err;
+
+ /* Force stream valid */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 3,
+ SP_STRM_FORCE | SP_STRM_CTRL);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int anx6345_get_downstream_info(struct anx6345 *anx6345)
+{
+ u8 value;
+ int err;
+
+ err = drm_dp_dpcd_readb(&anx6345->aux, DP_SINK_COUNT, &value);
+ if (err < 0) {
+ DRM_ERROR("Get sink count failed %d\n", err);
+ return err;
+ }
+
+ if (!DP_GET_SINK_COUNT(value)) {
+ DRM_ERROR("Downstream disconnected\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int anx6345_get_modes(struct drm_connector *connector)
+{
+ struct anx6345 *anx6345 = connector_to_anx6345(connector);
+ int err, num_modes = 0;
+
+ if (WARN_ON(!anx6345->powered))
+ return 0;
+
+ mutex_lock(&anx6345->lock);
+
+ if (!anx6345->edid) {
+ err = anx6345_get_downstream_info(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to get downstream info: %d\n", err);
+ goto unlock;
+ }
+
+ anx6345->edid = drm_get_edid(connector, &anx6345->aux.ddc);
+ if (!anx6345->edid)
+ DRM_ERROR("Failed to read EDID from panel\n");
+
+ err = drm_connector_update_edid_property(connector,
+ anx6345->edid);
+ if (err) {
+ DRM_ERROR("Failed to update EDID property: %d\n", err);
+ goto unlock;
+ }
+ }
+
+ num_modes += drm_add_edid_modes(connector, anx6345->edid);
+
+unlock:
+ mutex_unlock(&anx6345->lock);
+
+ if (anx6345->panel)
+ num_modes += drm_panel_get_modes(anx6345->panel);
+
+ return num_modes;
+}
+
+static const struct drm_connector_helper_funcs anx6345_connector_helper_funcs = {
+ .get_modes = anx6345_get_modes,
+};
+
+static enum drm_connector_status anx6345_detect(struct drm_connector *connector,
+ bool force)
+{
+ return connector_status_connected;
+}
+
+static void
+anx6345_connector_destroy(struct drm_connector *connector)
+{
+ struct anx6345 *anx6345 = connector_to_anx6345(connector);
+
+ if (anx6345->panel)
+ drm_panel_detach(anx6345->panel);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs anx6345_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = anx6345_detect,
+ .destroy = anx6345_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int anx6345_bridge_attach(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+ int err;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ /* Register aux channel */
+ anx6345->aux.name = "DP-AUX";
+ anx6345->aux.dev = &anx6345->client->dev;
+ anx6345->aux.transfer = anx6345_aux_transfer;
+
+ err = drm_dp_aux_register(&anx6345->aux);
+ if (err < 0) {
+ DRM_ERROR("Failed to register aux channel: %d\n", err);
+ return err;
+ }
+
+ err = drm_connector_init(bridge->dev, &anx6345->connector,
+ &anx6345_connector_funcs,
+ DRM_MODE_CONNECTOR_eDP);
+ if (err) {
+ DRM_ERROR("Failed to initialize connector: %d\n", err);
+ return err;
+ }
+
+ drm_connector_helper_add(&anx6345->connector,
+ &anx6345_connector_helper_funcs);
+
+ err = drm_connector_register(&anx6345->connector);
+ if (err) {
+ DRM_ERROR("Failed to register connector: %d\n", err);
+ return err;
+ }
+
+ anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
+ err = drm_connector_attach_encoder(&anx6345->connector,
+ bridge->encoder);
+ if (err) {
+ DRM_ERROR("Failed to link up connector to encoder: %d\n", err);
+ return err;
+ }
+
+ if (anx6345->panel) {
+ err = drm_panel_attach(anx6345->panel, &anx6345->connector);
+ if (err) {
+ DRM_ERROR("Failed to attach panel: %d\n", err);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static bool anx6345_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ return false;
+
+ /* Max 1200p at 5.4 Ghz, one lane */
+ if (mode->clock > 154000)
+ return false;
+
+ return true;
+}
+
+static void anx6345_bridge_disable(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+
+ /* Power off all modules except configuration registers access */
+ anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
+ if (anx6345->panel)
+ drm_panel_disable(anx6345->panel);
+}
+
+static void anx6345_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+
+ if (WARN_ON(!anx6345->powered))
+ return;
+}
+
+static void anx6345_bridge_enable(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+ int err;
+
+ if (anx6345->panel)
+ drm_panel_enable(anx6345->panel);
+
+ err = anx6345_start(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to initialize: %d\n", err);
+ return;
+ }
+
+ err = anx6345_config_dp_output(anx6345);
+ if (err)
+ DRM_ERROR("Failed to enable DP output: %d\n", err);
+}
+
+static const struct drm_bridge_funcs anx6345_bridge_funcs = {
+ .attach = anx6345_bridge_attach,
+ .mode_fixup = anx6345_bridge_mode_fixup,
+ .disable = anx6345_bridge_disable,
+ .mode_set = anx6345_bridge_mode_set,
+ .enable = anx6345_bridge_enable,
+};
+
+static void unregister_i2c_dummy_clients(struct anx6345 *anx6345)
+{
+ unsigned int i;
+
+ for (i = 1; i < ARRAY_SIZE(anx6345->i2c_clients); i++)
+ if (anx6345->i2c_clients[i] &&
+ anx6345->i2c_clients[i]->addr != anx6345->client->addr)
+ i2c_unregister_device(anx6345->i2c_clients[i]);
+}
+
+static const struct regmap_config anx6345_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0xff,
+};
+
+static const u16 anx6345_chipid_list[] = {
+ 0x6345,
+};
+
+static int anx6345_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct anx6345 *anx6345;
+ struct anx6345_platform_data *pdata;
+ unsigned int i, idl, idh, version;
+ bool found = false;
+ int err;
+
+ anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
+ if (!anx6345)
+ return -ENOMEM;
+
+ pdata = &anx6345->pdata;
+
+ mutex_init(&anx6345->lock);
+
+ anx6345->bridge.of_node = client->dev.of_node;
+
+ anx6345->client = client;
+ i2c_set_clientdata(client, anx6345);
+
+ err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0,
+ &anx6345->panel, NULL);
+ if (err == -EPROBE_DEFER)
+ return err;
+
+ if (err)
+ DRM_DEBUG("No panel found\n");
+
+ err = anx6345_init_pdata(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to initialize pdata: %d\n", err);
+ return err;
+ }
+
+ /* Map slave addresses of ANX6345 */
+ for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
+ if (anx6345_i2c_addresses[i] >> 1 != client->addr)
+ anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
+ anx6345_i2c_addresses[i] >> 1);
+ else
+ anx6345->i2c_clients[i] = client;
+
+ if (!anx6345->i2c_clients[i]) {
+ err = -ENOMEM;
+ DRM_ERROR("Failed to reserve I2C bus %02x\n",
+ anx6345_i2c_addresses[i]);
+ goto err_unregister_i2c;
+ }
+
+ anx6345->map[i] = devm_regmap_init_i2c(anx6345->i2c_clients[i],
+ &anx6345_regmap_config);
+ if (IS_ERR(anx6345->map[i])) {
+ err = PTR_ERR(anx6345->map[i]);
+ DRM_ERROR("Failed regmap initialization %02x\n",
+ anx6345_i2c_addresses[i]);
+ goto err_unregister_i2c;
+ }
+ }
+
+ /* Look for supported chip ID */
+ anx6345_poweron(anx6345);
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG,
+ &idl);
+ if (err)
+ goto err_poweroff;
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG,
+ &idh);
+ if (err)
+ goto err_poweroff;
+
+ anx6345->chipid = (u8)idl | ((u8)idh << 8);
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
+ &version);
+ if (err)
+ goto err_poweroff;
+
+ for (i = 0; i < ARRAY_SIZE(anx6345_chipid_list); i++) {
+ if (anx6345->chipid == anx6345_chipid_list[i]) {
+ DRM_INFO("Found ANX%x (ver. %d) eDP Transmitter\n",
+ anx6345->chipid, version);
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
+ anx6345->chipid, version);
+ err = -ENODEV;
+ goto err_poweroff;
+ }
+
+ anx6345->bridge.funcs = &anx6345_bridge_funcs;
+
+ drm_bridge_add(&anx6345->bridge);
+
+ return 0;
+
+err_poweroff:
+ anx6345_poweroff(anx6345);
+
+err_unregister_i2c:
+ unregister_i2c_dummy_clients(anx6345);
+ return err;
+}
+
+static int anx6345_i2c_remove(struct i2c_client *client)
+{
+ struct anx6345 *anx6345 = i2c_get_clientdata(client);
+
+ drm_bridge_remove(&anx6345->bridge);
+
+ unregister_i2c_dummy_clients(anx6345);
+
+ kfree(anx6345->edid);
+
+ return 0;
+}
+
+static const struct i2c_device_id anx6345_id[] = {
+ { "anx6345", 0 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, anx6345_id);
+
+static const struct of_device_id anx6345_match_table[] = {
+ { .compatible = "analogix,anx6345", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, anx6345_match_table);
+
+static struct i2c_driver anx6345_driver = {
+ .driver = {
+ .name = "anx6345",
+ .of_match_table = of_match_ptr(anx6345_match_table),
+ },
+ .probe = anx6345_i2c_probe,
+ .remove = anx6345_i2c_remove,
+ .id_table = anx6345_id,
+};
+module_i2c_driver(anx6345_driver);
+
+MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver");
+MODULE_AUTHOR("Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
index 9cb30962032e..53b0e73d6a24 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -117,7 +117,7 @@ ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg)
else /* For non-zero-sized set the length field. */
ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
- if ((msg->request & DP_AUX_I2C_READ) == 0) {
+ if ((msg->size > 0) && ((msg->request & DP_AUX_I2C_READ) == 0)) {
/* When WRITE | MOT write values to data buffer */
err = regmap_bulk_write(map_dptx,
SP_DP_BUF_DATA0_REG, buffer,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index c2ca854613a0..b29a0b3bc23c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -75,7 +75,11 @@
#define SP_CHA_STA BIT(2)
/* Bits for DP System Control Register 3 */
#define SP_HPD_STATUS BIT(6)
+#define SP_HPD_FORCE BIT(5)
+#define SP_HPD_CTRL BIT(4)
#define SP_STRM_VALID BIT(2)
+#define SP_STRM_FORCE BIT(1)
+#define SP_STRM_CTRL BIT(0)
/* Bits for DP System Control Register 4 */
#define SP_ENHANCED_MODE BIT(3)
@@ -120,6 +124,9 @@
#define SP_LINK_BW_SET_MASK 0x1f
#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
+/* DP Lane Count Setting Register */
+#define SP_DP_LANE_COUNT_SET_REG 0xa1
+
/* DP Training Pattern Set Register */
#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
@@ -133,6 +140,7 @@
/* DP Link Training Control Register */
#define SP_DP_LT_CTRL_REG 0xa8
+#define SP_DP_LT_INPROGRESS 0x80
#define SP_LT_ERROR_TYPE_MASK 0x70
# define SP_LT_NO_ERROR 0x00
# define SP_LT_AUX_WRITE_ERROR 0x01
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
index 7d683573e970..480c98a225b1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -183,6 +183,9 @@
#define SP_VBIT BIT(1)
#define SP_AUDIO_LAYOUT BIT(0)
+/* Analog Debug Register 1 */
+#define SP_ANALOG_DEBUG1_REG 0xdc
+
/* Analog Debug Register 2 */
#define SP_ANALOG_DEBUG2_REG 0xdd
#define SP_FORCE_SW_OFF_BYPASS 0x20
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 05/12] drm/bridge: Add Analogix anx6345 support
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 11 +
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
.../drm/bridge/analogix/analogix-anx6345.c | 845 ++++++++++++++++++
.../drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
.../drm/bridge/analogix/analogix-i2c-dptx.h | 8 +
.../bridge/analogix/analogix-i2c-txcommon.h | 3 +
6 files changed, 869 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
index ed2d05c12546..3c6ec535d361 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,3 +1,14 @@
+config DRM_ANALOGIX_ANX6345
+ tristate "Analogix ANX6345 bridge"
+ select DRM_ANALOGIX_DP_I2C
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ ANX6345 is an ultra-low Full-HD DisplayPort/eDP
+ transmitter designed for portable devices. The
+ ANX6345 transforms the LVTTL RGB output of an
+ application processor to eDP or DisplayPort.
+
config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP_I2C
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 2d523b67487d..12fed7b04e1e 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,5 +1,6 @@
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
analogix_dp_i2c-objs := analogix-i2c-dptx.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
obj-$(CONFIG_DRM_ANALOGIX_DP_I2C) += analogix_dp_i2c.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
new file mode 100644
index 000000000000..e275f5c9e8c4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -0,0 +1,845 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) Icenowy Zheng <icenowy@aosc.io>
+ * Based on analogix-anx6345.c, which is:
+ * Copyright(c) 2016, Analogix Semiconductor.
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_dp_helper.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+
+#include "analogix-i2c-dptx.h"
+#include "analogix-i2c-txcommon.h"
+
+#define I2C_NUM_ADDRESSES 2
+#define I2C_IDX_DPTX 0
+#define I2C_IDX_TXCOM 1
+
+#define XTAL_CLK 270 /* 27M */
+
+#define POLL_DELAY 50000 /* us */
+#define POLL_TIMEOUT 5000000 /* us */
+
+static const u8 anx6345_i2c_addresses[] = {
+ [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX,
+ [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
+};
+
+struct anx6345_platform_data {
+ struct regulator *dvdd12;
+ struct regulator *dvdd25;
+ struct gpio_desc *gpiod_reset;
+};
+
+struct anx6345 {
+ struct drm_dp_aux aux;
+ struct drm_bridge bridge;
+ struct i2c_client *client;
+ struct edid *edid;
+ struct drm_connector connector;
+ struct drm_dp_link link;
+ struct drm_panel *panel;
+ struct anx6345_platform_data pdata;
+ struct mutex lock;
+
+ /*
+ * I2C Slave addresses of ANX6345 are mapped as DPTX and SYS
+ */
+ struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
+ struct regmap *map[I2C_NUM_ADDRESSES];
+
+ u16 chipid;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
+
+ bool powered;
+};
+
+static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
+{
+ return container_of(c, struct anx6345, connector);
+}
+
+static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct anx6345, bridge);
+}
+
+static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, mask);
+}
+
+static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux);
+
+ return anx_aux_transfer(anx6345->map[I2C_IDX_DPTX], msg);
+}
+
+static int anx6345_dp_link_training(struct anx6345 *anx6345)
+{
+ unsigned int value;
+ u8 dp_bw;
+ int err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_POWERDOWN_CTRL_REG,
+ SP_TOTAL_PD);
+ if (err)
+ return err;
+
+ err = drm_dp_dpcd_readb(&anx6345->aux, DP_MAX_LINK_RATE, &dp_bw);
+ if (err < 0)
+ return err;
+
+ switch (dp_bw) {
+ case DP_LINK_BW_1_62:
+ case DP_LINK_BW_2_7:
+ break;
+
+ default:
+ DRM_DEBUG_KMS("DP bandwidth (%#02x) not supported\n", dp_bw);
+ return -EINVAL;
+ }
+
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_MUTE);
+ if (err)
+ return err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_VID_CTRL1_REG, SP_VIDEO_EN);
+ if (err)
+ return err;
+
+ /* Get DPCD info */
+ err = drm_dp_dpcd_read(&anx6345->aux, DP_DPCD_REV,
+ &anx6345->dpcd, DP_RECEIVER_CAP_SIZE);
+ if (err < 0) {
+ DRM_ERROR("Failed to read DPCD: %d\n", err);
+ return err;
+ }
+
+ /* Clear channel x SERDES power down */
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_ANALOG_POWER_DOWN_REG, SP_CH0_PD);
+ if (err)
+ return err;
+
+ /* Check link capabilities */
+ err = drm_dp_link_probe(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to probe link capabilities: %d\n", err);
+ return err;
+ }
+
+ /* Power up the sink */
+ err = drm_dp_link_power_up(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to power up DisplayPort link: %d\n", err);
+ return err;
+ }
+
+ /* Possibly enable downspread on the sink */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_DOWNSPREAD_CTRL1_REG, 0);
+ if (err)
+ return err;
+
+ if (anx6345->dpcd[DP_MAX_DOWNSPREAD] & DP_MAX_DOWNSPREAD_0_5) {
+ DRM_DEBUG("Enable downspread on the sink\n");
+ /* 4000PPM */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_DOWNSPREAD_CTRL1_REG, 8);
+ if (err)
+ return err;
+
+ err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL,
+ DP_SPREAD_AMP_0_5);
+ if (err < 0)
+ return err;
+ } else {
+ err = drm_dp_dpcd_writeb(&anx6345->aux, DP_DOWNSPREAD_CTRL, 0);
+ if (err < 0)
+ return err;
+ }
+
+ /* Set the lane count and the link rate on the sink */
+ if (drm_dp_enhanced_frame_cap(anx6345->dpcd))
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 4,
+ SP_ENHANCED_MODE);
+ else
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 4,
+ SP_ENHANCED_MODE);
+ if (err)
+ return err;
+
+ value = drm_dp_link_rate_to_bw_code(anx6345->link.rate);
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_MAIN_LINK_BW_SET_REG, value);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LANE_COUNT_SET_REG, anx6345->link.num_lanes);
+ if (err)
+ return err;
+
+ err = drm_dp_link_configure(&anx6345->aux, &anx6345->link);
+ if (err < 0) {
+ DRM_ERROR("Failed to configure DisplayPort link: %d\n", err);
+ return err;
+ }
+
+ /* Start training on the source */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_LT_CTRL_REG,
+ SP_LT_EN);
+ if (err)
+ return err;
+
+ err = regmap_read_poll_timeout(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LT_CTRL_REG,
+ value, !(value & SP_DP_LT_INPROGRESS),
+ POLL_DELAY, POLL_TIMEOUT);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int anx6345_tx_initialization(struct anx6345 *anx6345)
+{
+ int err, i;
+
+ /* FIXME: hardcode color depth now */
+ err = regmap_write(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL2_REG,
+ SP_IN_BPC_6BIT << SP_IN_BPC_SHIFT);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX], SP_DP_PLL_CTRL_REG, 0);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_TXCOM],
+ SP_ANALOG_DEBUG1_REG, 0);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LINK_DEBUG_CTRL_REG,
+ SP_NEW_PRBS7 | SP_M_VID_DEBUG);
+ if (err)
+ return err;
+
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_ANALOG_POWER_DOWN_REG, 0);
+ if (err)
+ return err;
+
+ /* Force HPD */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 3,
+ SP_HPD_FORCE | SP_HPD_CTRL);
+ if (err)
+ return err;
+
+ for (i = 0; i < 4; i++) {
+ /* 4 lanes */
+ err = regmap_write(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_LANE0_LT_CTRL_REG + i, 0);
+ if (err)
+ return err;
+ }
+
+ /* Reset AUX */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_RESET_CTRL2_REG, SP_AUX_RST);
+ if (err)
+ return err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_RESET_CTRL2_REG, SP_AUX_RST);
+ if (err)
+ return err;
+
+ err = anx6345_dp_link_training(anx6345);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static void anx6345_poweron(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ int err;
+
+ if (WARN_ON(anx6345->powered))
+ return;
+
+ if (pdata->dvdd12) {
+ err = regulator_enable(pdata->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to enable DVDD12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ if (pdata->dvdd25) {
+ err = regulator_enable(pdata->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to enable DVDD25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+ }
+
+ if (anx6345->panel)
+ drm_panel_prepare(anx6345->panel);
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
+ usleep_range(1000, 2000);
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
+
+ /* Power on registers module */
+ anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
+ anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_REGISTER_PD | SP_TOTAL_PD);
+
+ anx6345->powered = true;
+}
+
+static void anx6345_poweroff(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ int err;
+
+ if (WARN_ON(!anx6345->powered))
+ return;
+
+ gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ if (anx6345->panel)
+ drm_panel_unprepare(anx6345->panel);
+
+ if (pdata->dvdd25) {
+ err = regulator_disable(pdata->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to disable DVDD25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+ }
+
+ if (pdata->dvdd12) {
+ err = regulator_disable(pdata->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to disable DVDD12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ anx6345->powered = false;
+}
+
+static int anx6345_start(struct anx6345 *anx6345)
+{
+ int err;
+
+ if (!anx6345->powered)
+ anx6345_poweron(anx6345);
+
+ /* Power on needed modules */
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
+ SP_POWERDOWN_CTRL_REG,
+ SP_VIDEO_PD | SP_LINK_PD);
+
+ err = anx6345_tx_initialization(anx6345);
+ if (err) {
+ DRM_ERROR("Failed transmitter initialization: %d\n", err);
+ goto err_poweroff;
+ }
+
+ /*
+ * This delay seems to help keep the hardware in a good state. Without
+ * it, there are times where it fails silently.
+ */
+ usleep_range(10000, 15000);
+
+ return 0;
+
+err_poweroff:
+ DRM_ERROR("Failed DisplayPort transmitter initialization: %d\n", err);
+ anx6345_poweroff(anx6345);
+
+ return err;
+}
+
+static int anx6345_init_pdata(struct anx6345 *anx6345)
+{
+ struct anx6345_platform_data *pdata = &anx6345->pdata;
+ struct device *dev = &anx6345->client->dev;
+
+ /* 1.2V digital core power regulator */
+ pdata->dvdd12 = devm_regulator_get(dev, "dvdd12");
+ if (IS_ERR(pdata->dvdd12)) {
+ DRM_ERROR("DVDD12 regulator not found\n");
+ return PTR_ERR(pdata->dvdd12);
+ }
+
+ /* 2.5V digital core power regulator */
+ pdata->dvdd25 = devm_regulator_get(dev, "dvdd25");
+ if (IS_ERR(pdata->dvdd25)) {
+ DRM_ERROR("DVDD25 regulator not found\n");
+ return PTR_ERR(pdata->dvdd25);
+ }
+
+ /* GPIO for chip reset */
+ pdata->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+
+ return PTR_ERR_OR_ZERO(pdata->gpiod_reset);
+}
+
+static int anx6345_config_dp_output(struct anx6345 *anx6345)
+{
+ int err;
+
+ err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_MUTE);
+ if (err)
+ return err;
+
+ /* Enable DP output */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_VID_CTRL1_REG,
+ SP_VIDEO_EN);
+ if (err)
+ return err;
+
+ /* Force stream valid */
+ err = anx6345_set_bits(anx6345->map[I2C_IDX_DPTX],
+ SP_DP_SYSTEM_CTRL_BASE + 3,
+ SP_STRM_FORCE | SP_STRM_CTRL);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int anx6345_get_downstream_info(struct anx6345 *anx6345)
+{
+ u8 value;
+ int err;
+
+ err = drm_dp_dpcd_readb(&anx6345->aux, DP_SINK_COUNT, &value);
+ if (err < 0) {
+ DRM_ERROR("Get sink count failed %d\n", err);
+ return err;
+ }
+
+ if (!DP_GET_SINK_COUNT(value)) {
+ DRM_ERROR("Downstream disconnected\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int anx6345_get_modes(struct drm_connector *connector)
+{
+ struct anx6345 *anx6345 = connector_to_anx6345(connector);
+ int err, num_modes = 0;
+
+ if (WARN_ON(!anx6345->powered))
+ return 0;
+
+ mutex_lock(&anx6345->lock);
+
+ if (!anx6345->edid) {
+ err = anx6345_get_downstream_info(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to get downstream info: %d\n", err);
+ goto unlock;
+ }
+
+ anx6345->edid = drm_get_edid(connector, &anx6345->aux.ddc);
+ if (!anx6345->edid)
+ DRM_ERROR("Failed to read EDID from panel\n");
+
+ err = drm_connector_update_edid_property(connector,
+ anx6345->edid);
+ if (err) {
+ DRM_ERROR("Failed to update EDID property: %d\n", err);
+ goto unlock;
+ }
+ }
+
+ num_modes += drm_add_edid_modes(connector, anx6345->edid);
+
+unlock:
+ mutex_unlock(&anx6345->lock);
+
+ if (anx6345->panel)
+ num_modes += drm_panel_get_modes(anx6345->panel);
+
+ return num_modes;
+}
+
+static const struct drm_connector_helper_funcs anx6345_connector_helper_funcs = {
+ .get_modes = anx6345_get_modes,
+};
+
+static enum drm_connector_status anx6345_detect(struct drm_connector *connector,
+ bool force)
+{
+ return connector_status_connected;
+}
+
+static void
+anx6345_connector_destroy(struct drm_connector *connector)
+{
+ struct anx6345 *anx6345 = connector_to_anx6345(connector);
+
+ if (anx6345->panel)
+ drm_panel_detach(anx6345->panel);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs anx6345_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = anx6345_detect,
+ .destroy = anx6345_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int anx6345_bridge_attach(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+ int err;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ /* Register aux channel */
+ anx6345->aux.name = "DP-AUX";
+ anx6345->aux.dev = &anx6345->client->dev;
+ anx6345->aux.transfer = anx6345_aux_transfer;
+
+ err = drm_dp_aux_register(&anx6345->aux);
+ if (err < 0) {
+ DRM_ERROR("Failed to register aux channel: %d\n", err);
+ return err;
+ }
+
+ err = drm_connector_init(bridge->dev, &anx6345->connector,
+ &anx6345_connector_funcs,
+ DRM_MODE_CONNECTOR_eDP);
+ if (err) {
+ DRM_ERROR("Failed to initialize connector: %d\n", err);
+ return err;
+ }
+
+ drm_connector_helper_add(&anx6345->connector,
+ &anx6345_connector_helper_funcs);
+
+ err = drm_connector_register(&anx6345->connector);
+ if (err) {
+ DRM_ERROR("Failed to register connector: %d\n", err);
+ return err;
+ }
+
+ anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
+ err = drm_connector_attach_encoder(&anx6345->connector,
+ bridge->encoder);
+ if (err) {
+ DRM_ERROR("Failed to link up connector to encoder: %d\n", err);
+ return err;
+ }
+
+ if (anx6345->panel) {
+ err = drm_panel_attach(anx6345->panel, &anx6345->connector);
+ if (err) {
+ DRM_ERROR("Failed to attach panel: %d\n", err);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static bool anx6345_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ return false;
+
+ /* Max 1200p at 5.4 Ghz, one lane */
+ if (mode->clock > 154000)
+ return false;
+
+ return true;
+}
+
+static void anx6345_bridge_disable(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+
+ /* Power off all modules except configuration registers access */
+ anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
+ SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
+ if (anx6345->panel)
+ drm_panel_disable(anx6345->panel);
+}
+
+static void anx6345_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+
+ if (WARN_ON(!anx6345->powered))
+ return;
+}
+
+static void anx6345_bridge_enable(struct drm_bridge *bridge)
+{
+ struct anx6345 *anx6345 = bridge_to_anx6345(bridge);
+ int err;
+
+ if (anx6345->panel)
+ drm_panel_enable(anx6345->panel);
+
+ err = anx6345_start(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to initialize: %d\n", err);
+ return;
+ }
+
+ err = anx6345_config_dp_output(anx6345);
+ if (err)
+ DRM_ERROR("Failed to enable DP output: %d\n", err);
+}
+
+static const struct drm_bridge_funcs anx6345_bridge_funcs = {
+ .attach = anx6345_bridge_attach,
+ .mode_fixup = anx6345_bridge_mode_fixup,
+ .disable = anx6345_bridge_disable,
+ .mode_set = anx6345_bridge_mode_set,
+ .enable = anx6345_bridge_enable,
+};
+
+static void unregister_i2c_dummy_clients(struct anx6345 *anx6345)
+{
+ unsigned int i;
+
+ for (i = 1; i < ARRAY_SIZE(anx6345->i2c_clients); i++)
+ if (anx6345->i2c_clients[i] &&
+ anx6345->i2c_clients[i]->addr != anx6345->client->addr)
+ i2c_unregister_device(anx6345->i2c_clients[i]);
+}
+
+static const struct regmap_config anx6345_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0xff,
+};
+
+static const u16 anx6345_chipid_list[] = {
+ 0x6345,
+};
+
+static int anx6345_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct anx6345 *anx6345;
+ struct anx6345_platform_data *pdata;
+ unsigned int i, idl, idh, version;
+ bool found = false;
+ int err;
+
+ anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
+ if (!anx6345)
+ return -ENOMEM;
+
+ pdata = &anx6345->pdata;
+
+ mutex_init(&anx6345->lock);
+
+ anx6345->bridge.of_node = client->dev.of_node;
+
+ anx6345->client = client;
+ i2c_set_clientdata(client, anx6345);
+
+ err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0,
+ &anx6345->panel, NULL);
+ if (err == -EPROBE_DEFER)
+ return err;
+
+ if (err)
+ DRM_DEBUG("No panel found\n");
+
+ err = anx6345_init_pdata(anx6345);
+ if (err) {
+ DRM_ERROR("Failed to initialize pdata: %d\n", err);
+ return err;
+ }
+
+ /* Map slave addresses of ANX6345 */
+ for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
+ if (anx6345_i2c_addresses[i] >> 1 != client->addr)
+ anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
+ anx6345_i2c_addresses[i] >> 1);
+ else
+ anx6345->i2c_clients[i] = client;
+
+ if (!anx6345->i2c_clients[i]) {
+ err = -ENOMEM;
+ DRM_ERROR("Failed to reserve I2C bus %02x\n",
+ anx6345_i2c_addresses[i]);
+ goto err_unregister_i2c;
+ }
+
+ anx6345->map[i] = devm_regmap_init_i2c(anx6345->i2c_clients[i],
+ &anx6345_regmap_config);
+ if (IS_ERR(anx6345->map[i])) {
+ err = PTR_ERR(anx6345->map[i]);
+ DRM_ERROR("Failed regmap initialization %02x\n",
+ anx6345_i2c_addresses[i]);
+ goto err_unregister_i2c;
+ }
+ }
+
+ /* Look for supported chip ID */
+ anx6345_poweron(anx6345);
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG,
+ &idl);
+ if (err)
+ goto err_poweroff;
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG,
+ &idh);
+ if (err)
+ goto err_poweroff;
+
+ anx6345->chipid = (u8)idl | ((u8)idh << 8);
+
+ err = regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
+ &version);
+ if (err)
+ goto err_poweroff;
+
+ for (i = 0; i < ARRAY_SIZE(anx6345_chipid_list); i++) {
+ if (anx6345->chipid == anx6345_chipid_list[i]) {
+ DRM_INFO("Found ANX%x (ver. %d) eDP Transmitter\n",
+ anx6345->chipid, version);
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
+ anx6345->chipid, version);
+ err = -ENODEV;
+ goto err_poweroff;
+ }
+
+ anx6345->bridge.funcs = &anx6345_bridge_funcs;
+
+ drm_bridge_add(&anx6345->bridge);
+
+ return 0;
+
+err_poweroff:
+ anx6345_poweroff(anx6345);
+
+err_unregister_i2c:
+ unregister_i2c_dummy_clients(anx6345);
+ return err;
+}
+
+static int anx6345_i2c_remove(struct i2c_client *client)
+{
+ struct anx6345 *anx6345 = i2c_get_clientdata(client);
+
+ drm_bridge_remove(&anx6345->bridge);
+
+ unregister_i2c_dummy_clients(anx6345);
+
+ kfree(anx6345->edid);
+
+ return 0;
+}
+
+static const struct i2c_device_id anx6345_id[] = {
+ { "anx6345", 0 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, anx6345_id);
+
+static const struct of_device_id anx6345_match_table[] = {
+ { .compatible = "analogix,anx6345", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, anx6345_match_table);
+
+static struct i2c_driver anx6345_driver = {
+ .driver = {
+ .name = "anx6345",
+ .of_match_table = of_match_ptr(anx6345_match_table),
+ },
+ .probe = anx6345_i2c_probe,
+ .remove = anx6345_i2c_remove,
+ .id_table = anx6345_id,
+};
+module_i2c_driver(anx6345_driver);
+
+MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver");
+MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.io>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
index 9cb30962032e..53b0e73d6a24 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -117,7 +117,7 @@ ssize_t anx_aux_transfer(struct regmap *map_dptx, struct drm_dp_aux_msg *msg)
else /* For non-zero-sized set the length field. */
ctrl1 |= (msg->size - 1) << SP_AUX_LENGTH_SHIFT;
- if ((msg->request & DP_AUX_I2C_READ) == 0) {
+ if ((msg->size > 0) && ((msg->request & DP_AUX_I2C_READ) == 0)) {
/* When WRITE | MOT write values to data buffer */
err = regmap_bulk_write(map_dptx,
SP_DP_BUF_DATA0_REG, buffer,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index c2ca854613a0..b29a0b3bc23c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -75,7 +75,11 @@
#define SP_CHA_STA BIT(2)
/* Bits for DP System Control Register 3 */
#define SP_HPD_STATUS BIT(6)
+#define SP_HPD_FORCE BIT(5)
+#define SP_HPD_CTRL BIT(4)
#define SP_STRM_VALID BIT(2)
+#define SP_STRM_FORCE BIT(1)
+#define SP_STRM_CTRL BIT(0)
/* Bits for DP System Control Register 4 */
#define SP_ENHANCED_MODE BIT(3)
@@ -120,6 +124,9 @@
#define SP_LINK_BW_SET_MASK 0x1f
#define SP_INITIAL_SLIM_M_AUD_SEL BIT(5)
+/* DP Lane Count Setting Register */
+#define SP_DP_LANE_COUNT_SET_REG 0xa1
+
/* DP Training Pattern Set Register */
#define SP_DP_TRAINING_PATTERN_SET_REG 0xa2
@@ -133,6 +140,7 @@
/* DP Link Training Control Register */
#define SP_DP_LT_CTRL_REG 0xa8
+#define SP_DP_LT_INPROGRESS 0x80
#define SP_LT_ERROR_TYPE_MASK 0x70
# define SP_LT_NO_ERROR 0x00
# define SP_LT_AUX_WRITE_ERROR 0x01
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
index 7d683573e970..480c98a225b1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -183,6 +183,9 @@
#define SP_VBIT BIT(1)
#define SP_AUDIO_LAYOUT BIT(0)
+/* Analog Debug Register 1 */
+#define SP_ANALOG_DEBUG1_REG 0xdc
+
/* Analog Debug Register 2 */
#define SP_ANALOG_DEBUG2_REG 0xdd
#define SP_FORCE_SW_OFF_BYPASS 0x20
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 05/12] drm/bridge: Add Analogix anx6345 support
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-05 13:19 ` Torsten Duwe
-1 siblings, 0 replies; 176+ messages in thread
From: Torsten Duwe @ 2019-02-05 13:19 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Icenowy Zheng, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-kernel, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Laurent Pinchart, Daniel Vetter,
Mark Rutland, Thierry Reding, Sean Paul, arm-linux
First thing that struck me is that the chip's reset is actually low active
reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
^^^^
(please correct this in patches 11 and 12)
Consequently, you're using inverted values here in the driver:
> +static void anx6345_poweron(struct anx6345 *anx6345)
> +{
[...]
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
0 = reset on, ok.
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
1 = reset off, also fine.
> +
> + /* Power on registers module */
> + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> + anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_REGISTER_PD | SP_TOTAL_PD);
> +
> + anx6345->powered = true;
> +}
> +
> +static void anx6345_poweroff(struct anx6345 *anx6345)
> +{
> + struct anx6345_platform_data *pdata = &anx6345->pdata;
> + int err;
> +
> + if (WARN_ON(!anx6345->powered))
> + return;
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
> + usleep_range(1000, 2000);
This one got me a bit confused. Assert or deassert reset (again) before
poweroff?
Please stick to the logical value of the reset line.
Torsten
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 05/12] drm/bridge: Add Analogix anx6345 support
@ 2019-02-05 13:19 ` Torsten Duwe
0 siblings, 0 replies; 176+ messages in thread
From: Torsten Duwe @ 2019-02-05 13:19 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Daniel Vetter,
Maxime Ripard, Sean Paul, arm-linux, Icenowy Zheng
First thing that struck me is that the chip's reset is actually low active
reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
^^^^
(please correct this in patches 11 and 12)
Consequently, you're using inverted values here in the driver:
> +static void anx6345_poweron(struct anx6345 *anx6345)
> +{
[...]
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
0 = reset on, ok.
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
1 = reset off, also fine.
> +
> + /* Power on registers module */
> + anx6345_set_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> + anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM], SP_POWERDOWN_CTRL_REG,
> + SP_REGISTER_PD | SP_TOTAL_PD);
> +
> + anx6345->powered = true;
> +}
> +
> +static void anx6345_poweroff(struct anx6345 *anx6345)
> +{
> + struct anx6345_platform_data *pdata = &anx6345->pdata;
> + int err;
> +
> + if (WARN_ON(!anx6345->powered))
> + return;
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
> + usleep_range(1000, 2000);
This one got me a bit confused. Assert or deassert reset (again) before
poweroff?
Please stick to the logical value of the reset line.
Torsten
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
Validate the clock rate") prevents some panel and bridges from working with
sun4i driver.
Unfortunately, dotclock frequency for some modes are not achievable on
sunxi hardware, and there's a slight deviation in rate returned by
clk_round_rate(), so they fail this check.
Experiments show that panels and bridges work fine with this slight
deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
fine.
This patch adds a 1% tolerence to the dot clock check when bridge is
connected.
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 16 ++++++++++------
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f4a22689eb54..3f04446120f6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -61,6 +61,7 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
u32 vsync = mode->vsync_end - mode->vsync_start;
unsigned long rate = mode->clock * 1000;
long rounded_rate;
+ long tolerance = 0;
DRM_DEBUG_DRIVER("Validating modes...\n");
@@ -95,10 +96,14 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
+ if (tcon->bridge)
+ /* Check against a 1% tolerance for the dot clock for bridge */
+ tolerance = rate / 100;
+
+ if (rounded_rate < (rate - tolerance))
return MODE_CLOCK_LOW;
- if (rounded_rate > rate)
+ if (rounded_rate > (rate + tolerance))
return MODE_CLOCK_HIGH;
DRM_DEBUG_DRIVER("Clock rate OK\n");
@@ -172,7 +177,6 @@ static struct drm_encoder_funcs sun4i_rgb_enc_funcs = {
int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
{
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
struct sun4i_rgb *rgb;
int ret;
@@ -183,7 +187,7 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
encoder = &rgb->encoder;
ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
- &tcon->panel, &bridge);
+ &tcon->panel, &tcon->bridge);
if (ret) {
dev_info(drm->dev, "No panel or bridge found... RGB output disabled\n");
return 0;
@@ -225,8 +229,8 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
}
}
- if (bridge) {
- ret = drm_bridge_attach(encoder, bridge, NULL);
+ if (tcon->bridge) {
+ ret = drm_bridge_attach(encoder, tcon->bridge, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't attach our bridge\n");
goto err_cleanup_connector;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index b5214d71610f..487cb070b25c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -258,6 +258,7 @@ struct sun4i_tcon {
struct reset_control *lvds_rst;
struct drm_panel *panel;
+ struct drm_bridge *bridge;
/* Platform adjustments */
const struct sun4i_tcon_quirks *quirks;
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
Validate the clock rate") prevents some panel and bridges from working with
sun4i driver.
Unfortunately, dotclock frequency for some modes are not achievable on
sunxi hardware, and there's a slight deviation in rate returned by
clk_round_rate(), so they fail this check.
Experiments show that panels and bridges work fine with this slight
deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
fine.
This patch adds a 1% tolerence to the dot clock check when bridge is
connected.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 16 ++++++++++------
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f4a22689eb54..3f04446120f6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -61,6 +61,7 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
u32 vsync = mode->vsync_end - mode->vsync_start;
unsigned long rate = mode->clock * 1000;
long rounded_rate;
+ long tolerance = 0;
DRM_DEBUG_DRIVER("Validating modes...\n");
@@ -95,10 +96,14 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct drm_encoder *crtc,
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
rounded_rate = clk_round_rate(tcon->dclk, rate);
- if (rounded_rate < rate)
+ if (tcon->bridge)
+ /* Check against a 1% tolerance for the dot clock for bridge */
+ tolerance = rate / 100;
+
+ if (rounded_rate < (rate - tolerance))
return MODE_CLOCK_LOW;
- if (rounded_rate > rate)
+ if (rounded_rate > (rate + tolerance))
return MODE_CLOCK_HIGH;
DRM_DEBUG_DRIVER("Clock rate OK\n");
@@ -172,7 +177,6 @@ static struct drm_encoder_funcs sun4i_rgb_enc_funcs = {
int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
{
struct drm_encoder *encoder;
- struct drm_bridge *bridge;
struct sun4i_rgb *rgb;
int ret;
@@ -183,7 +187,7 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
encoder = &rgb->encoder;
ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
- &tcon->panel, &bridge);
+ &tcon->panel, &tcon->bridge);
if (ret) {
dev_info(drm->dev, "No panel or bridge found... RGB output disabled\n");
return 0;
@@ -225,8 +229,8 @@ int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
}
}
- if (bridge) {
- ret = drm_bridge_attach(encoder, bridge, NULL);
+ if (tcon->bridge) {
+ ret = drm_bridge_attach(encoder, tcon->bridge, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't attach our bridge\n");
goto err_cleanup_connector;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index b5214d71610f..487cb070b25c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -258,6 +258,7 @@ struct sun4i_tcon {
struct reset_control *lvds_rst;
struct drm_panel *panel;
+ struct drm_bridge *bridge;
/* Platform adjustments */
const struct sun4i_tcon_quirks *quirks;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread[parent not found: <20190203185501.8958-7-anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-04 14:20 ` Maxime Ripard
-1 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-04 14:20 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
Hi,
On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> Validate the clock rate") prevents some panel and bridges from working with
> sun4i driver.
>
> Unfortunately, dotclock frequency for some modes are not achievable on
> sunxi hardware, and there's a slight deviation in rate returned by
> clk_round_rate(), so they fail this check.
>
> Experiments show that panels and bridges work fine with this slight
> deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> fine.
>
> This patch adds a 1% tolerence to the dot clock check when bridge is
> connected.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
I'm not sure we want to make exceptions for all the hardware
combination we face, but we should go for something more generic (and
easier to maintain instead).
IIRC, from the previous discussion, HDMI had a tolerancy requirement
in the standard. Do you know if there's such a thing for eDP? That
would solve the issue for all the eDP displays at once.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-04 14:20 ` Maxime Ripard
0 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-04 14:20 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
linux-sunxi, dri-devel, Andrzej Hajda, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
linux-arm-kernel, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --]
Hi,
On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> Validate the clock rate") prevents some panel and bridges from working with
> sun4i driver.
>
> Unfortunately, dotclock frequency for some modes are not achievable on
> sunxi hardware, and there's a slight deviation in rate returned by
> clk_round_rate(), so they fail this check.
>
> Experiments show that panels and bridges work fine with this slight
> deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> fine.
>
> This patch adds a 1% tolerence to the dot clock check when bridge is
> connected.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
I'm not sure we want to make exceptions for all the hardware
combination we face, but we should go for something more generic (and
easier to maintain instead).
IIRC, from the previous discussion, HDMI had a tolerancy requirement
in the standard. Do you know if there's such a thing for eDP? That
would solve the issue for all the eDP displays at once.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-04 14:20 ` Maxime Ripard
@ 2019-02-04 16:26 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 16:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i driver.
> >
> > Unfortunately, dotclock frequency for some modes are not achievable on
> > sunxi hardware, and there's a slight deviation in rate returned by
> > clk_round_rate(), so they fail this check.
> >
> > Experiments show that panels and bridges work fine with this slight
> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > fine.
> >
> > This patch adds a 1% tolerence to the dot clock check when bridge is
> > connected.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> I'm not sure we want to make exceptions for all the hardware
> combination we face, but we should go for something more generic (and
> easier to maintain instead).
>
> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> in the standard. Do you know if there's such a thing for eDP? That
> would solve the issue for all the eDP displays at once.
I don't have access to eDP standard - vesa.org says it's available to
members only.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-04 16:26 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 16:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
linux-sunxi, dri-devel, Andrzej Hajda, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i driver.
> >
> > Unfortunately, dotclock frequency for some modes are not achievable on
> > sunxi hardware, and there's a slight deviation in rate returned by
> > clk_round_rate(), so they fail this check.
> >
> > Experiments show that panels and bridges work fine with this slight
> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > fine.
> >
> > This patch adds a 1% tolerence to the dot clock check when bridge is
> > connected.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>
> I'm not sure we want to make exceptions for all the hardware
> combination we face, but we should go for something more generic (and
> easier to maintain instead).
>
> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> in the standard. Do you know if there's such a thing for eDP? That
> would solve the issue for all the eDP displays at once.
I don't have access to eDP standard - vesa.org says it's available to
members only.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread[parent not found: <CA+E=qVfTfJ9E29gz83tdVGx5_KGWSQVJOAxKTzC+-n7=gdj0cA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-04 16:26 ` Vasily Khoruzhick
@ 2019-02-04 16:28 ` Icenowy Zheng
-1 siblings, 0 replies; 176+ messages in thread
From: Icenowy Zheng @ 2019-02-04 16:28 UTC (permalink / raw)
To: Vasily Khoruzhick, Maxime Ripard
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
linux-sunxi, dri-devel, Andrzej Hajda, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
><maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.
Try out to grab an old version?
I remember 1.0 is open.
>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
使用 K-9 Mail 发送自我的Android设备。
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-04 16:28 ` Icenowy Zheng
0 siblings, 0 replies; 176+ messages in thread
From: Icenowy Zheng @ 2019-02-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel, Vasily Khoruzhick, Maxime Ripard
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
Chen-Yu Tsai, dri-devel, Andrzej Hajda, linux-sunxi, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick <anarsoul@gmail.com> 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
><maxime.ripard@bootlin.com> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.
Try out to grab an old version?
I remember 1.0 is open.
>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
使用 K-9 Mail 发送自我的Android设备。
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread[parent not found: <0F6CBEA4-6DB6-40F1-A2FD-65101AF64F1F-h8G6r0blFSE@public.gmane.org>]
* Re: Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-04 16:28 ` Icenowy Zheng
@ 2019-02-04 18:50 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 18:50 UTC (permalink / raw)
To: Icenowy Zheng
Cc: arm-linux, Maxime Ripard, Mark Rutland, devicetree,
Archit Taneja, David Airlie, linux-sunxi, dri-devel,
Andrzej Hajda, Chen-Yu Tsai, Rob Herring, Thierry Reding,
Laurent Pinchart, Daniel Vetter, Sean Paul
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> >> in the standard. Do you know if there's such a thing for eDP? That
> >> would solve the issue for all the eDP displays at once.
> >
> >I don't have access to eDP standard - vesa.org says it's available to
> >members only.
>
> Try out to grab an old version?
>
> I remember 1.0 is open.
I can't find anything regarding dot clock tolerance in DisplayPort
specification.
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-04 18:50 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 18:50 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
Maxime Ripard, Chen-Yu Tsai, dri-devel, David Airlie,
linux-sunxi, Rob Herring, Thierry Reding, Laurent Pinchart,
Daniel Vetter, Sean Paul, arm-linux
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> >> in the standard. Do you know if there's such a thing for eDP? That
> >> would solve the issue for all the eDP displays at once.
> >
> >I don't have access to eDP standard - vesa.org says it's available to
> >members only.
>
> Try out to grab an old version?
>
> I remember 1.0 is open.
I can't find anything regarding dot clock tolerance in DisplayPort
specification.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CA+E=qVd7yh=JNZSvrfY4Diu+VJWFK6yLUJ5MavBcZ8Cftn6f-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-04 18:50 ` [linux-sunxi] " Vasily Khoruzhick
@ 2019-02-05 15:41 ` Maxime Ripard
-1 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-05 15:41 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Icenowy Zheng, arm-linux, Mark Rutland, devicetree,
Archit Taneja, David Airlie, linux-sunxi, dri-devel,
Andrzej Hajda, Chen-Yu Tsai, Rob Herring, Thierry Reding,
Laurent Pinchart, Daniel Vetter, Sean Paul
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > >> in the standard. Do you know if there's such a thing for eDP? That
> > >> would solve the issue for all the eDP displays at once.
> > >
> > >I don't have access to eDP standard - vesa.org says it's available to
> > >members only.
> >
> > Try out to grab an old version?
> >
> > I remember 1.0 is open.
>
> I can't find anything regarding dot clock tolerance in DisplayPort
> specification.
I guess since the DP is a VESA spec, it's probably .5%, just like on
the EDID (well, CVT).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-05 15:41 ` Maxime Ripard
0 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-05 15:41 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
Chen-Yu Tsai, dri-devel, Andrzej Hajda, linux-sunxi, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 824 bytes --]
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > >> in the standard. Do you know if there's such a thing for eDP? That
> > >> would solve the issue for all the eDP displays at once.
> > >
> > >I don't have access to eDP standard - vesa.org says it's available to
> > >members only.
> >
> > Try out to grab an old version?
> >
> > I remember 1.0 is open.
>
> I can't find anything regarding dot clock tolerance in DisplayPort
> specification.
I guess since the DP is a VESA spec, it's probably .5%, just like on
the EDID (well, CVT).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-05 15:41 ` [linux-sunxi] " Maxime Ripard
@ 2019-02-05 17:49 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-05 17:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, arm-linux, Mark Rutland, devicetree,
Archit Taneja, David Airlie, linux-sunxi, dri-devel,
Andrzej Hajda, Chen-Yu Tsai, Rob Herring, Thierry Reding,
Laurent Pinchart, Daniel Vetter, Sean Paul
On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > >> would solve the issue for all the eDP displays at once.
> > > >
> > > >I don't have access to eDP standard - vesa.org says it's available to
> > > >members only.
> > >
> > > Try out to grab an old version?
> > >
> > > I remember 1.0 is open.
> >
> > I can't find anything regarding dot clock tolerance in DisplayPort
> > specification.
>
> I guess since the DP is a VESA spec, it's probably .5%, just like on
> the EDID (well, CVT).
Unfortunately that's not enough for Pinebook. It needs 1% for 768p panel.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-05 17:49 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-05 17:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
Chen-Yu Tsai, dri-devel, Andrzej Hajda, linux-sunxi, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux, Icenowy Zheng
On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > >> would solve the issue for all the eDP displays at once.
> > > >
> > > >I don't have access to eDP standard - vesa.org says it's available to
> > > >members only.
> > >
> > > Try out to grab an old version?
> > >
> > > I remember 1.0 is open.
> >
> > I can't find anything regarding dot clock tolerance in DisplayPort
> > specification.
>
> I guess since the DP is a VESA spec, it's probably .5%, just like on
> the EDID (well, CVT).
Unfortunately that's not enough for Pinebook. It needs 1% for 768p panel.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-05 17:49 ` [linux-sunxi] " Vasily Khoruzhick
@ 2019-02-06 9:16 ` Maxime Ripard
-1 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-06 9:16 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, David Airlie, Chen-Yu Tsai, dri-devel,
linux-sunxi, Rob Herring, Thierry Reding, Laurent Pinchart,
Sean Paul, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > >> would solve the issue for all the eDP displays at once.
> > > > >
> > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > >members only.
> > > >
> > > > Try out to grab an old version?
> > > >
> > > > I remember 1.0 is open.
> > >
> > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > specification.
> >
> > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > the EDID (well, CVT).
>
> Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> panel.
And that mode is stored in the EDID as a standard (or established)
timing, or a detailed timing?
If the latter, then it should also provide the tolerancies as part of
the panel timing description.
If the former, then what would be the advertised pixel clock and the
one we can compute? Maybe we have a bug somewhere.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-06 9:16 ` Maxime Ripard
0 siblings, 0 replies; 176+ messages in thread
From: Maxime Ripard @ 2019-02-06 9:16 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
Chen-Yu Tsai, dri-devel, Andrzej Hajda, linux-sunxi, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Sean Paul,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > >> would solve the issue for all the eDP displays at once.
> > > > >
> > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > >members only.
> > > >
> > > > Try out to grab an old version?
> > > >
> > > > I remember 1.0 is open.
> > >
> > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > specification.
> >
> > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > the EDID (well, CVT).
>
> Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> panel.
And that mode is stored in the EDID as a standard (or established)
timing, or a detailed timing?
If the latter, then it should also provide the tolerancies as part of
the panel timing description.
If the former, then what would be the advertised pixel clock and the
one we can compute? Maybe we have a bug somewhere.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
2019-02-06 9:16 ` Maxime Ripard
@ 2019-02-06 11:42 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-06 11:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Chen-Yu Tsai, dri-devel,
Vasily Khoruzhick, linux-sunxi, Rob Herring, Sean Paul,
Laurent Pinchart, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1984 bytes --]
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote:
> On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > > >> would solve the issue for all the eDP displays at once.
> > > > > >
> > > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > > >members only.
> > > > >
> > > > > Try out to grab an old version?
> > > > >
> > > > > I remember 1.0 is open.
> > > >
> > > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > > specification.
> > >
> > > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > > the EDID (well, CVT).
> >
> > Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> > panel.
>
> And that mode is stored in the EDID as a standard (or established)
> timing, or a detailed timing?
>
> If the latter, then it should also provide the tolerancies as part of
> the panel timing description.
The simple-panel driver can, in addition to a struct drm_display_mode
take a struct display_timings to specify the modes. These allow to
define <minimum, typical, maximum> triplets for each parameter, which
are usually found in panel datasheets.
Of course that's not going to help you much if all you have is EDID and
if that doesn't provide tolerances.
Thierry
> If the former, then what would be the advertised pixel clock and the
> one we can compute? Maybe we have a bug somewhere.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
@ 2019-02-06 11:42 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-06 11:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Archit Taneja, David Airlie,
Chen-Yu Tsai, dri-devel, Andrzej Hajda, linux-sunxi, Rob Herring,
Sean Paul, Laurent Pinchart, Daniel Vetter, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1984 bytes --]
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote:
> On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> > > > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > > > >> in the standard. Do you know if there's such a thing for eDP? That
> > > > > >> would solve the issue for all the eDP displays at once.
> > > > > >
> > > > > >I don't have access to eDP standard - vesa.org says it's available to
> > > > > >members only.
> > > > >
> > > > > Try out to grab an old version?
> > > > >
> > > > > I remember 1.0 is open.
> > > >
> > > > I can't find anything regarding dot clock tolerance in DisplayPort
> > > > specification.
> > >
> > > I guess since the DP is a VESA spec, it's probably .5%, just like on
> > > the EDID (well, CVT).
> >
> > Unfortunately that's not enough for Pinebook. It needs 1% for 768p
> > panel.
>
> And that mode is stored in the EDID as a standard (or established)
> timing, or a detailed timing?
>
> If the latter, then it should also provide the tolerancies as part of
> the panel timing description.
The simple-panel driver can, in addition to a struct drm_display_mode
take a struct display_timings to specify the modes. These allow to
define <minimum, typical, maximum> triplets for each parameter, which
are usually found in panel datasheets.
Of course that's not going to help you much if all you have is EDID and
if that doesn't provide tolerances.
Thierry
> If the former, then what would be the advertised pixel clock and the
> one we can compute? Maybe we have a bug somewhere.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 07/12] drm/panel: simple: don't fail if we don't have panel desc
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
This is preparation for addition of generic eDP panel that
doesn't have any modes or delays defined.
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/panel/panel-simple.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e739a524..2f2cb2d81f2b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->desc->delay.disable)
+ if (p->desc && p->desc->delay.disable)
msleep(p->desc->delay.disable);
p->enabled = false;
@@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
regulator_disable(p->supply);
- if (p->desc->delay.unprepare)
+ if (p->desc && p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
p->prepared = false;
@@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
- if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
- if (delay)
- msleep(delay);
+ if (p->desc) {
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
+ }
p->prepared = true;
@@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
+ if (p->desc && p->desc->delay.enable)
msleep(p->desc->delay.enable);
if (p->backlight) {
@@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
+ if (!p->desc)
+ return 0;
+
if (p->desc->num_timings < num_timings)
num_timings = p->desc->num_timings;
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 07/12] drm/panel: simple: don't fail if we don't have panel desc
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
This is preparation for addition of generic eDP panel that
doesn't have any modes or delays defined.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/gpu/drm/panel/panel-simple.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e739a524..2f2cb2d81f2b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->desc->delay.disable)
+ if (p->desc && p->desc->delay.disable)
msleep(p->desc->delay.disable);
p->enabled = false;
@@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
regulator_disable(p->supply);
- if (p->desc->delay.unprepare)
+ if (p->desc && p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
p->prepared = false;
@@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
- if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
- if (delay)
- msleep(delay);
+ if (p->desc) {
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
+ }
p->prepared = true;
@@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
+ if (p->desc && p->desc->delay.enable)
msleep(p->desc->delay.enable);
if (p->backlight) {
@@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
+ if (!p->desc)
+ return 0;
+
if (p->desc->num_timings < num_timings)
num_timings = p->desc->num_timings;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
eDP panels usually have EDID EEPROM, so there's no need to define panel
width/height or any modes/timings in dts. But this panel still may have
regulator and/or backlight.
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.txt b/Documentation/devicetree/bindings/display/panel/panel-edp.txt
new file mode 100644
index 000000000000..fc7a0868048e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-edp.txt
@@ -0,0 +1,7 @@
+Generic eDP Display Panel
+
+Required properties:
+ - compatible: "panel-edp"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
eDP panels usually have EDID EEPROM, so there's no need to define panel
width/height or any modes/timings in dts. But this panel still may have
regulator and/or backlight.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
.../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.txt b/Documentation/devicetree/bindings/display/panel/panel-edp.txt
new file mode 100644
index 000000000000..fc7a0868048e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-edp.txt
@@ -0,0 +1,7 @@
+Generic eDP Display Panel
+
+Required properties:
+ - compatible: "panel-edp"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
[parent not found: <20190203185501.8958-9-anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-04 7:43 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 7:43 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> eDP panels usually have EDID EEPROM, so there's no need to define panel
> width/height or any modes/timings in dts. But this panel still may have
> regulator and/or backlight.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
Please don't try to make panels look more generic than they really are.
You're going to have to provide a compatible string for your device that
is more specific than "panel-edp". You claim that you don't need any
extra information that is panel specific, but you don't know that now.
We have in the past thought that we didn't need things like prepare
delay, but then we ran into situations where we did need them.
Just do what everybody else does. Provide a specific compatible string
and match on that in the panel-simple driver. Even if you can read all
the video timings from an EDID EEPROM, you can still provide a mode in
the panel descriptor to serve as a fallback if for example the EEPROM
is faulty on some device.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 7:43 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 7:43 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, linux-arm-kernel, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1264 bytes --]
On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> eDP panels usually have EDID EEPROM, so there's no need to define panel
> width/height or any modes/timings in dts. But this panel still may have
> regulator and/or backlight.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
Please don't try to make panels look more generic than they really are.
You're going to have to provide a compatible string for your device that
is more specific than "panel-edp". You claim that you don't need any
extra information that is panel specific, but you don't know that now.
We have in the past thought that we didn't need things like prepare
delay, but then we ran into situations where we did need them.
Just do what everybody else does. Provide a specific compatible string
and match on that in the panel-simple driver. Even if you can read all
the video timings from an EDID EEPROM, you can still provide a mode in
the panel descriptor to serve as a fallback if for example the EEPROM
is faulty on some device.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 7:43 ` Thierry Reding
@ 2019-02-04 8:13 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 8:13 UTC (permalink / raw)
To: Thierry Reding
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > width/height or any modes/timings in dts. But this panel still may have
> > regulator and/or backlight.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
>
> Please don't try to make panels look more generic than they really are.
> You're going to have to provide a compatible string for your device that
> is more specific than "panel-edp". You claim that you don't need any
> extra information that is panel specific, but you don't know that now.
> We have in the past thought that we didn't need things like prepare
> delay, but then we ran into situations where we did need them.
>
> Just do what everybody else does. Provide a specific compatible string
> and match on that in the panel-simple driver. Even if you can read all
> the video timings from an EDID EEPROM, you can still provide a mode in
> the panel descriptor to serve as a fallback if for example the EEPROM
> is faulty on some device.
Pinebook used several 768p panels that have slightly different timings
and recent batch uses 1080p panel.
What panel descriptor should I use as fallback?
> Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 8:13 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 8:13 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > width/height or any modes/timings in dts. But this panel still may have
> > regulator and/or backlight.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > ---
> > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
>
> Please don't try to make panels look more generic than they really are.
> You're going to have to provide a compatible string for your device that
> is more specific than "panel-edp". You claim that you don't need any
> extra information that is panel specific, but you don't know that now.
> We have in the past thought that we didn't need things like prepare
> delay, but then we ran into situations where we did need them.
>
> Just do what everybody else does. Provide a specific compatible string
> and match on that in the panel-simple driver. Even if you can read all
> the video timings from an EDID EEPROM, you can still provide a mode in
> the panel descriptor to serve as a fallback if for example the EEPROM
> is faulty on some device.
Pinebook used several 768p panels that have slightly different timings
and recent batch uses 1080p panel.
What panel descriptor should I use as fallback?
> Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CA+E=qVecudACOEXt74Kf=UA_F-uuHgEqHzKpYAq1ocMx3Sx+eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 8:13 ` Vasily Khoruzhick
@ 2019-02-04 8:23 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 8:23 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]
On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > width/height or any modes/timings in dts. But this panel still may have
> > > regulator and/or backlight.
> > >
> > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> >
> > Please don't try to make panels look more generic than they really are.
> > You're going to have to provide a compatible string for your device that
> > is more specific than "panel-edp". You claim that you don't need any
> > extra information that is panel specific, but you don't know that now.
> > We have in the past thought that we didn't need things like prepare
> > delay, but then we ran into situations where we did need them.
> >
> > Just do what everybody else does. Provide a specific compatible string
> > and match on that in the panel-simple driver. Even if you can read all
> > the video timings from an EDID EEPROM, you can still provide a mode in
> > the panel descriptor to serve as a fallback if for example the EEPROM
> > is faulty on some device.
>
> Pinebook used several 768p panels that have slightly different timings
> and recent batch uses 1080p panel.
>
> What panel descriptor should I use as fallback?
You don't use panel descriptors as fallback. The simple-panel driver
will bind to a panel device and use the corresponding descriptor. If
your device tree contains the correct information, the descriptor is
correct for the panel you have.
In other words you need to ensure that you have the correct panel in
device tree for the board that you're using. This is exactly the same
thing as for other devices.
One way to to this is to have separate device trees for each variant
of the board that you want to support. Another variant may be to have
a common device tree and then have some early firmware update the DTB
with the correct panel information.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 8:23 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 8:23 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2349 bytes --]
On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > width/height or any modes/timings in dts. But this panel still may have
> > > regulator and/or backlight.
> > >
> > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > ---
> > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> >
> > Please don't try to make panels look more generic than they really are.
> > You're going to have to provide a compatible string for your device that
> > is more specific than "panel-edp". You claim that you don't need any
> > extra information that is panel specific, but you don't know that now.
> > We have in the past thought that we didn't need things like prepare
> > delay, but then we ran into situations where we did need them.
> >
> > Just do what everybody else does. Provide a specific compatible string
> > and match on that in the panel-simple driver. Even if you can read all
> > the video timings from an EDID EEPROM, you can still provide a mode in
> > the panel descriptor to serve as a fallback if for example the EEPROM
> > is faulty on some device.
>
> Pinebook used several 768p panels that have slightly different timings
> and recent batch uses 1080p panel.
>
> What panel descriptor should I use as fallback?
You don't use panel descriptors as fallback. The simple-panel driver
will bind to a panel device and use the corresponding descriptor. If
your device tree contains the correct information, the descriptor is
correct for the panel you have.
In other words you need to ensure that you have the correct panel in
device tree for the board that you're using. This is exactly the same
thing as for other devices.
One way to to this is to have separate device trees for each variant
of the board that you want to support. Another variant may be to have
a common device tree and then have some early firmware update the DTB
with the correct panel information.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 8:23 ` Thierry Reding
@ 2019-02-04 9:40 ` Daniel Vetter
-1 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-04 9:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Vasily Khoruzhick, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, arm-linux, linux-sunxi
On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > width/height or any modes/timings in dts. But this panel still may have
> > > > regulator and/or backlight.
> > > >
> > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > ---
> > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > >
> > > Please don't try to make panels look more generic than they really are.
> > > You're going to have to provide a compatible string for your device that
> > > is more specific than "panel-edp". You claim that you don't need any
> > > extra information that is panel specific, but you don't know that now.
> > > We have in the past thought that we didn't need things like prepare
> > > delay, but then we ran into situations where we did need them.
> > >
> > > Just do what everybody else does. Provide a specific compatible string
> > > and match on that in the panel-simple driver. Even if you can read all
> > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > is faulty on some device.
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
This would defeat the point of edp, which is to standardize the mess of
panels (at least somewhat) and avoid having to change the DT/ACPI
tables/firmware for every board you ship. Also, we do have DP quirking
infrastructure already (using the OUI), I think if there's something that
doesn't work then we should quirk it there.
What does make sense though imo is if we try not to stuff the edp panel
into panel-simple, because it's anything like a simple dumb panel. There's
also some integration awkwardness since with this panel you need to do dp
aux/i2c transactions to get at the information (edid alone isn't good
enough for edp), and I'm not sure how exactly that's supposed to be
instantiated. Maybe a special function to instantiate an edp panel, which
takes both a DT node and the dp_aux controller would be much better,
instead of trying to auto-match against a DT compatible string and load a
panel driver which is almost all fake.
Or we teach dp_aux to register itself and somehow teach panel-edp how it
can get hold of the dp_aux channel it needs.
But fake mode in panel-simple sounds like the wrong approach. At least
from our experience with i915 (and I think other drivers supporting edp),
the standardization of panels for basic stuff at least worked.
Self-refresh seems an entirely different story unfortunately ... but again
quirking that for DP stuff should be done using the OUI I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 9:40 ` Daniel Vetter
0 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-04 9:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > width/height or any modes/timings in dts. But this panel still may have
> > > > regulator and/or backlight.
> > > >
> > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > ---
> > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > >
> > > Please don't try to make panels look more generic than they really are.
> > > You're going to have to provide a compatible string for your device that
> > > is more specific than "panel-edp". You claim that you don't need any
> > > extra information that is panel specific, but you don't know that now.
> > > We have in the past thought that we didn't need things like prepare
> > > delay, but then we ran into situations where we did need them.
> > >
> > > Just do what everybody else does. Provide a specific compatible string
> > > and match on that in the panel-simple driver. Even if you can read all
> > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > is faulty on some device.
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
This would defeat the point of edp, which is to standardize the mess of
panels (at least somewhat) and avoid having to change the DT/ACPI
tables/firmware for every board you ship. Also, we do have DP quirking
infrastructure already (using the OUI), I think if there's something that
doesn't work then we should quirk it there.
What does make sense though imo is if we try not to stuff the edp panel
into panel-simple, because it's anything like a simple dumb panel. There's
also some integration awkwardness since with this panel you need to do dp
aux/i2c transactions to get at the information (edid alone isn't good
enough for edp), and I'm not sure how exactly that's supposed to be
instantiated. Maybe a special function to instantiate an edp panel, which
takes both a DT node and the dp_aux controller would be much better,
instead of trying to auto-match against a DT compatible string and load a
panel driver which is almost all fake.
Or we teach dp_aux to register itself and somehow teach panel-edp how it
can get hold of the dp_aux channel it needs.
But fake mode in panel-simple sounds like the wrong approach. At least
from our experience with i915 (and I think other drivers supporting edp),
the standardization of panels for basic stuff at least worked.
Self-refresh seems an entirely different story unfortunately ... but again
quirking that for DP stuff should be done using the OUI I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <20190204094012.GP3271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 9:40 ` Daniel Vetter
@ 2019-02-04 11:22 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 11:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Vasily Khoruzhick, David Airlie, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 5586 bytes --]
On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > regulator and/or backlight.
> > > > >
> > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > ---
> > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > >
> > > > Please don't try to make panels look more generic than they really are.
> > > > You're going to have to provide a compatible string for your device that
> > > > is more specific than "panel-edp". You claim that you don't need any
> > > > extra information that is panel specific, but you don't know that now.
> > > > We have in the past thought that we didn't need things like prepare
> > > > delay, but then we ran into situations where we did need them.
> > > >
> > > > Just do what everybody else does. Provide a specific compatible string
> > > > and match on that in the panel-simple driver. Even if you can read all
> > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > is faulty on some device.
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> This would defeat the point of edp, which is to standardize the mess of
> panels (at least somewhat) and avoid having to change the DT/ACPI
> tables/firmware for every board you ship. Also, we do have DP quirking
> infrastructure already (using the OUI), I think if there's something that
> doesn't work then we should quirk it there.
The problem is that while the attempt may have been to standardize, it
failed. It doesn't take into account any of the details such as timing
between things like powering up the display and enabling the backlight
or similar. I don't know how you'd want to "quirk" those kinds of
requirements because they are highly panel specific.
> What does make sense though imo is if we try not to stuff the edp panel
> into panel-simple, because it's anything like a simple dumb panel. There's
> also some integration awkwardness since with this panel you need to do dp
> aux/i2c transactions to get at the information (edid alone isn't good
> enough for edp), and I'm not sure how exactly that's supposed to be
> instantiated. Maybe a special function to instantiate an edp panel, which
> takes both a DT node and the dp_aux controller would be much better,
> instead of trying to auto-match against a DT compatible string and load a
> panel driver which is almost all fake.
>
> Or we teach dp_aux to register itself and somehow teach panel-edp how it
> can get hold of the dp_aux channel it needs.
We already do that. drm_dp_aux registers as an I2C adapter that can be
used to read EDID EEPROMs using I2C-over-AUX transactions. We already
use that on some platforms.
Also note that simple-panel already supports getting video timings from
EDID. If a DDC link is present in DT, the driver will load the modes
from EDID and use them.
> But fake mode in panel-simple sounds like the wrong approach. At least
> from our experience with i915 (and I think other drivers supporting edp),
> the standardization of panels for basic stuff at least worked.
> Self-refresh seems an entirely different story unfortunately ... but again
> quirking that for DP stuff should be done using the OUI I think.
I can imagine that on x86 platforms OEMs can also easily hide some of
the necessary quirks in ACPI. None of that exists on ARM or other
architectures that solely rely on device tree to describe the device.
Since there's no way of specifying power sequences in DT (there have
been attempts in the past to make that work, but they failed miserably)
all we can do is match on a compatible string and encode the necessary
logic in the driver. Luckily we haven't run into anything too fancy up
to now and we've been able to make things work mostly with just a couple
of fairly generic parameters.
Also note that initially people thought this wasn't going to be
necessary and we only added the various "delay" parameters later on
because it did turn out that not all panels are created equal.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 11:22 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 11:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 5629 bytes --]
On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > regulator and/or backlight.
> > > > >
> > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > ---
> > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > >
> > > > Please don't try to make panels look more generic than they really are.
> > > > You're going to have to provide a compatible string for your device that
> > > > is more specific than "panel-edp". You claim that you don't need any
> > > > extra information that is panel specific, but you don't know that now.
> > > > We have in the past thought that we didn't need things like prepare
> > > > delay, but then we ran into situations where we did need them.
> > > >
> > > > Just do what everybody else does. Provide a specific compatible string
> > > > and match on that in the panel-simple driver. Even if you can read all
> > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > is faulty on some device.
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> This would defeat the point of edp, which is to standardize the mess of
> panels (at least somewhat) and avoid having to change the DT/ACPI
> tables/firmware for every board you ship. Also, we do have DP quirking
> infrastructure already (using the OUI), I think if there's something that
> doesn't work then we should quirk it there.
The problem is that while the attempt may have been to standardize, it
failed. It doesn't take into account any of the details such as timing
between things like powering up the display and enabling the backlight
or similar. I don't know how you'd want to "quirk" those kinds of
requirements because they are highly panel specific.
> What does make sense though imo is if we try not to stuff the edp panel
> into panel-simple, because it's anything like a simple dumb panel. There's
> also some integration awkwardness since with this panel you need to do dp
> aux/i2c transactions to get at the information (edid alone isn't good
> enough for edp), and I'm not sure how exactly that's supposed to be
> instantiated. Maybe a special function to instantiate an edp panel, which
> takes both a DT node and the dp_aux controller would be much better,
> instead of trying to auto-match against a DT compatible string and load a
> panel driver which is almost all fake.
>
> Or we teach dp_aux to register itself and somehow teach panel-edp how it
> can get hold of the dp_aux channel it needs.
We already do that. drm_dp_aux registers as an I2C adapter that can be
used to read EDID EEPROMs using I2C-over-AUX transactions. We already
use that on some platforms.
Also note that simple-panel already supports getting video timings from
EDID. If a DDC link is present in DT, the driver will load the modes
from EDID and use them.
> But fake mode in panel-simple sounds like the wrong approach. At least
> from our experience with i915 (and I think other drivers supporting edp),
> the standardization of panels for basic stuff at least worked.
> Self-refresh seems an entirely different story unfortunately ... but again
> quirking that for DP stuff should be done using the OUI I think.
I can imagine that on x86 platforms OEMs can also easily hide some of
the necessary quirks in ACPI. None of that exists on ARM or other
architectures that solely rely on device tree to describe the device.
Since there's no way of specifying power sequences in DT (there have
been attempts in the past to make that work, but they failed miserably)
all we can do is match on a compatible string and encode the necessary
logic in the driver. Luckily we haven't run into anything too fancy up
to now and we've been able to make things work mostly with just a couple
of fairly generic parameters.
Also note that initially people thought this wasn't going to be
necessary and we only added the various "delay" parameters later on
because it did turn out that not all panels are created equal.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 11:22 ` Thierry Reding
@ 2019-02-04 15:59 ` Daniel Vetter
-1 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-04 15:59 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Vasily Khoruzhick, David Airlie, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, arm-linux, linux-sunxi
On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > ---
> > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really are.
> > > > > You're going to have to provide a compatible string for your device that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > This would defeat the point of edp, which is to standardize the mess of
> > panels (at least somewhat) and avoid having to change the DT/ACPI
> > tables/firmware for every board you ship. Also, we do have DP quirking
> > infrastructure already (using the OUI), I think if there's something that
> > doesn't work then we should quirk it there.
>
> The problem is that while the attempt may have been to standardize, it
> failed. It doesn't take into account any of the details such as timing
> between things like powering up the display and enabling the backlight
> or similar. I don't know how you'd want to "quirk" those kinds of
> requirements because they are highly panel specific.
Hm right, we get these from some firmware tables (and mix them with the
spec one, since some of the firmware values are nonsense). I don't even
know whether we can read the timings over dp aux somehow (you can power up
the panel with some pessimistic values to figure those out, and you only
need dp aux to work, which is much simpler than the entire panel).
> > What does make sense though imo is if we try not to stuff the edp panel
> > into panel-simple, because it's anything like a simple dumb panel. There's
> > also some integration awkwardness since with this panel you need to do dp
> > aux/i2c transactions to get at the information (edid alone isn't good
> > enough for edp), and I'm not sure how exactly that's supposed to be
> > instantiated. Maybe a special function to instantiate an edp panel, which
> > takes both a DT node and the dp_aux controller would be much better,
> > instead of trying to auto-match against a DT compatible string and load a
> > panel driver which is almost all fake.
> >
> > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > can get hold of the dp_aux channel it needs.
>
> We already do that. drm_dp_aux registers as an I2C adapter that can be
> used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> use that on some platforms.
>
> Also note that simple-panel already supports getting video timings from
> EDID. If a DDC link is present in DT, the driver will load the modes
> from EDID and use them.
Could we extend this to dp aux somehow? For edp you need the dp aux (which
then gives you the ddc link automatically).
> > But fake mode in panel-simple sounds like the wrong approach. At least
> > from our experience with i915 (and I think other drivers supporting edp),
> > the standardization of panels for basic stuff at least worked.
> > Self-refresh seems an entirely different story unfortunately ... but again
> > quirking that for DP stuff should be done using the OUI I think.
>
> I can imagine that on x86 platforms OEMs can also easily hide some of
> the necessary quirks in ACPI. None of that exists on ARM or other
> architectures that solely rely on device tree to describe the device.
> Since there's no way of specifying power sequences in DT (there have
> been attempts in the past to make that work, but they failed miserably)
> all we can do is match on a compatible string and encode the necessary
> logic in the driver. Luckily we haven't run into anything too fancy up
> to now and we've been able to make things work mostly with just a couple
> of fairly generic parameters.
>
> Also note that initially people thought this wasn't going to be
> necessary and we only added the various "delay" parameters later on
> because it did turn out that not all panels are created equal.
Yeah this sucks, but oh well.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 15:59 ` Daniel Vetter
0 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-04 15:59 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > ---
> > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really are.
> > > > > You're going to have to provide a compatible string for your device that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > This would defeat the point of edp, which is to standardize the mess of
> > panels (at least somewhat) and avoid having to change the DT/ACPI
> > tables/firmware for every board you ship. Also, we do have DP quirking
> > infrastructure already (using the OUI), I think if there's something that
> > doesn't work then we should quirk it there.
>
> The problem is that while the attempt may have been to standardize, it
> failed. It doesn't take into account any of the details such as timing
> between things like powering up the display and enabling the backlight
> or similar. I don't know how you'd want to "quirk" those kinds of
> requirements because they are highly panel specific.
Hm right, we get these from some firmware tables (and mix them with the
spec one, since some of the firmware values are nonsense). I don't even
know whether we can read the timings over dp aux somehow (you can power up
the panel with some pessimistic values to figure those out, and you only
need dp aux to work, which is much simpler than the entire panel).
> > What does make sense though imo is if we try not to stuff the edp panel
> > into panel-simple, because it's anything like a simple dumb panel. There's
> > also some integration awkwardness since with this panel you need to do dp
> > aux/i2c transactions to get at the information (edid alone isn't good
> > enough for edp), and I'm not sure how exactly that's supposed to be
> > instantiated. Maybe a special function to instantiate an edp panel, which
> > takes both a DT node and the dp_aux controller would be much better,
> > instead of trying to auto-match against a DT compatible string and load a
> > panel driver which is almost all fake.
> >
> > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > can get hold of the dp_aux channel it needs.
>
> We already do that. drm_dp_aux registers as an I2C adapter that can be
> used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> use that on some platforms.
>
> Also note that simple-panel already supports getting video timings from
> EDID. If a DDC link is present in DT, the driver will load the modes
> from EDID and use them.
Could we extend this to dp aux somehow? For edp you need the dp aux (which
then gives you the ddc link automatically).
> > But fake mode in panel-simple sounds like the wrong approach. At least
> > from our experience with i915 (and I think other drivers supporting edp),
> > the standardization of panels for basic stuff at least worked.
> > Self-refresh seems an entirely different story unfortunately ... but again
> > quirking that for DP stuff should be done using the OUI I think.
>
> I can imagine that on x86 platforms OEMs can also easily hide some of
> the necessary quirks in ACPI. None of that exists on ARM or other
> architectures that solely rely on device tree to describe the device.
> Since there's no way of specifying power sequences in DT (there have
> been attempts in the past to make that work, but they failed miserably)
> all we can do is match on a compatible string and encode the necessary
> logic in the driver. Luckily we haven't run into anything too fancy up
> to now and we've been able to make things work mostly with just a couple
> of fairly generic parameters.
>
> Also note that initially people thought this wasn't going to be
> necessary and we only added the various "delay" parameters later on
> because it did turn out that not all panels are created equal.
Yeah this sucks, but oh well.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <20190204155909.GU3271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 15:59 ` Daniel Vetter
@ 2019-02-04 16:22 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Vasily Khoruzhick, David Airlie, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 5874 bytes --]
On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > >
> > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > regulator and/or backlight.
> > > > > > >
> > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > ---
> > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > >
> > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > You're going to have to provide a compatible string for your device that
> > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > delay, but then we ran into situations where we did need them.
> > > > > >
> > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > is faulty on some device.
> > > > >
> > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > and recent batch uses 1080p panel.
> > > > >
> > > > > What panel descriptor should I use as fallback?
> > > >
> > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > will bind to a panel device and use the corresponding descriptor. If
> > > > your device tree contains the correct information, the descriptor is
> > > > correct for the panel you have.
> > > >
> > > > In other words you need to ensure that you have the correct panel in
> > > > device tree for the board that you're using. This is exactly the same
> > > > thing as for other devices.
> > > >
> > > > One way to to this is to have separate device trees for each variant
> > > > of the board that you want to support. Another variant may be to have
> > > > a common device tree and then have some early firmware update the DTB
> > > > with the correct panel information.
> > >
> > > This would defeat the point of edp, which is to standardize the mess of
> > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > infrastructure already (using the OUI), I think if there's something that
> > > doesn't work then we should quirk it there.
> >
> > The problem is that while the attempt may have been to standardize, it
> > failed. It doesn't take into account any of the details such as timing
> > between things like powering up the display and enabling the backlight
> > or similar. I don't know how you'd want to "quirk" those kinds of
> > requirements because they are highly panel specific.
>
> Hm right, we get these from some firmware tables (and mix them with the
> spec one, since some of the firmware values are nonsense). I don't even
> know whether we can read the timings over dp aux somehow (you can power up
> the panel with some pessimistic values to figure those out, and you only
> need dp aux to work, which is much simpler than the entire panel).
>
> > > What does make sense though imo is if we try not to stuff the edp panel
> > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > also some integration awkwardness since with this panel you need to do dp
> > > aux/i2c transactions to get at the information (edid alone isn't good
> > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > takes both a DT node and the dp_aux controller would be much better,
> > > instead of trying to auto-match against a DT compatible string and load a
> > > panel driver which is almost all fake.
> > >
> > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > can get hold of the dp_aux channel it needs.
> >
> > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > use that on some platforms.
> >
> > Also note that simple-panel already supports getting video timings from
> > EDID. If a DDC link is present in DT, the driver will load the modes
> > from EDID and use them.
>
> Could we extend this to dp aux somehow? For edp you need the dp aux (which
> then gives you the ddc link automatically).
I suppose we could do that. We could introduce a new property that would
allow the panel driver to get at the struct drm_dp_aux that can access
the panel. I'm not sure how much that would buy us. I suppose the driver
could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
ddc-bus property in device tree. A drm_dp_aux object could also be used
to access DPCD if that's helpful.
The driver proposed here doesn't need access to DPCD, so I'm not sure
that would immediately help.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:22 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:22 UTC (permalink / raw)
To: Daniel Vetter
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 5918 bytes --]
On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > >
> > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > regulator and/or backlight.
> > > > > > >
> > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > ---
> > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > >
> > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > You're going to have to provide a compatible string for your device that
> > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > delay, but then we ran into situations where we did need them.
> > > > > >
> > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > is faulty on some device.
> > > > >
> > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > and recent batch uses 1080p panel.
> > > > >
> > > > > What panel descriptor should I use as fallback?
> > > >
> > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > will bind to a panel device and use the corresponding descriptor. If
> > > > your device tree contains the correct information, the descriptor is
> > > > correct for the panel you have.
> > > >
> > > > In other words you need to ensure that you have the correct panel in
> > > > device tree for the board that you're using. This is exactly the same
> > > > thing as for other devices.
> > > >
> > > > One way to to this is to have separate device trees for each variant
> > > > of the board that you want to support. Another variant may be to have
> > > > a common device tree and then have some early firmware update the DTB
> > > > with the correct panel information.
> > >
> > > This would defeat the point of edp, which is to standardize the mess of
> > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > infrastructure already (using the OUI), I think if there's something that
> > > doesn't work then we should quirk it there.
> >
> > The problem is that while the attempt may have been to standardize, it
> > failed. It doesn't take into account any of the details such as timing
> > between things like powering up the display and enabling the backlight
> > or similar. I don't know how you'd want to "quirk" those kinds of
> > requirements because they are highly panel specific.
>
> Hm right, we get these from some firmware tables (and mix them with the
> spec one, since some of the firmware values are nonsense). I don't even
> know whether we can read the timings over dp aux somehow (you can power up
> the panel with some pessimistic values to figure those out, and you only
> need dp aux to work, which is much simpler than the entire panel).
>
> > > What does make sense though imo is if we try not to stuff the edp panel
> > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > also some integration awkwardness since with this panel you need to do dp
> > > aux/i2c transactions to get at the information (edid alone isn't good
> > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > takes both a DT node and the dp_aux controller would be much better,
> > > instead of trying to auto-match against a DT compatible string and load a
> > > panel driver which is almost all fake.
> > >
> > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > can get hold of the dp_aux channel it needs.
> >
> > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > use that on some platforms.
> >
> > Also note that simple-panel already supports getting video timings from
> > EDID. If a DDC link is present in DT, the driver will load the modes
> > from EDID and use them.
>
> Could we extend this to dp aux somehow? For edp you need the dp aux (which
> then gives you the ddc link automatically).
I suppose we could do that. We could introduce a new property that would
allow the panel driver to get at the struct drm_dp_aux that can access
the panel. I'm not sure how much that would buy us. I suppose the driver
could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
ddc-bus property in device tree. A drm_dp_aux object could also be used
to access DPCD if that's helpful.
The driver proposed here doesn't need access to DPCD, so I'm not sure
that would immediately help.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:22 ` Thierry Reding
@ 2019-02-05 8:57 ` Daniel Vetter
-1 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-05 8:57 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Vasily Khoruzhick, David Airlie, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, arm-linux, linux-sunxi
On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > >
> > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > regulator and/or backlight.
> > > > > > > >
> > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > ---
> > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > >
> > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > >
> > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > is faulty on some device.
> > > > > >
> > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > and recent batch uses 1080p panel.
> > > > > >
> > > > > > What panel descriptor should I use as fallback?
> > > > >
> > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > your device tree contains the correct information, the descriptor is
> > > > > correct for the panel you have.
> > > > >
> > > > > In other words you need to ensure that you have the correct panel in
> > > > > device tree for the board that you're using. This is exactly the same
> > > > > thing as for other devices.
> > > > >
> > > > > One way to to this is to have separate device trees for each variant
> > > > > of the board that you want to support. Another variant may be to have
> > > > > a common device tree and then have some early firmware update the DTB
> > > > > with the correct panel information.
> > > >
> > > > This would defeat the point of edp, which is to standardize the mess of
> > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > infrastructure already (using the OUI), I think if there's something that
> > > > doesn't work then we should quirk it there.
> > >
> > > The problem is that while the attempt may have been to standardize, it
> > > failed. It doesn't take into account any of the details such as timing
> > > between things like powering up the display and enabling the backlight
> > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > requirements because they are highly panel specific.
> >
> > Hm right, we get these from some firmware tables (and mix them with the
> > spec one, since some of the firmware values are nonsense). I don't even
> > know whether we can read the timings over dp aux somehow (you can power up
> > the panel with some pessimistic values to figure those out, and you only
> > need dp aux to work, which is much simpler than the entire panel).
> >
> > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > also some integration awkwardness since with this panel you need to do dp
> > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > takes both a DT node and the dp_aux controller would be much better,
> > > > instead of trying to auto-match against a DT compatible string and load a
> > > > panel driver which is almost all fake.
> > > >
> > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > can get hold of the dp_aux channel it needs.
> > >
> > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > use that on some platforms.
> > >
> > > Also note that simple-panel already supports getting video timings from
> > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > from EDID and use them.
> >
> > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > then gives you the ddc link automatically).
>
> I suppose we could do that. We could introduce a new property that would
> allow the panel driver to get at the struct drm_dp_aux that can access
> the panel. I'm not sure how much that would buy us. I suppose the driver
> could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> ddc-bus property in device tree. A drm_dp_aux object could also be used
> to access DPCD if that's helpful.
>
> The driver proposed here doesn't need access to DPCD, so I'm not sure
> that would immediately help.
You definitely need dp aux to drive edp. That's where a lot of the really
important stuff is stored, and it sounds like on non-broken panels even
the timings (we've never implemented that on i915 somehow).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-05 8:57 ` Daniel Vetter
0 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-05 8:57 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > regulator and/or backlight.
> > > > > > > >
> > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > ---
> > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > >
> > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > >
> > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > is faulty on some device.
> > > > > >
> > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > and recent batch uses 1080p panel.
> > > > > >
> > > > > > What panel descriptor should I use as fallback?
> > > > >
> > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > your device tree contains the correct information, the descriptor is
> > > > > correct for the panel you have.
> > > > >
> > > > > In other words you need to ensure that you have the correct panel in
> > > > > device tree for the board that you're using. This is exactly the same
> > > > > thing as for other devices.
> > > > >
> > > > > One way to to this is to have separate device trees for each variant
> > > > > of the board that you want to support. Another variant may be to have
> > > > > a common device tree and then have some early firmware update the DTB
> > > > > with the correct panel information.
> > > >
> > > > This would defeat the point of edp, which is to standardize the mess of
> > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > infrastructure already (using the OUI), I think if there's something that
> > > > doesn't work then we should quirk it there.
> > >
> > > The problem is that while the attempt may have been to standardize, it
> > > failed. It doesn't take into account any of the details such as timing
> > > between things like powering up the display and enabling the backlight
> > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > requirements because they are highly panel specific.
> >
> > Hm right, we get these from some firmware tables (and mix them with the
> > spec one, since some of the firmware values are nonsense). I don't even
> > know whether we can read the timings over dp aux somehow (you can power up
> > the panel with some pessimistic values to figure those out, and you only
> > need dp aux to work, which is much simpler than the entire panel).
> >
> > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > also some integration awkwardness since with this panel you need to do dp
> > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > takes both a DT node and the dp_aux controller would be much better,
> > > > instead of trying to auto-match against a DT compatible string and load a
> > > > panel driver which is almost all fake.
> > > >
> > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > can get hold of the dp_aux channel it needs.
> > >
> > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > use that on some platforms.
> > >
> > > Also note that simple-panel already supports getting video timings from
> > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > from EDID and use them.
> >
> > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > then gives you the ddc link automatically).
>
> I suppose we could do that. We could introduce a new property that would
> allow the panel driver to get at the struct drm_dp_aux that can access
> the panel. I'm not sure how much that would buy us. I suppose the driver
> could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> ddc-bus property in device tree. A drm_dp_aux object could also be used
> to access DPCD if that's helpful.
>
> The driver proposed here doesn't need access to DPCD, so I'm not sure
> that would immediately help.
You definitely need dp aux to drive edp. That's where a lot of the really
important stuff is stored, and it sounds like on non-broken panels even
the timings (we've never implemented that on i915 somehow).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-05 8:57 ` Daniel Vetter
@ 2019-02-05 10:24 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-05 10:24 UTC (permalink / raw)
To: Daniel Vetter
Cc: Mark Rutland, devicetree, David Airlie, linux-sunxi, dri-devel,
Vasily Khoruzhick, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Sean Paul, Laurent Pinchart, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 8642 bytes --]
On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > regulator and/or backlight.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > ---
> > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > >
> > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > >
> > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > is faulty on some device.
> > > > > > >
> > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > and recent batch uses 1080p panel.
> > > > > > >
> > > > > > > What panel descriptor should I use as fallback?
> > > > > >
> > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > your device tree contains the correct information, the descriptor is
> > > > > > correct for the panel you have.
> > > > > >
> > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > thing as for other devices.
> > > > > >
> > > > > > One way to to this is to have separate device trees for each variant
> > > > > > of the board that you want to support. Another variant may be to have
> > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > with the correct panel information.
> > > > >
> > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > doesn't work then we should quirk it there.
> > > >
> > > > The problem is that while the attempt may have been to standardize, it
> > > > failed. It doesn't take into account any of the details such as timing
> > > > between things like powering up the display and enabling the backlight
> > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > requirements because they are highly panel specific.
> > >
> > > Hm right, we get these from some firmware tables (and mix them with the
> > > spec one, since some of the firmware values are nonsense). I don't even
> > > know whether we can read the timings over dp aux somehow (you can power up
> > > the panel with some pessimistic values to figure those out, and you only
> > > need dp aux to work, which is much simpler than the entire panel).
> > >
> > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > panel driver which is almost all fake.
> > > > >
> > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > can get hold of the dp_aux channel it needs.
> > > >
> > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > use that on some platforms.
> > > >
> > > > Also note that simple-panel already supports getting video timings from
> > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > from EDID and use them.
> > >
> > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > then gives you the ddc link automatically).
> >
> > I suppose we could do that. We could introduce a new property that would
> > allow the panel driver to get at the struct drm_dp_aux that can access
> > the panel. I'm not sure how much that would buy us. I suppose the driver
> > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > to access DPCD if that's helpful.
> >
> > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > that would immediately help.
>
> You definitely need dp aux to drive edp. That's where a lot of the really
> important stuff is stored, and it sounds like on non-broken panels even
> the timings (we've never implemented that on i915 somehow).
I'm not sure I understand what you're saying here. I haven't worked with
eDP panels in a while, but my recollection is that you can use DP AUX to
read video timings over EDID. We provide support for that by exporting a
DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
and then that I2C adapter can be used to read the EDID. I wasn't aware
that eDP panels additionally stored the video timings somewhere else.
What I meant above was that aside from the I2C-over-AUX for reading the
EDID, this driver doesn't do anything else with DP AUX in order to turn
the panel on. Looking at the eDP support we have on Tegra, there's a
DPCD register (DP_SET_POWER) that needs to be written in order to take
the sink device (i.e. panel) out of the power saving state. We do that
as part of the connector implementation rather than within the panel
driver. There are also additional registers such as DP_LINK_BW_SET that
need to be programmed. I think this is also relevant to regular DP and
detailed in the specification.
Given all the above, I'm beginning to think that Rob's right in that
perhaps we shouldn't be treating eDP panels as panels, but rather to
make them look more like DP monitors and make all this code part of the
connector implementation. I think pretty much the only differences to
regular DP are that we might require some lower-level resources that a
DP monitor would usually have built-in (reset or power GPIOs, power
supplies, backlight, ...).
I'm not sure if that's enough for eDP panels, though. For example the
AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
panel. But the driver also specifies a couple of additional delays which
suggests that either it violates the eDP specification or that the eDP
specification doesn't define any power sequencing delays that would've
been needed. Or perhaps these delays are specified somewhere and the
driver just doesn't use them?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-05 10:24 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-05 10:24 UTC (permalink / raw)
To: Daniel Vetter
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 8642 bytes --]
On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > regulator and/or backlight.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > ---
> > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > >
> > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > >
> > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > is faulty on some device.
> > > > > > >
> > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > and recent batch uses 1080p panel.
> > > > > > >
> > > > > > > What panel descriptor should I use as fallback?
> > > > > >
> > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > your device tree contains the correct information, the descriptor is
> > > > > > correct for the panel you have.
> > > > > >
> > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > thing as for other devices.
> > > > > >
> > > > > > One way to to this is to have separate device trees for each variant
> > > > > > of the board that you want to support. Another variant may be to have
> > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > with the correct panel information.
> > > > >
> > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > doesn't work then we should quirk it there.
> > > >
> > > > The problem is that while the attempt may have been to standardize, it
> > > > failed. It doesn't take into account any of the details such as timing
> > > > between things like powering up the display and enabling the backlight
> > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > requirements because they are highly panel specific.
> > >
> > > Hm right, we get these from some firmware tables (and mix them with the
> > > spec one, since some of the firmware values are nonsense). I don't even
> > > know whether we can read the timings over dp aux somehow (you can power up
> > > the panel with some pessimistic values to figure those out, and you only
> > > need dp aux to work, which is much simpler than the entire panel).
> > >
> > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > panel driver which is almost all fake.
> > > > >
> > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > can get hold of the dp_aux channel it needs.
> > > >
> > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > use that on some platforms.
> > > >
> > > > Also note that simple-panel already supports getting video timings from
> > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > from EDID and use them.
> > >
> > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > then gives you the ddc link automatically).
> >
> > I suppose we could do that. We could introduce a new property that would
> > allow the panel driver to get at the struct drm_dp_aux that can access
> > the panel. I'm not sure how much that would buy us. I suppose the driver
> > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > to access DPCD if that's helpful.
> >
> > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > that would immediately help.
>
> You definitely need dp aux to drive edp. That's where a lot of the really
> important stuff is stored, and it sounds like on non-broken panels even
> the timings (we've never implemented that on i915 somehow).
I'm not sure I understand what you're saying here. I haven't worked with
eDP panels in a while, but my recollection is that you can use DP AUX to
read video timings over EDID. We provide support for that by exporting a
DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
and then that I2C adapter can be used to read the EDID. I wasn't aware
that eDP panels additionally stored the video timings somewhere else.
What I meant above was that aside from the I2C-over-AUX for reading the
EDID, this driver doesn't do anything else with DP AUX in order to turn
the panel on. Looking at the eDP support we have on Tegra, there's a
DPCD register (DP_SET_POWER) that needs to be written in order to take
the sink device (i.e. panel) out of the power saving state. We do that
as part of the connector implementation rather than within the panel
driver. There are also additional registers such as DP_LINK_BW_SET that
need to be programmed. I think this is also relevant to regular DP and
detailed in the specification.
Given all the above, I'm beginning to think that Rob's right in that
perhaps we shouldn't be treating eDP panels as panels, but rather to
make them look more like DP monitors and make all this code part of the
connector implementation. I think pretty much the only differences to
regular DP are that we might require some lower-level resources that a
DP monitor would usually have built-in (reset or power GPIOs, power
supplies, backlight, ...).
I'm not sure if that's enough for eDP panels, though. For example the
AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
panel. But the driver also specifies a couple of additional delays which
suggests that either it violates the eDP specification or that the eDP
specification doesn't define any power sequencing delays that would've
been needed. Or perhaps these delays are specified somewhere and the
driver just doesn't use them?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-05 10:24 ` Thierry Reding
@ 2019-02-05 16:36 ` Daniel Vetter
-1 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-05 16:36 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Vasily Khoruzhick, David Airlie, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, arm-linux, linux-sunxi
On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > regulator and/or backlight.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > ---
> > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > >
> > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > >
> > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > is faulty on some device.
> > > > > > > >
> > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > and recent batch uses 1080p panel.
> > > > > > > >
> > > > > > > > What panel descriptor should I use as fallback?
> > > > > > >
> > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > correct for the panel you have.
> > > > > > >
> > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > thing as for other devices.
> > > > > > >
> > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > with the correct panel information.
> > > > > >
> > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > doesn't work then we should quirk it there.
> > > > >
> > > > > The problem is that while the attempt may have been to standardize, it
> > > > > failed. It doesn't take into account any of the details such as timing
> > > > > between things like powering up the display and enabling the backlight
> > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > requirements because they are highly panel specific.
> > > >
> > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > the panel with some pessimistic values to figure those out, and you only
> > > > need dp aux to work, which is much simpler than the entire panel).
> > > >
> > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > panel driver which is almost all fake.
> > > > > >
> > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > can get hold of the dp_aux channel it needs.
> > > > >
> > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > use that on some platforms.
> > > > >
> > > > > Also note that simple-panel already supports getting video timings from
> > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > from EDID and use them.
> > > >
> > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > then gives you the ddc link automatically).
> > >
> > > I suppose we could do that. We could introduce a new property that would
> > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > to access DPCD if that's helpful.
> > >
> > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > that would immediately help.
> >
> > You definitely need dp aux to drive edp. That's where a lot of the really
> > important stuff is stored, and it sounds like on non-broken panels even
> > the timings (we've never implemented that on i915 somehow).
>
> I'm not sure I understand what you're saying here. I haven't worked with
> eDP panels in a while, but my recollection is that you can use DP AUX to
> read video timings over EDID. We provide support for that by exporting a
> DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> and then that I2C adapter can be used to read the EDID. I wasn't aware
> that eDP panels additionally stored the video timings somewhere else.
I didn't know either, but understood Vasily's comment that this is
possible. Haven't dug around in the specs though.
> What I meant above was that aside from the I2C-over-AUX for reading the
> EDID, this driver doesn't do anything else with DP AUX in order to turn
> the panel on. Looking at the eDP support we have on Tegra, there's a
> DPCD register (DP_SET_POWER) that needs to be written in order to take
> the sink device (i.e. panel) out of the power saving state. We do that
> as part of the connector implementation rather than within the panel
> driver. There are also additional registers such as DP_LINK_BW_SET that
> need to be programmed. I think this is also relevant to regular DP and
> detailed in the specification.
>
> Given all the above, I'm beginning to think that Rob's right in that
> perhaps we shouldn't be treating eDP panels as panels, but rather to
> make them look more like DP monitors and make all this code part of the
> connector implementation. I think pretty much the only differences to
> regular DP are that we might require some lower-level resources that a
> DP monitor would usually have built-in (reset or power GPIOs, power
> supplies, backlight, ...).
>
> I'm not sure if that's enough for eDP panels, though. For example the
> AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> panel. But the driver also specifies a couple of additional delays which
> suggests that either it violates the eDP specification or that the eDP
> specification doesn't define any power sequencing delays that would've
> been needed. Or perhaps these delays are specified somewhere and the
> driver just doesn't use them?
I honestly don't know, but gut feeling also goes towards making edp
something else than a dumb panel. There's a lot of stuff you need to do
that overlaps with normal DP sinks, plus there's a lot of stuff (but not
everything, or at least it needs some quirking sometimes) that you're
supposed to autodiscover. But I'm not sure what's the best solution really
is, since for i915 all the quirking we need is in some i915-specific
tables (and I'm not even sure how much of that quirking is really
necessary, and how much just convenience for us because the fw already did
the hard work of poking the information out of the panel).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-05 16:36 ` Daniel Vetter
0 siblings, 0 replies; 176+ messages in thread
From: Daniel Vetter @ 2019-02-05 16:36 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > regulator and/or backlight.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > >
> > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > >
> > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > is faulty on some device.
> > > > > > > >
> > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > and recent batch uses 1080p panel.
> > > > > > > >
> > > > > > > > What panel descriptor should I use as fallback?
> > > > > > >
> > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > correct for the panel you have.
> > > > > > >
> > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > thing as for other devices.
> > > > > > >
> > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > with the correct panel information.
> > > > > >
> > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > doesn't work then we should quirk it there.
> > > > >
> > > > > The problem is that while the attempt may have been to standardize, it
> > > > > failed. It doesn't take into account any of the details such as timing
> > > > > between things like powering up the display and enabling the backlight
> > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > requirements because they are highly panel specific.
> > > >
> > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > the panel with some pessimistic values to figure those out, and you only
> > > > need dp aux to work, which is much simpler than the entire panel).
> > > >
> > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > panel driver which is almost all fake.
> > > > > >
> > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > can get hold of the dp_aux channel it needs.
> > > > >
> > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > use that on some platforms.
> > > > >
> > > > > Also note that simple-panel already supports getting video timings from
> > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > from EDID and use them.
> > > >
> > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > then gives you the ddc link automatically).
> > >
> > > I suppose we could do that. We could introduce a new property that would
> > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > to access DPCD if that's helpful.
> > >
> > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > that would immediately help.
> >
> > You definitely need dp aux to drive edp. That's where a lot of the really
> > important stuff is stored, and it sounds like on non-broken panels even
> > the timings (we've never implemented that on i915 somehow).
>
> I'm not sure I understand what you're saying here. I haven't worked with
> eDP panels in a while, but my recollection is that you can use DP AUX to
> read video timings over EDID. We provide support for that by exporting a
> DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> and then that I2C adapter can be used to read the EDID. I wasn't aware
> that eDP panels additionally stored the video timings somewhere else.
I didn't know either, but understood Vasily's comment that this is
possible. Haven't dug around in the specs though.
> What I meant above was that aside from the I2C-over-AUX for reading the
> EDID, this driver doesn't do anything else with DP AUX in order to turn
> the panel on. Looking at the eDP support we have on Tegra, there's a
> DPCD register (DP_SET_POWER) that needs to be written in order to take
> the sink device (i.e. panel) out of the power saving state. We do that
> as part of the connector implementation rather than within the panel
> driver. There are also additional registers such as DP_LINK_BW_SET that
> need to be programmed. I think this is also relevant to regular DP and
> detailed in the specification.
>
> Given all the above, I'm beginning to think that Rob's right in that
> perhaps we shouldn't be treating eDP panels as panels, but rather to
> make them look more like DP monitors and make all this code part of the
> connector implementation. I think pretty much the only differences to
> regular DP are that we might require some lower-level resources that a
> DP monitor would usually have built-in (reset or power GPIOs, power
> supplies, backlight, ...).
>
> I'm not sure if that's enough for eDP panels, though. For example the
> AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> panel. But the driver also specifies a couple of additional delays which
> suggests that either it violates the eDP specification or that the eDP
> specification doesn't define any power sequencing delays that would've
> been needed. Or perhaps these delays are specified somewhere and the
> driver just doesn't use them?
I honestly don't know, but gut feeling also goes towards making edp
something else than a dumb panel. There's a lot of stuff you need to do
that overlaps with normal DP sinks, plus there's a lot of stuff (but not
everything, or at least it needs some quirking sometimes) that you're
supposed to autodiscover. But I'm not sure what's the best solution really
is, since for i915 all the quirking we need is in some i915-specific
tables (and I'm not even sure how much of that quirking is really
necessary, and how much just convenience for us because the fw already did
the hard work of poking the information out of the panel).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <20190205163649.GG3271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-05 16:36 ` Daniel Vetter
@ 2019-02-14 19:51 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 19:51 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Tue, Feb 5, 2019 at 8:36 AM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
>
> On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > > ---
> > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > >
> > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > >
> > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > is faulty on some device.
> > > > > > > > >
> > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > >
> > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > >
> > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > correct for the panel you have.
> > > > > > > >
> > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > thing as for other devices.
> > > > > > > >
> > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > with the correct panel information.
> > > > > > >
> > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > doesn't work then we should quirk it there.
> > > > > >
> > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > between things like powering up the display and enabling the backlight
> > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > requirements because they are highly panel specific.
> > > > >
> > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > >
> > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > panel driver which is almost all fake.
> > > > > > >
> > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > can get hold of the dp_aux channel it needs.
> > > > > >
> > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > use that on some platforms.
> > > > > >
> > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > from EDID and use them.
> > > > >
> > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > then gives you the ddc link automatically).
> > > >
> > > > I suppose we could do that. We could introduce a new property that would
> > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > to access DPCD if that's helpful.
> > > >
> > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > that would immediately help.
> > >
> > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > important stuff is stored, and it sounds like on non-broken panels even
> > > the timings (we've never implemented that on i915 somehow).
> >
> > I'm not sure I understand what you're saying here. I haven't worked with
> > eDP panels in a while, but my recollection is that you can use DP AUX to
> > read video timings over EDID. We provide support for that by exporting a
> > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > that eDP panels additionally stored the video timings somewhere else.
>
> I didn't know either, but understood Vasily's comment that this is
> possible. Haven't dug around in the specs though.
It probes link capabilities such as lanes number and rate, see
drm_dp_link_probe(),
I'm not sure if it's panel property or not.
> > What I meant above was that aside from the I2C-over-AUX for reading the
> > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > the panel on. Looking at the eDP support we have on Tegra, there's a
> > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > the sink device (i.e. panel) out of the power saving state. We do that
> > as part of the connector implementation rather than within the panel
> > driver. There are also additional registers such as DP_LINK_BW_SET that
> > need to be programmed. I think this is also relevant to regular DP and
> > detailed in the specification.
> >
> > Given all the above, I'm beginning to think that Rob's right in that
> > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > make them look more like DP monitors and make all this code part of the
> > connector implementation. I think pretty much the only differences to
> > regular DP are that we might require some lower-level resources that a
> > DP monitor would usually have built-in (reset or power GPIOs, power
> > supplies, backlight, ...).
> >
> > I'm not sure if that's enough for eDP panels, though. For example the
> > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > panel. But the driver also specifies a couple of additional delays which
> > suggests that either it violates the eDP specification or that the eDP
> > specification doesn't define any power sequencing delays that would've
> > been needed. Or perhaps these delays are specified somewhere and the
> > driver just doesn't use them?
>
> I honestly don't know, but gut feeling also goes towards making edp
> something else than a dumb panel. There's a lot of stuff you need to do
> that overlaps with normal DP sinks, plus there's a lot of stuff (but not
> everything, or at least it needs some quirking sometimes) that you're
> supposed to autodiscover. But I'm not sure what's the best solution really
> is, since for i915 all the quirking we need is in some i915-specific
> tables (and I'm not even sure how much of that quirking is really
> necessary, and how much just convenience for us because the fw already did
> the hard work of poking the information out of the panel).
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-14 19:51 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 19:51 UTC (permalink / raw)
To: Daniel Vetter
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, dri-devel, linux-sunxi, Rob Herring, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
arm-linux, Icenowy Zheng
On Tue, Feb 5, 2019 at 8:36 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > > > ---
> > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > >
> > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > >
> > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > is faulty on some device.
> > > > > > > > >
> > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > >
> > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > >
> > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > correct for the panel you have.
> > > > > > > >
> > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > thing as for other devices.
> > > > > > > >
> > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > with the correct panel information.
> > > > > > >
> > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > doesn't work then we should quirk it there.
> > > > > >
> > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > between things like powering up the display and enabling the backlight
> > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > requirements because they are highly panel specific.
> > > > >
> > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > >
> > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > panel driver which is almost all fake.
> > > > > > >
> > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > can get hold of the dp_aux channel it needs.
> > > > > >
> > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > use that on some platforms.
> > > > > >
> > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > from EDID and use them.
> > > > >
> > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > then gives you the ddc link automatically).
> > > >
> > > > I suppose we could do that. We could introduce a new property that would
> > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > to access DPCD if that's helpful.
> > > >
> > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > that would immediately help.
> > >
> > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > important stuff is stored, and it sounds like on non-broken panels even
> > > the timings (we've never implemented that on i915 somehow).
> >
> > I'm not sure I understand what you're saying here. I haven't worked with
> > eDP panels in a while, but my recollection is that you can use DP AUX to
> > read video timings over EDID. We provide support for that by exporting a
> > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > that eDP panels additionally stored the video timings somewhere else.
>
> I didn't know either, but understood Vasily's comment that this is
> possible. Haven't dug around in the specs though.
It probes link capabilities such as lanes number and rate, see
drm_dp_link_probe(),
I'm not sure if it's panel property or not.
> > What I meant above was that aside from the I2C-over-AUX for reading the
> > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > the panel on. Looking at the eDP support we have on Tegra, there's a
> > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > the sink device (i.e. panel) out of the power saving state. We do that
> > as part of the connector implementation rather than within the panel
> > driver. There are also additional registers such as DP_LINK_BW_SET that
> > need to be programmed. I think this is also relevant to regular DP and
> > detailed in the specification.
> >
> > Given all the above, I'm beginning to think that Rob's right in that
> > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > make them look more like DP monitors and make all this code part of the
> > connector implementation. I think pretty much the only differences to
> > regular DP are that we might require some lower-level resources that a
> > DP monitor would usually have built-in (reset or power GPIOs, power
> > supplies, backlight, ...).
> >
> > I'm not sure if that's enough for eDP panels, though. For example the
> > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > panel. But the driver also specifies a couple of additional delays which
> > suggests that either it violates the eDP specification or that the eDP
> > specification doesn't define any power sequencing delays that would've
> > been needed. Or perhaps these delays are specified somewhere and the
> > driver just doesn't use them?
>
> I honestly don't know, but gut feeling also goes towards making edp
> something else than a dumb panel. There's a lot of stuff you need to do
> that overlaps with normal DP sinks, plus there's a lot of stuff (but not
> everything, or at least it needs some quirking sometimes) that you're
> supposed to autodiscover. But I'm not sure what's the best solution really
> is, since for i915 all the quirking we need is in some i915-specific
> tables (and I'm not even sure how much of that quirking is really
> necessary, and how much just convenience for us because the fw already did
> the hard work of poking the information out of the panel).
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-05 10:24 ` Thierry Reding
@ 2019-02-14 20:05 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 20:05 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, David Airlie, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > regulator and/or backlight.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > ---
> > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > >
> > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > >
> > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > is faulty on some device.
> > > > > > > >
> > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > and recent batch uses 1080p panel.
> > > > > > > >
> > > > > > > > What panel descriptor should I use as fallback?
> > > > > > >
> > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > correct for the panel you have.
> > > > > > >
> > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > thing as for other devices.
> > > > > > >
> > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > with the correct panel information.
> > > > > >
> > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > doesn't work then we should quirk it there.
> > > > >
> > > > > The problem is that while the attempt may have been to standardize, it
> > > > > failed. It doesn't take into account any of the details such as timing
> > > > > between things like powering up the display and enabling the backlight
> > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > requirements because they are highly panel specific.
> > > >
> > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > the panel with some pessimistic values to figure those out, and you only
> > > > need dp aux to work, which is much simpler than the entire panel).
> > > >
> > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > panel driver which is almost all fake.
> > > > > >
> > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > can get hold of the dp_aux channel it needs.
> > > > >
> > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > use that on some platforms.
> > > > >
> > > > > Also note that simple-panel already supports getting video timings from
> > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > from EDID and use them.
> > > >
> > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > then gives you the ddc link automatically).
> > >
> > > I suppose we could do that. We could introduce a new property that would
> > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > to access DPCD if that's helpful.
> > >
> > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > that would immediately help.
> >
> > You definitely need dp aux to drive edp. That's where a lot of the really
> > important stuff is stored, and it sounds like on non-broken panels even
> > the timings (we've never implemented that on i915 somehow).
>
> I'm not sure I understand what you're saying here. I haven't worked with
> eDP panels in a while, but my recollection is that you can use DP AUX to
> read video timings over EDID. We provide support for that by exporting a
> DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> and then that I2C adapter can be used to read the EDID. I wasn't aware
> that eDP panels additionally stored the video timings somewhere else.
>
> What I meant above was that aside from the I2C-over-AUX for reading the
> EDID, this driver doesn't do anything else with DP AUX in order to turn
> the panel on. Looking at the eDP support we have on Tegra, there's a
> DPCD register (DP_SET_POWER) that needs to be written in order to take
> the sink device (i.e. panel) out of the power saving state. We do that
> as part of the connector implementation rather than within the panel
> driver. There are also additional registers such as DP_LINK_BW_SET that
> need to be programmed. I think this is also relevant to regular DP and
> detailed in the specification.
>
> Given all the above, I'm beginning to think that Rob's right in that
> perhaps we shouldn't be treating eDP panels as panels, but rather to
> make them look more like DP monitors and make all this code part of the
> connector implementation. I think pretty much the only differences to
> regular DP are that we might require some lower-level resources that a
> DP monitor would usually have built-in (reset or power GPIOs, power
> supplies, backlight, ...).
I spent some time poking drm_connector code and I came to conclusion
that it's not a good idea.
Basically edp-connector driver will duplicate simple-panel code and
will bring extra complexity
into bridge driver for no benefit at all.
Also currently there are no stand-alone connector drivers, they all
are part of display controller
driver.
One more thing to add is that I'm not sure that drm_connector is
suitable for managing power
and backlight - I can't find appropriate callback in
drm_connector_funcs to enable power and/or
backlight. Basically there's nothing similar to enable() or disable()
from drm_bridge_funcs.
> I'm not sure if that's enough for eDP panels, though. For example the
> AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> panel. But the driver also specifies a couple of additional delays which
> suggests that either it violates the eDP specification or that the eDP
> specification doesn't define any power sequencing delays that would've
> been needed. Or perhaps these delays are specified somewhere and the
> driver just doesn't use them?
Sigh. We can't foresee any bizarre behavior some hardware may or may
not have. Anyway,
can you propose something that can handle same hardware with different
edp panels via
single software image (u-boot aka firmware is part of software image)
and is acceptable
upstream?
Regards,
Vasily
> Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-14 20:05 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 20:05 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > regulator and/or backlight.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > >
> > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > >
> > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > is faulty on some device.
> > > > > > > >
> > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > and recent batch uses 1080p panel.
> > > > > > > >
> > > > > > > > What panel descriptor should I use as fallback?
> > > > > > >
> > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > correct for the panel you have.
> > > > > > >
> > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > thing as for other devices.
> > > > > > >
> > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > with the correct panel information.
> > > > > >
> > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > doesn't work then we should quirk it there.
> > > > >
> > > > > The problem is that while the attempt may have been to standardize, it
> > > > > failed. It doesn't take into account any of the details such as timing
> > > > > between things like powering up the display and enabling the backlight
> > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > requirements because they are highly panel specific.
> > > >
> > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > the panel with some pessimistic values to figure those out, and you only
> > > > need dp aux to work, which is much simpler than the entire panel).
> > > >
> > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > panel driver which is almost all fake.
> > > > > >
> > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > can get hold of the dp_aux channel it needs.
> > > > >
> > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > use that on some platforms.
> > > > >
> > > > > Also note that simple-panel already supports getting video timings from
> > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > from EDID and use them.
> > > >
> > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > then gives you the ddc link automatically).
> > >
> > > I suppose we could do that. We could introduce a new property that would
> > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > to access DPCD if that's helpful.
> > >
> > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > that would immediately help.
> >
> > You definitely need dp aux to drive edp. That's where a lot of the really
> > important stuff is stored, and it sounds like on non-broken panels even
> > the timings (we've never implemented that on i915 somehow).
>
> I'm not sure I understand what you're saying here. I haven't worked with
> eDP panels in a while, but my recollection is that you can use DP AUX to
> read video timings over EDID. We provide support for that by exporting a
> DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> and then that I2C adapter can be used to read the EDID. I wasn't aware
> that eDP panels additionally stored the video timings somewhere else.
>
> What I meant above was that aside from the I2C-over-AUX for reading the
> EDID, this driver doesn't do anything else with DP AUX in order to turn
> the panel on. Looking at the eDP support we have on Tegra, there's a
> DPCD register (DP_SET_POWER) that needs to be written in order to take
> the sink device (i.e. panel) out of the power saving state. We do that
> as part of the connector implementation rather than within the panel
> driver. There are also additional registers such as DP_LINK_BW_SET that
> need to be programmed. I think this is also relevant to regular DP and
> detailed in the specification.
>
> Given all the above, I'm beginning to think that Rob's right in that
> perhaps we shouldn't be treating eDP panels as panels, but rather to
> make them look more like DP monitors and make all this code part of the
> connector implementation. I think pretty much the only differences to
> regular DP are that we might require some lower-level resources that a
> DP monitor would usually have built-in (reset or power GPIOs, power
> supplies, backlight, ...).
I spent some time poking drm_connector code and I came to conclusion
that it's not a good idea.
Basically edp-connector driver will duplicate simple-panel code and
will bring extra complexity
into bridge driver for no benefit at all.
Also currently there are no stand-alone connector drivers, they all
are part of display controller
driver.
One more thing to add is that I'm not sure that drm_connector is
suitable for managing power
and backlight - I can't find appropriate callback in
drm_connector_funcs to enable power and/or
backlight. Basically there's nothing similar to enable() or disable()
from drm_bridge_funcs.
> I'm not sure if that's enough for eDP panels, though. For example the
> AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> panel. But the driver also specifies a couple of additional delays which
> suggests that either it violates the eDP specification or that the eDP
> specification doesn't define any power sequencing delays that would've
> been needed. Or perhaps these delays are specified somewhere and the
> driver just doesn't use them?
Sigh. We can't foresee any bizarre behavior some hardware may or may
not have. Anyway,
can you propose something that can handle same hardware with different
edp panels via
single software image (u-boot aka firmware is part of software image)
and is acceptable
upstream?
Regards,
Vasily
> Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CA+E=qVcUsz=5s1+RqDdQ4Hm3_Q3jDFuZwuYXUuVx3ubFWmcG7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-14 20:05 ` Vasily Khoruzhick
@ 2019-02-14 20:38 ` Rob Herring
-1 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-14 20:38 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Daniel Vetter, David Airlie, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > > ---
> > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > >
> > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > >
> > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > is faulty on some device.
> > > > > > > > >
> > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > >
> > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > >
> > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > correct for the panel you have.
> > > > > > > >
> > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > thing as for other devices.
> > > > > > > >
> > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > with the correct panel information.
> > > > > > >
> > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > doesn't work then we should quirk it there.
> > > > > >
> > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > between things like powering up the display and enabling the backlight
> > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > requirements because they are highly panel specific.
> > > > >
> > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > >
> > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > panel driver which is almost all fake.
> > > > > > >
> > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > can get hold of the dp_aux channel it needs.
> > > > > >
> > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > use that on some platforms.
> > > > > >
> > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > from EDID and use them.
> > > > >
> > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > then gives you the ddc link automatically).
> > > >
> > > > I suppose we could do that. We could introduce a new property that would
> > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > to access DPCD if that's helpful.
> > > >
> > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > that would immediately help.
> > >
> > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > important stuff is stored, and it sounds like on non-broken panels even
> > > the timings (we've never implemented that on i915 somehow).
> >
> > I'm not sure I understand what you're saying here. I haven't worked with
> > eDP panels in a while, but my recollection is that you can use DP AUX to
> > read video timings over EDID. We provide support for that by exporting a
> > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > that eDP panels additionally stored the video timings somewhere else.
> >
> > What I meant above was that aside from the I2C-over-AUX for reading the
> > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > the panel on. Looking at the eDP support we have on Tegra, there's a
> > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > the sink device (i.e. panel) out of the power saving state. We do that
> > as part of the connector implementation rather than within the panel
> > driver. There are also additional registers such as DP_LINK_BW_SET that
> > need to be programmed. I think this is also relevant to regular DP and
> > detailed in the specification.
> >
> > Given all the above, I'm beginning to think that Rob's right in that
> > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > make them look more like DP monitors and make all this code part of the
> > connector implementation. I think pretty much the only differences to
> > regular DP are that we might require some lower-level resources that a
> > DP monitor would usually have built-in (reset or power GPIOs, power
> > supplies, backlight, ...).
>
> I spent some time poking drm_connector code and I came to conclusion
> that it's not a good idea.
> Basically edp-connector driver will duplicate simple-panel code and
> will bring extra complexity
> into bridge driver for no benefit at all.
I said this on irc, but for everyone's benefit, what's used in the
kernel and the binding don't have to be aligned. I still think
following a connector binding in DT makes sense even if the kernel
implementation is actually a panel driver. Really, there's no
difference in bindings between a connector node and panel node.
> Also currently there are no stand-alone connector drivers, they all
> are part of display controller
> driver.
Probably that is something to be refactored. I think we have lots of cases of:
if (is_connector)
// call connector func
else
// call panel func
Or maybe that was panel vs. bridge (then a connector)? It's been a
while since I looked at this. In any case, each device in the chain
shouldn't really have much knowledge as to what it is attached to.
> One more thing to add is that I'm not sure that drm_connector is
> suitable for managing power
> and backlight - I can't find appropriate callback in
> drm_connector_funcs to enable power and/or
> backlight. Basically there's nothing similar to enable() or disable()
> from drm_bridge_funcs.
Nobody has put the 5V supply on HDMI on a switchable regulator? It may
need to be always on for HPD to work, but I wouldn't expect all board
designers to get that right.
> > I'm not sure if that's enough for eDP panels, though. For example the
> > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > panel. But the driver also specifies a couple of additional delays which
> > suggests that either it violates the eDP specification or that the eDP
> > specification doesn't define any power sequencing delays that would've
> > been needed. Or perhaps these delays are specified somewhere and the
> > driver just doesn't use them?
>
> Sigh. We can't foresee any bizarre behavior some hardware may or may
> not have.
Bingo! You just summed up why we have specific compatibles.
> Anyway,
> can you propose something that can handle same hardware with different
> edp panels via
> single software image (u-boot aka firmware is part of software image)
> and is acceptable
> upstream?
compatible = "vendor,some-panel", "edp-connector";
Either you have to fixup the first string for the actual panel or have
some testing up front that you don't need to. The kernel can start
with only using the fallback string and if panel constraints turn out
to be specified sufficiently, we'll never need to use the panel
compatible.
Rob
^ permalink raw reply [flat|nested] 176+ messages in thread* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-14 20:38 ` Rob Herring
0 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-14 20:38 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > > > ---
> > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > >
> > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > >
> > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > is faulty on some device.
> > > > > > > > >
> > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > >
> > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > >
> > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > correct for the panel you have.
> > > > > > > >
> > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > thing as for other devices.
> > > > > > > >
> > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > with the correct panel information.
> > > > > > >
> > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > doesn't work then we should quirk it there.
> > > > > >
> > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > between things like powering up the display and enabling the backlight
> > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > requirements because they are highly panel specific.
> > > > >
> > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > >
> > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > panel driver which is almost all fake.
> > > > > > >
> > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > can get hold of the dp_aux channel it needs.
> > > > > >
> > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > use that on some platforms.
> > > > > >
> > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > from EDID and use them.
> > > > >
> > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > then gives you the ddc link automatically).
> > > >
> > > > I suppose we could do that. We could introduce a new property that would
> > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > to access DPCD if that's helpful.
> > > >
> > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > that would immediately help.
> > >
> > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > important stuff is stored, and it sounds like on non-broken panels even
> > > the timings (we've never implemented that on i915 somehow).
> >
> > I'm not sure I understand what you're saying here. I haven't worked with
> > eDP panels in a while, but my recollection is that you can use DP AUX to
> > read video timings over EDID. We provide support for that by exporting a
> > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > that eDP panels additionally stored the video timings somewhere else.
> >
> > What I meant above was that aside from the I2C-over-AUX for reading the
> > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > the panel on. Looking at the eDP support we have on Tegra, there's a
> > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > the sink device (i.e. panel) out of the power saving state. We do that
> > as part of the connector implementation rather than within the panel
> > driver. There are also additional registers such as DP_LINK_BW_SET that
> > need to be programmed. I think this is also relevant to regular DP and
> > detailed in the specification.
> >
> > Given all the above, I'm beginning to think that Rob's right in that
> > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > make them look more like DP monitors and make all this code part of the
> > connector implementation. I think pretty much the only differences to
> > regular DP are that we might require some lower-level resources that a
> > DP monitor would usually have built-in (reset or power GPIOs, power
> > supplies, backlight, ...).
>
> I spent some time poking drm_connector code and I came to conclusion
> that it's not a good idea.
> Basically edp-connector driver will duplicate simple-panel code and
> will bring extra complexity
> into bridge driver for no benefit at all.
I said this on irc, but for everyone's benefit, what's used in the
kernel and the binding don't have to be aligned. I still think
following a connector binding in DT makes sense even if the kernel
implementation is actually a panel driver. Really, there's no
difference in bindings between a connector node and panel node.
> Also currently there are no stand-alone connector drivers, they all
> are part of display controller
> driver.
Probably that is something to be refactored. I think we have lots of cases of:
if (is_connector)
// call connector func
else
// call panel func
Or maybe that was panel vs. bridge (then a connector)? It's been a
while since I looked at this. In any case, each device in the chain
shouldn't really have much knowledge as to what it is attached to.
> One more thing to add is that I'm not sure that drm_connector is
> suitable for managing power
> and backlight - I can't find appropriate callback in
> drm_connector_funcs to enable power and/or
> backlight. Basically there's nothing similar to enable() or disable()
> from drm_bridge_funcs.
Nobody has put the 5V supply on HDMI on a switchable regulator? It may
need to be always on for HPD to work, but I wouldn't expect all board
designers to get that right.
> > I'm not sure if that's enough for eDP panels, though. For example the
> > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > panel. But the driver also specifies a couple of additional delays which
> > suggests that either it violates the eDP specification or that the eDP
> > specification doesn't define any power sequencing delays that would've
> > been needed. Or perhaps these delays are specified somewhere and the
> > driver just doesn't use them?
>
> Sigh. We can't foresee any bizarre behavior some hardware may or may
> not have.
Bingo! You just summed up why we have specific compatibles.
> Anyway,
> can you propose something that can handle same hardware with different
> edp panels via
> single software image (u-boot aka firmware is part of software image)
> and is acceptable
> upstream?
compatible = "vendor,some-panel", "edp-connector";
Either you have to fixup the first string for the actual panel or have
some testing up front that you don't need to. The kernel can start
with only using the fallback string and if panel constraints turn out
to be specified sufficiently, we'll never need to use the panel
compatible.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread[parent not found: <CAL_JsqKQ0EmyYGYvz__ZZGN7_6jLezevHWc+psn82Uy6hWZXMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-14 20:38 ` Rob Herring
@ 2019-02-14 20:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 20:54 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, Daniel Vetter, David Airlie, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Thu, Feb 14, 2019 at 12:38 PM Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > > > ---
> > > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > > >
> > > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > > >
> > > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > > is faulty on some device.
> > > > > > > > > >
> > > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > > >
> > > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > > >
> > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > > correct for the panel you have.
> > > > > > > > >
> > > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > > thing as for other devices.
> > > > > > > > >
> > > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > > with the correct panel information.
> > > > > > > >
> > > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > > doesn't work then we should quirk it there.
> > > > > > >
> > > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > > between things like powering up the display and enabling the backlight
> > > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > > requirements because they are highly panel specific.
> > > > > >
> > > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > > >
> > > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > > panel driver which is almost all fake.
> > > > > > > >
> > > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > > can get hold of the dp_aux channel it needs.
> > > > > > >
> > > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > > use that on some platforms.
> > > > > > >
> > > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > > from EDID and use them.
> > > > > >
> > > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > > then gives you the ddc link automatically).
> > > > >
> > > > > I suppose we could do that. We could introduce a new property that would
> > > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > > to access DPCD if that's helpful.
> > > > >
> > > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > > that would immediately help.
> > > >
> > > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > > important stuff is stored, and it sounds like on non-broken panels even
> > > > the timings (we've never implemented that on i915 somehow).
> > >
> > > I'm not sure I understand what you're saying here. I haven't worked with
> > > eDP panels in a while, but my recollection is that you can use DP AUX to
> > > read video timings over EDID. We provide support for that by exporting a
> > > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > > that eDP panels additionally stored the video timings somewhere else.
> > >
> > > What I meant above was that aside from the I2C-over-AUX for reading the
> > > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > > the panel on. Looking at the eDP support we have on Tegra, there's a
> > > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > > the sink device (i.e. panel) out of the power saving state. We do that
> > > as part of the connector implementation rather than within the panel
> > > driver. There are also additional registers such as DP_LINK_BW_SET that
> > > need to be programmed. I think this is also relevant to regular DP and
> > > detailed in the specification.
> > >
> > > Given all the above, I'm beginning to think that Rob's right in that
> > > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > > make them look more like DP monitors and make all this code part of the
> > > connector implementation. I think pretty much the only differences to
> > > regular DP are that we might require some lower-level resources that a
> > > DP monitor would usually have built-in (reset or power GPIOs, power
> > > supplies, backlight, ...).
> >
> > I spent some time poking drm_connector code and I came to conclusion
> > that it's not a good idea.
> > Basically edp-connector driver will duplicate simple-panel code and
> > will bring extra complexity
> > into bridge driver for no benefit at all.
>
> I said this on irc, but for everyone's benefit, what's used in the
> kernel and the binding don't have to be aligned. I still think
> following a connector binding in DT makes sense even if the kernel
> implementation is actually a panel driver. Really, there's no
> difference in bindings between a connector node and panel node.
>
> > Also currently there are no stand-alone connector drivers, they all
> > are part of display controller
> > driver.
>
> Probably that is something to be refactored. I think we have lots of cases of:
>
> if (is_connector)
> // call connector func
> else
> // call panel func
>
> Or maybe that was panel vs. bridge (then a connector)? It's been a
> while since I looked at this. In any case, each device in the chain
> shouldn't really have much knowledge as to what it is attached to.
>
> > One more thing to add is that I'm not sure that drm_connector is
> > suitable for managing power
> > and backlight - I can't find appropriate callback in
> > drm_connector_funcs to enable power and/or
> > backlight. Basically there's nothing similar to enable() or disable()
> > from drm_bridge_funcs.
>
> Nobody has put the 5V supply on HDMI on a switchable regulator? It may
> need to be always on for HPD to work, but I wouldn't expect all board
> designers to get that right.
>
> > > I'm not sure if that's enough for eDP panels, though. For example the
> > > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > > panel. But the driver also specifies a couple of additional delays which
> > > suggests that either it violates the eDP specification or that the eDP
> > > specification doesn't define any power sequencing delays that would've
> > > been needed. Or perhaps these delays are specified somewhere and the
> > > driver just doesn't use them?
> >
> > Sigh. We can't foresee any bizarre behavior some hardware may or may
> > not have.
>
> Bingo! You just summed up why we have specific compatibles.
>
> > Anyway,
> > can you propose something that can handle same hardware with different
> > edp panels via
> > single software image (u-boot aka firmware is part of software image)
> > and is acceptable
> > upstream?
>
> compatible = "vendor,some-panel", "edp-connector";
>
> Either you have to fixup the first string for the actual panel or have
> some testing up front that you don't need to.
Where do I take actual panel compatible from?
> The kernel can start
> with only using the fallback string and if panel constraints turn out
> to be specified sufficiently, we'll never need to use the panel
> compatible.
So what panel compatible you want me to use if vendor used at least 3
different panels?
Introduce 2 more dts files (3 in total) even if they all work just
fine with a single dts now?
Add one more dts once laptop vendor decides to change panel vendor?
>
> Rob
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-14 20:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-14 20:54 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Thu, Feb 14, 2019 at 12:38 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> >
> > On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote:
> > > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > > > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > > > > > > > regulator and/or backlight.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > > > > > > > 1 file changed, 7 insertions(+)
> > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > > > > > > > >
> > > > > > > > > > > Please don't try to make panels look more generic than they really are.
> > > > > > > > > > > You're going to have to provide a compatible string for your device that
> > > > > > > > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > > > > > > > extra information that is panel specific, but you don't know that now.
> > > > > > > > > > > We have in the past thought that we didn't need things like prepare
> > > > > > > > > > > delay, but then we ran into situations where we did need them.
> > > > > > > > > > >
> > > > > > > > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > > > > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > > > > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > > > > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > > > > > > > is faulty on some device.
> > > > > > > > > >
> > > > > > > > > > Pinebook used several 768p panels that have slightly different timings
> > > > > > > > > > and recent batch uses 1080p panel.
> > > > > > > > > >
> > > > > > > > > > What panel descriptor should I use as fallback?
> > > > > > > > >
> > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver
> > > > > > > > > will bind to a panel device and use the corresponding descriptor. If
> > > > > > > > > your device tree contains the correct information, the descriptor is
> > > > > > > > > correct for the panel you have.
> > > > > > > > >
> > > > > > > > > In other words you need to ensure that you have the correct panel in
> > > > > > > > > device tree for the board that you're using. This is exactly the same
> > > > > > > > > thing as for other devices.
> > > > > > > > >
> > > > > > > > > One way to to this is to have separate device trees for each variant
> > > > > > > > > of the board that you want to support. Another variant may be to have
> > > > > > > > > a common device tree and then have some early firmware update the DTB
> > > > > > > > > with the correct panel information.
> > > > > > > >
> > > > > > > > This would defeat the point of edp, which is to standardize the mess of
> > > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI
> > > > > > > > tables/firmware for every board you ship. Also, we do have DP quirking
> > > > > > > > infrastructure already (using the OUI), I think if there's something that
> > > > > > > > doesn't work then we should quirk it there.
> > > > > > >
> > > > > > > The problem is that while the attempt may have been to standardize, it
> > > > > > > failed. It doesn't take into account any of the details such as timing
> > > > > > > between things like powering up the display and enabling the backlight
> > > > > > > or similar. I don't know how you'd want to "quirk" those kinds of
> > > > > > > requirements because they are highly panel specific.
> > > > > >
> > > > > > Hm right, we get these from some firmware tables (and mix them with the
> > > > > > spec one, since some of the firmware values are nonsense). I don't even
> > > > > > know whether we can read the timings over dp aux somehow (you can power up
> > > > > > the panel with some pessimistic values to figure those out, and you only
> > > > > > need dp aux to work, which is much simpler than the entire panel).
> > > > > >
> > > > > > > > What does make sense though imo is if we try not to stuff the edp panel
> > > > > > > > into panel-simple, because it's anything like a simple dumb panel. There's
> > > > > > > > also some integration awkwardness since with this panel you need to do dp
> > > > > > > > aux/i2c transactions to get at the information (edid alone isn't good
> > > > > > > > enough for edp), and I'm not sure how exactly that's supposed to be
> > > > > > > > instantiated. Maybe a special function to instantiate an edp panel, which
> > > > > > > > takes both a DT node and the dp_aux controller would be much better,
> > > > > > > > instead of trying to auto-match against a DT compatible string and load a
> > > > > > > > panel driver which is almost all fake.
> > > > > > > >
> > > > > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it
> > > > > > > > can get hold of the dp_aux channel it needs.
> > > > > > >
> > > > > > > We already do that. drm_dp_aux registers as an I2C adapter that can be
> > > > > > > used to read EDID EEPROMs using I2C-over-AUX transactions. We already
> > > > > > > use that on some platforms.
> > > > > > >
> > > > > > > Also note that simple-panel already supports getting video timings from
> > > > > > > EDID. If a DDC link is present in DT, the driver will load the modes
> > > > > > > from EDID and use them.
> > > > > >
> > > > > > Could we extend this to dp aux somehow? For edp you need the dp aux (which
> > > > > > then gives you the ddc link automatically).
> > > > >
> > > > > I suppose we could do that. We could introduce a new property that would
> > > > > allow the panel driver to get at the struct drm_dp_aux that can access
> > > > > the panel. I'm not sure how much that would buy us. I suppose the driver
> > > > > could go and use that drm_dp_aux to do I2C-over-AUX and ignore any
> > > > > ddc-bus property in device tree. A drm_dp_aux object could also be used
> > > > > to access DPCD if that's helpful.
> > > > >
> > > > > The driver proposed here doesn't need access to DPCD, so I'm not sure
> > > > > that would immediately help.
> > > >
> > > > You definitely need dp aux to drive edp. That's where a lot of the really
> > > > important stuff is stored, and it sounds like on non-broken panels even
> > > > the timings (we've never implemented that on i915 somehow).
> > >
> > > I'm not sure I understand what you're saying here. I haven't worked with
> > > eDP panels in a while, but my recollection is that you can use DP AUX to
> > > read video timings over EDID. We provide support for that by exporting a
> > > DP AUX controller as I2C adapter (i.e. register with the I2C subsystem)
> > > and then that I2C adapter can be used to read the EDID. I wasn't aware
> > > that eDP panels additionally stored the video timings somewhere else.
> > >
> > > What I meant above was that aside from the I2C-over-AUX for reading the
> > > EDID, this driver doesn't do anything else with DP AUX in order to turn
> > > the panel on. Looking at the eDP support we have on Tegra, there's a
> > > DPCD register (DP_SET_POWER) that needs to be written in order to take
> > > the sink device (i.e. panel) out of the power saving state. We do that
> > > as part of the connector implementation rather than within the panel
> > > driver. There are also additional registers such as DP_LINK_BW_SET that
> > > need to be programmed. I think this is also relevant to regular DP and
> > > detailed in the specification.
> > >
> > > Given all the above, I'm beginning to think that Rob's right in that
> > > perhaps we shouldn't be treating eDP panels as panels, but rather to
> > > make them look more like DP monitors and make all this code part of the
> > > connector implementation. I think pretty much the only differences to
> > > regular DP are that we might require some lower-level resources that a
> > > DP monitor would usually have built-in (reset or power GPIOs, power
> > > supplies, backlight, ...).
> >
> > I spent some time poking drm_connector code and I came to conclusion
> > that it's not a good idea.
> > Basically edp-connector driver will duplicate simple-panel code and
> > will bring extra complexity
> > into bridge driver for no benefit at all.
>
> I said this on irc, but for everyone's benefit, what's used in the
> kernel and the binding don't have to be aligned. I still think
> following a connector binding in DT makes sense even if the kernel
> implementation is actually a panel driver. Really, there's no
> difference in bindings between a connector node and panel node.
>
> > Also currently there are no stand-alone connector drivers, they all
> > are part of display controller
> > driver.
>
> Probably that is something to be refactored. I think we have lots of cases of:
>
> if (is_connector)
> // call connector func
> else
> // call panel func
>
> Or maybe that was panel vs. bridge (then a connector)? It's been a
> while since I looked at this. In any case, each device in the chain
> shouldn't really have much knowledge as to what it is attached to.
>
> > One more thing to add is that I'm not sure that drm_connector is
> > suitable for managing power
> > and backlight - I can't find appropriate callback in
> > drm_connector_funcs to enable power and/or
> > backlight. Basically there's nothing similar to enable() or disable()
> > from drm_bridge_funcs.
>
> Nobody has put the 5V supply on HDMI on a switchable regulator? It may
> need to be always on for HPD to work, but I wouldn't expect all board
> designers to get that right.
>
> > > I'm not sure if that's enough for eDP panels, though. For example the
> > > AUO B133HTN01 panel, used by the exynos5800-peach-pi, seems to be an eDP
> > > panel. But the driver also specifies a couple of additional delays which
> > > suggests that either it violates the eDP specification or that the eDP
> > > specification doesn't define any power sequencing delays that would've
> > > been needed. Or perhaps these delays are specified somewhere and the
> > > driver just doesn't use them?
> >
> > Sigh. We can't foresee any bizarre behavior some hardware may or may
> > not have.
>
> Bingo! You just summed up why we have specific compatibles.
>
> > Anyway,
> > can you propose something that can handle same hardware with different
> > edp panels via
> > single software image (u-boot aka firmware is part of software image)
> > and is acceptable
> > upstream?
>
> compatible = "vendor,some-panel", "edp-connector";
>
> Either you have to fixup the first string for the actual panel or have
> some testing up front that you don't need to.
Where do I take actual panel compatible from?
> The kernel can start
> with only using the fallback string and if panel constraints turn out
> to be specified sufficiently, we'll never need to use the panel
> compatible.
So what panel compatible you want me to use if vendor used at least 3
different panels?
Introduce 2 more dts files (3 in total) even if they all work just
fine with a single dts now?
Add one more dts once laptop vendor decides to change panel vendor?
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 8:23 ` Thierry Reding
@ 2019-02-04 16:11 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 16:11 UTC (permalink / raw)
To: Thierry Reding
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
That defeats the purpose of using eDP panels. Panel can identify
itself and report what timings it supports.
If we use separate DTBs then users will have to figure out what panel
is installed in their hardware and use appropriate software image -
that's something I'd like to avoid.
I can add a descriptor for something like "pinebook eDP panel" if it
works for you, but it won't have any display timings in it.
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:11 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 16:11 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
That defeats the purpose of using eDP panels. Panel can identify
itself and report what timings it supports.
If we use separate DTBs then users will have to figure out what panel
is installed in their hardware and use appropriate software image -
that's something I'd like to avoid.
I can add a descriptor for something like "pinebook eDP panel" if it
works for you, but it won't have any display timings in it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CA+E=qVew+8__yrAud1gFnLQ8HCwDdGhVjV=c173HGvZxH=7zZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:11 ` Vasily Khoruzhick
@ 2019-02-04 16:27 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:27 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On Mon, Feb 04, 2019 at 08:11:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.
>
> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.
>
> I can add a descriptor for something like "pinebook eDP panel" if it
> works for you, but it won't have any display timings in it.
I'd like to point you to this:
http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
it addresses some of your questions. Hopefully that will also help you
understand that this isn't only about display timings.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:27 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:27 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 1762 bytes --]
On Mon, Feb 04, 2019 at 08:11:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.
>
> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.
>
> I can add a descriptor for something like "pinebook eDP panel" if it
> works for you, but it won't have any display timings in it.
I'd like to point you to this:
http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
it addresses some of your questions. Hopefully that will also help you
understand that this isn't only about display timings.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:11 ` Vasily Khoruzhick
@ 2019-02-04 16:39 ` Rob Herring
-1 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 16:39 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, David Airlie, linux-sunxi, dri-devel,
Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Sean Paul,
Laurent Pinchart, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.
If you are confident that this works for all panels, then the firmware
can identify the right panel and update the DTB with the correct
information. If this doesn't work in the firmware, then it is not
going to work in the kernel either and you are SOL without specific
panel information in the DT.
> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.
I think Thierry meant either way this is a firmware problem. If you
have a SKU per device and panel type, then the firmware just picks a
dtb among a set.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:39 ` Rob Herring
0 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 16:39 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That defeats the purpose of using eDP panels. Panel can identify
> itself and report what timings it supports.
If you are confident that this works for all panels, then the firmware
can identify the right panel and update the DTB with the correct
information. If this doesn't work in the firmware, then it is not
going to work in the kernel either and you are SOL without specific
panel information in the DT.
> If we use separate DTBs then users will have to figure out what panel
> is installed in their hardware and use appropriate software image -
> that's something I'd like to avoid.
I think Thierry meant either way this is a firmware problem. If you
have a SKU per device and panel type, then the firmware just picks a
dtb among a set.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CAL_JsqLAODca_U94hCi9O3E6XiUjAYCoL7_0gkf_eMY0nnT8Ag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:39 ` Rob Herring
@ 2019-02-04 17:02 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 17:02 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, David Airlie, Daniel Vetter, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Mon, Feb 4, 2019 at 8:39 AM Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > That defeats the purpose of using eDP panels. Panel can identify
> > itself and report what timings it supports.
>
> If you are confident that this works for all panels, then the firmware
> can identify the right panel and update the DTB with the correct
> information. If this doesn't work in the firmware, then it is not
> going to work in the kernel either and you are SOL without specific
> panel information in the DT.
"firmware" is u-boot and on this platform it sits on the same physical
media as OS (it's either microsd or eMMC).
I guess u-boot can fill in timings for kernel, but I don't see much
point in it. If u-boot can't read EDID then same is true
for kernel.
> > If we use separate DTBs then users will have to figure out what panel
> > is installed in their hardware and use appropriate software image -
> > that's something I'd like to avoid.
>
> I think Thierry meant either way this is a firmware problem. If you
> have a SKU per device and panel type, then the firmware just picks a
> dtb among a set.
Unfortunately it's one SKU per multiple panels.
> Rob
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 17:02 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 17:02 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 8:39 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> >
> > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > That defeats the purpose of using eDP panels. Panel can identify
> > itself and report what timings it supports.
>
> If you are confident that this works for all panels, then the firmware
> can identify the right panel and update the DTB with the correct
> information. If this doesn't work in the firmware, then it is not
> going to work in the kernel either and you are SOL without specific
> panel information in the DT.
"firmware" is u-boot and on this platform it sits on the same physical
media as OS (it's either microsd or eMMC).
I guess u-boot can fill in timings for kernel, but I don't see much
point in it. If u-boot can't read EDID then same is true
for kernel.
> > If we use separate DTBs then users will have to figure out what panel
> > is installed in their hardware and use appropriate software image -
> > that's something I'd like to avoid.
>
> I think Thierry meant either way this is a firmware problem. If you
> have a SKU per device and panel type, then the firmware just picks a
> dtb among a set.
Unfortunately it's one SKU per multiple panels.
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 8:23 ` Thierry Reding
@ 2019-02-04 16:27 ` Rob Herring
-1 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 16:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, David Airlie, linux-sunxi, dri-devel,
Vasily Khoruzhick, Maxime Ripard, Chen-Yu Tsai, Sean Paul,
Laurent Pinchart, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > width/height or any modes/timings in dts. But this panel still may have
> > > > regulator and/or backlight.
> > > >
> > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > ---
> > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > >
> > > Please don't try to make panels look more generic than they really are.
> > > You're going to have to provide a compatible string for your device that
> > > is more specific than "panel-edp". You claim that you don't need any
> > > extra information that is panel specific, but you don't know that now.
> > > We have in the past thought that we didn't need things like prepare
> > > delay, but then we ran into situations where we did need them.
> > >
> > > Just do what everybody else does. Provide a specific compatible string
> > > and match on that in the panel-simple driver. Even if you can read all
> > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > is faulty on some device.
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
That can be a pain to manage especially if panels are swapped run to
run with 2nd sources.
I think it is perfectly fine to have a generic-ish fallback as long as
it is just that, a fallback. If the panel has quirks, then you'd
better make sure the firmware is stuffing in the right compatibles or
that you can update the firmware.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:27 ` Rob Herring
0 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 16:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Sean Paul, Laurent Pinchart, Daniel Vetter,
arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > width/height or any modes/timings in dts. But this panel still may have
> > > > regulator and/or backlight.
> > > >
> > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > ---
> > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > >
> > > Please don't try to make panels look more generic than they really are.
> > > You're going to have to provide a compatible string for your device that
> > > is more specific than "panel-edp". You claim that you don't need any
> > > extra information that is panel specific, but you don't know that now.
> > > We have in the past thought that we didn't need things like prepare
> > > delay, but then we ran into situations where we did need them.
> > >
> > > Just do what everybody else does. Provide a specific compatible string
> > > and match on that in the panel-simple driver. Even if you can read all
> > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > is faulty on some device.
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel driver
> will bind to a panel device and use the corresponding descriptor. If
> your device tree contains the correct information, the descriptor is
> correct for the panel you have.
>
> In other words you need to ensure that you have the correct panel in
> device tree for the board that you're using. This is exactly the same
> thing as for other devices.
>
> One way to to this is to have separate device trees for each variant
> of the board that you want to support. Another variant may be to have
> a common device tree and then have some early firmware update the DTB
> with the correct panel information.
That can be a pain to manage especially if panels are swapped run to
run with 2nd sources.
I think it is perfectly fine to have a generic-ish fallback as long as
it is just that, a fallback. If the panel has quirks, then you'd
better make sure the firmware is stuffing in the right compatibles or
that you can update the firmware.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CAL_JsqKt1kOXmRNvkYsQ6AL69+TPZURKpDbKkkEUb2+KZ5hKjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:27 ` Rob Herring
@ 2019-02-04 16:56 ` Thierry Reding
-1 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:56 UTC (permalink / raw)
To: Rob Herring
Cc: Vasily Khoruzhick, David Airlie, Daniel Vetter, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 4286 bytes --]
On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > regulator and/or backlight.
> > > > >
> > > > > Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > ---
> > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > >
> > > > Please don't try to make panels look more generic than they really are.
> > > > You're going to have to provide a compatible string for your device that
> > > > is more specific than "panel-edp". You claim that you don't need any
> > > > extra information that is panel specific, but you don't know that now.
> > > > We have in the past thought that we didn't need things like prepare
> > > > delay, but then we ran into situations where we did need them.
> > > >
> > > > Just do what everybody else does. Provide a specific compatible string
> > > > and match on that in the panel-simple driver. Even if you can read all
> > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > is faulty on some device.
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That can be a pain to manage especially if panels are swapped run to
> run with 2nd sources.
>
> I think it is perfectly fine to have a generic-ish fallback as long as
> it is just that, a fallback. If the panel has quirks, then you'd
> better make sure the firmware is stuffing in the right compatibles or
> that you can update the firmware.
simple-panel would probably work if you stuck in some mostly compatible
string and provided a ddc-i2c-bus property in the device tree node. The
generic-ish fallback case could be implemented by providing a fallback
compatible string (we used to have "simple-panel", which I think would
still be adequate for this I suppose) and adding a dummy descriptor in
the driver, perhaps one with pre-defined delays that could be adjusted
to work for all cases, or they could just be 0. At least that way we'd
be explicitly documenting that we support this as a fallback.
I'm not sure how you'd want to enforce that people provide the right
compatible strings that way. Currently there's no way to make your panel
work without adding a panel driver, so people are forced to write the
DT bindings and a driver, or add support to an existing one. If we open
this backdoor, I suspect many people will just take the easy route and
rely on the fallback. And then what do we do when we get bug reports
about panels not working, or requiring some quirks. How do we go and
find out what the right compatible strings are for each board, or how to
fix things for something we don't have access to.
This all sounds like a Pandora's box to me.
Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 16:56 ` Thierry Reding
0 siblings, 0 replies; 176+ messages in thread
From: Thierry Reding @ 2019-02-04 16:56 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Sean Paul, Laurent Pinchart, Daniel Vetter,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 4276 bytes --]
On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > regulator and/or backlight.
> > > > >
> > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > ---
> > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > >
> > > > Please don't try to make panels look more generic than they really are.
> > > > You're going to have to provide a compatible string for your device that
> > > > is more specific than "panel-edp". You claim that you don't need any
> > > > extra information that is panel specific, but you don't know that now.
> > > > We have in the past thought that we didn't need things like prepare
> > > > delay, but then we ran into situations where we did need them.
> > > >
> > > > Just do what everybody else does. Provide a specific compatible string
> > > > and match on that in the panel-simple driver. Even if you can read all
> > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > is faulty on some device.
> > >
> > > Pinebook used several 768p panels that have slightly different timings
> > > and recent batch uses 1080p panel.
> > >
> > > What panel descriptor should I use as fallback?
> >
> > You don't use panel descriptors as fallback. The simple-panel driver
> > will bind to a panel device and use the corresponding descriptor. If
> > your device tree contains the correct information, the descriptor is
> > correct for the panel you have.
> >
> > In other words you need to ensure that you have the correct panel in
> > device tree for the board that you're using. This is exactly the same
> > thing as for other devices.
> >
> > One way to to this is to have separate device trees for each variant
> > of the board that you want to support. Another variant may be to have
> > a common device tree and then have some early firmware update the DTB
> > with the correct panel information.
>
> That can be a pain to manage especially if panels are swapped run to
> run with 2nd sources.
>
> I think it is perfectly fine to have a generic-ish fallback as long as
> it is just that, a fallback. If the panel has quirks, then you'd
> better make sure the firmware is stuffing in the right compatibles or
> that you can update the firmware.
simple-panel would probably work if you stuck in some mostly compatible
string and provided a ddc-i2c-bus property in the device tree node. The
generic-ish fallback case could be implemented by providing a fallback
compatible string (we used to have "simple-panel", which I think would
still be adequate for this I suppose) and adding a dummy descriptor in
the driver, perhaps one with pre-defined delays that could be adjusted
to work for all cases, or they could just be 0. At least that way we'd
be explicitly documenting that we support this as a fallback.
I'm not sure how you'd want to enforce that people provide the right
compatible strings that way. Currently there's no way to make your panel
work without adding a panel driver, so people are forced to write the
DT bindings and a driver, or add support to an existing one. If we open
this backdoor, I suspect many people will just take the easy route and
rely on the fallback. And then what do we do when we get bug reports
about panels not working, or requiring some quirks. How do we go and
find out what the right compatible strings are for each board, or how to
fix things for something we don't have access to.
This all sounds like a Pandora's box to me.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:56 ` Thierry Reding
@ 2019-02-04 17:07 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 17:07 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, David Airlie, Daniel Vetter, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.
>
> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.
>
> This all sounds like a Pandora's box to me.
OK, just give me an option that will work on this platform with a
single software image (keep in mind that u-boot aka "firmware" is part
of this image) and that is acceptable for upstream and I'll try to
implement it.
> Thierry
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 17:07 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 17:07 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.
>
> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.
>
> This all sounds like a Pandora's box to me.
OK, just give me an option that will work on this platform with a
single software image (keep in mind that u-boot aka "firmware" is part
of this image) and that is acceptable for upstream and I'll try to
implement it.
> Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 16:56 ` Thierry Reding
@ 2019-02-04 20:23 ` Rob Herring
-1 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 20:23 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, David Airlie, linux-sunxi, dri-devel,
Vasily Khoruzhick, Maxime Ripard, Chen-Yu Tsai, Sean Paul,
Laurent Pinchart, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 10:56 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> > On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > ---
> > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really are.
> > > > > You're going to have to provide a compatible string for your device that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > That can be a pain to manage especially if panels are swapped run to
> > run with 2nd sources.
> >
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.
I'd like something more specific than 'simple-panel' that at least
implies it has EDID and whatever else we think it should imply.
Looking into this a bit more, why don't we just do a connector here?
eDP has a standard connector (with power). It's just like other
connectors, but with power and no hotplug. If someone does their own
interface, then they should do their own connector or panel binding.
> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.
We'll simply reject anything that should be implied by compatible. And
now we can enforce with schema that DTs aren't populated with
fallbacks alone. Of course, we can't make anyone pass all schema
checks before shipping a dtb.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 20:23 ` Rob Herring
0 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 20:23 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Sean Paul, Laurent Pinchart, Daniel Vetter,
arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 10:56 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote:
> > On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote:
> > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > >
> > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote:
> > > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel
> > > > > > width/height or any modes/timings in dts. But this panel still may have
> > > > > > regulator and/or backlight.
> > > > > >
> > > > > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > > > > ---
> > > > > > .../devicetree/bindings/display/panel/panel-edp.txt | 7 +++++++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.txt
> > > > >
> > > > > Please don't try to make panels look more generic than they really are.
> > > > > You're going to have to provide a compatible string for your device that
> > > > > is more specific than "panel-edp". You claim that you don't need any
> > > > > extra information that is panel specific, but you don't know that now.
> > > > > We have in the past thought that we didn't need things like prepare
> > > > > delay, but then we ran into situations where we did need them.
> > > > >
> > > > > Just do what everybody else does. Provide a specific compatible string
> > > > > and match on that in the panel-simple driver. Even if you can read all
> > > > > the video timings from an EDID EEPROM, you can still provide a mode in
> > > > > the panel descriptor to serve as a fallback if for example the EEPROM
> > > > > is faulty on some device.
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses 1080p panel.
> > > >
> > > > What panel descriptor should I use as fallback?
> > >
> > > You don't use panel descriptors as fallback. The simple-panel driver
> > > will bind to a panel device and use the corresponding descriptor. If
> > > your device tree contains the correct information, the descriptor is
> > > correct for the panel you have.
> > >
> > > In other words you need to ensure that you have the correct panel in
> > > device tree for the board that you're using. This is exactly the same
> > > thing as for other devices.
> > >
> > > One way to to this is to have separate device trees for each variant
> > > of the board that you want to support. Another variant may be to have
> > > a common device tree and then have some early firmware update the DTB
> > > with the correct panel information.
> >
> > That can be a pain to manage especially if panels are swapped run to
> > run with 2nd sources.
> >
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update the firmware.
>
> simple-panel would probably work if you stuck in some mostly compatible
> string and provided a ddc-i2c-bus property in the device tree node. The
> generic-ish fallback case could be implemented by providing a fallback
> compatible string (we used to have "simple-panel", which I think would
> still be adequate for this I suppose) and adding a dummy descriptor in
> the driver, perhaps one with pre-defined delays that could be adjusted
> to work for all cases, or they could just be 0. At least that way we'd
> be explicitly documenting that we support this as a fallback.
I'd like something more specific than 'simple-panel' that at least
implies it has EDID and whatever else we think it should imply.
Looking into this a bit more, why don't we just do a connector here?
eDP has a standard connector (with power). It's just like other
connectors, but with power and no hotplug. If someone does their own
interface, then they should do their own connector or panel binding.
> I'm not sure how you'd want to enforce that people provide the right
> compatible strings that way. Currently there's no way to make your panel
> work without adding a panel driver, so people are forced to write the
> DT bindings and a driver, or add support to an existing one. If we open
> this backdoor, I suspect many people will just take the easy route and
> rely on the fallback. And then what do we do when we get bug reports
> about panels not working, or requiring some quirks. How do we go and
> find out what the right compatible strings are for each board, or how to
> fix things for something we don't have access to.
We'll simply reject anything that should be implied by compatible. And
now we can enforce with schema that DTs aren't populated with
fallbacks alone. Of course, we can't make anyone pass all schema
checks before shipping a dtb.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
[parent not found: <CAL_JsqJx98DfHZSafiXA8QiO=bn1zy8g6keQ15L=cUmbVkTTOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 20:23 ` Rob Herring
@ 2019-02-04 20:26 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 20:26 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, David Airlie, Daniel Vetter, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Archit Taneja, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, dri-devel,
devicetree, arm-linux, linux-sunxi
On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > simple-panel would probably work if you stuck in some mostly compatible
> > string and provided a ddc-i2c-bus property in the device tree node. The
> > generic-ish fallback case could be implemented by providing a fallback
> > compatible string (we used to have "simple-panel", which I think would
> > still be adequate for this I suppose) and adding a dummy descriptor in
> > the driver, perhaps one with pre-defined delays that could be adjusted
> > to work for all cases, or they could just be 0. At least that way we'd
> > be explicitly documenting that we support this as a fallback.
>
> I'd like something more specific than 'simple-panel' that at least
> implies it has EDID and whatever else we think it should imply.
>
> Looking into this a bit more, why don't we just do a connector here?
> eDP has a standard connector (with power). It's just like other
> connectors, but with power and no hotplug. If someone does their own
> interface, then they should do their own connector or panel binding.
Where do we put backlight in this case?
> > I'm not sure how you'd want to enforce that people provide the right
> > compatible strings that way. Currently there's no way to make your panel
> > work without adding a panel driver, so people are forced to write the
> > DT bindings and a driver, or add support to an existing one. If we open
> > this backdoor, I suspect many people will just take the easy route and
> > rely on the fallback. And then what do we do when we get bug reports
> > about panels not working, or requiring some quirks. How do we go and
> > find out what the right compatible strings are for each board, or how to
> > fix things for something we don't have access to.
>
> We'll simply reject anything that should be implied by compatible. And
> now we can enforce with schema that DTs aren't populated with
> fallbacks alone. Of course, we can't make anyone pass all schema
> checks before shipping a dtb.
>
> Rob
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 20:26 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-04 20:26 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh+dt@kernel.org> wrote:
> > simple-panel would probably work if you stuck in some mostly compatible
> > string and provided a ddc-i2c-bus property in the device tree node. The
> > generic-ish fallback case could be implemented by providing a fallback
> > compatible string (we used to have "simple-panel", which I think would
> > still be adequate for this I suppose) and adding a dummy descriptor in
> > the driver, perhaps one with pre-defined delays that could be adjusted
> > to work for all cases, or they could just be 0. At least that way we'd
> > be explicitly documenting that we support this as a fallback.
>
> I'd like something more specific than 'simple-panel' that at least
> implies it has EDID and whatever else we think it should imply.
>
> Looking into this a bit more, why don't we just do a connector here?
> eDP has a standard connector (with power). It's just like other
> connectors, but with power and no hotplug. If someone does their own
> interface, then they should do their own connector or panel binding.
Where do we put backlight in this case?
> > I'm not sure how you'd want to enforce that people provide the right
> > compatible strings that way. Currently there's no way to make your panel
> > work without adding a panel driver, so people are forced to write the
> > DT bindings and a driver, or add support to an existing one. If we open
> > this backdoor, I suspect many people will just take the easy route and
> > rely on the fallback. And then what do we do when we get bug reports
> > about panels not working, or requiring some quirks. How do we go and
> > find out what the right compatible strings are for each board, or how to
> > fix things for something we don't have access to.
>
> We'll simply reject anything that should be implied by compatible. And
> now we can enforce with schema that DTs aren't populated with
> fallbacks alone. Of course, we can't make anyone pass all schema
> checks before shipping a dtb.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
2019-02-04 20:26 ` Vasily Khoruzhick
@ 2019-02-04 20:34 ` Rob Herring
-1 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 20:34 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, David Airlie, linux-sunxi, dri-devel,
Maxime Ripard, Chen-Yu Tsai, Thierry Reding, Sean Paul,
Laurent Pinchart, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 2:26 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > > simple-panel would probably work if you stuck in some mostly compatible
> > > string and provided a ddc-i2c-bus property in the device tree node. The
> > > generic-ish fallback case could be implemented by providing a fallback
> > > compatible string (we used to have "simple-panel", which I think would
> > > still be adequate for this I suppose) and adding a dummy descriptor in
> > > the driver, perhaps one with pre-defined delays that could be adjusted
> > > to work for all cases, or they could just be 0. At least that way we'd
> > > be explicitly documenting that we support this as a fallback.
> >
> > I'd like something more specific than 'simple-panel' that at least
> > implies it has EDID and whatever else we think it should imply.
> >
> > Looking into this a bit more, why don't we just do a connector here?
> > eDP has a standard connector (with power). It's just like other
> > connectors, but with power and no hotplug. If someone does their own
> > interface, then they should do their own connector or panel binding.
>
> Where do we put backlight in this case?
In the connector node. You'd need a backlight supply,
'backlight-enable-gpios' and backlight phandle to pwm-backlight node.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 176+ messages in thread
* Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
@ 2019-02-04 20:34 ` Rob Herring
0 siblings, 0 replies; 176+ messages in thread
From: Rob Herring @ 2019-02-04 20:34 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Archit Taneja, Andrzej Hajda,
David Airlie, linux-sunxi, dri-devel, Maxime Ripard,
Chen-Yu Tsai, Thierry Reding, Sean Paul, Laurent Pinchart,
Daniel Vetter, arm-linux, Icenowy Zheng
On Mon, Feb 4, 2019 at 2:26 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Mon, Feb 4, 2019 at 12:23 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > > simple-panel would probably work if you stuck in some mostly compatible
> > > string and provided a ddc-i2c-bus property in the device tree node. The
> > > generic-ish fallback case could be implemented by providing a fallback
> > > compatible string (we used to have "simple-panel", which I think would
> > > still be adequate for this I suppose) and adding a dummy descriptor in
> > > the driver, perhaps one with pre-defined delays that could be adjusted
> > > to work for all cases, or they could just be 0. At least that way we'd
> > > be explicitly documenting that we support this as a fallback.
> >
> > I'd like something more specific than 'simple-panel' that at least
> > implies it has EDID and whatever else we think it should imply.
> >
> > Looking into this a bit more, why don't we just do a connector here?
> > eDP has a standard connector (with power). It's just like other
> > connectors, but with power and no hotplug. If someone does their own
> > interface, then they should do their own connector or panel binding.
>
> Where do we put backlight in this case?
In the connector node. You'd need a backlight supply,
'backlight-enable-gpios' and backlight phandle to pwm-backlight node.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 09/12] drm/panel: simple: add generic eDP panel
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
eDP panels usually have EDID EEPROM, so there's no need to define panel
width/height or any modes/timings in dts. But this panel still has
regulator and backlight.
Add compatible for generic eDP panel so such kind of panel can be
defined in dts.
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 2f2cb2d81f2b..9698f5819930 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2759,6 +2759,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "winstar,wf35ltiacd",
.data = &winstar_wf35ltiacd,
+ }, {
+ .compatible = "panel-edp",
+ .data = NULL,
}, {
/* sentinel */
}
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 09/12] drm/panel: simple: add generic eDP panel
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
eDP panels usually have EDID EEPROM, so there's no need to define panel
width/height or any modes/timings in dts. But this panel still has
regulator and backlight.
Add compatible for generic eDP panel so such kind of panel can be
defined in dts.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 2f2cb2d81f2b..9698f5819930 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2759,6 +2759,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "winstar,wf35ltiacd",
.data = &winstar_wf35ltiacd,
+ }, {
+ .compatible = "panel-edp",
+ .data = NULL,
}, {
/* sentinel */
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 10/12] arm64: allwinner: a64: add pinmux for RGB666 LCD
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:54 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Allwinner A64's TCON0 can output RGB666 LCD signal.
Add its pinmux.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 837a03dee875..4fc3ca5fa53e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -559,6 +559,15 @@
function = "i2c1";
};
+ lcd_rgb666_pins: lcd-rgb666 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD6", "PD7", "PD8", "PD9",
+ "PD10", "PD11", "PD12", "PD13",
+ "PD14", "PD15", "PD16", "PD17",
+ "PD18", "PD19", "PD20", "PD21";
+ function = "lcd0";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 10/12] arm64: allwinner: a64: add pinmux for RGB666 LCD
@ 2019-02-03 18:54 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:54 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
Allwinner A64's TCON0 can output RGB666 LCD signal.
Add its pinmux.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 837a03dee875..4fc3ca5fa53e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -559,6 +559,15 @@
function = "i2c1";
};
+ lcd_rgb666_pins: lcd-rgb666 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD6", "PD7", "PD8", "PD9",
+ "PD10", "PD11", "PD12", "PD13",
+ "PD14", "PD15", "PD16", "PD17",
+ "PD18", "PD19", "PD20", "PD21";
+ function = "lcd0";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 11/12] arm64: allwinner: a64: enable LCD-related hardware for Pinebook
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:55 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:55 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Pinebook has an ANX6345 bridge connected to the RGB666 LCD output and
eDP panel input. The bridge is controlled via I2C that's connected to
R_I2C bus.
Enable all this hardware in device tree.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../dts/allwinner/sun50i-a64-pinebook.dts | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index d22736a62481..49f5d4b0c7f4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -63,6 +63,18 @@
};
};
+ edp_panel: edp-panel {
+ compatible = "panel-edp", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <®_dc1sw>;
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out_panel>;
+ };
+ };
+ };
+
reg_vcc3v3: vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -102,6 +114,10 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
phys = <&usbphy 0>;
phy-names = "usb";
@@ -112,6 +128,10 @@
status = "okay";
};
+&mixer0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
@@ -163,6 +183,46 @@
status = "okay";
};
+&r_i2c {
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_i2c_pins_a>;
+ status = "okay";
+
+ anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_fldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
&r_rsb {
status = "okay";
@@ -334,6 +394,20 @@
"MIC2", "Internal Microphone Right";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_anx6345: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&anx6345_in_tcon0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 11/12] arm64: allwinner: a64: enable LCD-related hardware for Pinebook
@ 2019-02-03 18:55 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:55 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
Pinebook has an ANX6345 bridge connected to the RGB666 LCD output and
eDP panel input. The bridge is controlled via I2C that's connected to
R_I2C bus.
Enable all this hardware in device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
.../dts/allwinner/sun50i-a64-pinebook.dts | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index d22736a62481..49f5d4b0c7f4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -63,6 +63,18 @@
};
};
+ edp_panel: edp-panel {
+ compatible = "panel-edp", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <®_dc1sw>;
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out_panel>;
+ };
+ };
+ };
+
reg_vcc3v3: vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -102,6 +114,10 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
phys = <&usbphy 0>;
phy-names = "usb";
@@ -112,6 +128,10 @@
status = "okay";
};
+&mixer0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
@@ -163,6 +183,46 @@
status = "okay";
};
+&r_i2c {
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_i2c_pins_a>;
+ status = "okay";
+
+ anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_fldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
&r_rsb {
status = "okay";
@@ -334,6 +394,20 @@
"MIC2", "Internal Microphone Right";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_anx6345: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&anx6345_in_tcon0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread
* [PATCH RESEND v2 12/12] arm64: allwinner: a64: enable LCD-related hardware for TERES-I
2019-02-03 18:54 ` Vasily Khoruzhick
@ 2019-02-03 18:55 ` Vasily Khoruzhick
-1 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:55 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Vasily Khoruzhick
From: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
TERES-I has an ANX6345 bridge connected to the RGB666 LCD output and
eDP panel input. The bridge is controlled via I2C that's connected to
I2C0 bus.
Enable all this hardware in device tree.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Signed-off-by: Vasily Khoruzhick <anarsoul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../boot/dts/allwinner/sun50i-a64-teres-i.dts | 71 +++++++++++++++++--
1 file changed, 67 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index c455b24dd079..6c4090f59bed 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -56,6 +56,17 @@
};
};
+ edp_panel: edp-panel {
+ compatible = "panel-edp", "simple-panel";
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out_panel>;
+ };
+ };
+ };
+
+
reg_usb1_vbus: usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -72,20 +83,58 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
-/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
- * driver for this chip at the moment, the bootloader initializes it.
- * However it can be accessed with the i2c-dev driver from user space.
- */
&i2c0 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
+
+ anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -258,6 +307,20 @@
vcc-hdmi-supply = <®_dldo1>;
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_anx6345: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&anx6345_in_tcon0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.20.1
^ permalink raw reply related [flat|nested] 176+ messages in thread* [PATCH RESEND v2 12/12] arm64: allwinner: a64: enable LCD-related hardware for TERES-I
@ 2019-02-03 18:55 ` Vasily Khoruzhick
0 siblings, 0 replies; 176+ messages in thread
From: Vasily Khoruzhick @ 2019-02-03 18:55 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Thierry Reding, Maxime Ripard, Chen-Yu Tsai, Archit Taneja,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi
From: Icenowy Zheng <icenowy@aosc.io>
TERES-I has an ANX6345 bridge connected to the RGB666 LCD output and
eDP panel input. The bridge is controlled via I2C that's connected to
I2C0 bus.
Enable all this hardware in device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
.../boot/dts/allwinner/sun50i-a64-teres-i.dts | 71 +++++++++++++++++--
1 file changed, 67 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index c455b24dd079..6c4090f59bed 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -56,6 +56,17 @@
};
};
+ edp_panel: edp-panel {
+ compatible = "panel-edp", "simple-panel";
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out_panel>;
+ };
+ };
+ };
+
+
reg_usb1_vbus: usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -72,20 +83,58 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
-/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
- * driver for this chip at the moment, the bootloader initializes it.
- * However it can be accessed with the i2c-dev driver from user space.
- */
&i2c0 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
+
+ anx6345: anx6345@38 {
+ compatible = "analogix,anx6345";
+ reg = <0x38>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ anx6345_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ anx6345_in_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+
+ anx6345_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ anx6345_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -258,6 +307,20 @@
vcc-hdmi-supply = <®_dldo1>;
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_anx6345: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&anx6345_in_tcon0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 176+ messages in thread